Markdown Lane Check - llms.txt, .md twins, Accept: text/markdown

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/markdown 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 — explain_llms_txt, 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 — explain_llms_txt on the reference skeleton this server hands out as the answer to every llms.txt finding — parsed here as if you had pasted it, so nothing is fetched 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 explain_llms_txt with {"text":"# Your project\n\n> One paragraph: what this is, who it is for, and what it is no 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.3/5.0

Behavior5/5

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

Beyond annotations, the description discloses determinism, no third-party access, no API key or account needed, canned input from the host's own data, and that the output is a real structuredContent, not a mock. This is rich behavioral disclosure consistent with readOnlyHint and idempotentHint.

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 redundant, repeating 'no third party' and 'no API key/account/consent' multiple times, and it leads with a raw JSON-RPC request body plus URL rather than a straightforward purpose statement. It could be cut to a few sentences.

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?

For a zero-parameter, read-only, idempotent tool with an output schema, the description covers everything: invocation semantics, side effects, return value authenticity, and use case. It is arguably over-complete, but nothing needed for correct invocation is missing.

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

Parameters5/5

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

The tool has zero parameters, so there is no schema to document. The description reinforces this with 'Takes no arguments' and clarifies the input is canned from the host's own data, leaving no ambiguity for the agent.

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 a pre-canned worked example of explain_llms_txt and returns the exact structuredContent. It is distinct from siblings like explain_llms_txt (which would run on user input) and whoami. However, the opening JSON-RPC body delays the plain-language purpose, so not a perfect 5.

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?

Explicitly tells the agent to use it 'to see the shape of an answer before you decide what to send,' establishing a clear preview/dry-run use case. It does not name alternatives or exclusions, but for a zero-argument demo tool this is adequate.

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

All Markdown Lane Check - llms.txt, .md twins, Accept: text/markdown 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

A3.6/5.0

Disambiguation2/5

check_markdown_lane and explain_llms_txt are clearly distinct, but markdown_lane_self_report and whoami overlap heavily in what they report about the caller's fetched markdown lanes, and both claim to be the 'FIRST CALL'. The example tool adds further confusion by being a demo rather than a distinct analysis operation.

Naming Consistency2/5

Tool names mix styles: check_markdown_lane and explain_llms_txt use verb_noun, markdown_lane_self_report is a noun phrase, while whoami and example are single generic words. There is no consistent naming convention across the set.

Tool Count4/5

Five tools is a reasonable size for a focused checker, and the core check/explain pair earns its place. However, example is arguably unnecessary and the self-report/whoami pair could be consolidated without losing functionality.

Completeness4/5

The core domain is well covered: check_markdown_lane tests the six markdown lane affordances, and explain_llms_txt critiques llms.txt content. Minor gaps exist, such as no direct tool for checking an individual .md twin's status independent of the full lane check, but the main workflows have no dead ends.

Resources

Need Help?