Estimate whether an operation would hit 402/429 before spending. For rag_index you can pass textLength/byteLength instead of amount.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| amount | No | ||
| byteLength | No | ||
| textLength | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It does disclose that this is a preflight/non-spending estimator ('before spending'), which is an important behavioral trait. It does not describe side effects, permissions, or output behavior, but the core safety implication is stated.
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 short, front-loaded sentences. The core purpose appears in the first clause, and the only additional sentence carries a specific parameter exception. No filler or redundancy.
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 tool with no annotations and no output schema, the description omits what the estimate returns (boolean? status?) and how each kind should be parameterized. The five kind enum values and four parameters are only partially covered by the rag_index note, leaving an agent with significant ambiguity.
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 description adds meaningful parameter semantics beyond the schema: for rag_index, textLength/byteLength can replace amount. However, schema_description_coverage is 0% and the description leaves the meaning of amount for kvp_ops, storage_bytes, rag_query, and inbound_email undocumented, so it only partially compensates.
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 a specific verb ('Estimate'), a resource class ('an operation'), and a concrete outcome ('would hit 402/429 before spending'). It stops short of explicitly distinguishing itself from sibling budget_get, though the phrase 'before spending' implies a preflight role.
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 phrase 'before spending' gives a clear temporal context, and the rag_index sentence gives conditional parameter guidance. However, it never tells the agent when to prefer budget_estimate over budget_get or other billing siblings, and no exclusions or alternatives are named.
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.
Most tools are named as resource+action and target distinct surfaces (inbox, kvp, files, billing), so an agent can generally select the right tool. A few pairs like budget_get vs usage_get and inbox_message_get vs inbox_message_raw have adjacent purposes, but their descriptions mostly clear up the boundary.
The predominant convention is snake_case noun_verb, e.g. kvp_get, inbox_create, files_list. Minor deviations like inspect_storage (verb-noun) and bare noun names such as billing_portal and files_types slightly break the pattern.
With 35 tools, the server is well above the 25+ threshold and bundles many subdomains—billing, KVP, inbox, RAG, files, keys, support—into one surface. It would be more coherent as separate servers or with a significantly trimmed inbox tool set.
Core workflows are mostly covered: inbox lifecycle, webhooks, KVP CRUD, billing, and usage are solid. However file upload has no corresponding delete/remove tool, and keys have create but no list/revoke, leaving noticeable lifecycle gaps.