Paid $0.01 USDC exact on Base: UTC clock (unix, ms, iso). No params. Alias of REST GET /now and /time. For IANA zones use tool tz. payTo 0x3903F05a17676566958B0a3E0c21E0bd49B66ea0.
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "now"
}
}| 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?
Annotations declare readOnlyHint=true, but the description adds a critical behavioral trait: the operation costs $0.01 USDC and specifies a payment address. It also discloses it's an alias to REST endpoints, providing transparency beyond annotations.
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?
Extremely compact yet packed with essential information: cost, formats, alias, alternative tool, and payTo address. The critical cost caveat is front-loaded, and there is no wasted phrasing.
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 with no output schema, the description covers every requirement: behavior, timezone, formats, cost, and routing to the correct sibling. Nothing an agent needs is missing.
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?
With zero parameters, the baseline is 4. The description confirms 'No params' matches the schema, satisfying the requirement without needing extra detail.
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?
States a specific verb ('UTC clock') and clearly lists output formats (unix, ms, iso). Explicitly differentiates from sibling 'tz' for IANA zones, making its purpose unmistakable.
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?
Explicitly tells the agent when not to use it ('For IANA zones use tool tz') and clarifies it has no parameters. The alias note ('REST GET /now and /time') adds implementation context, giving a complete usage picture.
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.