API Meter

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

Annotations already declare the non-read-only, non-idempotent, non-destructive, open-world profile; the description adds the details that actually matter for calling it safely — keys are returned once and cannot be re-fetched, and signups are throttled to 5 per hour per network. That one-time-secret disclosure is critical operational context an agent could not infer from 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?

Three tight sentences: what it does, what it returns plus the store-the-keys warning, then the rate limit. No filler and the most actionable warning is not buried.

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?

There is no output schema, and the description compensates by enumerating the four return values. Combined with the one-time-key warning, rate limit, and fully documented parameters, an agent has everything needed to invoke and handle the result correctly.

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%: all three required parameters carry their own descriptions including format constraints and the hashing note. The description adds no parameter-level meaning beyond the schema, 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 ("Sign up an API for API Meter") and immediately names the concrete outputs (slug, ingest key, dashboard key, proxy URL). None of the siblings (export_usage, get_ingest_snippet, get_usage) create accounts, so the agent can tell this is the only write/provisioning path.

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 free-tier boundary ("free to 250K requests/month") and the network rate cap give the agent clear context for when this call is appropriate and what volume it implies. There are no exclusions or named alternatives, but no sibling overlaps this capability, so routing is unambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely useful context beyond them: the return payload is JSON rows or CSV text depending on format, and the detail row shape is customer x plan x method x endpoint. It still omits pagination, row limits and any key/permission expectations, which keeps it off a 5.

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 dense sentences with the resource and output formats front-loaded; nothing is wasted. The '(same as /api/export)' aside adds little for an agent but costs only a few tokens.

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?

There is no output schema, yet the description does state the return shapes, which covers the biggest gap. However, for a 5-parameter export tool it leaves the two required parameters (slug, dashboard_key) undefined and says nothing about result size or whether month is mandatory.

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 0%, so the description must carry parameter meaning. It does well on two enum params (view, format) but leaves slug, dashboard_key and month entirely unexplained — 'monthly' hints at month but does not state its format or whether it is required (it is not). With 3 of 5 params undocumented in both places, it cannot score higher.

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 uses a specific verb+resource ('export ... usage rows') and pins the granularity ('monthly', 'billing-ready'). It explains the two shapes via view=detail vs view=customers, so an agent understands what it gets. It does not explicitly differentiate itself from the sibling get_usage, which is the only remaining ambiguity.

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?

Usage is only implied: choosing view=detail vs view=customers and format=csv is described, but the description never says when to call export_usage instead of the sibling get_usage, nor when csv is preferable to json. The '/api/export' reference is an API pointer rather than selection guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. "Batched, fail-open, never blocks your API" is valuable but describes the behavior of the emitted code, not of the tool call itself — nothing is said about auth requirements or what the call returns (a string? an object with install steps?). No contradiction with 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?

One short sentence plus a three-word qualifier, front-loaded with what the caller receives. Zero filler.

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 two-parameter, no-output-schema tool the description should state that the return value is the code string and that it varies by framework; neither is covered. The instrumentation-field list is helpful but leaves the essential call shape under-explained.

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 50%: slug is documented in-schema, but framework's enum carries no description and the description never mentions that the snippet is framework-specific or that a slug is substituted into it. With half the parameters undocumented, the description should have compensated and does not.

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?

"Copy-paste server code that reports each request ... to API Meter" names the resource (an ingest snippet) and the exact payload it instruments, which cleanly separates it from the sibling tools (create_account, export_usage, get_usage). The verb is implied by the tool name rather than stated, but an agent can tell what it produces.

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?

There is no statement of when to use this versus get_usage or export_usage, no mention of prerequisites (does it need an existing API key or account first?), and no guidance on choosing a framework. Only the onboarding-adjacent framing hints at the use case.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description goes beyond them by pinning the aggregation window to UTC months and explaining the '-agent' plan-label bucket and that such traffic is counted and billed like any request. It still omits pagination/limit behavior and the fact that a dashboard key is needed for authorization.

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, front-loaded with the resource and window, followed by the one non-obvious special case. The parenthetical earns its space because the agent bucket is otherwise undiscoverable.

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?

There is no output schema, so the return shape (one row per group with counts/costs) is never described, and the auth requirement for dashboard_key is unstated. Adequate to select the tool, thin on what comes back.

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 only 40% across five parameters. The description reinforces month (UTC) and group_by values but mostly restates what the schema already says, and it says nothing about the required slug or dashboard_key, nor about the limit cap of 200.

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 resource and scope: monthly usage for one API, grouped by customer/endpoint/plan. An agent can tell what it returns, but nothing distinguishes it from the sibling export_usage, which is likely the closest alternative.

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 read-only reporting intent is implied by 'usage ... grouped by', but there is no explicit when-to-use statement and no mention of when to prefer export_usage or get_ingest_snippet. Usage must be inferred from the name and grouping options.

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