Content Sweep

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

Goes well beyond annotations: discloses the required action scope for auth, that credits are reserved (prepaid maximum from the quote), that an operation_id is returned and must be polled via get_operation, and that sandbox execution is simulated. Annotations (openWorld, idempotent, non-destructive) only cover the safety profile, so this added operational context is genuinely valuable.

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 action and prerequisite, and nearly every clause carries information. The dense semicolon-chained clauses make it slightly run-on rather than crisp, keeping it just under the top mark.

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 naming the returned fields (evidence_id, SHA-256 hash, timestamped metadata, operation_id) and the polling tool. Auth, credit reservation, and sandbox behavior round out everything needed to invoke 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?

Schema description coverage is 100%, so the baseline is 3 and the schema already carries both parameter definitions. The description adds surrounding meaning by explaining where quote_id originates (create_quote with action='evidence' and the full task input) and the async result flow, though it says nothing extra about idempotency_key beyond what the schema documents.

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 ('Capture a new immutable metadata observation') scoped to 'an existing case', and clearly distinguishes itself from siblings by naming create_quote as the prerequisite and get_evidence as the export path. An agent can tell what this does versus its neighbors 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?

Explicit ordered workflow: call create_quote with action='evidence' and a defined input object first, then capture, then use get_evidence to export. It also names what this tool does NOT capture (screenshots, images, audio, video), which prevents misuse. Conditions selecting this tool versus alternatives are fully specified.

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

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

Annotations only declare safety/idempotency hints; the description adds the paid-credit reservation model, the returned operation_id plus async polling requirement, the required action scope for auth, the sandbox-simulation note, and the crucial caveat that blocked retrieval or timeout cannot prove removal. This is exactly the behavioral context annotations cannot carry, with no contradiction of readOnlyHint=false or idempotentHint=true.

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 and the description is dense with useful facts, but the polling guidance ('poll get_operation for results') is stated twice and the paragraph hops between prerequisite, returns, cost, auth and environment, slightly diluting structure. Minor redundancy rather than real bloat.

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 paid, asynchronous, quote-gated tool with no output schema, the description covers the return fields, the cost/credit model, the async polling path, the auth scope and the interpretive caveat. An agent has everything needed to call it and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters (quote_id, idempotency_key) are fully documented in-schema, so baseline 3 applies. The description does add that the quote must come from create_quote(action='status') and that all task input lives in the quote, but it adds no syntax or conflict semantics beyond what the schema already states.

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 ('Fetch a fresh content observation for an existing case') and immediately distinguishes itself from siblings by contrast: get_case reads stored observations, get_operation polls queued work. An agent can identify the tool's role 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 an explicit prerequisite flow (create_quote with action='status' and the required input fields), names the free alternatives (get_operation, get_case) and the condition selecting them, and flags the tool as paid network work. Nothing is left 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?

Annotations cover the safety profile (non-destructive but not read-only, non-idempotent, open-world), and the description adds genuinely new behavioral context: a 15-minute validity window, no credit reservation, no rights granted, and an authentication/delegation-scope requirement. It also discloses the exact prerequisites (rights-holder, work, delegation scope) needed to call it.

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 sentences, front-loaded with the core semantics and TTL before the routing and auth details. The enumerated sibling list is long but each entry is load-bearing for selecting the follow-up tool; no filler 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?

With no output schema, the description correctly states what is returned (a quote ID) and how to consume it. It covers expiry, cost semantics, auth requirements, and downstream routing, so an agent has everything needed despite the tool's nested, multi-action 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 description coverage is 100% and the nested input schema already documents every action-to-field mapping in detail. The description reinforces "complete input" and the per-action binding but adds no field-level meaning beyond the schema, 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 and resource ("Create a free quote") plus the exact scope it binds (action, complete input, rate version, max USD-cent price, 15-minute TTL). It immediately distinguishes itself from sibling task tools by naming what it does not do (reserve/spend credits, grant rights).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: the returned quote ID feeds one of seven named sibling tools (find_copies, investigate_url, capture_evidence, prepare_takedown, submit_takedown, check_status, monitor_case), and it clearly excludes reservation/spending. When-to-use and what-it-is-not are both 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?

Annotations cover the safety profile (mutation, non-idempotent, non-destructive, open world). The description adds real value beyond them: the rights-scope prerequisite, that the caller needs no creator login or subscription, and crucially that registration records identity but does not authorize enforcement.

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 constraint before the id/return detail. No filler, though the clause list is slightly dense.

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 correctly supplies the return value (a rights-holder id) and its downstream use. Prerequisites and the enforcement caveat are present; only a pagination/error-shape note is absent, which is minor for a create tool.

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 the schema itself documents name (required), country_code, and contact_email plus the "Use the returned id as rights_holder_id" note. The description restates name/country/email without adding format or constraint detail 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 (Register) and resource (rights holder) scoped to "managed by this organization," and clarifies it happens without a creator login or subscription. This cleanly separates it from siblings like create_work and delegate_authority.

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 names the context (registering a managed holder without creator login/subscription), states the prerequisite (requires rights scope), and points at the downstream tools that consume the id (create_work, delegate_authority). No explicit when-not-to-use beyond the enforcement disclaimer.

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

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

Annotations only declare it is a non-read-only, non-idempotent, open-world, non-destructive write. The description adds substantial behavior beyond that: the signing secret is returned only once, delivery is at-least-once with bounded retries, unsafe destinations are refused, and there is a five-receiver quota.

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 dense sentences, front-loaded with purpose and auth/return semantics before delivery behavior and quota. Every sentence carries information, though the HMAC-verification sentence is receiver-side guidance rather than this tool's action.

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 only one parameter, the description still covers the return value (signing secret, once), authentication scope, delivery guarantees, and failure/quota limits. An agent has everything needed to call it and to anticipate the outcome.

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 the single url parameter is already documented in the schema, including the no-redirect/no-private-address rule. The description's 'public HTTPS receiver' phrasing reinforces rather than extends the schema, 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?

The first sentence states a specific verb (Register) and resource (public HTTPS receiver for signed lifecycle events), plus the scope (this organization). It is trivially distinguishable from revoke_webhook and get_webhook_deliveries, which are the related 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 states prerequisites (webhooks scope), hard constraints (public HTTPS only, no redirects, no private-network resolution, max five active receivers), which tells the agent when this call will fail. It does not explicitly name alternatives or say when not to register at all, but the operational 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?

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the write/non-idempotent profile is covered. The description adds value the annotations do not: the rights-scope requirement as an auth precondition, the return value ('a work id for delegation and quoted work'), and the semantic caveat that registration does not itself establish infringement.

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 sentences, front-loaded with purpose, then prerequisites, then inputs, then return/behavioral caveat. Every clause carries information, though the final clause is slightly dense.

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 output schema, the description covers prerequisites, required/optional inputs, the return identifier, and a critical scope caveat, which is enough for correct invocation. Minor gap: it does not explicitly point to create_rights_holder as the source of the required rights_holder_id.

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 the nested body object already documents rights_holder_id, description, original_url and external_id. The description repeats the same fields plus the minor hint that external_id is 'your' (caller-supplied) id, adding little 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?

The description states a specific verb+resource ('Register a protected original work') and scopes it to 'an existing rights holder in this organization', which distinguishes it from the sibling create_rights_holder and from copy-detection 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?

It gives a prerequisite ('Requires rights scope', 'under an existing rights holder') and a key disambiguation ('registering an original does not determine whether a suspected copy infringes'), steering the agent away from find_copies. It never explicitly names create_rights_holder as the tool that must run first, so 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?

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds behavior annotations don't carry: immediate revocability, future expiry semantics, the attestation version source, and the 'payment never substitutes for authority' guardrail. The only missing piece is what happens on re-delegation or conflict.

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 tightly packed sentences, front-loaded with the core action and ending with the key constraint (payment ≠ authority). No filler, though the density makes it read more like a spec than 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?

There is no output schema, and the description compensates by stating the return ('a delegation id for create_quote'). Preconditions, conditional flags, revocation, and expiry are all covered; only error/duplicate-handling behavior is absent for a non-idempotent mutation.

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 nested body is self-documented, but the description still adds meaning the schema cannot: the conditional intent behind can_appoint_content_sweep ('only when the mandate permits appointment; submission requires it') and the role of the authorization_reference/attestation_version pair. This is more than a restatement of field 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?

Specific verb+resource: 'Record the rights holder's existing authority for exact works and actions' with the qualifying artifacts (reference, attestation version, expiry). It implicitly separates itself from revoke_authority by noting revocation is possible and names create_quote as the downstream consumer, so an agent can place it in the workflow.

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 concrete preconditions ('Requires rights scope and rights_authorized=true') and a conditional rule for can_appoint_content_sweep tied to whether submission is needed. It stops short of naming the alternative tool (revoke_authority) or stating when not to delegate, so it is clear context without explicit exclusions.

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?

Goes well beyond the annotations (write, non-destructive, non-idempotent, open-world) by disclosing that no authentication is needed to enroll, that a bootstrap access_token is returned only once and must be sent as Authorization: Bearer, and that all credits, search results and receipts are simulated. The one-time token disclosure is high-value operational detail; missing only failure modes and any cleanup/re-enrollment 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?

Three tight sentences, each carrying distinct information: purpose, credential-return contract, and simulation scope. Front-loaded with the core action and zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by naming the returned organization_id and access_token and explaining how to use the token. Combined with the sandbox scope it is nearly complete for a one-parameter creation tool; the only gap is absence of any explicit sibling routing to enroll_live.

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% for the single 'name' parameter, so the schema already carries the semantics and the description adds nothing about it. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (create) and resource (free, isolated sandbox organization) with clear scope qualifiers. 'Sandbox' implicitly contrasts with the sibling enroll_live, but the description never names that alternative, so the differentiation is inferential rather than explicit.

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 through the 'sandbox' framing and 'free, without browser signup' context; there is no explicit when-to-use statement and no reference to the obvious alternative enroll_live for production/live enrollment. An agent must infer that this is the test-environment path.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false and openWorld=true; the description goes well beyond them by disclosing that live credentials are returned ONCE (a critical, non-recoverable side effect that reinforces non-idempotency), the identity/attestation requirements needed to succeed, and the activating gates. This is the kind of operational context the annotations cannot carry.

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 core action, then requirements, then the return value and scope limits. No filler, no restatement of the tool name, and each 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?

There is no output schema, so the description correctly compensates by stating what comes back ('returns new live credentials once'). Combined with prerequisites, gating conditions, and explicit scope exclusions, an agent has everything needed to decide whether to call it and what to expect.

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 nested body description already lists fields, so the baseline is 3. The description adds interpretive meaning by mapping groups of parameters to intent: 'accountable customer identity' (legal_name, authorization_reference), 'accepted current terms' (terms_version, terms_accepted), and 'authorized-agent attestation' (authorized_agent). That is a modest but real value-add over 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: 'Create a separate live organization using an authenticated sandbox account.' The sandbox→live transformation is unambiguous and the closing sentence ('Does not purchase credits or establish copyright authority') fences off adjacent concepts. It stops short of explicitly distinguishing itself from the closest sibling, enroll_agent, so it is clear but not fully self-differentiating.

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 invocation context (authenticated sandbox account) and enumerates the prerequisites that gate success: accountable customer identity, accepted current terms, authorized-agent attestation, supported countries, activation gates. It offers negative scope exclusions ('does not purchase credits'), but never names an alternative tool for those adjacent needs, so it is strong context without explicit alternative routing.

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?

Beyond the annotations (which only declare non-read-only, non-idempotent, non-destructive, open-world), the description discloses the 15-minute lifetime, the one-time return of the token, and the critical cascading behavior that child tokens stop working when the parent expires or is revoked. That is meaningful behavioral context an agent could not infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action and outcome, followed by the constraint and the lifetime/cascade caveat. No filler or repetition.

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, but the description states what is returned ('the token once'), the lifetime, and the invalidation condition, which covers the essential return behavior. Combined with a fully documented single parameter, nothing needed to call it correctly 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?

Schema coverage is 100% and the single param is already documented, so the baseline is 3. The description adds real meaning on top: scopes must be a nonempty subset of the parent's permissions, which is a semantic constraint not captured in the schema's array bounds.

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 precise verb+resource+outcome: exchange an authenticated bootstrap credential for a 15-minute access_token. It clearly distinguishes this from sibling credential tools like revoke_credential, rotate_credential, and enroll_agent without needing to name 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?

It states the precondition for use (an authenticated bootstrap credential) and the constraint that scopes must be a nonempty subset of the parent's permissions, which tells the agent when the call will succeed. It does not explicitly name alternative tools or spell out when-not to use it, so it falls short of the top mark.

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

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

Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable context beyond annotations: it explains the credit reservation behavior ('Reserves the quoted maximum from prepaid credits'), returns an operation_id for polling, mentions sandbox simulation, and clarifies that results don't determine infringement. It doesn't detail authentication specifics beyond 'Authenticate with the matching action scope'.

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 fairly concise, front-loading the core action and then adding necessary context about prerequisites, results, and limitations. Every sentence adds value, though it could be slightly more structured with bullet points for 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?

Given the tool's complexity (requires two-step workflow with create_quote and polling), the description provides sufficient information: prerequisites, results, limitations, and behavioral notes like credit reservation. No output schema exists, so the description appropriately explains return values. It misses minor details like rate limits or error handling, but overall it's complete enough for an agent to use 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 100%, so the schema already fully documents both parameters (quote_id and idempotency_key). The description mentions using a creator handle and existing text/identity matching, but these are not actual parameters—they are stored in the quote created earlier. It doesn't add new meaning beyond what the schema provides for the actual 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?

The description clearly states the action: search supported sources for suspected copies using a creator handle and text/identity matching. It distinguishes itself from siblings like investigate_url by noting 'no visual similarity search' and from create_quote by specifying the prerequisite. However, it doesn't explicitly name how it differs from investigate_url or other search-related 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 provides clear usage context: 'First create_quote(action=search,...)' and describes the workflow with 'Results include...' and 'poll get_operation'. It also states limitations like 'no visual similarity search' and 'they do not determine infringement'. However, it doesn't explicitly say when NOT to use this tool or list alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, yet the description adds real context beyond them: 'Requires account scope; free, without network investigation.' That discloses auth prerequisites and cost/no-network traits an agent cannot infer from the annotations alone.

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: the first front-loads the returned fields, the second gives usage and constraints. No filler, nothing 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?

With no output schema, the description carries the return-value burden and does so by listing the exact fields returned (organization_id, principal_id, environment, status), plus scope and cost constraints. Nothing material is missing for a zero-arg read tool.

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 adds no param syntax because none exists, but it does clarify what identifiers come back, which substitutes usefully for absent input documentation.

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 (Read) plus resource (this credential's account) and enumerates exactly what is returned: organization_id, principal_id, sandbox/live environment and account status. An agent can distinguish it from siblings like get_balance, get_usage or check_status 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?

Provides an explicit use case: 'Use to confirm which account later work affects.' Clear context for invoking it, but it names no alternative tools and gives no when-not-to-use condition, 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral facts: a required billing scope, that the call is free, that reserved funds are locked against other operations, and that credits cannot cross organizations. It stops short of describing freshness or caching, so it lands just under the top.

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 what is read and what fields come back, then the scope requirement, then the invariants. No filler and nothing repeated from the schema or annotations.

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 parameters and no output schema, the description carries the full burden and does so: it enumerates the returned monetary fields and their unit (USD), states the auth scope and cost, and explains the reserved/transfer constraints. An agent has everything needed to call and interpret this tool.

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 field names in the description (balance_cents, reserved_cents, available_cents, USD) describe the response rather than inputs, which is output information rather than parameter guidance, but nothing about parameters is needed here.

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 and resource ('Read organization-bound prepaid balance') and names the exact fields returned (balance_cents, reserved_cents, available_cents), so an agent knows precisely what it gets. It does not, however, differentiate itself from the adjacent get_usage or purchase_credits siblings, which is the only thing keeping it from 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 states the prerequisite ('Requires billing scope') and the cost profile ('free'), which is useful invocation context. But it never says when to call this instead of get_usage or purchase_credits, so usage is implied rather than guided.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds materially new facts: it is free, it does not re-fetch the target, and its return is tenant-scoped with no internal reasoning or other customers' data. These are cost and data-exposure disclosures the annotations do not carry.

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 what the tool reads, then cost/refetch behavior, then the alternative, then the return scope. No filler and nothing repeated from the schema or annotations.

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 characterizing the return (tenant-scoped case state, no internal reasoning or other customer data), and annotations cover the safety profile. One required parameter is fully documented, leaving no gap an agent would need to guess at.

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 there is a single parameter, so the baseline is 3. The description only adds the ownership constraint (case owned by this organization) on top of the schema's note that id comes from investigate_url's completed operation.

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 (Read) and resource (stored observations/details for a case), and immediately scopes it (owned by this organization, does not fetch the target again). It distinguishes itself from investigate_url (which does the fetching) and from check_status, so an agent can select it 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 an explicit routing rule: use check_status with a fresh status quote when a new content observation is needed, implying get_case is for re-reading existing observations. Covers the primary alternative but does not address other plausibly-overlapping siblings such as get_evidence.

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

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

Annotations already mark this read-only, idempotent, and non-destructive, and the description adds genuinely new operational context: the 100-event window, immutability of events, free-of-charge, the required webhooks scope, and out-of-order delivery handling via dedup on event ID. That is substantive disclosure beyond the structured fields.

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 what is returned and how many, then cost/scope, then operational guidance and the sibling alternative. No filler or restatement of the tool 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?

With no output schema, the description carries the burden and does so: it enumerates return fields, caps the result size, states the auth scope and cost, and warns about out-of-order delivery. Nothing needed to call this correctly 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 there is nothing for the description to disambiguate; baseline 4 applies. The mention of stable id/type/data/createdAt describes the payload fields, not inputs, so it does not add parameter meaning still owed.

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 ('Read') and resource ('this organization's ... lifecycle events') with explicit scope ('last 100') and returned fields (id, type, data, createdAt). An agent can distinguish it from replay_event and get_webhook_deliveries without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes to the alternative: 'Use replay_event for a known event and active receiver,' and states the scope prerequisite ('Requires webhooks scope'). It lacks an explicit when-not-to-use-this condition, but the alternative routing and scoping requirement are 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?

Annotations already declare read-only, idempotent, non-destructive, but the description adds value they cannot: the observation is immutable, the payload includes a SHA-256 hash plus capturedAt and retention expiry, and — most usefully — it explicitly discloses what is NOT returned (no screenshots, media, or storage paths). Scope requirement and zero cost are also stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences with no filler: identity/contents first, then requirements, then the negative return contract, then the sibling routing. Every clause carries information an agent needs.

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 naming the returned fields and the excluded media types, plus the scope prerequisite and cost. Nothing material to invoking it correctly 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?

Only one parameter and schema coverage is 100%, with the schema itself explaining that the id is an evidence_id from investigation, evidence capture, or status observation. The description adds only the 'owned' qualifier and scope requirement, 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 (Export) and resource (an owned immutable metadata observation), and immediately enumerates what it contains (SHA-256 hash, capturedAt, retention expiry). It is clearly distinguishable from the create-side sibling capture_evidence, which it names.

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 the prerequisite (requires evidence scope), a cost signal (free), and routes to the alternative for the opposite operation: 'Use capture_evidence with a quote to create a new observation.' It does not, however, contrast against the other read-style siblings (get_case, get_packet, get_operation), so the when-to-use-this-one framing 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?

Annotations already cover readOnlyHint, idempotentHint and destructiveHint=false, so the description earns credit mainly for adding the auth scope requirement ('Requires monitor scope'), the cost profile ('free'), and the enumerated return surface, which matters because no output schema exists. 'Does not run monitoring or increase its budget' largely restates the read-only annotation, which keeps this at a 4 rather than 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?

Three short sentences, front-loaded with the verb and scope, then prerequisites/cost, then the boundary condition. No filler and nothing 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 single-parameter read tool with no output schema, the description covers scope, cost, side-effect boundary and the returned fields, which is close to everything an agent needs. It does not say what happens when the id is unknown or not owned, a minor remaining gap.

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 the single id parameter is already documented there, including its provenance from monitor_case. The description only adds the implicit constraint that the monitor must be owned by the caller; otherwise the schema carries the parameter semantics, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Read') and resource ('owned monitor'), then enumerates exactly what is returned (action, cadence, expiry, budget, nextRunAt, status, pauseReason). The closing negation 'Does not run monitoring' separates it from monitor_case without requiring the agent to open 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 two concrete usage facts: it requires monitor scope and is free, plus a negative boundary ('does not run monitoring or increase its budget'). It stops short of naming an alternative tool or an explicit when-to-use-instead-of-pause/resume_monitor condition, so it is clear context rather than 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?

Annotations already cover read-only, idempotent, and non-destructive nature. The description adds behavioral details: no credits consumed, action scope requirement, possible states, and returned fields. It also warns about 'blocked' state and reconciliation, which is valuable beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded with the core action. Every sentence carries information, though it could be slightly more structured (e.g., separating states from usage). It's appropriately sized for the 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?

Given the simple schema (one parameter), annotations, and no output schema, the description covers what an agent needs: when to call, what states to expect, return fields, and caveats. The only minor gap is lack of explicit mention of polling interval or timeout 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?

The schema has 100% coverage for the single 'id' parameter, so baseline is 3. The description adds that it's an operation_id returned when a task was queued and to use it instead of case/packet/quote IDs, which adds 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?

The description states a specific verb ('Poll') and resource ('an asynchronous operation by operation_id'), and clearly distinguishes it from task tools ('Use after any task tool'). The scope is precise and unambiguous.

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 explicitly says when to use it ('Use after any task tool') and conditions like 'blocked submission_reconciliation_required must be reconciled before retry.' It also clarifies that a succeeded submit doesn't prove removal, which is a critical usage nuance.

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

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral context: the required 'prepare' scope, that the call is free, and the conceptual warning that a stored receipt is separate from removal evidence. What's missing is any note on failure modes when the packet is not owned or not yet ready, which is why it is 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?

Four sentences, each carrying distinct information and front-loaded with what is read before the scope/cost and the sibling routing. Slightly dense with two separate clarifications at the end, but 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 single-parameter read with no output schema, the description supplies the return contents (packet, fingerprint, stored receipt), the auth scope, the cost, and the boundaries against adjacent tools. Nothing an agent needs to invoke it correctly is 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?

With a single parameter at 100% schema coverage, the schema already documents 'id' including its provenance link to prepare_takedown. The description adds no syntax, format, or edge-case detail (e.g. behavior on unknown/expired id) beyond what the schema states, 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?

Starts with a specific verb+resource ('Read an owned prepared notice packet, fingerprint and any stored submission receipt'), enumerating exactly what comes back. It also explicitly distinguishes itself from the sibling mutation tools prepare_takedown and submit_takedown, so an agent can disambiguate 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?

The description states both the negative boundary ('Does not prepare or send a notice') and the alternatives with their selecting conditions ('Use prepare_takedown to create a packet and submit_takedown for authorized delivery'). It leaves nothing to inference about when this read tool is the right pick.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely new context beyond them: the billing scope authorization requirement, the fact that the call is free, and that prices are versioned and denominated in USD cents.

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. The resource and scope are front-loaded, and the auth/cost constraints and sibling routing follow in descending priority order.

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, read-only tool with no output schema, the description covers what is returned (rate card and action prices), the unit, the auth requirement, and the cost. Only minor details such as response shape or caching/versioning mechanics are absent, which is acceptable here.

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 has an empty schema, so there is nothing for the description to disambiguate. Baseline for a parameterless tool applies; no parameter-level detail is missing.

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 (read) plus the exact resource (the authenticated environment's versioned rate card and action prices), including the unit (USD cents). It also names the sibling create_quote, so an agent can distinguish this read-only price lookup from the quote-binding tool 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 a prerequisite ('Requires billing scope') and routes the agent to create_quote for the follow-on action, which is clear context for use. It stops short of an explicit when-not-to-use statement or a full alternative comparison, so it lands just below 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?

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuinely non-structured context: a hard cap of the last 100 entries, that billing scope is required, and that the call is free — useful behavioral facts an agent can't get from the annotation block.

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: scope and returned fields first, prerequisites and intended use second. No filler, no restating the tool name, every clause carries 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 and no parameters, the description carries the burden and largely meets it by describing the returned record shape (IDs and timestamps), the 100-entry limit, the scope requirement, and cost. Only minor gaps remain, such as whether truncation at 100 is detectable or how to page further.

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 per the rubric. The description correctly describes the fixed result window rather than implying filtering options, which is appropriate for a parameterless 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?

Specific verb ('Read') plus a precisely bounded resource: the last 100 ledger entries for this organization, enumerated as purchases, reservations, charges and releases with operation/purchase IDs and timestamps. That content spec cleanly separates it from balance- or account-oriented siblings like get_balance and get_account without needing to name 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?

'Use to reconcile spending with operation results' gives a concrete use case and implies the right context (post-operation reconciliation) versus siblings such as get_balance or get_operation. It does not state when NOT to use it or name an explicit alternative, so it falls 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: a hard cap of 100 records, the auth scope required, zero cost, and the guarantee that receiver failure does not lose operation or case state.

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 compact sentences, front-loaded with what is returned, followed by scope/cost and a failure guarantee. Every sentence earns its place and no wording 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 simple parameterless read-only list tool with no output schema, the description supplies the record cap, the field list, the scope requirement, and the state-safety guarantee. It could be slightly more complete by noting ordering guarantees or retention, but nothing critical to correct invocation 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 there is nothing for the description to clarify beyond the schema. Per the baseline for parameterless tools, a 4 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 ('Inspect') and resource ('last 100 owned webhook delivery attempts') and enumerates the returned fields, so an agent can tell it is a read-only delivery-log tool. It does not explicitly name or contrast with any sibling (e.g., replay_event), so it falls short of the 5 level.

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 the precondition 'Requires webhooks scope; free,' which is useful context, but gives no when-to-use guidance, no exclusions, and does not point to any alternative sibling for related tasks. Usage is only implied by the description of returned content.

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

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

Annotations already establish that this is an open-world, idempotent, non-destructive mutation, but the description adds substantial extra context: it creates a tenant-owned case, reserves the quoted maximum from prepaid credits, returns an operation_id for polling, requires action-scoped authentication, and notes sandbox simulation. It also discloses the important limitation that CDN visibility does not prove the origin host and that no notice is sent.

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 front-loaded with the core action and then layers on prerequisites, results, limitations, authentication, billing, async behavior, and environment. Every sentence carries operational value, and none is redundant with the annotations or 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?

There is no output schema, so the description must explain what comes back. It does so by listing case_id, evidence_id, page metadata, registrar/network attribution, supported contacts, and retrieval limitations, and by directing the agent to poll get_operation. It also covers prerequisites, auth, credits, and sandbox behavior, making it complete for a complex async mutation tool.

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 both quote_id and idempotency_key are already fully documented in the schema. The description adds workflow context for how the quote_id is obtained via create_quote, but it does not deepen parameter semantics beyond what the schema provides, especially for idempotency_key. 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?

The description states a specific verb and resource: investigate a supplied public URL and create a tenant-owned case. It distinguishes the operation from siblings by naming the required create_quote step and the get_operation polling flow, and it explicitly says no notice is sent, separating it from takedown-oriented 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?

Prerequisites are clear: first call create_quote with action='investigate', then authenticate with the matching action scope. The description also explains the async follow-up via get_operation and notes that investigation does not send a notice, but it does not explicitly compare when to choose this tool over all relevant alternatives such as prepare_takedown.

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

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

Annotations cover safety/idempotency, and the description adds substantial context beyond them: each run reserves credits, runs pause when funding/authority/expiry/limits disallow work, the quoted maximum is reserved from prepaid credits, the matching action scope is required for auth, and sandbox execution is simulated. This is exactly the operational detail annotations cannot convey.

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 and no sentence is pure filler, but the block is dense and slightly muddled: it says 'Returns monitor_id' and later 'returns operation_id; poll get_operation', which leaves the agent unsure which identifier it receives. The credit-reservation point is also restated near the end.

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 complex, credit-consuming enrollment tool with no output schema, the description covers prerequisites, auth scope, budget/expiry behavior, pausing conditions, sandbox simulation, and result polling. Minor gaps remain on how it interacts with pause_monitor/resume_monitor and on the monitor_id vs operation_id confusion.

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 quote_id and idempotency_key are already documented. The description adds the useful point that all task input lives inside the quote (rights_holder_id, work_id, delegation_id, target_action, expires_at, limits, handles), but this elaborates the quote's contents rather than either parameter's own semantics. 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 and resource ('Enroll recurring search or case-status observations') and immediately scopes it with budget and expiry. An agent can distinguish it from get_monitor, pause_monitor, resume_monitor, and create_quote 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 clear prerequisites: call create_quote(action='monitor') first, supply main_handle for target_action='search' or case_id for 'status', and poll get_operation for results. It also states a boundary ('Never schedules takedown submissions'), but does not explicitly say when to prefer pause_monitor/resume_monitor or when not to enroll at all.

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent, open-world. The description adds substantive behavior beyond that: a monitor-scope auth requirement, preservation of the original expiry and budget, and the important side-effect nuance that an already queued operation is not cancelled. That is exactly the kind of consequence detail annotations cannot convey.

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 tight sentences, front-loaded with the action and scope before the constraints. Every clause earns its place — scope requirement, preservation semantics, queued-op caveat, and the complement 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?

For a single-parameter mutation with annotations covering the safety profile and no output schema, the description covers auth, reversibility via resume_monitor, and partial-effect behavior. It says nothing about the response or whether repeated pauses are rejected, which is minor but a gap.

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?

There is one parameter ('id') and schema description coverage is 100%, with the schema stating 'Owned monitor_id to pause.' The description adds no syntax or format detail beyond what the schema already documents, so the baseline of 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 ('Pause future scheduled runs for an owned monitor') with clear scope ('owned', 'future scheduled runs'). It is immediately distinguishable from the sibling resume_monitor, which is also named.

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?

Names the complementary alternative and its effect ('Use resume_monitor to restart within the same bounds') and states the scope prerequisite, giving an agent clear routing. It stops short of an explicit when-not-to-use condition, so it is clear context rather than full when/when-not guidance.

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

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

Annotations cover the safety profile (not read-only, idempotent, non-destructive), and the description adds substantial context beyond them: it reserves the quoted maximum from prepaid credits (a financial side effect), returns operation_id requiring polling via get_operation, requires a matching action scope for auth, demands attestation only within the rights holder's authority, and notes sandbox execution is simulated. This is rich disclosure of side effects and follow-up 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 with purpose, then prerequisite, then return shape, then behavioral notes. Dense but each clause carries information. The nested inline create_quote payload is a bit heavy in one sentence, but nothing is redundant 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?

No output schema exists, yet the description explains the return values (readiness, missing fields/blockers, packet_id and destination when ready) plus the async polling pattern and credit reservation. Auth scope, prerequisites, and sandbox behavior are all covered, leaving no material gap for invoking 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?

Schema coverage is 100% with detailed descriptions of both quote_id and idempotency_key, so the baseline is 3. The description adds meaning by explaining that all task input (rights_holder_id, work_id, delegation_id, case_id, evidence_id, attestations, explanation) is captured in the upstream quote, clarifying what the quote_id actually represents.

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 ('Prepare') plus resource ('copyright notice packet') and scope ('for an existing case and evidence without sending it'). The 'without sending it' clause cleanly distinguishes it from the sibling submit_takedown, so an agent can route correctly without opening schemas.

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 an explicit prerequisite sequence ('First create_quote(action="prepare", ...)') and a constraint ('Optional destination must match a supported route'), and the 'without sending' framing implies the sending alternative. It stops short of naming submit_takedown or stating when-not-to-use conditions, so it is clear but not fully routing-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?

Annotations only cover readOnly=false, idempotent=true, openWorld=true, destructive=false. The description goes well beyond them, disclosing the auth requirement (billing scope), the live 402 payment-challenge retry path, that the authorization must be sent separately from the Bearer token, that provider confirmation credits the balance exactly once, that sandbox purchases are simulated, and that cards are supported while stablecoins are not. These are exactly the operational traits an agent cannot infer from structured fields.

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 core action is front-loaded in the first sentence, followed by requirements and then the payment flow. Six sentences is dense, but each carries distinct information (flow, idempotency semantics, sandbox, supported instruments) with little redundancy. Slightly list-like, but no filler sentences that fail to earn their 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?

There is no output schema, so the description must carry return behavior, and it does explain the outcome ('credits the balance exactly once') and the intermediate 402 challenge. Combined with 100% schema coverage on four parameters, an agent has enough to call it correctly. Only finer response detail (e.g., what the success payload contains) is 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 a baseline of 3 applies, but the description adds real meaning: it pins the currency/units ('in USD cents'), confirms the idempotency-key requirement, and clarifies that payment_authorization is a separate credential from the account Bearer token. That last point materially disambiguates how the parameter is supplied.

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 a specific verb and resource: 'Purchase organization-bound prepaid service credits in USD cents.' That is unambiguous and clearly distinct from siblings like get_balance or set_spending_policy. It stops short of naming or contrasting any sibling, so it lands 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?

The description implies usage through the two-phase flow ('retry the same purchase/key with payment_authorization') and states prerequisites ('Requires billing scope and an idempotency key'). However, it never says when to choose this tool over funding-adjacent alternatives such as set_spending_policy, nor states any exclusions. That is implied rather than explicit guidance.

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

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

Annotations only cover the generic safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description adds real behavioral context beyond that: the ten-replay cap per delivery, the requirement that the receiver deduplicate repeated IDs, and the guarantee that the underlying operation is not re-executed or re-charged. This is consistent with idempotentHint=false, since deduplication responsibility is pushed to the receiver.

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 sentences, front-loaded with the action and its defining property, followed by constraints and then the negative scope. Every sentence carries distinct information with no repetition.

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 a simple two-parameter shape, the description covers everything an agent needs: what is requeued, the required scope, the rate limit, the receiver-side obligation, and the fact that no billing or operation side effect occurs.

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 both parameters are already documented with their sources ('Stable event ID from get_events' / 'Owned active webhook ID from create_webhook'). The description reinforces the 'owned active webhook' and 'original event ID' constraints but adds no new syntax or format detail, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Requeue a known event to an owned active webhook') and adds the key qualifier 'while preserving its original event ID.' This is clearly distinguishable from siblings like create_webhook, revoke_webhook, and get_webhook_deliveries 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 concrete preconditions and limits: 'Requires webhooks scope; at most ten explicit replays per delivery,' plus an explicit negative scope ('Does not rerun the underlying operation or charge it again'). It references get_events and create_webhook as the sources of its inputs, but does not name an alternative tool for cases where replay is the wrong choice, so it stops short of a full when/when-not/alternative treatment.

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

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

Annotations already declare a non-read-only, non-idempotent, non-destructive, open-world mutation. The description adds meaningful context beyond that: it requires monitor scope and current authority, and critically it will NOT expand spending ceilings or grant rights. It stops short of describing the return value, which the absent output schema leaves unaddressed.

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-loading the action and its budget/expiry guardrails before the auth and limit caveats. Zero 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 no-output-schema mutation, the description covers the authorization requirement, the non-expansion guarantee, and the expiry constraint well. The main remaining gap is the return/result behavior after a successful resume, which an agent might reasonably want to know.

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 both id and delegation_id are already fully documented with descriptions. The description adds only that delegation_id is optional and 'replacing' the existing delegation, which the schema's 'Optional replacement delegation' already conveys. Baseline 3 is appropriate when the schema does the heavy lifting.

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 precise verb+resource ('Resume an owned monitor') plus scope constraints ('within its existing expiry and total budget'). An agent can immediately distinguish it from pause_monitor and get_monitor without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit preconditions ('Requires monitor scope and current authority') and an exclusion ('expired monitors cannot resume'). It does not explicitly name pause_monitor as the inverse operation, so it falls just short of the top score.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description goes further: 'Irreversibly', the fact that queued work and future monitor runs recheck revocation, the limitation on already-sent notices, and the return value. This is behavioral context well beyond the annotation set and consistent with it.

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 short sentences, front-loaded with the action and its irreversible nature, then prerequisite, then scope limits, then return value. No filler and no repetition of the annotations.

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 still discloses the return value (revoked=true), the required rights scope, and the downstream effects on queued work and monitors. Nothing needed to invoke or reason about consequences 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?

Schema description coverage is 100%, and the single id parameter is already documented as the 'Delegation ID returned by delegate_authority.' The description only echoes 'by ID' and adds no format, sourcing, or constraint detail beyond the schema, so the baseline of 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?

Specific verb+resource+scope: 'Irreversibly revoke an owned delegation by ID.' Naming 'delegation' directly ties it to the delegate_authority sibling and separates it from revoke_credential and revoke_webhook, so an agent can pick the right revocation tool without opening schemas.

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 prerequisite ('Requires rights scope') and tells the agent the boundary of what revocation accomplishes ('stops later authorized actions but does not retract a notice already sent'), which is real guidance on when this is the sufficient tool. It stops short of naming explicit alternatives or a when-not-to-use case, so it falls just under 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?

Annotations already flag destructiveHint=true and non-idempotency, but the description adds behavior the annotations cannot express: dependent access tokens stop authenticating, self-revocation breaks future calls, and the response is revoked=true. These are exactly the operational consequences an agent needs before invoking an irreversible action.

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 scope, then consequences and return value. No filler or repetition; every clause conveys a distinct fact.

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-parameter destructive mutation, the description covers the precondition, the cascade effect, the self-lockout hazard, and the return value even though no output schema exists. Nothing material 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?

Schema description coverage is 100% and the single 'id' parameter is fully documented in the schema, so the description only echoes 'by ID'. Baseline 3 is appropriate since the schema carries the parameter meaning.

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 ('revoke an owned service-principal credential by ID') and the scope ('owned service-principal'), which separates it cleanly from the sibling revoke_authority and revoke_webhook. An agent can identify the target object 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 clear precondition ('Requires credentials scope') and a critical usage caveat ('revoking the credential used for this call prevents later calls with it'). It does not explicitly name revoke_authority or revoke_webhook as alternatives for other object types, so the sibling routing is left 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?

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds real behavioral context beyond them: the required auth scope, the caveat that an in-flight delivery may still complete, the concrete response shape (revoked=true), and the explicit statement that case state and events survive. That is exactly the extra context the annotation set cannot convey.

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, all front-loaded: action first, then preconditions and caveats, then the guarantee about what is not destroyed. No filler and every clause carries 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 single-parameter destructive tool with no output schema, the description covers everything an agent needs: prerequisite scope, irreversibility caveat (in-flight delivery), response contract, and non-effects. Nothing material is left to inference.

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% for the single required 'id' parameter, and the schema already explains it is the webhook ID returned by create_webhook. The description's 'owned webhook' phrasing reinforces the ownership constraint but adds no format or syntax detail, so the baseline of 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 ('Deactivate an owned webhook') plus the secondary effect ('cancel its pending deliveries'). This clearly separates it from sibling create_webhook and the read-only get_webhook_deliveries, so an agent can pick it 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?

'Requires webhooks scope' and 'owned webhook' give clear preconditions for when this tool applies, and 'Does not delete case state or events' usefully bounds when it is not the right tool. It stops short of naming an alternative or an explicit when-not-to-use scenario, so it is not a full 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?

Annotations establish the write/idempotency profile but say nothing about invalidation scope or secret handling; the description fills exactly that gap — the old credential and its child tokens are invalidated, and the new secret is returned only once. That 'shown once, store it now' warning is the single most actionable behavior for an agent.

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 sentences, each load-bearing: what changes, what is required, what comes back. The destructive consequence is front-loaded and the storage warning is last, which is the right ordering.

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 carries the full return-value burden and does so ('Returns the new credential once'). For a zero-parameter, high-consequence operation, nothing an agent needs before calling 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 and there is no schema content to duplicate. The description still adds credential-context semantics (which credential type may invoke it), which is useful framing rather than parameter documentation.

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 ("Replace the current bootstrap credential and invalidate it and its child tokens") plus the observable effect, which behaviorally separates it from revoke_credential. It never names that sibling or any alternative, so it falls short of the explicit differentiation a 5 requires.

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 concrete preconditions: an agent must be on the credentials scope and hold a bootstrap credential, not a short-lived token. It also tells the agent to persist the returned value before subsequent calls. It stops short of explicitly contrasting rotation with revocation or stating when rotation is the right 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?

Annotations already declare it a non-read-only, non-idempotent, non-destructive open-world write. The description adds meaningful context beyond them: the auth prerequisite (billing scope), the full set of required fields for enabling replenishment, the returned state (applied limits and automatic_funding), and the scope-limiting note that it does not purchase credits.

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 core action and scope, then transition rules, then return/side-effect clarification. Each clause earns its place, though the second sentence is packed with a long field enumeration that could be trimmed.

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 nested-body mutation tool with no output schema, the description covers the auth requirement, the conditional funding_policy branch, the returned state, and the non-purchase boundary. Annotations carry the remaining side-effect profile, leaving little an agent needs that 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?

Schema coverage is 100%, so baseline is 3, but the description adds genuine semantics the schema does not: the USD-cents unit, the behavioral meaning of funding_policy=null (replenishment stays off), and the fact that the nested object requires all five fields as an explicit mandate. It interprets the structure rather than restating it.

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 (set organization and current-credential daily spending ceilings, in USD cents) and explicitly disambiguates from the sibling purchase_credits by noting it "does not itself purchase credits." An agent can distinguish this policy-setting tool from credit-purchasing and credential tools without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear triggering conditions: "Requires billing scope" and the conditional branch rule "Set funding_policy=null to keep automatic replenishment off; enabling it requires an explicit amount, threshold, daily maximum, future expiry and mandate reference." It clarifies what the tool is not (a purchase mechanism) but does not name an explicit alternative sibling by name for the wrong-scope case.

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

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

Annotations cover the safety profile (destructive=true, idempotent=true, openWorld=true), and the description adds substantial context beyond them: re-checks of delegation, permission, evidence, route, policy and funding; the distinction between submission status, provider receipt and removal status; the reconciliation-required path; credit reservation and returned operation_id; and matching auth scope. This is exactly the extra behavioral detail the annotations cannot convey.

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 purpose and dependency, then compactly enumerates rechecks, result semantics, retry rule, auth and credit behavior. Every sentence carries information, though the density makes it slightly hard 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?

With no output schema and a destructive, credit-consuming mutation, the description compensates by explaining what is returned (operation_id), how to retrieve results (poll get_operation), and how to interpret partial success (provider acceptance does not prove removal, reconciliation required). Nothing essential to correct invocation 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?

Schema description coverage is 100%, so both quote_id and idempotency_key are already well documented in the schema. The description adds only the reminder that task input lives inside the quote, which the schema also states. 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+resource ('Submit a prepared packet through a supported, activated enforcement route') and distinguishes itself from siblings prepare_takedown and create_quote by making the quote prerequisite explicit. An agent can tell what this does and what it depends on 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 the required sequencing ('First create_quote(action="submit", ...)'), the retry rule ('reconcile the original operation before any retry'), and the sandbox caveat. It never explicitly says when NOT to use it versus prepare_takedown, but the workflow context is clear enough to route correctly.

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