Skip to main content
Glama

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

by dev.workers.pathwren.www

Can an agent read this site as markdown?

check_markdown_lane
Read-onlyIdempotent

FIRST CALL, needs nothing: {"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"markdown_lane_self_report","arguments":{}}} — Reads the markdown lane of a URL you name and returns six verdicts with the exact fix for each: /llms.txt, /llms-full.txt, the .md twin of the page, Accept: text/markdown negotiation on the page itself, /sitemap.md, and whether the page ADVERTISES its twin with or the equivalent Link header. Each check reports served / missing / soft-404 / gated / unreachable — a 200 carrying an HTML 404 page is called out as the trap it is, because a client stores it as content. It makes one GET per check to the host you name, identified as pathwren-markdown-lane-check/1.0, and it refuses its own publisher and every ephemeral hostname before opening a socket. Example: arguments={"url":"https://example.com/"} returns the six verdicts for that origin.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe page to check, e.g. https://example.com/docs/getting-started. The origin is used for /llms.txt and /sitemap.md; the exact path is used for the .md twin, the Accept negotiation and the alternate-link pointer.

Schema Changelog

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

  1. First observed

TDQS

A3.6/5.0
Behavior5/5

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

The description goes well beyond the annotations, disclosing that the tool makes one GET per check, identifies itself as 'pathwren-markdown-lane-check/1.0', refuses its own publisher and ephemeral hostnames, and treats a 200 HTML 404 as a soft-404 trap. These behavioral details are valuable and do not contradict the readOnly/idempotent hints.

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

Conciseness3/5

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

The description is dense and information-rich, but the opening JSON-RPC snippet referring to markdown_lane_self_report is extraneous and confusing for a tool named check_markdown_lane. The rest is a long single paragraph; useful details are present but structure could be improved by separating the first-call instruction from the tool's own behavior.

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?

Given there is no output schema, the description does a strong job explaining return semantics: six verdicts, the exact checks performed, status categories, and the soft-404 trap. It also describes network behavior and provides an example. Minor gaps remain around exact response formatting and error cases, but overall it is substantially complete.

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

Parameters3/5

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

The input schema already documents the single url parameter at 100% coverage, including how origin vs exact path is used. The description reinforces this with an example and the six check behaviors, but adds little semantic meaning beyond what the schema already provides.

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 core purpose is clearly stated: 'Reads the markdown lane of a URL you name and returns six verdicts with the exact fix for each.' The resource and action are specific. However, the opening 'FIRST CALL, needs nothing: {jsonrpc call to markdown_lane_self_report}' muddies which tool is being described and does not differentiate this tool from its siblings.

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

Usage Guidelines2/5

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

There is no explicit statement of when to use check_markdown_lane versus alternatives like markdown_lane_self_report or explain_llms_txt. The phrase 'FIRST CALL, needs nothing' is confusing and appears to instruct calling a different sibling tool, which undermines rather than clarifies usage guidance.

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 toolsInspect
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