check_published_llms_txtRuft die live ausgelieferte /llms.txt einer Domain ab und prüft HTTP-Status, Content-Type und Inhalt. Nutzen Sie dies, um zu klären, warum PageSpeed Insights eine llms.txt bemängelt.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Domain oder beliebige URL der Website, z. B. "beispiel.de". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, and the description adds meaningful behavioral detail: it fetches the live /llms.txt and evaluates HTTP status, content-type, and content. This goes beyond the annotations by explaining exactly what the tool inspects, though it doesn't disclose output format or response behavior.
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?
Two concise, information-dense sentences. The first sentence states the core operation and checked aspects, and the second provides the practical use case. No filler or redundant repetition.
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?
The tool is simple with one param and clear behavior, but there is no output schema and the description doesn't state what the tool returns. An agent knows what it checks and why to use it, but not what result shape to expect, which is a notable gap for a diagnostic tool.
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 description coverage is 100%, so the parameter url is already documented as 'Domain oder beliebige URL der Website'. The description adds little beyond the schema; it implies the URL is the target domain, but that matches the schema. Baseline 3 is appropriate since the schema carries the parameter semantics.
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 uses a specific verb and resource: retreives the live-delivered /llms.txt of a domain and checks HTTP status, content-type, and content. It distinguishes itself from siblings by emphasizing 'live ausgelieferte' and the PageSpeed Insights use case, which clearly separates it from generate_llms_txt and validate_llms_txt.
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 gives an explicit trigger for use: 'Nutzen Sie dies, um zu klären, warum PageSpeed Insights eine llms.txt bemängelt.' This is clear context for when the tool should be invoked. However, it doesn't mention alternatives or when not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct role: generate creates a draft, validate scores arbitrary content against llmstxt.org, check_lighthouse applies exact Lighthouse rules, and check_published fetches a live URL. The only mild overlap is that validate also reports Lighthouse status, but the descriptions clarify the different focus.
Names are all snake_case verb-first phrases such as generate_llms_txt and check_published_llms_txt. check_lighthouse_agentic_browsing breaks the llms_txt-noun pattern slightly and is awkward, but the verb-first convention is otherwise consistent.
With four tools, the server is tightly scoped to the llms.txt workflow: creation, validation, Lighthouse auditing, and live publishing checks. Each tool addresses a clear need without bloat.
The set covers the full practical lifecycle: generate a draft, validate against the standard, check Lighthouse compliance, and verify the published file. No obvious dead ends or missing core operations.