Cloud for Bots

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

With no annotations, the description carries the full burden and actually does well: it discloses the auth model (BYOK stored in Secrets under named keys or key_secret), the billing behavior (no markup, provider bills you), and a side effect (every call lands in the run ledger). It omits error/rate-limit behavior and return shape, but the disclosure is above average for an unannotated tool.

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?

Front-loads the core purpose, then layers auth, billing and side-effect notes in short clauses. Dense but every clause carries information; slight compression ('[bot-ai]' tag) adds noise.

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 10-parameter tool with no annotations and no output schema, the description covers operational context but leaves most parameters undocumented. An agent can tell what the tool is and how it authenticates, but not what to pass for prompt, messages, system, run_id, max_tokens or temperature.

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% and only 1 of 10 params has an enum, so the description must compensate. It clarifies key_secret (stored secret name) and indirectly maps Grok/Claude/GPT to the provider values, but leaves bot, prompt vs messages, system, run_id, max_tokens and temperature entirely unexplained.

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 action and resource: a model gateway that calls Grok, Claude or GPT. The verb+resource are unambiguous, but it never contrasts itself against a sibling (there is no competing LLM-call tool, though it references secrets and ledger without positioning against 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?

Provides a prerequisite ('Bring your own provider key, stored first in Secrets') which implies when the tool is usable, but gives no explicit when-to-use guidance or alternatives. Usage is inferable rather than stated.

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?

With no annotations, the description carries the full burden and delivers well: it enumerates the three return states (auto_approve, needs_approval, deny), describes the approval card and tappable link, and crucially discloses the free-plan watch-only behavior (nothing counts as approved, logged for the weekly report). It omits error/edge handling and any rate or auth context, keeping it just short of exhaustive.

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, front-loaded with the purpose, then returns, then the plan caveat. None of it is redundant with the schema and every sentence carries actionable information.

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 usefully names the three outcome states plus the plan-gated behavior, which is the key context an agent needs. It stops short of detailing the fields inside an approval card or decision response, but the essentials are 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 description coverage is 100% and every sub-field of the nested 'action' object (type, target, summary, amount_usd, reversible) is already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies despite the nested-object complexity.

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 action ('check whether the user's rules auto-approve' a consequential action) with the resource and the pre-action timing. This clearly distinguishes it from siblings like approve_get_rules (reads rules) and approve_get_decision (retrieves a decision already made), since this tool is the pre-flight check.

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?

'Before a consequential action' gives an explicit trigger condition, and the free-plan sentence directs the agent to 'ask your user as you normally would' in that context. It does not, however, name alternatives such as approve_get_decision for reading an existing decision, so the routing is implied rather than spelled out.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It states the tool checks approval status and implies a read-only check, but it does not describe permissions, idempotency, error handling, rate limits, or the full set of possible statuses, leaving significant transparency gaps.

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 two compact sentences with no wasted words. The core purpose is front-loaded, followed immediately by the conditional usage rule, making it easy for an agent to parse.

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 simple two-parameter check tool with no output schema and no annotations, the description provides the essential purpose and a usage condition. However, it does not describe the possible return statuses (e.g., pending) or what the response contains, leaving the agent to infer the full decision workflow.

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 description coverage is 0%, so the description must compensate for the two undocumented parameters. It names card_id and card_token and indicates they identify the approval card, but adds no format, source, or constraint details beyond restating the parameter names.

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 and resource: checking whether the user approved or rejected an approval card. It is clear what the tool does, but it does not distinguish itself from siblings like approve_check_action or approve_get_rules, leaving some ambiguity about which approval tool to choose.

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?

It gives a clear usage directive: 'Only act when status is approved.' This tells the agent how to use the result, providing context without exclusions. However, it does not name alternative tools or explain when not to use this tool.

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?

With no annotations, the description must carry the behavioral burden. 'Show' implies a read-only operation, and the mention of default starter rules adds scoping context, but it doesn't explicitly confirm non-destructiveness, auth requirements, or return format.

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 a single, front-loaded sentence with no wasted words. It efficiently communicates the action, scope, and fallback behavior.

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 read tool with no output schema and no annotations, the description is largely complete. It states what is returned (rules in effect) and the fallback case, though it could mention that it doesn't require any input.

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 tool has zero parameters, so the baseline score is 4. No additional parameter semantics are needed.

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 ('Show') and resource ('rules in effect'), and clarifies the scope as either your key's rules or default starter rules. It distinguishes from the sibling approve_set_rules, though it doesn't explicitly contrast with approve_check_action or approve_get_decision.

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 explicit guidance on when to use this tool versus alternatives like approve_check_action or approve_get_decision. The parenthetical about default starter rules provides some context, but no when-to-use or exclusions are stated.

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?

With no annotations, the description carries the full burden and discloses real behavior: precedence ("first matching rule wins"), the default fallback ("anything unmatched needs approval"), the auth requirement, and the preview/confirm flow. The main gap is that it never states whether existing rules are replaced or merged, which matters for a set-type mutation.

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?

Dense and front-loaded, opening with the purpose and then packing the rule structure and workflow into compact notation. Every element earns its place, though the inline object notation sacrifices a little readability for density.

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 and 0% schema coverage, the description still covers purpose, the rule object structure, precedence, default behavior, auth, and the two-step confirm workflow. Only the replace-vs-merge semantics and return value are unaddressed, which are minor relative to what is provided.

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% and the schema types both params only loosely (rules as opaque array of objects), so the description must compensate. It explains the full rule shape ({name, when:{type, max_usd, min_usd, reversible, target_ends_with}, verdict with enum values}) and the confirm flag's preview semantics, adding substantial meaning beyond the schema.

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+resource ("Save the user's rules") and even defines the rule format, so an agent immediately knows this persists approval rules. It does not explicitly name the sibling it complements (approve_get_rules), but the purpose is unambiguous and distinct from read-oriented siblings.

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?

Gives a concrete procedural workflow: call once without confirm to preview, then again with confirm=true, plus the auth prerequisite ("needs an API key so they stay yours"). It does not compare against alternatives like approve_get_rules, but the invocation guidance is clear and actionable.

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?

With no annotations, the description carries the burden and does disclose real behavioral facts: free tier of 200 calls/day, 'Not metered', and that it returns an upgrade link. However it does not explain the return format, whether identity is inferred from the calling credential, or any error behavior.

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 efficiently packed sentences, front-loaded with the core action and the resource scope. The upgrade link and tier details are slightly promotional but still informative and brief.

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 no parameters, so the description must describe the payload, which it does by naming today's usage and the upgrade link. Given its simplicity, this is sufficient for an agent to call it 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?

The tool takes zero parameters, which sets the baseline at 4. The description's note that usage is shown 'for your key or IP' usefully clarifies that identity comes from the caller context rather than an input.

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 clear verb+resource: show today's usage and provide an upgrade link for the approval-rules tool. The '[approval-rules]' prefix distinguishes it from the many sibling usage_and_upgrade tools (budget_, loop_, memory_, wake_). It is clear but relies on the prefix rather than prose to differentiate from siblings.

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 guidance on when to call this versus alternatives. The description mentions 'your key or IP' and free-tier limits but never explains context, prerequisites, or when an agent should invoke this instead of, e.g., approve_get_rules or another usage_and_upgrade sibling.

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?

With no annotations, the description carries the disclosure burden and does so: "Read-only; sends nothing" clearly states the operation does not mutate state or emit notifications. It also describes the report's composition, though it doesn't cover formatting or size limits.

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 front-loaded sentence delivers the purpose and the report's contents, followed by a short behavioral tag. No filler; each clause about the report contents maps to an actual output field.

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 must communicate what comes back, and it lists the report sections and safety posture. For a zero-parameter read-only report this is essentially complete, minor gaps only around output format.

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 tool takes zero parameters, so there is nothing to document; baseline 4 applies. The schema is trivially complete at 100% coverage.

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 gives a specific verb ("Draft") and resource (a plain-English 7-day report) and enumerates its contents: actions checked, auto-approvals, escalations, top ask kinds, and rule suggestions. Combined with the '[approval-rules]' scope marker, an agent can distinguish it from the many other '*_weekly_report' siblings, which cover different domains.

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 implied — you call it to get a weekly summary of how your rules performed — but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as approve_get_rules or approve_check_action. Adequate but leaves routing to inference.

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?

With no annotations, the description carries the full burden and does so richly: sessions survive between calls and across days, {{secret:NAME}} values are typed only on that secret's allowed hosts and redacted from replies, handoff types the code without returning it, and the sandbox allowance (3 live, 60 min/day free) is disclosed.

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?

It is a dense single block, but the differentiator (persistent headless Chrome) is front-loaded and every clause carries information. Slightly better formatting of the action list would help, but there is little waste.

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 13-parameter tool with no annotations and no output schema, it covers return values (url, title, page text, links), persistence semantics, secret handling, rate limits, and the escalation path. The remaining gap is the undocumented top-level tuning params such as max_text and wait_s.

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?

At 0% schema description coverage the description must compensate, and it documents the steps sub-actions (goto, click, fill, type, press, select, wait_for, wait_ms, scroll, back, extract, eval, screenshot, clear_cookies) plus handoff's kind/note/fill/submit and the {{secret:NAME}} fill syntax. But top-level params like max_text, wait_s, text, and links go undocumented, leaving a significant gap.

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 mechanism: a real headless Chrome per named session with enumerated actions (open, run, screenshot, pause, kill, list, handoff). An agent can distinguish it from fetch (static retrieval) and handoff (human escalation) without opening the 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?

Gives a concrete conditional route — 'Stuck on 2FA? action handoff' — and implies use when logins/cookies/tabs must persist across calls. However, it never explicitly contrasts with sibling fetch for simple static requests, so the when-not guidance is inferred rather than stated.

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?

With no annotations, the description carries the full burden. It does disclose the returned content (limits, remaining, stopped reason, ledger tail) and one operational rule about close=true, which is real behavioral value. However, it never explains what actually happens when close=true (does it finalize/destroy the budget, is it reversible?), nor any auth or side-effect profile, which are the key unknowns for a tool with a mutating flag.

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 zero filler. The status/inspection content is front-loaded and the conditional instruction is placed last where it belongs.

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 description usefully enumerates what the caller gets back, and it flags the one required handle. The remaining gap is the semantics of the close parameter, whose consequence is never stated — a notable omission for a tool that may terminate a budget.

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 50%: handle is well documented in the schema itself, but close has no schema description. The description partially compensates by stating the condition for close=true, yet it leaves the flag's effect unspecified. This is a marginal improvement over the schema, not full coverage.

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 gives a specific read verb plus a concrete resource enumeration: spend vs limits, remaining budget, run-stopped status and reason, and the last 20 ledger events. An agent can tell this apart from budget_record, budget_reserve, or budget_open_budget by the read-only status framing, though it never explicitly names those siblings.

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?

It provides one conditional usage hint ('Set close=true when the run finishes') that tells the agent when to use a flag. Beyond that there is no guidance on when to call this versus budget_usage_and_upgrade, budget_weekly_report, or budget_record, and no stated prerequisites apart from the handle.

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?

With no annotations, the description carries the burden and does useful work: it discloses that a handle is returned, that the ledger is shared across sub-agents, and that the cap is genuinely enforcing ('cannot exceed the run cap'). It omits auth/tier requirements and what an exceeded-cap response looks like (the schema's mode field hints at this but the description doesn't).

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 action and scope, then the propagation rule that an agent most needs. No filler, and the handle-sharing constraint is given prominence rather than 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?

For a 7-param tool with no output schema and no annotations, the description covers the essentials: what it opens, that it returns a handle, and how to use it across a run. Missing only edge details such as what happens at the cap boundary and whether a companion close/status sibling must be used.

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 description coverage is 100%, so every one of the 7 parameters is already documented in the schema with defaults, enums, and tier limits. The description paraphrases the cap dimensions but adds no format, unit, or interaction detail beyond what the schema provides; baseline 3 is appropriate.

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 (Open) plus resource (a hard budget) and scope (one agent run, before it starts), and enumerates the cap dimensions: dollars, tokens, calls, wall-clock seconds. This clearly distinguishes it from siblings like budget_budget_status, budget_record, and budget_reserve, which manage an existing ledger rather than opening one.

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?

Gives clear lifecycle context ('before it starts') and tells the agent to propagate the returned handle to every sub-agent so they share one ledger. It does not, however, name when NOT to use it or explicitly point to a sibling alternative (e.g. budget_reserve vs this), so it stops short of full routing 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?

No annotations are provided, so the description carries the full burden. It adds genuine behavioral context by explaining the sign convention (positive = overage, negative = refund) and that the operation is non-blocking, but it omits error behavior, idempotency, and the fact that the handle ties sub-agents to one budget.

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, front-loaded with the action and followed by a behavioral note. Nothing is wasted, though the parenthetical could be tighter.

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 4-parameter mutation tool with no annotations, no output schema, and low schema coverage, the description explains the core reconciliation concept well but leaves parameter usage and error/retry semantics unaddressed.

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 25% (only 'handle' is documented). The description conveys the sign semantics relevant to the numeric inputs but never names usd, tokens, or note, so the other three parameters remain undocumented in both schema and description.

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: report the actual usage minus the reserved amount after a call. It clearly delineates this reconciliation step from the reservation step (budget_reserve) and status querying (budget_budget_status), so an agent can place it in the workflow without opening a sibling 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?

Gives clear context for when to call it ('After a call'), which is the key trigger. It stops short of naming the complementary siblings (open_budget/reserve) as explicit alternatives, but the sequencing is inferable.

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?

With no annotations, the description carries the burden and largely succeeds: it discloses the return contract (allowed=true/false with the tripping limit), the side effect (deducts), and the concurrency guarantee (atomic, so parallel sub-agents cannot slip under the cap). It stops short of disclosing auth needs, idempotency/refund semantics for reservations, or rate limits, which keeps it from 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?

Front-loaded with the timing instruction, then the return contract, then the failure protocol, then the concurrency rationale. Every sentence earns its place with no padding 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?

No output schema exists, and the description fills that gap by describing allowed=true/false results and the limit field. Combined with 100% schema coverage, an agent has enough to invoke correctly; only minor behavioral details (refund, expiry, auth) are absent.

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 description coverage is 100%, so all five parameters (usd, tokens, calls, note, handle) are already documented in the schema, including the handle format and sub-agent sharing guidance. The description adds essentially nothing parameter-specific beyond 'with your estimate', so baseline 3 is appropriate.

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 ('reserve' budget) and frames it precisely against the sibling budget_record workflow: reserve comes BEFORE the call, record comes after. The agent can tell this reserves/deducts budget rather than recording actual spend or reporting status. No ambiguity about the tool's 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?

Gives explicit when-to-use ('Call BEFORE each model call, tool call or sub-agent spawn with your estimate') and explicit when-not plus remediation ('When allowed is false, stop, do not retry, and return your partial result'). The operational flow is fully prescribed, leaving no inference for the agent.

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?

No annotations, so the description carries the full burden. It usefully discloses that the operation is a read (usage display), that it is not metered, and it quotes the free-tier quota of 500 calls/day. It does not state scoping (key vs IP resolution) or what happens near the limit.

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?

Compact single sentence with the namespace tag up front, then the action, then quota facts. Slightly overloaded by mixing a usage query with a promotional link, but nothing is wasted.

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, no-output-schema read tool, the description covers what the tool does, the quota context, and the upgrade angle. Missing only when-to-use guidance versus the many sibling usage/report tools.

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?

Zero parameters, so baseline 4 applies. The description explains the implicit subject (the caller's key or IP) that determines what usage is shown, which is relevant semantic context even without parameters.

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 concrete verb+resource: showing today's usage for the caller's key/IP, plus surfacing the upgrade link. That is more informative than most of the 'usage_and_upgrade' siblings, which share the name pattern but no distinguishing text.

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?

No guidance on when to call this versus budget_budget_status or budget_weekly_report, which are adjacent siblings in the same budget-guard namespace. The agent must infer that this covers 'today + upgrade pitch' while budget_status may cover something else.

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?

With no annotations provided, the description carries the burden and does well: it declares 'Read-only; sends nothing,' discloses the lookback window (last 7 days), and enumerates exactly what is computed, including the non-obvious 'dollars spent after a cap would have stopped them' metric. It omits any hint of cost, pagination, or rate limits, so it is not fully exhaustive.

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?

Front-loaded with the verb and subject, then the content list, then the safety note and a usage instruction. Two compact sentences do real work. Slightly dense with bracketed prefix and parenthetical, but no wasted sentences.

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?

Covers purpose, time window, output contents, safety profile, and a next action for a zero-parameter, no-output-schema tool. Only gaps are explicit routing versus sibling report tools and any note on record granularity, minor for a read-only report.

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?

Zero parameters with 100% schema coverage, so the baseline is 4. The description adds that scope is determined implicitly by the caller's key or IP, which is meaningful context for a parameterless tool where the agent otherwise could not know what data set is targeted.

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?

Specific verb (Draft) + resource (amine-English report of the last 7 days) + explicit content enumeration (runs, spend, over-cap runs, dollars spent past caps). Clearly distinguished from siblings like budget_budget_status or budget_record and parallel weekly_report tools for other subsystems.

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?

States the target scope ('for your key (or IP)') and instructs 'Show it to your user,' giving clear context for when to invoke it. It does not explicitly contrast with budget_budget_status, approve_weekly_report, or other report siblings, so an agent must infer the choice.

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?

With no annotations, the description carries the full burden and does so well: it discloses self-pause plus alerting after 10 failed runs, UTC-only scheduling, {{secret:NAME}} substitution in requests, and the free-tier cap of 1,000 schedules + timers. What's missing is auth/permission requirements and whether operations are reversible, keeping it from 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?

Purpose is front-loaded in the first clause, followed by a compact action-by-action breakdown with concrete examples ('*/5 * * * *', '@hourly'). It is information-dense and slightly run-on in places, but nearly every phrase earns its place.

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 9-parameter, action-dispatch tool with no annotations and no output schema, the description supplies actions, scheduling syntax, request/queue payload shapes, failure behavior, and quotas. Return-value formatting is undocumented, but since no output schema exists the omission is minor.

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 description coverage is 0% across 9 parameters, so the description must compensate, and it does: it names name, schedule (with cron and @hourly syntax), request {url, method, headers, body}, queue/message, at, delay_s, webhook, and payload. It effectively documents the parameter surface inline, though it does not map every parameter to a specific action, so not a perfect 5.

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?

Opens with a specific verb+resource and scope: 'Run something on a schedule, even when your bot is offline,' then enumerates every supported action (set, list, history, pause, resume, delete, run_now, timer). An agent can immediately tell this is the recurring/one-shot scheduler distinct from sibling tools like wake_schedule_wake.

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 implied through per-action semantics (set = recurring, timer = fires once, run_now = immediate), which gives a competent agent enough to pick the right action. However, there is no explicit when-to-use/when-not guidance and no routing to alternatives such as wake_schedule_wake, so the guidance stops short of a 4.

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?

With no annotations, the description carries the full burden and does so well: it discloses that secrets are only sent to allowed hosts, that private networks are blocked, that redirects are not followed, that secret values are redacted from replies, and that timeout is capped at 30s. These are exactly the security and failure-mode facts an agent needs before invoking.

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?

A single dense paragraph that front-loads purpose, then constraints, then an Args list. Nothing is wasted, though the run-on security clause and trailing arg list make it slightly cramped to scan.

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 5-param tool with no output schema and no annotations, the description covers security behavior and redaction of the reply well. It leaves return shape (status codes, error format) and method defaults unstated, but the essentials for correct invocation are 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 0%, so the description must compensate. It names all five parameters and adds real semantics: where the {{secret:NAME}} placeholder may appear (url, headers, body) and the timeout_s cap of 30. It does not clarify the default method or the expected body/headers structure, leaving some gaps.

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 action (call any https API) plus the distinguishing mechanism (server-side filling of stored secrets via {{secret:NAME}}). This clearly separates it from siblings like browser, sandbox, secrets, and vault.

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 implied by the secret-injection mechanism, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative (e.g., when to prefer browser over fetch). The security constraints hint at what will fail but do not route the agent between tools.

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?

No annotations exist, so the description carries the burden. It usefully discloses the workflow (one-tap link, bot polls and continues) and the free-key limitation, but says nothing about per-action behavior, especially the destructive/irreversible nature of 'cancel', or auth requirements.

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?

Very dense and front-loaded (scenario first, actions second, caveat last) with no filler. The telegraphic style is efficient, though it borders on too terse for the parameter surface.

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 8-parameter, multi-action tool with no annotations, no output schema, and 0% schema coverage, the two-sentence description is insufficient—an agent has no guidance on most parameters or the differing behavior of each action.

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 description coverage is 0% for 8 parameters, so the description must compensate. It only names the valid action values (create/status/cancel/list); the other seven params (id, ui, url, kind, note, run_id, notify_email) remain entirely undocumented.

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 scenario and verb: a human-handoff for captcha/2FA where a person gets a one-tap link and the bot polls to continue. It's distinguishable from siblings like approve_* or wake_*, though the multi-action nature (create/status/cancel/list) blurs the single purpose somewhat.

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 trigger condition is explicit (bot hits captcha/2FA), and a constraint is given (free keys are watch-only). It does not name alternative tools or clarify which action to pick for a given situation, but the when-to-use context is clear.

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?

With no annotations, the description carries the full burden and does so well: it discloses the free-tier quota (50 inboxes), the URL-rotation behavior on re-create, where events land (queue inbox.<name>), and the need to ack. It omits auth/permission requirements and failure behavior, so not 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?

Information-dense and front-loaded with the purpose before the action list. Every clause earns its place, though the telegraphic semicolon chains make it feel slightly run-on rather than crisp prose.

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 2-param, no-annotation, no-output-schema tool, it covers lifecycle, quota, return value ('create (name) -> url'), and cross-tool integration adequately. Auth requirements are the main omission an agent might still need.

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 description coverage is 0%, so the description must compensate. It ties 'name' to create, URL rotation, and the queue naming convention (inbox.<name>), and lists the enum values inline. However it does not specify name format, uniqueness, or what list/delete require, leaving the compensation partial.

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: 'Give a bot its own public webhook URL', then enumerates the exact actions (create/list/delete). It clearly distinguishes itself from the sibling queue tool by explaining that events land in the inbox and are read via queue, so an agent can route correctly without opening either 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?

Gives per-action guidance (create produces a URL you can POST anything to; create again rotates the URL) and explicitly names the alternative workflow (read events with the queue tool, pull then ack). It lacks any explicit exclusions or edge-case guidance, so it stops short of a 5.

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?

With no annotations, the description carries the full burden. It discloses meaningful behavior per action (record writes a run with status/usd/tokens; feed returns bot runs plus Agent Cost Log costs and failed API calls; rollup aggregates per day), but omits permission requirements, mutation side effects, and rate/limit behavior.

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?

Front-loaded purpose followed by tightly packed per-action parameter lists; dense but every clause carries information. The run-on style is slightly hard to parse but wastes little.

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 14-parameter, three-action tool with no annotations and no output schema, the description is fairly complete: it covers all actions and squats each parameter into its action context. Missing only return-shape and permission/limit detail, which the tool's simplicity partly excuses.

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 compensate, and it largely does: it assigns parameters to each action (record takes bot/status/run_id/kind/usd/tokens/model/ms/note; feed takes since/bot/status/limit; rollup takes days) and supplies the status enum values. This mapping is information the flat schema does not convey.

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 (bot run ledger + cost view) and enumerates three concrete actions (record, feed, rollup). It's clear what the tool does, though it does not explicitly differentiate itself from cost-related siblings like budget_record or budget_budget_status.

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 action list implies when each mode applies (record a run, read a feed, aggregate by day), but there is no explicit when-to-use guidance or routing against sibling tools that also touch budgets/costs. Usage must be inferred from the action semantics.

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?

No annotations are provided, so the description carries the full burden. 'Read' signals a non-mutating operation and the listed payload fields give useful output context, but auth requirements, behavior on missing/unknown slugs, and any rate limits are undisclosed.

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?

A single front-loaded sentence naming the resource and payload, with a terse args note. No wasted text, though 'Args: slug' adds little.

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 one-parameter read with no output schema and no annotations, enumerating the returned fields is genuinely helpful. Still missing are error/not-found behavior and permission expectations, leaving it only adequately complete.

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 0% schema description coverage, the description must compensate, but 'Args: slug' only restates what the schema already declares (a required slug string). No format, casing, or resolution rules for the slug are added.

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 ('Read one library entry') and enumerates the fields returned (recipe, tools, version, signature, install/success counts). The word 'one' implicitly differentiates it from library_search, but no sibling is named explicitly.

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 'Args: slug' note implies this is for retrieving a single known entry, which weakly suggests library_search as the way to discover slugs. However, there is no explicit when-to-use/when-not guidance or naming of the alternative tool.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the quota cost ('Counts one install per account') and enumerates the returned artifacts, but says nothing about permissions, whether an existing install is overwritten, or failure modes for an already-installed bot.

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?

A single sentence, front-loaded with the action, then returns, quota, and args. Dense but every clause adds something; no padding.

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 no annotations, so the description does the reporting work well with the returns list and quota note. However, for a mutating install operation it omits provenance of the slug, auth/permission needs, and overwrite/error behavior.

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 description coverage is 0%, so the description must compensate. 'Args: slug' merely restates the parameter name; it does not explain what a slug is or where to obtain it (presumably from library_search), leaving the single required argument underspecified.

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 ('Clone a library bot into this bot') that is clearly distinct from siblings like library_get, library_publish, and library_search. It also says what comes back (recipe steps, tools, prompt, memory_seed), but it never names an alternative sibling explicitly.

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 when-to-use or when-not-to-use guidance; the agent must infer that this is the install counterpart to library_search. The only constraint mentioned ('Counts one install per account') is a quota fact, not routing advice.

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?

With no annotations, the description carries the full burden and does meaningful work: it discloses ownership/signing semantics, an automatic content-scanning block with a concrete escape hatch, and that re-publishing creates a new version. It omits update/overwrite semantics and failure/error behavior, so not a full 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?

Purpose is front-loaded in the first clause, followed by ownership, safety constraint, and the compact args list. Dense but every sentence carries information; the long inline data-field enumeration is the only mildly heavy element.

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 nested-object mutation tool with no output schema and 0% schema coverage, the description covers the top-level args but leaves the nested field names (steps, memory_seed, handoff_inbox, forked_from, works_with) unexplained and does not state what publishing returns or how version conflicts are handled.

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 description coverage is 0%, so the description must compensate, and it does: slug gets a concrete format constraint (3-48 lowercase/dashes) and the nested data object's fields are enumerated. It stops short of typing or marking which nested fields are required/optional beyond '?'.

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 ('Publish or update (new version) a reusable bot recipe') and names the library namespace, which cleanly separates it from siblings like library_get, library_install and library_search. An agent can identify the operation without opening the 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?

Gives preconditions rather than just context: the publishing key owns and signs the recipe, and publication is auto-blocked if content contains secrets, with {{secret:NAME}} placeholders as the prescribed workaround. It never explicitly names a sibling alternative (e.g. library_install for consuming recipes), so it stops short of a 5.

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?

With no annotations, the description carries the full behavioral burden. It does disclose a genuinely non-obvious consequence — that this call feeds library ranking — but omits whether it is a write/mutation, whether it is idempotent, and any permission requirements.

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 short, front-loaded sentences with the behavioral consequence placed before the arg list. No padding, though the trailing 'Args:' list is slightly redundant for a two-parameter tool.

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?

No output schema and no annotations, so the bar is higher. The description covers the core invocation trigger and argument names but says nothing about permissions, failure modes, or what the agent gets back, leaving moderate gaps.

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 description coverage is 0%, so the description must compensate. It names both parameters and the type of 'ok' (boolean), which covers the two required args, but adds no meaning about the slug format or the semantics of the ok flag beyond its type.

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: reporting whether an installed recipe worked, scoped to the bot-library namespace. It is distinguishable from siblings like library_install and library_publish, though it is not explicitly separated from library_report, which the phrase 'report whether it worked' could be confused with.

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?

Gives a clear trigger condition ('after running an installed recipe'), which implies when the tool should be called. However, it offers no exclusions or explicit routing against the similarly named library_report sibling, leaving the agent to infer the distinction.

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?

With no annotations, the description carries the full burden. It does disclose a genuine behavioral fact beyond the schema: 3 reports from different accounts auto-pause the entry. However, it omits auth requirements, what a successful submission returns, and whether reports are reversible, so the disclosure is partial.

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 short sentences, front-loaded with the action, then the consequence, then the args. Minimal waste, though the terse args list could carry a little more substance.

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 mutation with no annotations and no output schema, the mention of auto-pause is valuable, but the definition is silent on the return value, the optionality/format of reason, and any per-account rate limits.

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 description coverage is 0%, so the description must compensate, yet it only lists 'Args: slug, reason' with no added meaning. It does not say that slug identifies the target entry or what the optional reason should contain, adding essentially nothing over the property names.

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 (Report) and resource (a library entry), and enumerates the qualifying conditions (broken, unsafe, spammy). It is distinguishable from siblings like library_rate or library_install, though it never explicitly names an 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 enumerated report conditions imply when to use it (on broken/unsafe/spammy entries) but there is no explicit when-not guidance, no prerequisites, and no named alternative such as library_rate for other feedback.

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?

No annotations are provided, so the description carries the full burden. It does disclose meaningful traits — results are ranked by real installs and reported success, and no API key is required — but says nothing about return shape, pagination, or behavior when q is omitted.

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?

A single front-loaded sentence covers purpose and ranking, followed by a compact args line. Tight and largely waste-free, though the bracketed prefix is mildly noisy.

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 simple 2-optional-param search with no output schema and no annotations, the description covers purpose, ranking, parameter cap, and auth. It still omits what the results look like and what an empty q returns, leaving gaps an agent might need.

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 description coverage is 0%, so the description must compensate. It marks both params optional (q?, limit?) and adds the meaningful cap 'limit max 50', which is beyond the schema, but leaves the semantics of q (free-text query? prefix?) completely unexplained.

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+resource: finding bot recipes published by other bots, and adds the ranking basis (real installs and reported success). This clearly distinguishes it from sibling library_* tools like library_get, library_install, and library_publish, though it never names 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?

Usage is implied by the verb 'find' — an agent can infer this is the discovery step before library_get or library_install — but there is no explicit when-to-use/when-not guidance or reference to the alternatives. The 'No key needed' note gives useful context but is not routing 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?

With no annotations, the description carries the full burden and does substantial work: it discloses auto-release at expiry, that the fence increments per new holder, ttl_s defaults to 60, wait_s is capped at 25, and there is a 1,000-lock free-tier ceiling. It still omits failure/contention behavior and what each action returns, so it is not fully transparent.

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?

Front-loaded with the resource definition before the action list, and the terse per-action parentheticals pack a lot of parameter-to-action mapping into little space. The compressed shorthand is efficient but slightly dense, costing a bit of readability.

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 6-parameter, 5-action coordination primitive with no annotations and no output schema, the description covers acquisition semantics well but never says what status/acquire/list return (holder, token, fence, lock inventory), leaving the agent to guess at return values.

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 compensate, and it largely does: it maps parameters to actions (name/holder/ttl_s/wait_s for acquire; name/token/ttl_s for renew; name/token for release; name for status), and supplies a default and a cap not present in the schema. It still does not explain where the token comes from (presumably acquire) or its format, so meaning is incomplete for one parameter.

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 (named locks/leases shared across all bots on the account) and enumerates the exact action set it supports (acquire, renew, release, status, list). The example (browser.lock) and the note that locks are account-wide make it immediately distinguishable from siblings like queue, cron, or handoff.

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 action list implies when each mode applies (acquire to take a lease, renew to extend, release to free, status/list to inspect), which is meaningful guidance. However, there is no explicit statement of when a caller should prefer this over related coordination tools (queue, cron, handoff), and no stated preconditions beyond TTL defaults.

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?

With no annotations, the description carries the full burden and does well: it discloses the three verdicts (ok, loop_detected, halted), the Pro halt-on-loop behavior, and the Free watch-only mode returning would_halt. It stops short of 5 by omitting any auth/rate-limit or persistence details.

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?

Front-loaded with the bracketed tag and the core instruction, then the mechanism and mode differences. Every sentence carries information, though the Pro/Free sentence is dense and could be split.

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 6-parameter tool with no output schema and no annotations, the description supplies the missing return-value semantics (the verdicts) and the mode-dependent behavior. It is close to complete, with only minor missing detail on run lifecycle handling that the schema covers.

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 schema already documents all six parameters in detail (normalization, defaults, min/max). The description only echoes the fingerprint inputs (tool + normalized args + error) without adding syntax or format meaning beyond the schema, so the baseline 3 is correct.

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 action and resource: after each step, call this tool, which 'fingerprints the call (tool + normalized args + error)' and returns a verdict. It is clear what the tool does. It does not explicitly differentiate itself from the sibling loop_loop_status, so it falls short of a 5.

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?

It gives explicit timing ('Call AFTER each tool call or agent step') and prescribes behavior on a hit ('stop the run, do not retry, and tell your user'). That is strong contextual guidance, but it names no alternatives or when-not-to-use cases relative to the other loop_* siblings, so it stops at 4.

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?

With no annotations, the description carries the full burden, and it does disclose the return content including the 10-step truncation cap, which is genuinely useful behavioral detail. However, it never states that this is a safe read-only inspection, nor how to retrieve steps beyond the last 10, so the safety and pagination profile is left unstated.

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?

A single sentence with the scope, the key state (halted), and the return breadth front-loaded. No filler, no repetition of the title.

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 one-parameter read tool with no output schema, the description covers what is returned and the step cap, which is close to sufficient. What is missing is the read-only nature and how run_id relates to the sibling per-step check, but these are minor gaps at this complexity.

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 run_id description already explains the id's format and the requirement to reuse it across steps and sub-agents. The description adds nothing about run_id, so it sits at the baseline for a fully documented parameter.

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 ("Show") and a specific resource (a run's loops, halted status, last 10 steps), so the agent knows exactly what it gets back. It does not explicitly distinguish itself from the sibling loop_check_step (per-step vs whole-run scope), leaving that separation to inference.

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: the tool is for inspecting a run's aggregate loop state. There is no stated condition for choosing it over loop_check_step, no prerequisite, and no note on when it should not be used.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the free tier (500 calls/day), that the tool is not metered, and the $49/month upgrade offer, but it never explicitly states this is a read-only, non-mutating operation or what the response contains.

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?

A single tight sentence that front-loads the action, with the pricing/free-tier detail following. The parenthetical URL is minor clutter but nothing is wasted.

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, read-only reporting tool with no output schema and no annotations, the description covers what it returns at a high level (usage + upgrade link) and the free-tier constraint. Adequate for correct invocation.

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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies for a no-parameter tool.

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 (Show) and resource (today's usage for your key or IP) plus the upgrade link, giving a clear operation. It doesn't explicitly differentiate itself from the many sibling '*_usage_and_upgrade' tools beyond the shared naming convention, so it falls short of a 5.

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 mention of 'today's usage' and the free-tier limit implies the context of checking quota or seeking an upgrade, but there is no explicit when-to-use statement, prerequisites, or routing to alternative siblings. Usage is only implied.

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?

With no annotations provided, the description carries the full burden and does state the key behavioral trait: 'Read-only; sends nothing,' which tells the agent this is a pure, side-effect-free read. It doesn't mention generation cost, latency, or narrowing options, but for a zero-param read tool the safety disclosure is the material one.

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 compact sentences with no filler: the deliverable and its scope lead, the safety disclaimer and usage instruction follow. Every clause earns its place.

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?

No output schema exists, and the description compensates by naming exactly what the report contains (runs, loops caught, wasted repeat steps, worst offenders) and its format (plain-English). Nothing an agent needs in order to call and relay this tool 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?

The tool takes zero parameters, so the baseline is 4. The description correctly introduces no parameter claims, and the parenthetical '(or IP)' only hints at implicit key resolution rather than describing an input field.

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?

Specific verb ('Draft a plain-English report') plus scope ('last 7 days ... for your key (or IP)') and an enumerated content list (runs, loops caught, wasted repeat steps, worst offenders). The '[loop-breaker]' domain tag cleanly separates it from the other *_weekly_report siblings (approve_, budget_, memory_), so an agent can route correctly without opening the 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?

'Show it to your user' gives a downstream usage instruction, and the 7-day window implies the reporting context. However, there is no guidance on when to prefer this over loop_loop_status or loop_check_step, and no exclusion conditions — usage is implied rather than stated.

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?

With no annotations, the description carries the load, and it does disclose the returned fields (step, size, time) and that results are scoped to "your key". It does not explain what "recent" means (count/limit), ordering, or read-only guarantees, so meaningful gaps remain.

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 economical sentence with the resource and scope front-loaded and the returned fields in a compact parenthetical. No wasted text; could only be marginally tightened.

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 simple read tool with one optional param, complete schema coverage and no output schema, the description covers purpose, scope, and return fields adequately. Only the ambiguity of "recent" (limit/ordering) is left open.

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 param is well-documented there, but the description still adds meaning: omitting run_id returns checkpoints across all runs, a conditional behavior not stated in the schema. That elevates it above the baseline 3.

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+resource ("List recent checkpoints") and clarifies scope ("for one run or all runs on your key"), which cleanly separates it from memory_save_checkpoint and memory_resume. It doesn't name siblings explicitly, but an agent can tell it is the read/inspection counterpart to the save tool.

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 "for one run or all runs" implies when the run_id matters versus when it can be omitted, which is useful guidance. However, it gives no explicit when-to-use versus alternatives like memory_resume, and no exclusions or prerequisites.

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?

With no annotations the description carries the full burden, and it does real work: it discloses the conditional behavior (returns state only if a checkpoint exists), the exact return content, the resume-and-skip semantics, and the "(Pro)" tier gate. It omits whether the call itself mutates anything or requires further permissions, which keeps it short of 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?

The imperative trigger is front-loaded in the first clause, and every sentence carries load: trigger, conditional outcome, fallback. No padding.

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 one-parameter, no-output-schema tool this covers what an agent needs: when to call it, what it returns, and what to do when there is no checkpoint. The absence of annotations leaves a small gap around side effects/permissions that the description does not close.

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 description coverage is 100%, so run_id is already fully documented in the schema, including the stable-across-restart requirement. The description adds only the framing that run_id is matched against existing checkpoints, which is marginal beyond the schema baseline.

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+resource (resume a run from a checkpoint) and defines scope: it returns the last step, state and done list. It is distinguishable from memory_save_checkpoint and memory_list_checkpoints by its resume-and-continue framing, though it never names those siblings explicitly.

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?

"Call FIRST when a run starts" gives a clear, actionable trigger, and "If none, start fresh" covers the fallback branch. It stops short of naming the complementary tools (save_checkpoint, list_checkpoints), so the routing is implied rather than explicit.

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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses a 256 KB size envelope, the retention policy (last 20 per run, kept 30 days), plan-gated behavior (Free watch-only saves nothing and returns would_save with exactly what would have been stored), and a security constraint (no passwords or API keys). That is unusually rich operational context.

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?

Four sentences, front-loaded with the action and timing, and each sentence carries distinct, necessary information: payload/size, retention, free-tier return semantics, security warning. No filler or restatement of the name.

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 mutation tool with no annotations and no output schema, the description covers what is stored, for how long, plan-dependent behavior, and the free-tier return field. Only minor gaps remain, such as error behavior and the explicit relationship to memory_resume for the recovery path.

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 already 100%, so the baseline is 3, but the description adds meaning beyond the field docs by enumerating what state should hold (cursor, ids done, partial results) and imposing a 256 KB limit on it. The 'ids done' phrasing also links to the otherwise-undocumented-in-description 'done' parameter.

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 ('save_checkpoint', 'Call after each completed step with the state you would need to continue') and makes the scope concrete with examples (cursor, ids done, partial results). It is clearly distinguishable from siblings like memory_resume and memory_list_checkpoints without opening any 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?

Gives explicit timing ('after each completed step') and what the payload should contain, which is real when-to-use guidance. It does not name an alternative tool or a when-not condition (e.g., relative to memory_resume), so it falls short of the top band.

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?

No annotations are provided, so the description carries the full burden. It discloses the free tier limit (500 calls/day), the not-metered behavior, and the upgrade cost/URL, which are useful non-obvious traits. But it doesn't state whether this is a read-only operation, what 'key or IP' scoping means for auth, or the response shape.

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?

Front-loads '[run-memory]' namespace and the core action, packs free tier and upgrade info efficiently. A single sentence but dense; no wasted words.

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-param informational tool with no output schema, the description covers the key facts (usage, upgrade link, pricing). It doesn't explain return format or what 'today's usage' includes, which would help an agent know whether to call it. Adequate but minimal.

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?

Zero parameters, so the baseline is 4. The description correctly implies no inputs are needed and identifies the implicit scoping (key or IP).

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 (Show) and resource (today's usage for key or IP) plus the upgrade link. The 'usage_and_upgrade' pattern is a sibling family tool, and the description clearly identifies what this instance covers (memory/run-memory) versus budget/loop/approve/wake variants.

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 'Not metered' and free tier limit provide clear context on when this is useful. However, it doesn't explicitly say when to use this versus memory_weekly_report or memory_list_checkpoints, or that no parameters are needed to get the key's usage.

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?

With no annotations provided, the description carries the full behavioral burden and explicitly discloses that the operation is read-only and sends nothing. It also explains plan-dependent behavior by noting checkpoints saved (Pro) or that would have been saved (free). It does not mention permissions or rate limits, but for a read-only report that is a minor gap.

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 tightly packed clauses with no wasted words: first the purpose and scope, then the safety property. The most important information is front-loaded, and the colon list efficiently enumerates report contents.

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, no-output-schema, read-only tool with no annotations, the description covers purpose, time scope, report contents, and side-effect profile well enough for correct invocation. The only meaningful omission is when to choose this tool over the many sibling weekly_report and memory tools.

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 input schema has zero parameters, so parameter semantics are not applicable. Per the rubric, 0 params gives a baseline of 4; the description correctly adds no irrelevant parameter 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?

The description gives a specific verb ('Draft'), resource ('plain-English report'), and scope ('last 7 days'), plus the exact contents: runs and checkpoints saved or that would have been saved. It clearly distinguishes the tool from checkpoint-management siblings like memory_list_checkpoints and memory_save_checkpoint, but it does not explicitly name an alternative or contrast itself with the other weekly_report tools.

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 says what the tool produces but never states when to use it versus alternatives, despite many sibling tools including approve_weekly_report, budget_weekly_report, and loop_weekly_report. 'Read-only; sends nothing' describes behavior, not selection criteria, so there is no real usage 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?

With no annotations, the description carries the full burden and does most of it: at-least-once delivery, visibility timeout redelivery, promotion to dead letters after max_attempts, and concrete free-tier quotas (1,000 queues, 10,000 pushes/day). It omits auth requirements and whether purge is irreversible, and the 'dead_only?' flag implies a parameter not present in the schema.

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 dense sentences, front-loaded with the resource, then an action->parameter index, then the delivery semantics and quota. Every clause carries information; the parenthetical argument lists avoid re-stating what is already in the schema.

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 10-parameter, no-annotation, no-output-schema tool it covers actions, control flow, and limits well. The remaining gap is return shape: it never says pull yields message ids that ack requires, nor what stats/dead return, which an agent needs to complete the pull-ack cycle.

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% across 10 parameters, so the description must compensate and does: it scopes each parameter to its action (push takes queue/message/messages[]/delay_s/max_attempts; pull takes queue/max/visibility_s; nack takes ids/delay_s/error; purge takes dead_only) and adds a constraint the schema lacks (max<=10). This is the only source of parameter meaning in the definition.

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 names a specific resource ('Durable job queues for bots') and enumerates all eight actions with their arguments, so an agent knows exactly what surface this tool exposes. No sibling in the list (cron, wake_*, lock) serves the same durable-message-queue role, and the action list makes the distinction self-evident.

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?

It gives per-action usage semantics in-line: 'ack when done or the message returns after visibility_s', nack with error/delay, max<=10 on pull. That tells an agent how to drive the at-least-once loop, but it never states when to prefer this tool over cron/wake or when the queue pattern is inappropriate.

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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the counting algorithm (sliding window), the return shape of take (allowed, remaining, retry_after_s), and a quota limit (free 200 counters). It does not mention persistence, permissions, or cross-bot auth requirements.

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?

Highly front-loaded and dense: identity first, then a compact action/return breakdown, then two short trailing facts (sliding window, free tier). Every clause earns its place; nothing is padded.

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 4-parameter tool with no annotations and no output schema, the description covers the essentials: what it is, its actions, its return values, and its quota. Minor gaps remain around error/quota-exceeded behavior and auth, but the core picture is complete.

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 compensate, and it does: it maps parameters to actions, explains the limit format ('6/6h'), and marks n as optional ('n?'). The meaning of n is still left implicit, but overall it adds substantial meaning beyond the bare schema.

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: 'Shared rate counters across all your bots', with a concrete example ('6 posts per 6h across all lanes'). This clearly conveys a distributed rate-limiting counter. However, it does not differentiate from the similarly named sibling library_rate, which likely also deals with rates.

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 implied rather than stated: the action list (take/peek/list) shows the operating modes but there is no explicit 'use this when...' guidance or exclusion against alternatives like library_rate or lock. An agent can infer take is for consuming quota and peek for inspection, but must reason it out.

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?

No annotations are supplied, so the description carries the full disclosure burden. It does reveal the return contents and the ui=openui live-card behavior, which is genuinely useful, but says nothing about permissions, whether the call is read-only, or any cost/rate implications.

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 short sentences, no filler, and the core identification of the tool's output is front-loaded before the parameter guidance. Every sentence carries distinct information.

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 enumerating the returned timeline components, and it documents both parameters. For a two-parameter read tool this is nearly sufficient; only permissions and run_id format are unaddressed.

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 description coverage is 0%, so the description must compensate and largely does: it explains that run_id is optional and what omitting it produces, and that ui=openui yields a live card. Only the accepted format/identity form of run_id is left unexplained.

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+resource pair ("Timeline of a run") and enumerates exactly what the timeline contains: steps, loops, checkpoints, spend, stop point. That is far more concrete than the bare name 'replay', though it never contrasts itself with adjacent-looking siblings such as memory_list_checkpoints or loop_loop_status.

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?

Gives explicit conditional usage in both directions: pass run_id to inspect a specific run, omit it to list recent runs. It does not name alternative tools or state exclusions, but the two modes of operation are 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?

With no annotations, the description carries the full burden, and it does disclose the summary's contents and that the tool is opt-in with mutating actions (subscribe/unsubscribe). It omits the side effects of subscribing (external email/webhook delivery), delivery cadence, permissions, and reversibility of unsubscribe.

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 dense sentence with the identity tag up front, the payload next, and the supported actions last — every clause carries information. It is efficient, though the terseness leaves real gaps rather than eliminating waste.

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 four undescribed parameters, no annotations and no output schema, the description is too thin: it never explains how email and webhook_url relate to subscribing, what preview returns, or what happens on unsubscribe. The action vocabulary is the only parameter-level information the agent gets.

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% and four parameters (ui, email, action, webhook_url) have no descriptions. The description implicitly supplies the allowed values for 'action' (subscribe/unsubscribe/preview), but never names the parameter and gives no clue that email vs. webhook_url are alternative delivery channels or what the 'ui' enum means.

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 names a concrete deliverable: an opt-in daily owner summary whose content is enumerated (loops stopped, spend blocked, approvals waiting), plus the three modes it supports. That is much clearer than the bare name 'report'. It does not, however, distinguish itself from the many *weekly_report siblings.

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?

Listing 'subscribe, unsubscribe, preview' implies the three usage modes, and 'opt-in' signals that it must be enabled before it fires. But there is no guidance on when to prefer this over approve_weekly_report / budget_weekly_report, nor which action to pick under which circumstance.

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?

With no annotations provided, the description carries the full burden and does so well: it discloses that state (files, installed packages, running processes) survives between calls and across days, the auto-pause/resume behavior, quota limits (3 sandboxes, 60 run-minutes/day), and the secrets isolation guarantee. It omits what kill does to persisted state and what happens when quotas are exhausted.

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 dense and front-loads identity before enumerating actions, lifecycle, and quota, so the most decision-relevant facts come first. It is long and reads as a run-on list of actions, but nearly every clause carries information the schema does not.

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 no annotations, so the description should arguably explain what run/status/list return (stdout, exit code, sandbox state), which it does not. For a 13-parameter tool this leaves a real gap, though the action coverage and persistence/secret semantics are otherwise solid.

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 description coverage is only 8% (just the secrets field), so the description must compensate and largely does, mapping cmd/cwd/timeout_s/background to run, path+content/content_base64 to write_file/read_file, and ns/prefix/dir to the sync actions. The notably absent piece is the `name` parameter, which selects which sandbox is targeted and is never explained.

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 resource (a named Linux sandbox with Python, Node, shell, internet) and enumerates the exact actions it supports, so an agent can tell immediately this is the code-execution tool and not a sibling like ai, browser, or fetch. It also distinguishes itself by the persistence model ('pauses instead of dying').

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 implied through the action list and the store-sync coupling ('sync_from_store... copy your stored files in'), and lifecycle facts (created on first use, auto-pause, ~1s resume) inform when it is cheap to call. However, there is no explicit 'use this when you need X instead of Y' framing against siblings, so guidance remains inferential.

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?

With no annotations, the description carries the full burden and does well: it discloses that values are write-once from the bot's perspective ('your bot never sees them again'), that list returns 'names only, never values', and that allowed_hosts scopes where a secret may be sent. It omits error/overwrite behavior on re-set and what happens to references after delete.

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?

Dense and front-loaded: purpose first, then per-action param semantics, then the integration hint and quota. Every clause carries information (naming convention, host scoping, value non-disclosure) with no 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 4-param mutation tool with no annotations and no output schema, the description covers parameters, secrecy guarantees, quota and consumption path. Minor gaps remain around failure modes and lifecycle after delete, which the absent output schema cannot fill.

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 description coverage is 0%, yet the description compensates for every one of the four parameters: name ('UPPER_SNAKE_CASE'), value, allowed_hosts with a literal example array, and the action enum's three modes with their distinct behaviors. An agent could construct a valid call from the prose alone.

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 ('Store API keys and tokens') and enumerates the three concrete actions (set/list/delete), which is more precise than the bare name 'secrets'. The '[bot-secrets]' prefix and the {{secret:NAME}} reference distinguish it from adjacent siblings like vault, store and library_get.

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?

It explains the consuming workflow explicitly: 'Use them with the fetch tool as {{secret:NAME}}', and the action list maps each mode to its effect. It stops short of saying when to prefer this over sibling credential stores such as vault or store, so usage context is clear but alternatives are not named.

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?

With no annotations, the description carries the full burden and delivers real behavioral context: durability across restarts, account-wide sharing, namespace defaulting, and concrete quotas (100 MB, 100k items, 256 KB values, 4 MB files). It omits auth requirements and the destructive consequences of delete/file_delete, keeping it from 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?

Front-loaded with the core identity before the action list and quotas, with no filler sentences. It is dense and long, but every clause maps to a real action or parameter, so the length is justified by the tool's complexity.

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 13-parameter, no-annotation, no-output-schema tool, the description covers actions, key parameters, namespacing, and limits well. It stops short of describing return shapes per action, which is a minor gap given no output schema exists.

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% across 13 params, so the description must compensate — and it largely does, documenting value/ttl_seconds/if_version (compare-and-set), by, prefix/after/limit, name/content_base64/content_type, and the ns default. Only key and action are left to the schema, so coverage is strong though not exhaustive.

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 (durable key-value + file storage for the bot) and enumerates every action, so an agent knows exactly what it is. It does not explicitly distinguish itself from storage-adjacent siblings like vault, secrets, or memory_*, so it falls short of a 5.

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 lists actions but never says when to reach for this tool over alternatives such as memory_save_checkpoint or vault. The 'survives sandbox restarts' line hints at persistence scope, but there is no explicit when/when-not guidance or named alternative.

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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: publish fan-out semantics ('copies each message into every subscribed queue'), the delivery guarantee while a bot sleeps, the read-and-ack workflow via the queue tool, and a quota ('Free: 500 subscriptions'). It omits auth/permission requirements and error behavior, so not a full 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?

The definition is dense and front-loaded: bus identity first, then actions, then the key delivery nuance and quota. Every sentence contributes information with no filler. Slightly run-on, but efficient.

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, no annotations, and 6 params at 0% coverage, the description does a good job conveying the core pub/sub workflow and how results are consumed (read via queue, ack). It leaves gaps on list output, error handling, and the 'from' field, but an agent can select and invoke the main flows 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 description coverage is 0%, so the description must compensate. It helpfully maps parameters to actions — subscribe (topic, queue), publish (topic, message or messages, from?) — which is valuable, but it leaves semantics undefined: the meaning of 'from', the distinction between 'message' and 'messages', and any topic naming/format rules are unexplained. Partial compensation, so a 3.

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 opens with '[bot-bus] Agent-to-agent message bus', a specific resource, and enumerates the four actions (subscribe, unsubscribe, publish, list) with their key params. It clearly frames the tool as a publish/subscribe hub rather than the vague name 'topic' alone would suggest, and gestures at the sibling 'queue' as the reader. It stops short of a crisp one-line differentiator from the queue tool, keeping it at 4 rather than 5.

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?

It explains a usage scenario ('a handoff waits safely while the receiving bot sleeps; it reads with the queue tool and acks'), which implies when publish/subscribe are appropriate. But it never states when to use this tool versus 'queue' or 'handoff' directly, nor any exclusions. Usage is implied rather than prescribed.

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?

With no annotations, the description carries full behavioral burden. It discloses that passwords are hidden from the bot and that watch is free, but omits permissions, destructiveness, reversibility, session persistence, or what each action does.

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 a single front-loaded sentence followed by an action list. It is concise and wastes little space, though the parenthetical could be clearer.

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 8 parameters including nested objects, no output schema, and no annotations, the description is far from complete. It provides no parameter documentation, no action semantics, and no usage context sufficient for correct invocation.

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% and 8 parameters exist. The description only names possible action values (put, list, delete, login, fetch, end, watch) without explaining them, and leaves ui, url, form, name, note, domain, and session entirely undocumented.

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 the tool is a login vault for sign-in sessions without exposing passwords, and lists seven actions. The resource and verb are clear, but it does not differentiate itself from siblings like secrets or fetch.

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?

No guidance is given on when to use this tool versus alternatives, nor are prerequisites or exclusions stated. The action list implies use but provides no selection criteria.

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?

With no annotations, the description carries the full burden, and it does disclose the important mutation-safety pattern: the first call is a non-destructive preview and only confirm=true commits. It does not say whether cancellation is reversible, who may cancel, or what happens to an already-fired wake.

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 sentences, front-loaded with the action and resource, followed immediately by the invocation protocol. Every clause earns its place.

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 3-parameter mutation tool with no annotations and no output schema, the description covers the critical confirm gate but omits what the preview returns, error/not-found behavior, and whether the cancellation is permanent.

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 description coverage is only 33% (only inbox is documented), so the description must compensate. It does clarify confirm (preview vs execute) and identifies wake_id as the target, but adds no format or constraint detail for wake_id and does not address the optional inbox.

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+resource ("Cancel a pending wake-up") plus the keying parameter (wake_id). It is trivially distinguishable from its siblings wake_schedule_wake and wake_check_wakes, which schedule and inspect rather than cancel.

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?

Gives explicit procedural guidance: call once without confirm to preview, then again with confirm=true. This tells the agent how to invoke it safely, though it names no alternatives and states no when-not-to-use condition.

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?

With no annotations, the description carries the full burden and does well: 'each returned once' discloses the consumption/at-most-once semantics, and it names the returned fields (saved state, thread ID) despite there being no output schema. It omits auth/rate-limit or failure behavior, so not 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 tight sentences, front-loaded with the core action; no filler. The final sentence could have been folded in and the bracketed '[agent-wake]' prefix spends tokens on a namespace marker, keeping it below 5.

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 single-optional-param, no-output-schema read tool, the description covers purpose, trigger timing, and return shape (state + thread ID), which is enough to call it correctly. Details like what happens to consumed wake-ups on subsequent calls or how to resume from 'state' are left implicit.

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 description coverage is 100%, so the schema already fully documents 'inbox' including the 12+ char and API-key fallback rules. The description only restates 'your inbox' and adds no syntax or format detail, so the 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+resource ('collect wake-ups... and list upcoming ones') scoped to 'your inbox,' and the paired name makes clear it is the read counterpart to wake_schedule_wake and wake_cancel_wake. An agent can distinguish check vs schedule vs cancel without opening any 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?

'Call this at the start of a session' gives an explicit triggering condition, which is stronger than most definitions. It stops short of naming alternatives or when-not to use it (e.g., relation to wake_schedule_wake), so it does not reach a 5.

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?

With no annotations provided, the description carries the full behavioral burden and does most of it well: it discloses the destination of saved state (callback POST vs. held for check_wakes), the mandatory two-step preview-then-confirm workflow, and what gets saved (notes, thread ID, next step). It does not cover failure modes, authentication requirements (only hinted at in the schema), or rate limits, so it falls short of complete.

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?

Four compact sentences, front-loaded with the core action and mechanism, then the confirmation procedure. Nothing is padding, though the callback/check_wakes contrast appears twice (once at the top and again implicitly in the confirm instruction), which is slightly redundant.

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 7-parameter tool with a nested state object and no annotations or output schema, the description covers the essential workflow, the persistence model, and the preview/confirm safety pattern adequately. Missing details are mostly operational edge cases (auth via inbox/API key, error behavior) that an agent could infer or discover.

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, but the description adds real meaning by explaining the confirm parameter's role in the two-step preview/save flow and by clarifying that the callback URL is what determines whether state is pushed or held. The nested 'state' object and inbox secrecy/API-key behavior are left to the schema.

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 ('Schedule a wake-up for your agent') and immediately explains the mechanism: at the chosen time, saved state is POSTed to a callback URL or held for check_wakes. This distinguishes it cleanly from sibling tools wake_cancel_wake and wake_check_wakes, which handle cancellation and retrieval rather than creation.

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 states when to use it ('so a later, fresh session picks up where this one stopped'), names the alternative retrieval path ('Without it, collect wakes with check_wakes'), and prescribes the exact operational sequence: call once without confirm to preview, show the user, then call again with confirm=true.

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?

With no annotations, the description carries the full burden. It usefully discloses the free-tier ceiling (50 calls/day), that usage is 'not metered,' and that a paid upgrade exists. It does not state auth requirements or return format, but for a zero-parameter informational tool this is adequate behavioral context.

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 tight sentences, front-loaded with the core action and followed by the quota and upgrade details. No filler, repetition, or buried information.

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 simple no-param informational endpoint with no output schema, the description covers what is shown, the quota, the metering status, and the upgrade path. It omits auth mechanics and exact return shape, which are minor gaps at this complexity level.

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 tool takes zero parameters and schema coverage is trivially 100%. No parameter detail is needed, and the description appropriately does not invent any. Rubric baseline for 0-param tools is 4.

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 ('Show') with the resource ('today's usage ... and the $49/month All Access upgrade link') and scopes it to agent-wake. It distinguishes itself from unrelated siblings by naming the product and usage/upgrade focus, though it does not explicitly contrast with other *_usage_and_upgrade tools.

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?

No explicit when-to-use or when-not-to-use guidance is given. The free-tier limit implies this is for checking quota, but the agent must infer that context; no alternatives or exclusions are named.

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