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?
No annotations are present, and the description only adds the privacy note 'No identifiers are retained.' It does not disclose side effects, error behavior, or whether the operation is read-only, leaving the agent without essential behavioral information.
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 very short and efficient in word count, but it is too vague to be useful. It lacks essential details about the tool's behavior, making the brevity a drawback rather than a strength.
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 description is severely incomplete. It provides no context about what 'classification' entails, what output the agent should expect, or how the tool integrates with the sibling tools. The absence of an output schema and any explanatory context leaves the agent guessing.
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?
Each parameter has a clear individual description in the schema (e.g., 'HTTPS URL to normalize or cite'), so schema coverage is 100%. However, the tool description does not clarify how these parameters relate to the classification purpose, and no additional meaning is added beyond the schema definitions.
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 'Show how this request is classified' is vague and does not specify what classification means or what criteria are used. It does not clearly distinguish this tool from its siblings, leaving the agent uncertain about its exact function.
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 is provided on when to use this tool instead of alternatives. The description lacks any indication of typical use cases, prerequisites, or situations where this tool would be preferred over similar sibling tools.
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 operate on URLs (citation, normalize-url, domain-shape, compatibility) with overlapping inputs but different outputs, and hour-utc vs utc-time are close in purpose. Descriptions mostly clarify the distinction, but an agent could easily select the wrong URL-analysis tool without deeper inspection.
Names mix single nouns (citation, compatibility, timezone) with hyphenated compounds that alternate verb-first (normalize-url, inspect-robots) and noun-first (status-catalog, domain-shape). No consistent verb_noun or action-object pattern is present.
Eleven tools is within a reasonable count range, but the set spans time, URL parsing, HTTP status, and JSON validation with no unifying scope. Several tools feel like a grab-bag rather than a focused server, so the count is not fully earned.
The time tools lack basic conversions or formatting options, and the URL tools have no clear workflow for fetching, parsing, and classifying content. For the apparent 'web/URL utilities plus time' scope, there are significant gaps that would force agents to work around missing functionality.