Fetch a public robots.txt and return group counts only.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions that the tool fetches a public file and returns counts. It does not disclose network behavior, failure modes on unreachable hosts, rate limits, or side effects, and it silently hides the fact that the listed parameters do not map to robots.txt fetching.
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 single, front-loaded sentence with no filler: it opens with the verb and resource and immediately states the result. It is appropriately concise and easy to parse, though its brevity contributes to the under-specification of usage and parameters.
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 tool with no annotations and no output schema, the description is the only source of operational context, and it is inadequate. It does not explain the return shape of 'group counts', which parameters are relevant, or how this tool relates to its siblings, and the input schema actively conflicts with the described behavior.
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?
This is a severe mismatch. Although schema description coverage is 100%, the parameter descriptions are unrelated to the stated purpose: 'url' is 'HTTPS URL to normalize or cite', 'json' is 'JSON text to validate; discarded after the check', and 'zone' is 'IANA timezone name'. The description adds no mapping to these parameters, so an agent cannot determine how to invoke the tool correctly.
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 is specific: it names the verb 'Fetch' and the resource 'public robots.txt', and defines the outcome as 'return group counts only'. This clearly states what the tool does. However, it does not differentiate from sibling tools by name or alternative, so it just misses a 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?
The description provides no guidance on when to use this tool versus alternatives like citation, and no exclusions or prerequisites. It only states the action without any context about the intended use case, leaving an agent to guess when fetching robots.txt group counts is the right choice.
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.
Several tools overlap: citation and normalize-url both decompose URLs into host/scheme, http-200 is a single-code subset of status-catalog, and timezone/utc-time both give current time. compatibility is too vague to position relative to the others, so an agent could easily select the wrong tool.
All names use lowercase-with-hyphens, but the style mixes nouns (status-catalog, timezone), verbs (normalize-url, validate-json), and code-like labels (http-200). There is no consistent verb_noun pattern, though the naming remains readable.
Eleven tools is within a reasonable range for a web/HTTP utility server. However, a few tools could be consolidated (http-200 into status-catalog, utc-time into timezone), so the count is slightly higher than needed but not excessive.
The set covers common status-code lookup, URL parsing, robots.txt inspection, JSON validation, and time retrieval, but it lacks natural complements such as timezone conversion, header inspection, or URL construction. These gaps are workable, but they make the surface feel incomplete for a general HTTP/URL utility tool.