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?
The phrasing 'return group counts only' implies a read-only operation that filters output, but it does not describe error handling, potential side effects, or what happens if the robots.txt is inaccessible. Since annotations provide no additional context, some behavioral details are missing.
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 concise sentence that directly states the tool's core function. No unnecessary words or redundancy.
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 incomplete because the description does not reconcile the mismatched parameters with the stated purpose. An agent cannot determine how to correctly populate the required fields or what 'group counts' refers to in the context of robots.txt, making the tool difficult to use correctly.
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 parameter descriptions in the schema are generic and clearly mismatched with the tool's purpose (e.g., 'JSON text to validate', 'IANA timezone name'). They do not explain how url or host relate to fetching robots.txt, nor why json and zone are included. This is a significant gap.
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 action (fetch) and resource (robots.txt) and specifies the output (group counts only). However, 'group counts' is ambiguous and the parameters do not align with the stated purpose, which slightly reduces clarity.
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. It does not mention any prerequisites or conditions, leaving the agent to infer appropriate usage from the tool name alone.
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 clear, distinct purpose: URL parsing, HTTP status codes, timezone handling, JSON validation, and robots.txt fetching. Even overlapping areas like URL tools focus on different aspects (origin/path vs. host/scheme vs. domain labels).
All tool names follow a consistent lowercase-with-hyphens convention (e.g., normalize-url, validate-json). No camelCase, underscores, or mixed styles, making the naming pattern predictable and uniform.
With 11 tools, the set sits within the typical 3-15 range. The domain is a mix of unrelated utilities (URL, time, JSON, HTTP), which feels slightly unfocused but not excessive.
The tools cover common operations for their respective areas: URL parsing, time/UTC, JSON validation, and HTTP status. Minor gaps exist (e.g., no URL encoding/decoding or generic HTTP request tool), but the current set is reasonably comprehensive for its stated purposes.