Burs-IA Utils

Compatibilidad del initialize de MCP

mcp-protocol-compat

Read-onlyIdempotent

Compara una solicitud initialize de MCP y su respuesta (revisiones hasta 2025-11-25; desde 2026-07-28 no hay initialize, y lo informa): negociación de versión, capacidades por revisión, capacidades requeridas que faltan, nombres desconocidos y clientInfo/serverInfo. Cuándo: hay que analizar un intercambio initialize de MCP ya capturado para encontrar diferencias de versión y de capacidades. No para: revisar un server.json del MCP Registry (mcp-server-json-lint); ni una prueba en vivo de compatibilidad 2026-07-28 de un endpoint MCP remoto (SKU x402 de pago aparte de Burs-IA verify-mcp-2026, por llamada en USDC en Base). Efectos secundarios: ninguno (solo lectura, sin red, sin estado guardado). Determinista: la misma entrada da la misma salida. Límites: entrada JSON de hasta 64 KB, 1 s por llamada, resultado de hasta 1 MB.

EN: Compares an MCP initialize request and its response (revisions up to 2025-11-25; from 2026-07-28 there is no initialize, which it… [EN completo / full EN: inputSchema.description]

Input Schema

Name	Required	Description
`client`	Yes	initialize request: the JSON-RPC message or its params ({protocolVersion, capabilities, clientInfo}) (object; required).
`server`	Yes	initialize response: the JSON-RPC message (result or error) or its result ({protocolVersion, capabilities, serverInfo}) (object; required).
`client_supported_versions`	No	Every protocol revision the client can speak (default: only the requested one) (array of string; optional; up to 50 items).
`required_client_capabilities`	No	Client capabilities the server needs (e.g. "sampling", "elicitation") (array of string; optional; up to 50 items).
`required_server_capabilities`	No	Server capabilities the client needs, as dotted paths (e.g. "tools", "resources.subscribe") (array of string; optional; up to 50 items).

Output Schema

Name	Required	Description	Default
`notes`	No
`errors`	No
`reason`	No
`missing`	No
`unknown`	No
`warnings`	No
`handshake`	No
`compatible`	No
`server_version`	No
`version_agreed`	No
`requested_version`	No
`negotiated_version`	No
`client_capabilities`	No
`server_capabilities`	No
`server_supported_versions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 1, 2026

addedInput schema / description

Added value: +"EN: Compares an MCP initialize request and its response (revisions up to 2025-11-25; from 2026-07-28 there is no initialize, which it reports): version negotiation, client and server capabilities per revision, missing required and unknown capabilities, clientInfo/serverInfo. When: a captured MCP initialize exchange has to be analysed for protocol-version and capability mismatches. Not for: linting an MCP Registry server.json (mcp-server-json-lint); nor a live 2026-07-28 compatibility probe of a remote MCP endpoint (separate paid Burs-IA x402 SKU verify-mcp-2026, per call in USDC on Base). Side effects: none (read-only, no network access, no stored state). Deterministic: the same input gives the same output. Limits: JSON input up to 64 KB, 1 s per call, result up to 1 MB."

First observedNov 1, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds traits the annotations do not carry: revision-dependent behavior (no initialize exists from 2026-07-28, and it reports that), determinism, and hard limits (64 KB input, 1 s runtime, 1 MB result). The 'solo lectura, sin red, sin estado guardado' sentence mostly restates readOnlyHint/openWorldHint/idempotentHint but does not contradict them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then labeled Cuándo / No para / Efectos secundarios / Determinista / Límites sections, which is easy to scan. It loses a point for being long and for duplicating itself in a full EN block and again in the schema description, which bloats the definition without adding new information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shape need not be explained; the description correctly spends its budget on version scope, exclusions, side effects and limits. The remaining gap is minor: it does not say what happens if the exchange is malformed or uses an unrecognized revision, though 'lo informa' hints at reporting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description explains the semantic role of the optional inputs: the required_client_capabilities / required_server_capabilities arrays drive the 'missing required capabilities' computation, and unknown names are matched against per-revision capability sets. That is meaning beyond the bare field descriptions, though the client/server vs client_supported_versions distinction is left to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: compares a captured MCP initialize request with its response, listing exactly what is computed (version negotiation, per-revision capabilities, missing required and unknown capabilities, clientInfo/serverInfo). It also pins the revision window (up to 2025-11-25, none from 2026-07-28), so it is immediately distinguishable from the lint and probe siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Cuándo' clause scopes it to analysing an already-captured initialize exchange, and 'No para' names two alternatives: mcp-server-json-lint for server.json registry files and the separate paid verify-mcp-2026 x402 probe for live remote endpoints. When, when-not and alternatives are all present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Burs-IA Utils tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?