MCP specification gap analysis

This is the living register of meaningful differences between this project and the upstream Model Context Protocol (MCP) specification.

It is not a failure list. A missing MCP feature is acceptable when the decision is explicit. An undocumented difference is not acceptable.

Review this document whenever:

• the MCP specification changes;
• @modelcontextprotocol/sdk is upgraded;
• this server adds or removes MCP capabilities, transports, tools, resources, signing modes or authentication;
• public documentation claims support for a specific MCP specification version.

Current baseline

Item	Current value
Last reviewed against MCP spec	2025-06-18
Upstream spec source	https://modelcontextprotocol.io/specification/2025-06-18
MCP SDK package	@modelcontextprotocol/sdk
SDK version at review	1.29.0
SDK latest protocol version at review	2025-11-25
SDK supported versions at review	2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05, 2024-10-07
Project transports	stdio; stateless Streamable HTTP POST /mcp
Project capabilities	tools; resource templates
Project non-goal	full MCP feature coverage

Priority meanings

Priority	Meaning
Now	Should be fixed before making stronger MCP-version or transport-conformance claims. Usually a mandatory spec/security requirement or a low-cost correction.
Next	Should be addressed in the next protocol/transport hardening pass, but does not block the current read-only public documentation if accurately disclosed.
Later	Valid optional feature or polish; implement only when it provides project value.
Won't implement	Deliberately out of scope for this project unless the product direction changes.
Monitor	Inherited SDK behavior or spec/SDK drift that should be rechecked on upgrades.

Implementation scope statement

The precise public wording for the current state is:

This server uses the Model Context Protocol TypeScript SDK and supports MCP clients negotiating protocol version 2025-06-18 for its implemented tools and resource-template features.

Do not claim full MCP conformance, certification or complete Streamable HTTP support unless the Now items below have been resolved and this register has been reviewed again.

Gap register

Area	MCP specification concern	Current status	Difference intentional?	Priority	Decision	Reason	Action
Streamable HTTP security	Servers implementing Streamable HTTP MUST validate the Origin header to mitigate DNS rebinding.	src/app.ts constructs StreamableHTTPServerTransport without DNS rebinding / allowedOrigins configuration. A request with Origin: https://evil.example was accepted during audit.	No. This is an inherited SDK option that the app did not configure.	Now	Implement configurable Origin/host validation for HTTP deployments.	This is a mandatory transport security requirement and there is no project-specific reason to omit it. Public hosted and self-hosted HTTP deployments need an explicit posture.	Add env/deployment configuration for allowed origins/hosts or enable the SDK's DNS rebinding protection where appropriate; document defaults and tests.
JSON-RPC batching	MCP 2025-06-18 removed support for JSON-RPC batching.	The SDK transport accepts an HTTP request body that is a JSON array. A batched initialize request returned 200 during audit.	No. This is inherited SDK behavior.	Now	Reject JSON-RPC batch arrays at the app boundary for this server when claiming 2025-06-18 compatibility.	The project does not need batching, and accepting it conflicts with the reviewed specification version.	Add Express middleware or transport guard before handleRequest; test that array bodies return a JSON-RPC/HTTP error.
HTTP lifecycle	Initialization MUST be the first interaction.	In stateless HTTP mode a direct tools/list request without prior initialize succeeded, because each POST builds a fresh server/transport and no session state is kept.	Partly. Stateless HTTP was chosen for simple public read-only hosting, but the lifecycle consequence was not fully documented before this register.	Next	Decide between stateful Streamable HTTP sessions and accurately documented stateless compatibility mode.	Enforcing lifecycle strictly may require server-side session state or a different transport construction pattern. This needs a design pass to avoid breaking common clients.	Evaluate StreamableHTTPServerTransport stateful mode, session storage, /readyz behavior, client compatibility and deployment cost.
HTTP protocol-version header	For HTTP after initialization, clients must include MCP-Protocol-Version; unsupported values should be rejected.	SDK rejects unsupported explicit values but accepts missing headers. In this app's stateless mode, post-initialization state is not tracked, so the server cannot know whether a request is subsequent to initialization.	Partly inherited from SDK and partly consequence of stateless HTTP design.	Next	Revisit together with HTTP lifecycle/session design.	This is difficult to enforce meaningfully without session state. It is also primarily a client MUST, but server acceptance weakens strict transport-conformance claims.	If stateful HTTP is adopted, test missing/invalid protocol headers after initialization. If stateless remains, document this as an intentional compatibility mode.
Protocol version target	Server response should negotiate a supported protocol version.	SDK 1.29.0 has latest protocol 2025-11-25; it returns 2025-06-18 when requested, 2025-11-25 when requested, and 2025-11-25 for unknown versions.	Yes, inherited from using the current MCP SDK.	Monitor	Do not say the server exclusively targets 2025-06-18. Say it supports clients negotiating 2025-06-18 for implemented features.	The dependency may support newer protocol versions before this project has audited their full behavior.	On SDK upgrades, record SDK latest/supported versions and rerun raw initialize probes for 2025-06-18, SDK latest and an unknown version.
Streamable HTTP GET/SSE standalone stream	Streamable HTTP supports POST and GET with optional SSE for server-to-client messages.	src/app.ts intercepts GET /mcp and returns 405; POST responses may use SSE per request.	Yes for current product.	Later	Keep unsupported until the server has server-initiated requests/notifications that require standalone GET/SSE.	Current public endpoint is read-oriented and does not need server-initiated sampling, roots, elicitation or live notifications. Supporting GET streams would add operational complexity.	If server-initiated notifications or subscriptions are introduced, revisit GET/SSE support and tests.
Authorization for HTTP	MCP HTTP authorization is optional, but protected HTTP servers that support MCP authorization should follow the authorization spec and Protected Resource Metadata requirements.	Public HTTP endpoint is read-only and unauthenticated; write signing over HTTP is refused unless an explicit unsafe trusted-deployment override is set. No OAuth resource-server metadata is implemented.	Yes.	Later	Do not implement MCP OAuth until user-specific/private capabilities or protected hosted deployments exist.	Current public endpoint exposes public Blurt blockchain data only. Deployment-specific auth can live at reverse proxy/gateway layer for now.	If the hosted service becomes protected or user-specific, design OAuth/resource metadata before launch.
Tools capability	Servers that support tools must declare tools; tools/list and tools/call define tool metadata, inputs and results.	Implemented via McpServer.registerTool; initialize advertises tools: { listChanged: true }; tools include name, title, description, inputSchema, outputSchema, annotations and structured results.	Yes.	Monitor	Keep as core supported feature.	Tools are the main product surface.	Recheck generated tool contract and SDK output after SDK upgrades.
Tool list pagination	tools/list supports cursor pagination.	The SDK returns all registered tools in one response with no nextCursor. The list is small and static.	Yes.	Later	Do not implement custom pagination unless the tool list becomes large or SDK behavior changes.	Pagination adds no value for ~25 read tools plus opt-in write tools.	Monitor if tool count grows substantially.
Tool list change notifications	If listChanged is declared, servers should notify when the tool list changes.	SDK hardcodes tools: { listChanged: true }; this server's tool list is fixed at server construction and does not change at runtime.	Yes, inherited SDK high-level API behavior.	Monitor	Accept as harmless for static tool lists.	No runtime change occurs, so no notification is needed. If future runtime changes are added, notifications become important.	If dynamic tool enable/disable is added after initialization, add list-changed notifications or stop advertising the capability if the SDK allows.
Structured tool output	MCP 2025-06-18 supports structuredContent and optional outputSchema.	Implemented for normal successful tool results through withStandardStructuredContent; errors return isError with text.	Yes.	Monitor	Keep.	Structured output is valuable for agents and generated contract docs.	Tighten per-tool data schemas only when the project is ready to make stronger compatibility promises.
Resources and resource templates	Servers that support resources must declare resources; templates are exposed via resources/templates/list; resources are read with resources/read.	Implemented with four blurt:// resource templates. Initialize advertises resources: { listChanged: true }.	Yes.	Monitor	Keep as supported feature.	Resource templates are useful for connector-style search/fetch workflows.	Recheck resource URI templates and reads after SDK upgrades.
Resource listing behavior	Resource list/template list supports pagination and may list concrete resources.	Templates are listed; concrete resource listing is effectively empty because templates use { list: undefined }. No cursor pagination.	Yes.	Later	Keep template-first model; do not list all possible Blurt blockchain resources.	Blurt blockchain resources are unbounded. Concrete listing would be artificial or expensive.	If curated resource lists are added, define stable pagination and freshness rules.
Resource subscriptions	Resource capability may support subscribe; servers that support it send notifications/resources/updated.	Not advertised and not implemented.	Yes.	Won't implement	Do not implement until there is a concrete live-update product need.	Public Blurt blockchain reads are request/response; subscriptions would require state, polling and operational commitments.	Revisit only if live notifications or watch-style features become a product goal.
Prompts	Servers may expose user-controlled prompt templates.	Not advertised and not implemented.	Yes.	Won't implement	Do not implement for now.	This server's role is data/tools, not prompt-template distribution. Human examples live in docs, not MCP prompt objects.	Revisit only if the project needs curated Blurt analysis workflows as selectable client prompts.
Completion	Servers may support argument completion for prompts/resources.	Not advertised and not implemented.	Yes.	Later	Defer.	Completion would be useful only after prompts or richer resource browsing need it.	Revisit with prompts or curated resources.
MCP logging	Servers may advertise logging and send notifications/message; logs must avoid secrets.	Not advertised. Server logs go to stderr / process logs, not MCP client logging notifications.	Yes.	Later	Keep operational logs outside MCP for now.	MCP logging is not required for current clients and may expose implementation details if done casually.	If implemented, design redaction and log-level behavior first.
Ping	Either party may send ping; receiver must respond promptly.	Implemented by SDK default handler.	Yes.	Monitor	Keep inherited SDK behavior.	No custom project code required.	Include in future raw protocol smoke tests if lifecycle/transport code changes.
Cancellation	Cancellation notifications are optional; receivers should stop processing where possible and may ignore non-cancellable work.	SDK handles notification plumbing; Blurt RPC calls are not actively aborted by project handlers.	Partly intentional.	Later	Defer active cancellation until long-running tools or abortable RPC wrappers justify it.	Most calls are short RPC reads; adding cancellation plumbing now would add complexity with limited value.	If long-running tools are added, pass abort signals to RPC/fetch layers and test cancellation.
Progress notifications	Progress is optional for long-running operations.	Not emitted by tools.	Yes.	Won't implement	Do not implement for current short request/response tools.	Current operations do not have meaningful progress stages.	Revisit only for long-running scans, exports or batch workflows.
Sampling, roots, elicitation	Server-initiated client features are optional and require negotiated client capabilities.	Not used.	Yes.	Won't implement	Keep out of scope.	The server does not need model calls, filesystem roots or interactive elicitation to expose public Blurt blockchain data.	Revisit only if a new feature explicitly needs client-provided roots, sampling or user elicitation.
Error style for tool failures	Tool calls may return tool-level isError results; transport errors should be reserved for protocol failures.	Implemented: most tool failures return isError: true with text; protocol/schema failures are handled by SDK.	Yes.	Monitor	Keep.	Lets AI clients recover from data/API failures without treating the MCP session as broken.	Continue avoiding secret leakage in error text.

Maintenance procedure

When reviewing this register:

1. Fetch the exact MCP specification version under review.
2. Record the installed @modelcontextprotocol/sdk version, LATEST_PROTOCOL_VERSION and supported versions.
3. Probe the live app with raw protocol requests for:
   • initialize with the target version;
   • initialize with SDK latest;
   • unknown protocol version;
   • direct operation before initialize;
   • batch request body;
   • HTTP Origin behavior;
   • missing/invalid MCP-Protocol-Version header where applicable.
4. Compare advertised capabilities with implemented handlers.
5. Update every affected row with a decision and priority.
6. Update public wording if the support/conformance statement changes.

Current publication wording

Use this wording until the Now items are resolved and a stricter audit passes:

This server uses the Model Context Protocol TypeScript SDK and supports MCP clients negotiating protocol version 2025-06-18 for its implemented tools and resource-template features.