Paid $0.01 USDC exact on Base: unix cron parser. expr required. Optional tz (default UTC) and n (1-20, default 5). Returns next fire times in UTC and America/Denver. No API keys. payTo 0x3903F05a17676566958B0a3E0c21E0bd49B66ea0.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | Next fire count 1-20. Default 5. | |
| tz | No | IANA timezone the cron is interpreted in. Default UTC. | |
| expr | Yes | Unix crontab 5-field (minute hour day-of-month month day-of-week). |
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?
Annotations already mark the tool read-only; the description adds meaningful context by disclosing a $0.01 USDC cost on Base, stating 'No API keys,' and specifying that results are returned in UTC and America/Denver. There is no contradiction with the 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?
The description is compact and information-dense, covering pricing, function, required and optional parameters, output time zones, auth requirements, and the payTo address in roughly fifty words. The payment detail is front-loaded and every clause contributes useful information, though the phrasing is slightly run-on.
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?
Given no output schema, the description explains what will be returned ('next fire times in UTC and America/Denver') and covers cost, input requirements, and defaults. It is slightly vague about the exact return format and how payment is settled, but the core information an agent needs to invoke the tool is present.
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?
Schema coverage is 100%, so the baseline is 3. The description mostly restates schema facts such as expr being required, tz defaulting to UTC, and n defaulting to 5. It adds the overall cron-parsing context but does not materially deepen per-parameter meaning beyond what the schema already provides.
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 clearly identifies the tool as a 'unix cron parser' and states that it 'Returns next fire times,' which is a specific function tied to a concrete resource. It is readily distinguishable by name and domain from siblings like tz or check, though it does not explicitly contrast itself with them.
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?
The description implies when to use the tool by identifying it as a cron parser and listing the required expr parameter along with optional tz and n. However, it never explicitly states when to use this tool versus alternatives, nor gives any exclusions or when-not-to-use conditions.
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.