Get request statistics

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new behavior: the tool is free and does not consume credits, and bulk job credits and per-address results are deliberately omitted. It also lists the returned metrics, which matters given there is no output schema. It stops short of describing aggregation boundaries (account-wide vs key-level) or the lookback handling near day edges.

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?

Two sentences, no filler: the first front-loads the capability and metrics, the second carries the scope exclusions and the free-of-charge fact. Every clause earns its place and the routing information arrives before the caveats.

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?

With no output schema, the description compensates by listing the metrics returned, and it explains the tool's relationship to bulk jobs and the account info tool. An agent has enough to choose it, parameterize it, and interpret its output without follow-up.

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% and the single 'days' parameter already carries its default (30) and max (365). The description restates the N-days window concept but adds no format, boundary, or edge-case semantics beyond what the schema provides, so baseline 3 applies.

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 and resource (EzVerify request statistics) and enumerates exactly which metrics are returned: total requests, credits used, valid/invalid/risky/unknown counts, average processing time. It also delimits scope against get_account_info and the bulk-job tools, so an agent can distinguish it from every sibling without opening a schema.

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 routes the agent to get_account_info when the goal is a month's credit total, and implicitly frames this tool as the lookback-window option ('last N days'). It doesn't state outright when not to use it, but the exclusion of bulk credit data and the free/no-credit note give the agent a clear decision signal.

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