Wiki · Concept · Last reviewed June 25, 2026

MCP Completion

MCP completion is the Model Context Protocol server utility for offering autocompletion suggestions while users fill in prompt arguments or resource-template arguments.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Completion, AI Agents, UX, Information Disclosure

Definition

MCP completion is a server utility in the Model Context Protocol. The 2025-11-25 specification defines it as a standardized way for servers to provide autocompletion suggestions for the arguments of MCP prompts and resource templates. A user might begin typing a language, project, file path, framework, customer, or other argument value, and the server can return contextual suggestions.

The utility is deliberately about argument selection, not model generation. It helps a client build an interactive interface around server-defined prompts and resources. The specification compares the intended experience to IDE-style completion but does not require a particular user interface; clients may use dropdowns, search boxes, command palettes, or any pattern that fits the host application.

How It Works

A server that supports this utility declares the completions capability during MCP initialization. The lifecycle specification lists completions as a server capability for argument autocompletion, and normal operation is supposed to respect the capabilities negotiated at startup.

Clients request suggestions with completion/complete. The request identifies what is being completed through a reference object and includes the current argument name and partial value. The completion page defines two reference types: ref/prompt, which references a prompt by name, and ref/resource, which references a resource URI. For prompts or URI templates with multiple arguments, the request can include prior argument choices in context.arguments so the server can narrow later suggestions.

Completion connects directly to the prompt and resource-template pages. The prompts specification notes that prompt arguments may be completed through the completion API. The resources specification says the same for resource-template arguments. In practice, completion is the small hinge between a reusable template and a usable picker.

Result Shape

A completion result contains a completion object. Its values array carries the suggestion strings and is capped at 100 items per response. The result may also include total, an optional count of available matches, and hasMore, a boolean indicating whether additional results exist.

The specification's implementation guidance says servers should return suggestions sorted by relevance, implement fuzzy matching where appropriate, rate limit completion requests, and validate inputs. Clients should debounce rapid requests, cache completion results where appropriate, and handle missing or partial results gracefully. Error handling uses standard JSON-RPC errors, including method-not-found when the capability is unsupported, invalid-params for invalid prompt names or missing required arguments, and internal-error for server failures.

Governance Requirements

A governed deployment should treat completion as a data-exposure surface. Logs should preserve the server identity, referenced prompt name or resource URI, argument name, partial value sent by the client, returned suggestion count, whether hasMore was true, user or role, timestamp, client, and access-control decision. For sensitive domains, the log should also record whether suggestions were filtered by tenant, project, clearance, jurisdiction, or consent status.

The completion box should not reveal data the user could not otherwise discover. A search-like suggestion list can leak customer names, case identifiers, private repositories, file names, internal project codenames, or forbidden categories even when the user never reads the underlying resource. That makes completion governance closer to search-result governance than ordinary UI polish.

Failure Modes

Suggestion leakage. The server returns names or identifiers that confirm the existence of restricted records.

Context laundering. Previous argument choices in context.arguments narrow results in a way that bypasses the access-control checks that would apply to a final read or prompt retrieval.

Autocomplete authority. A client visually privileges the first suggestion, causing users to treat server ranking as policy, truth, or recommendation.

Request flooding. Rapid typing produces many completion calls, exposing partial user intent and increasing server load unless clients debounce and servers rate limit.

Source Discipline

Claims about MCP completion should cite the versioned completion specification and distinguish completion from prompts, resources, and tools. Capability claims should cite the lifecycle page. Security claims should cite the completion page's explicit requirements to validate inputs, rate limit, control access to sensitive suggestions, and prevent completion-based information disclosure.

Spiralist Reading

MCP completion looks minor because it is only a suggestion list. That is exactly why it matters. Interfaces often govern action before anyone notices policy has entered the room.

The Spiralist reading is that autocomplete is soft power. It narrows imagination, reveals what the system thinks is available, and invites the user to choose from a menu the server prepared. The ethical question is whether that menu is accurate, authorized, auditable, and honest about what it omits.

Open Questions

Sources

Return to Wiki