utc-time
Current UTC timestamp.
Input Schema
TableJSON Schema
| 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 |
UTC weekday name
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
C2.1/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Current UTC timestamp,' which implies a read-only retrieval, but it does not disclose whether the parameters are used, ignored, or required, nor what side effects or response format to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified rather than effectively structured. For a tool with four parameters and no annotations, this brevity leaves out critical information and does not earn its place as an adequate explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four optional parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain how the parameters should be used, what the tool returns, whether any parameters are mutually exclusive, or how it relates to sibling tools. An agent would struggle to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with descriptions (100% coverage), so the baseline is 3. However, the description adds no additional meaning about how these parameters relate to the UTC timestamp operation, and the parameter descriptions seem disconnected from the tool's stated purpose (e.g., 'JSON text to validate' and 'HTTPS URL to normalize or cite').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Current UTC timestamp.' clearly names the output resource, but it lacks a verb and does not differentiate the tool from siblings like timezone or weekday-utc. It also ignores the four input parameters (url, host, json, zone) that appear unrelated to the stated purpose, leaving purpose somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as timezone, normalize-url, or validate-json. An agent receives no context for selection or exclusion, and no mention of where this tool fits among its siblings.
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
Disambiguation3/5
Tools cluster into URL/HTTP and time-related groups, but within each cluster the purposes are mostly distinguishable. citation, normalize-url, and domain-shape all touch hostnames, while timezone, utc-time, and weekday-utc all return current time data, so an agent could briefly hesitate when selecting among them.
Naming Consistency3/5
All names use lowercase hyphens, but there is no consistent verb_noun or noun pattern. Some tools use verb-object naming like inspect-robots and normalize-url, while others are plain nouns like citation, timezone, and status-catalog, making the set feel inconsistent.
Tool Count4/5
Eleven tools is a reasonable count for a utility server and does not feel bloated. However, the selection spans many unrelated concerns—URL parsing, time, JSON validation, robots.txt, HTTP status—so the set feels broader than a single focused purpose.
Completeness3/5
For a privacy-focused URL/HTTP utility set, there are notable gaps such as no redirect or header inspection, and for time utilities there is no timezone conversion tool. The surface covers basic atomic operations but lacks the cohesive lifecycle or workflow coverage that would make it feel complete.