x402-time
Time: UTC time, unix, ms. 🆓 5 free trial calls per signed wallet
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Time: UTC time, unix, ms. 🆓 5 free trial calls per signed wallet
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose a meaningful behavioral constraint: '5 free trial calls per signed wallet' indicates auth and rate-limit context. However, it does not clarify whether all three formats are returned together, what the response structure is, or whether the time comes from the server.
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 extremely compact: a title-like noun phrase followed by a usage-limit note. Every element earns its place; the cost/trial-call info is front-loaded after the core purpose. A verb would make it slightly clearer, but there is no fluff.
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?
For a zero-parameter tool, the description is mostly adequate, but it does not specify the output shape or format. Given the large sibling list of time-related utilities, a brief note on what distinguishes this from x402-time-utilities or x402-timestamp-pretty would improve completeness.
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 tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter information, but none is needed since the input schema is already fully empty.
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 the resource (time) and specifies the output formats (UTC, unix, ms). It is not a tautology, but it lacks a verb like 'get' or 'return'. It distinguishes from relative-time siblings like x402-time-ago and x402-time-until by naming absolute time formats.
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 explicit guidance on when to use this tool versus alternatives. The format list implies it is for fetching current absolute time, but it never mentions sibling tools such as x402-epoch-to-date, x402-timestamp-pretty, or x402-time-utilities, or states when not to use it.
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.