MCP Logging and Completion Utilities

Core idea: MCP utilities can improve developer visibility and argument entry, but they are optional capabilities—not substitutes for service observability or authorization.

Two smaller MCP features solve different interface problems. Logging lets a server emit severity-labelled diagnostic notifications on a request stream. Completion lets a client ask a server for contextual suggestions while a user fills a prompt argument or resource-template value. Understanding their boundaries prevents useful conveniences from becoming data leaks or architectural dependencies.

TL;DR

• Servers advertise logging or completions before clients use them.
• Protocol logs are request-scoped diagnostics and must never contain secrets.
• The current specification recommends ordinary stderr or external telemetry for new logging implementations.
• Completion suggests bounded argument values; it does not execute a prompt or authorize access.
• Suggestions must be filtered to what the current user is permitted to see.

Protocol logging

A logging-capable server can send notifications/message entries with standard severity levels and an optional logger name. A request can include a desired minimum level in metadata, and the server may emit messages at or above that threshold on the corresponding response stream.

This can help a development client display “index scan started,” “downstream request timed out,” or other diagnostic context alongside an active operation. It is not a durable audit log. Delivery depends on the request stream, and user interfaces may suppress or summarize messages.

Log data must not contain credentials, tokens, or sensitive information. Apply redaction and access controls. Treat server-provided logs as untrusted display content: escape them, limit size and rate, and never let a message masquerade as host policy or user approval.

Current logging direction

The current specification marks protocol logging as eligible for removal and recommends stderr for local servers or external logging systems for managed services. This aligns operational telemetry with ordinary service practice: structured logs, metrics, traces, retention, search, and incident controls.

Existing systems may still implement protocol notifications for interactive diagnostics. Do not make production monitoring depend on them. Use a correlation ID to connect safe user-facing messages with protected backend telemetry.

Completion

Completion supports interfaces where a user enters a prompt argument or resource-template value. The client sends completion/complete with a reference to the prompt or resource, the argument name, the partial value, and—when relevant—previously resolved arguments. The server returns bounded suggestions.

Suppose a resource template represents repo://{owner}/{name}. After the user chooses an owner and starts typing a repository name, the server can suggest repositories within that owner. Context from the first argument makes the second list relevant.

Completion improves discoverability but does not prove permission. The server must filter results using the current verified identity and tenant. It should avoid returning hidden resource names, personal data, secrets, or an unbounded directory listing.

Capability negotiation

Both utilities are optional. A server advertises support, and a client must handle absence gracefully. Cache suggestions only with a freshness and identity policy because authorization and available values can change. Validate reference type, argument name, schema, result count, and size.

Clients should debounce requests while the user types and cancel stale work. Servers should return quickly, rank relevant suggestions, and apply rate limits. Completion should not trigger side effects. If producing suggestions requires an expensive scan, build an index or use a separate search interaction rather than blocking every keystroke.

A combined example

A deployment prompt asks for an environment and service. Completion suggests only environments the user can access, then only services in the chosen environment. When the final deployment tool runs, backend telemetry records the policy decision and downstream calls. The user interface may show one safe status message, while sensitive diagnostic details remain in protected logs.

The suggestion does not grant deployment rights. Execution rechecks permissions because discovery, completion, and action are separate stages.

Common mistakes

• Sending secrets or entire payloads through protocol logs.
• Using interactive notifications as the only incident record.
• Returning completion values from another tenant.
• Triggering writes while generating suggestions.
• Caching suggestions across identities.
• Assuming an advertised value is authorized forever.
• Building new logging infrastructure without considering the feature's current status.

My Take

Utilities should make the interface clearer without becoming hidden control planes. Completion is valuable when it narrows a legitimate user choice. Logging is valuable when it explains active work. Authorization, audit, and observability still belong in deterministic systems designed for those responsibilities.

Sources

• Model Context Protocol specification (2026-07-28): Logging
• Model Context Protocol specification (2026-07-28): Completion