MCP completion is the protocol’s answer to a small but real annoyance: you’re filling in an argument for a prompt template or picking a resource by its URI, and you have no idea what values are actually valid. The completion/complete request lets a client ask a server “here’s what I’ve typed so far — what are you expecting?” and get back a short, ranked list of suggestions, the same idea as a dropdown that narrows as you type in an IDE. It is one of the quieter primitives in MCP’s tools, resources, and prompts model, and it’s worth knowing what it does and doesn’t cover — because the thing most people assume it does, autocompleting a tool call, is exactly the part it skips.
What completion actually autocompletes
Completion applies to two things: prompt arguments and resource template URIs. A prompt in MCP is a reusable template a server exposes — think “summarize this ticket in tone X” with atone parameter — and completion is how a client can offer suggested values for that parameter instead of asking a person to guess or type freely. A resource template is a parameterized URI, like file:///{path} or repo://{owner}/{name}, and completion is how a server can suggest which paths or repo names actually exist as the value gets typed.
It does not apply to tool call arguments. That distinction matters more than it looks. Prompts and resources in MCP are largely user- or client-controlled — a person or a UI is picking a prompt template or browsing resources, so a dropdown of valid values is a genuine interface improvement. Tools are model-controlled — the model itself decides what arguments to pass based on the tool’s schema and description, not a person typing into a field. There’s no autocomplete step in that flow, because there’s no human filling anything in for a tool call to autocomplete. If a tool needs a constrained value, that constraint belongs in its input schema as an enum, not in a completion request nobody will send.
How the request and response actually look
A server that wants to offer suggestions declares it up front, in its initialize response: "capabilities": { "completions": {} }. From there, the client sends a completion/complete request with three pieces: a reference to what’s being completed — either ref/prompt (a prompt by name) or ref/resource (a resource URI) — an argument object naming which parameter is being typed and its current partial value, and optionally a context of other argument values already resolved earlier in the same form, so a server can offer suggestions that depend on more than one field at once.
The server responds with a small object: a values array of suggested strings (capped at 100 per response), an optional total giving the full count of matches if there are more than what’s returned, and a hasMore boolean flagging that the list was truncated. Nothing here is exotic — it’s the same shape as any search-as-you-type endpoint, just standardized so every MCP client can drive it the same way against every server that supports it.
What the spec expects from each side
The guidance on both ends is ordinary API-design common sense, which is exactly why it is easy to skip. Servers are expected to rate-limit completion requests, validate the partial input rather than trusting it blindly, sort suggestions by relevance, and use fuzzy matching rather than a strict prefix match so a slightly-off guess still surfaces the right value. Clients are expected to debounce rapid keystrokes rather than firing a request per character, cache results where it makes sense, and handle a truncated list gracefully instead of assuming values is exhaustive.
The same section that defines the happy path also calls out the failure mode plainly: a completion endpoint that echoes back whatever a user is typing, unvalidated, into a server-side query is a way to leak data the requester shouldn’t see or to open an injection path in whatever backend the suggestions come from — a search-as-you-type box on a normal web app has exactly the same risk, and the fix is the same too: treat the partial argument as untrusted input, not as a value already cleared for use.
Why almost no server bothers
Completion is optional, and most MCP servers don’t implement it, for a fairly mundane reason: most servers expose tools, not prompts or resource templates, and completion has nothing to offer a tool-only server. Even servers that do expose prompts or resources often just ship them without a completions capability, because the payoff — a nicer typing experience for a human filling in a form — is a smaller win than the tool-calling half of MCP that the model drives directly. It’s the same pattern we’ve seen with sampling and roots: real primitives in the spec, genuinely useful for the narrow case they were built for, and adopted by a small slice of servers because most tool-first servers simply don’t have that case.
If you’re generating a server from an existing API with a tool like gate’s MCP server builder, this is one more primitive an OpenAPI spec doesn’t carry over automatically — a conversion tool maps endpoints to tools, and deciding whether any of those also deserve a prompt template or a resource with autocompletable values is a separate, deliberate step on top of the generated surface, not something the conversion infers on its own. For most APIs, the practical path is still the plain tool surface covered in turning an API into an MCP server.
The bottom line
MCP completion is argument autocomplete for prompt templates and resource URIs — a narrow, genuinely useful feature for the cases where a person is typing a value by hand. It doesn’t touch tool calls, which stay entirely between the model and the tool’s own schema. Most servers skip it because most servers are tool-first and have nothing for it to complete, and that’s fine — it’s an optional capability, not a gap you need to work around. See gate’s MCP server directory for what today’s servers actually implement.