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

Who is calling? (no arguments)

whoami

Read-onlyIdempotent

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"whoami","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 describes YOU, the caller — the user-agent you sent, the address you came from, the class our instrument books you as, and whether this host has seen you before. Takes no arguments. Safe to call. Deterministic. Touches no third party. Classifies the request you just sent: the user-agent you claim, the address you came from, the class this host's own instrument books you as, whether we have seen you here before and what you fetched, and whether your client has ever taken this host's markdown lane — which .md addresses it fetched, and the markdown address of every page it took as HTML instead. Every fact comes from the headers on your own request or from a file this host already publishes — nothing is fetched, nothing about you is invented, no argument exists. Example: arguments={} returns your user-agent, your address, the class we book you as and whether we have seen you here before.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`you`	Yes	The user-agent you sent and the address you came from.
`caveats`	Yes	What this answer does NOT establish — a user-agent is a claim.
`license`	Yes
`answered_by`	Yes	Which server answered, at which endpoint.
`independent`	Yes	This host is independent and unaffiliated.
`we_book_you_as`	Yes	The class this host's own instrument records for that user-agent.
`we_have_seen_you`	Yes	Whether this user-agent appears in the published observation window.
`this_call_touched`	Yes	Exactly which files were read to answer. No third party is contacted.

Schema Changelog

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

First observedSep 6, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the annotations, the description explicitly discloses that all facts come from the caller's own headers or a host-published file, nothing is fetched, nothing is invented, and no argument exists. It also clarifies the tool is read-only, deterministic, and touches no third party. This is exemplary transparency and is consistent with the 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 verbose and repetitive, restating the same list of returned facts almost verbatim twice ('the user-agent you sent, the address you came from, the class... whether we have seen you here before'). It is not front-loaded efficiently; the exact JSON-RPC body could have been a brief example rather than woven into long prose.

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-argument, read-only identity tool, the description is complete: it gives exact invocation instructions, the source of all returned data, safety guarantees, and a concrete example of the output fields. The output schema and annotations cover the remaining formal details.

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?

With zero parameters and 100% schema coverage, the schema already conveys that no arguments are needed. The description reinforces this by stating 'Takes no arguments,' 'no argument exists,' and providing an exact invocation example with arguments={}. It adds useful confirmation but does not need to do much because the schema is fully explicit.

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?

The description clearly states that the tool identifies the caller, listing the exact facts returned: user-agent, client address, caller class, and whether the host has seen the caller before. This goes well beyond the name and title and gives an agent a concrete model of what the tool does. It is specific and easily distinguished from unrelated sibling tools.

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

Usage Guidelines3/5

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

The description provides strong practical guidance: no arguments, no API key, no account, safe to call, deterministic, and no third-party contact. However, it does not explicitly state when to prefer this tool over siblings like markdown_lane_self_report or check_markdown_lane, nor does it give any exclusions beyond 'takes no arguments.'

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?