Model Context Protocol LLM: Tools, Not Prompts

Model Context Protocol LLM support means the model runs inside a client that can discover tools on an MCP server and call them mid-turn. The protocol is just the handshake and the JSON. The win is that the LLM receives a named result (a file, a query row, a UI element) instead of another pasted paragraph.

Most explainers stop at what is an MCP server. Fine as a definition. This post is what changes when the consumer is an LLM on your Mac, with a concrete local example. The spec-level tour is Model Context Protocol.

What does model context protocol llm actually mean?

Three roles.

Host / client. Claude Code, Cursor, Codex, Zed, or a custom loop. This is where the LLM lives. It holds the conversation and decides to call a tool.

Server. A local or remote process that exposes tools, resources, sometimes prompts. MCP server examples shows the zoo.

Model. The weights. They do not speak MCP by themselves. The client translates tool calls to the model's function-calling API and back.

If someone says "this LLM supports MCP," they mean the product around the LLM does. The checkpoint does not open a socket.

Why not just paste more into the prompt?

You can. People did. That is how we got 20-page system prompts and desktop screenshots.

Tool results are better for three reasons.

Schema. The client can show a tool name and typed fields. The model is less likely to invent a path.

On demand. The LLM fetches when it needs a capture, not at turn zero.

Locality. A server on 127.0.0.1 can see your AX tree without putting the whole desktop in the first user message.

The failure mode is the same as prompt stuffing if the tool returns a novel. A directory dump is a paste with extra steps. Demand small, named payloads.

A local Mac example the docs skip

You want the LLM to fix a button. The button is on screen. The file is somewhere in src/.

Without MCP: screenshot plus "the green one." The model context protocol LLM still guesses.

With a screen-context server: you circle and speak. The server hit-tests with AXUIElementCopyElementAtPosition. It returns role, label, frame, confidence, circled-versus-dwelled, per-mark words, a crop, focused-window text up to 40,000 characters, optional OCR, the AXWebArea URL.

The LLM now has an identity. It can search the repo for "Save changes" or click the frame if you really want computer use.

PinVari ships that server at ~/.pinvari/mcp/pinvari-mcp. Connect from the app, or:

claude mcp add --scope user pinvari -- "$HOME/.pinvari/mcp/pinvari-mcp"

The app must be running. The connector talks to 127.0.0.1:3402. Docs: pinvari.com/mcp.

Tools the LLM actually calls: pinvari_next_instruction, pinvari_get_capture, pinvari_list_captures, pinvari_get_frame, pinvari_request_capture, pinvari_mark_done, pinvari_health.

pinvari_request_capture is the interesting one for a model context protocol LLM. The model can ask you to point. The notch island lights up. You mark. The result returns on the same socket. That is a human tool the protocol did not invent, and it beats autonomous clicking.

What a good tool result looks like to the LLM

Identity. AXButton, "Export CSV", frame, parent chain.

Uncertainty. Confidence 0.74, provenance dwelled. The client should teach the model to ask, never silently guess, under about 0.8.

Instruction. "Disable this when the table is empty." Deixis already bound.

Evidence. A crop, not a 5K wallpaper.

Honesty. ocr_fallback: true when AX was empty. Chromium may need AXManualAccessibility and a 150ms retry. Bare AXGroup should descend to a labeled child.

If your model context protocol LLM integration strips those fields to "save tokens," you stripped the reason you used MCP.

Client differences that bite

Claude Code. First-class MCP. User-scope add with an explicit binary path. Restart the session after config changes.

Cursor. ~/.cursor/mcp.json or project .cursor/mcp.json. Quit the app to reload. Agent mode must have the server enabled.

Codex CLI. Local, if you register the stdio binary. The hosted Codex app may not see 127.0.0.1.

Zed. Similar local config. Confirm tools in its agent panel.

A raw OpenAI or Anthropic SDK app. You must implement the MCP client. The LLM API only has function calling. You are the protocol.

Pick one host and get one server green before you collect a dozen.

What MCP does not do for an LLM

It does not give the model your screen by default. You still grant Accessibility and Screen Recording to the Mac app behind the server.

It does not keep secrets out of the prompt. Tool results go to the vendor unless you run a local model.

It does not replace tests. A named button is not a passing spec.

It does not make a 7B local model wise. It makes that model aimed. Pair with Ollama or MLX if you want weights on-device; keep the server local either way.

How I would teach a team

Hour 1: define client, server, model. Draw the socket on a whiteboard. No tools yet.

Hour 2: add a health tool. Prove a green dot.

Hour 3: one capture. Prove the LLM prints the AX name, not a guess.

Hour 4: disable extra servers. Measure how much quieter the context window feels.

Ship the capture app as a one-time license if you do not want to write overlays. macOS 14+, Apple Silicon and Intel, notarized DMG. Transcription and OCR on-device. You bring the model context protocol LLM host.

Pause and scroll (Option-Command-P) when a page is long. Multi-display marks remember the monitor. Sessions recover after a crash. Command Center groups by app.

That is the whole story: protocol, local server, named element, model you already pay for.

How should a model context protocol LLM host handle errors?

Surface them as tool results, not as silent retries the user never sees.

If the Mac app is quit, pinvari_health should say so. The model should tell you to open it, not invent an element.

If Accessibility is denied, the result should say empty AX, not "the Submit button" from a prior turn.

If confidence is low, the host should prefer pinvari_request_capture over a second autonomous guess.

That is protocol hygiene. JSON-RPC errors are useless if the client swallows them and the LLM smiles.

Fail loud in the tool result so the model can ask you a real question.

Log the tool name and a 200-character preview of the result in the terminal. When a session goes wrong, you will want that more than a vibe.

What belongs in an MCP tool schema for an LLM?

A short name, a one-line description, and required fields that are identities, not essays.

element_role, confidence, instruction beat notes every time. The model context protocol LLM will fill a free-text field with poetry.

Add an enum for provenance. Circled versus dwelled changes how hard the model should trust the hit. Leave room for ocr_fallback. Hide secrets from the result preview.

FAQ

Does the model need special training for Model Context Protocol?

No. It needs function calling, which every current coding model has. The client maps MCP tools to those functions. Training on MCP JSON is optional sugar.

Is model context protocol llm the same as retrieval-augmented generation?

RAG stuffs documents into the prompt or a vector store. MCP lets the model call a tool when it wants a fact. You can build RAG behind an MCP tool. They are not synonyms.

Can I use MCP with a local LLM only?

Yes. The host must implement the client and point at Ollama or MLX. The server does not care which weights sit in the host.

Why does my LLM ignore the MCP tool?

Too many tools, a vague user prompt, or a server that failed the handshake. Reduce the tool list. Ask for the tool by name. Check the panel for a green dot and a real schema.

What port does a local PinVari MCP server use?

The connector talks to the app on 127.0.0.1:3402. The stdio binary is $HOME/.pinvari/mcp/pinvari-mcp. Both require the app running.

Should every LLM product implement MCP?

If it is a coding agent on a real machine, yes, or an equivalent function-calling bridge. If it is a consumer chat box with no local tools, a protocol badge is decoration.