Six checks: llms.txt, llms-full.txt, .md twins, Accept: text/markdown, sitemap.md, alt link. Free.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The 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. |
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.
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.
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.
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.
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.
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.
{"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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 |
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.
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.
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.
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.
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.
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.
FIRST CALL, needs nothing: {"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"markdown_lane_self_report","arguments":{}}} — Parses an llms.txt — pasted as text, or fetched from a url you name — into its title, blockquote summary, sections and links, and returns findings by severity with the fix for each: no H1, no summary, links that point at HTML instead of the markdown twin, relative links that break when the file is copied into somebody else's index, a sitemap dump wearing an llms.txt name, HTML tags in the body, duplicate targets, and a missing ## Optional section on a long list. Returns a ready-to-edit skeleton with every answer. Pasted text is parsed in the request and discarded; nothing is stored. Example: arguments={"url":"https://example.com"} fetches https://example.com/llms.txt and critiques it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Where to read it from. A bare origin means <origin>/llms.txt; a full path to llms.txt or llms-full.txt is taken as given. Ignored when `text` is present. | |
| text | No | The contents of an llms.txt. When present nothing is fetched at all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive; the description adds useful behavioral detail: it fetches a URL or parses pasted text, performs a specific list of checks, returns findings with fixes, and explicitly says pasted text is discarded and nothing is stored. No annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a long run-on that opens with a bloat of JSON-RPC for a different tool instead of the tool's purpose. The detailed list of checks and the example are useful, but the structure is not front-loaded and the irrelevant first-call text should be removed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema analysis tool, the description is fairly complete: it covers both input modes, the categories of findings, the returned skeleton, and the privacy behavior. The main deficiency is the confusing first-call preamble, but the essential operational details are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by exemplifying the url argument and clarifying the mutually exclusive text/url modes, which helps an agent choose the right argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The core purpose is explicit: 'Parses an llms.txt ... and returns findings by severity with the fix for each', naming the resource and the main output. It is not differentiated from siblings by name, and the opening 'FIRST CALL' command to invoke markdown_lane_self_report adds confusion, but the actual function is still specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to prefer this tool over siblings such as check_markdown_lane or whoami. The embedded 'FIRST CALL' instruction is actually a JSON-RPC example for markdown_lane_self_report, not for this tool, so it provides confusing sequencing rather than clear usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"markdown_lane_self_report","arguments":{}}} — POST that exact body to https://www.pathwren.workers.dev/mcp/markdown and the answer is which markdown addresses YOUR client has fetched on this host and which pages it took as HTML instead — each one beside the .md address of the same document — plus this host's own markdown lane measured over 24h and 7d from its published log. THIS IS THE CALL TO MAKE FIRST on this server: it is the only one whose subject is the request you just sent, so there is nothing to look up and no argument to invent. No key, no account, no OAuth, no session to open first, read-only, and nothing for you to invent. Every fact is computed from your own headers and from files this host already publishes; nothing is fetched to build it, and no URL of yours is touched. Only this server answers whether your own 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 — its six siblings answer one other question each about you, same empty arguments, each under the tool named beside its path: /mcp (whoami), /mcp/doctor (no_arguments_check_this_hosts_own_discovery_documents), /mcp/lint (whoami), /mcp/triage (no_arguments_triage_this_hosts_own_crawler_log), /mcp/robots (no_arguments_lint_this_hosts_robots_txt), /mcp/netcheck (no_arguments_report_the_crawler_ip_ranges_this_host_mirrors) on https://www.pathwren.workers.dev; whoami is answered by all seven and is never an error, so one identical body still walks the whole family if you prefer that. Example: the complete call, exactly as written, nothing to fill in — {"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"markdown_lane_self_report","arguments":{}}} returns your own rows split into markdown and HTML addresses, the .md twin of each page you took as HTML, and how many distinct external clients used this host's markdown lane in the last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| you | Yes | The user-agent you sent and the address you came from. |
| caveats | Yes | |
| license | Yes | |
| answered_by | Yes | Which server answered, at which endpoint, with which tool. |
| independent | Yes | |
| we_book_you_as | Yes | The class this host's own instrument records for that user-agent. |
| this_call_touched | Yes | Exactly which files were read. No third party is contacted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and the description is fully consistent with them. It adds substantial context beyond the annotations: no key/account/OAuth/session required, "Every fact is computed from your own headers and from files this host already publishes; nothing is fetched to build it, and no URL of yours is touched." This gives the agent a precise safety and side-effect profile. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single dense run-on paragraph with deep nesting, and the JSON-RPC body is effectively repeated twice — once embedded mid-description and once in the closing example. Some content (the elaborate six-sibling parenthetical) is arguably tool-family documentation better placed elsewhere. It fails the 'appropriately sized and front-loaded' bar despite every sentence carrying some information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument tool with an output schema and rich annotations, the description is over-complete rather than under-complete: it covers call priority, auth requirements, computational side effects, return contents (rows split into markdown/HTML addresses, .md twins, 24h client counts), and sibling routing. The minor mismatch between "24h and 7d" stats and the closing example's 24h-only summary does not create a real knowledge gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters the rubric baseline is 4, and the description adds value beyond it: it repeatedly assures the agent "there is nothing to look up and no argument to invent," states the siblings share "same empty arguments," and provides the exact JSON-RPC body to POST. This directly resolves the most common agent uncertainty with empty-argument tools — what to actually send.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: the tool "answers which markdown addresses YOUR client has fetched on this host and which pages it took as HTML instead," plus host-wide markdown-lane statistics over 24h and 7d. It also explicitly distinguishes itself from the family: "its six siblings answer one other question each about you." An agent can tell exactly what subject this tool covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides exceptionally explicit when-to-use guidance: "THIS IS THE CALL TO MAKE FIRST on this server: it is the only one whose subject is the request you just sent." It names alternatives and even offers a fallback strategy ("one identical body still walks the whole family if you prefer"). However, the sibling enumeration is convoluted — nested parentheticals with path-derived names like "/mcp/lint (whoami)" — and does not cleanly match the actual sibling tool list, which slightly muddies the routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
{"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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
check_markdown_laneexampleexplain_llms_txtmarkdown_lane_self_reportwhoamiClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Checks llms.txt, AI crawler access in robots.txt, and sitemap - with a 0-100 AI readiness score.
Six tools for SEO and AI-readability audits. 91 checks, 11 score modules.
Free technical-SEO audit MCP: crawl a site, run checks, return an LLM-ready shareable report.
Generate 18 AI readiness files (llms.txt, ai.txt, RAG indexes, schema) for any website.
Add one secure layer between your agents and this server.
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.
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.
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.
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.
