Skip to main content
Glama

UTC Clock

inspect-robots

Fetch a public robots.txt and return group counts only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoHTTPS URL to normalize or cite
hostNoPublic hostname
jsonNoJSON text to validate; discarded after the check
zoneNoIANA timezone name

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It adds useful scope by saying 'group counts only,' signaling that full robots.txt content is not returned, but it does not mention network behavior, failure modes, or limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with zero filler. 'Only' adds meaningful scope without extra words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has four parameters whose mapping to the stated purpose is unexplained, and there is no output schema to clarify return values. An agent would struggle to decide what to pass for 'json' or 'zone' when fetching a robots.txt, making the one-line description insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the parameter descriptions are generic and largely mismatched to the tool's purpose ('json' to validate, 'zone' as timezone, 'url' to normalize or cite). The description adds no clarification about how these parameters relate to fetching a robots.txt, so it fails to compensate for the confusing schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Fetch'), a resource ('public robots.txt'), and a precise result ('return group counts only'), so an agent understands the core action. It does not explicitly differentiate from sibling tools, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is implied: use this when you need group counts from a public robots.txt file. There is no explicit guidance on when not to use it, what precedes it, or how it compares to alternatives like 'citation.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

C2.7/5.0
Disambiguation2/5

utc-time, timezone, and iana-zones all occupy overlapping time/zone territory, while citation and normalize-url both inspect URLs. compatibility is vague and hard to distinguish from HTTP/status-related tools, making tool selection genuinely ambiguous.

Naming Consistency3/5

Names consistently use lowercase hyphenation, but they mix noun-only labels like timezone and status-catalog with verb-led names like normalize-url and inspect-robots. The pattern is readable but not truly consistent.

Tool Count3/5

Ten tools is a moderate count, but the server's stated purpose as a UTC clock only justifies roughly three of them. The remaining URL, robots, HTTP, and JSON tools make the set feel inflated and off-purpose.

Completeness2/5

For a clock server, utc-time, timezone, and iana-zones cover basics but omit timezone conversion, offsets, and DST details. For the broader utility surface implied by the other tools, there are major gaps and no coherent workflow.