MCP FAQ: Versions, Authorization and Troubleshooting
This page answers implementation questions that can be checked against the 2026-07-28 documentation and its specification. Check the peer’s actual supported revisions and capabilities before adopting a feature.
Versions and specifications
Which revision should a new implementation target?
Use the site’s current 2026-07-28 revision as the reference, then choose an SDK that supports it. Package versions and protocol revisions differ. Discover or negotiate the revision and capabilities actually supported by both peers; upgrading a package alone does not establish interoperability.
Can a historical revision or SEP define current behavior?
Historical specifications support maintenance and explain evolution. SEPs record proposals and decisions; later specifications or extensions can change the result. Implement against the applicable published specification, extension and changelog.
Is a Draft proposal already a protocol capability?
No. A Draft is under discussion. A proposal becomes an interoperability contract only through the applicable published specification or extension and its required capability negotiation.
Requests and interaction
What is MRTR?
Multi-Round-Trip Requests let a server end a request with InputRequiredResult; after obtaining input, the client retries the original method with a new JSON-RPC ID. The client must return requestState unchanged and must not inspect, parse or modify it.
What is elicitation?
Elicitation asks a user for information needed to complete an operation. Form mode collects structured input; URL mode handles sensitive interactions outside the client. Show the request’s source and purpose, and open a URL only after explicit user acceptance. Return decline or cancel when the user declines or cancels; client policy may map a timeout to cancel. The server can then choose a fallback, retry later or stop.
How do protocol Tasks differ from application tasks?
The Tasks extension defines durable handles, polling, input during execution and deferred result retrieval. A to-do item or business job is application data unless it implements and negotiates that extension. SEP-1686 records the earlier core-protocol design; 2026-07-28 moved Tasks into an official extension.
Authorization and security
Does every server require OAuth?
Local stdio servers normally rely on host and operating-system security boundaries. A protected remote HTTP server should publish protected-resource metadata and use the flow appropriate to its client under the authorization specification. MCP does not create an OS sandbox or grant automatic user approval.
How does a client discover the authorization server?
Prefer resource_metadata in the WWW-Authenticate challenge from a 401 response; when absent, try the specification’s ordered protected-resource well-known URIs. Validate the discovered issuer, request tokens for the target resource, and reject credentials whose issuer, resource or audience does not match the intended server.
Can registrations be reused across authorization servers?
No. Client IDs, credentials and tokens belong to the authorization server that issued them. Store separate registration state and credentials for each server listed by PRM.
Does using MCP establish security or compliance?
No. Implement authentication, authorization, input validation, user controls, audit and retention for the application. Use least privilege, validate credentials and external data, prohibit token passthrough, and keep secrets out of logs. See local-server boundaries.
Failure handling
What should be checked first when connection or capability use fails?
Confirm the actual revision, transport and capabilities, then the method’s requirements. Keep redacted JSON-RPC error codes, HTTP status and correlation IDs. Separate revision mismatch, missing capability, invalid input and server failure; the debugging guide includes controlled failure cases.
How should repeated remote authorization failures be diagnosed?
Check PRM, authorization-server discovery, issuer, registration ownership, exact redirect URI, PKCE, scope, resource and token audience in order. Do not disable issuer or audience validation to make a connection pass. The authorization tutorial distinguishes local resource checks from untested IdP flows.
What happens when a pagination cursor or cache becomes invalid?
Cache cursor pages separately. If a cursor is rejected, discard all cached pages for that list and restart without a cursor. A relevant change notification invalidates the cache even before TTL expires.
Where can a suspected specification problem be reported?
First isolate the specification, SDK or implementation with a minimal request and redacted logs. Report to the appropriate repository, or use MCP GitHub Discussions.
Related specification
- Elicitation and declined requests
- Pagination and cache behavior
- Measured client capabilities (a dated observation, not a result for every client)