MCP Endpoint Lint - handshake, tool schemas, JSON-RPC errors

Run this server's worked example (no arguments)

example

Read-onlyIdempotent

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"example","arguments":{}}} — POST that exact body to https://www.pathwren.workers.dev/mcp/lint and you are done: free, read-only, no API key, no account, no consent prompt, nothing for you to invent, and what comes back is this server's own worked example — score_card, run for real on a canned input from this host's own data — so you see the exact shape of an answer before you send anything of yours. Takes no arguments. Safe to call. Deterministic. Touches no third party. Runs this server's own worked example end to end — score_card on this server's built-in fixture — an in-process MCP endpoint with one real defect wired in per check (it ignores the protocol version you ask for, refuses a second initialize, publishes a tool whose required names a property that does not exist, and answers an unknown method with an HTML 500). No outbound request is made and no third party is touched — and returns exactly the structuredContent a real call returns, not a mock and not a description of one. Use it to see the shape of an answer before you decide what to send. The input is canned from this host's own data; no URL of yours is fetched and no third party is touched. Example: arguments={} runs score_card with {"url":"fixture://mcp-endpoint-lint/demo"} and returns its real answer.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`ran`	Yes	The tool name and the exact arguments that were run.
`answer`	Yes	The real structuredContent of that call, not a mock.
`license`	Yes
`reproduce`	Yes	A command that reproduces this answer.
`answered_by`	Yes
`what_it_shows`	Yes
`input_came_from`	Yes	Where the canned input came from — always this host's own data.
`this_is_not_a_mock`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already mark readOnly, idempotent, and non-destructive, and the description adds substantial context: no third-party contact, deterministic behavior, in-process execution, a fixture input, one real defect wired per check, and that the return value is the exact structuredContent of a real call, not a mock. This goes well beyond the structured annotations.

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

Conciseness2/5

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

The description is heavily repetitive, repeating 'no third party is touched' three times and 'worked example' multiple times. It also includes a raw JSON-RPC POST body that is tangential to invoking this MCP tool and could confuse an agent. The core information is buried in a long, redundant block.

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

Completeness5/5

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

Given the tool has no parameters, has an output schema, and carries safety/lifecycle annotations, the description provides more than enough context: purpose, exact input, real output, safety, determinism, and behavioral caveats. Nothing essential is missing for an agent to decide whether and how to call it.

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?

The tool has zero parameters, and the description explicitly states 'Takes no arguments' and gives the exact argument shape {}. With no parameters to document, the description handles parameter semantics clearly and accurately, though it somewhat redundantly repeats the empty-argument message.

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

Purpose4/5

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

The description clearly states the tool runs this server's worked example end to end, specifically score_card on a built-in fixture, and returns real structuredContent. It is specific about the resource and action, though it does not explicitly name sibling tools or draw a sharp line against score_card for real inputs.

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

Usage Guidelines4/5

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

It explicitly says to use it 'to see the shape of an answer before you decide what to send' and notes it takes no arguments, is safe, and makes no outbound requests. However, it never explicitly states when not to use it or names an alternative tool for real inputs.

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

All MCP Endpoint Lint - handshake, tool schemas, JSON-RPC errors tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

The four diagnostic tools (discovery_report, handshake_report, tools_list_report, error_conformance) have clearly distinct targets, and score_card is an aggregator while whoami and example serve identity and demo purposes. The main ambiguity is that example essentially runs score_card on the built-in fixture, overlapping with score_card called with empty arguments.

Naming Consistency3/5

Three tools follow the <area>_report pattern, but error_conformance, score_card, example, and whoami break it without a consistent alternative. All names are snake_case and readable, but the set mixes report nouns, a card noun, a generic noun, and a command-style name.

Tool Count5/5

Seven tools is well-scoped for an MCP endpoint linter: four focused checks, one aggregator, one demo, and one identity/debugging utility. No tool feels redundant or missing for the stated purpose.

Completeness5/5

The server covers the full advertised surface: discovery documents, handshake behavior, tool schema validity, and JSON-RPC error conformance, with score_card tying them together. The only additions are supporting utilities rather than missing domain operations.

Resources

Need Help?