Show how this request is classified. No identifiers are retained.
| 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. It adds exactly one behavioral fact — 'No identifiers are retained' — which is useful privacy context, but it omits how inputs are processed, whether any state is kept, and what the classification output represents.
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 sentences with zero filler; the purpose is front-loaded and the privacy disclosure follows naturally. It is concise, though brevity is partly achieved by omitting substantive details.
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?
With no output schema, no annotations, and four optional parameters, the description must explain how the inputs map to the output. It does not — an agent cannot determine which parameter(s) to populate or what classification result to expect.
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 schema already documents all four parameters, justifying the baseline 3. The description adds no parameter-level meaning: it never mentions url, host, json, or zone, nor how each affects the classification.
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 states a specific action (show a classification) but leaves 'classified' undefined — the tool name suggests compatibility assessment, yet the description never mentions compatibility or what classification categories exist. It is distinguishable from siblings only by implication, not enough for an agent to anticipate the result.
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?
No guidance on when to invoke this tool over its siblings (citation, domain-shape), no exclusions, and no inter-tool routing. The privacy note ('No identifiers are retained') implies safe usage but does not establish a selection condition.
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.