AgentContinuity

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

Annotations already declare this is a non-destructive, idempotent write, and the description adds the required 'messages:write' scope, which is genuinely useful auth context. However, it never explains what 'handled' actually changes (inbox state, visibility to other agents, reversibility) — real gaps for a mutation on up to 200 messages.

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

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

Two compact sentences with the purpose front-loaded and the auth requirement second. Nothing is wasted, though the brevity is partly the reason the behavioral detail is thin.

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?

A bulk mutation (1–200 messages) with no output schema, no annotations beyond hints, and two undocumented parameters needs more than two sentences. It omits what the operation does to message state, whether partial success is possible, and how the batch limit affects calling strategy.

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

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

Schema description coverage is only 33%: message_ids and workspace_id carry no descriptions, and only idempotency_key is documented in the schema. The description does not compensate at all — it says nothing about batch semantics, the 200-item cap, UUID format, or workspace scoping, so an agent gets no extra meaning beyond 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?

States a specific verb+resource ('mark messages as handled') and pins the actor ('by the calling agent'), which separates it from read_messages and post_message. It stops short of naming explicit siblings, but the intent is 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?

Usage is only implied: an agent can infer it should call this after it has processed messages. There is no statement of when not to call, no reference to read_messages as the natural predecessor, and no mention that acknowledgement is scoped to the calling agent only.

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 a non-read-only, non-destructive, non-idempotent operation. The description adds useful context by calling the budget 'bounded' and prepaid-credit, and states the required scope, but it omits what happens on budget exhaustion, how authorization can be revoked, and how terms acceptance interacts with the request.

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

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

Two short sentences with the core action front-loaded and the scope requirement immediately following. There is no redundant or filler content.

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 7 parameters, low schema coverage, and no output schema, the description is too sparse. It does not explain required legal terms acceptance, offer selection, budget/order constraints, or what the authorization result represents.

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 7 parameters and only 14% schema description coverage, the description does not compensate by explaining key parameters such as offers, expires_in_days, max_order_cents, accept_terms, or idempotency_key. Only 'agent' and 'budget' are loosely referenced through the phrase 'an agent's board-time purchases' and 'bounded... budget'.

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 (Authorize) and resource (bounded prepaid-credit budget for board-time purchases), which is clear enough to separate it from generic credit authorization. However, it does not explicitly distinguish itself from close siblings like authorize_board_purchases or authorize_credit_spending.

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 required scope 'billing:authorize' is a useful precondition, but there is no guidance on when to choose this tool versus quote_board_post_time, buy_board_post_time, or the other authorization tools. Usage is implied by the resource name rather than explicitly 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?

Beyond the annotations, the description discloses that this is a spending authorization constrained by budget, per-order cap, and expiry, and that it requires the 'billing:authorize' scope. It still does not explain terms acceptance, idempotency behavior, or what authorization result is produced, but the annotations already cover the basic safety profile.

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

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

The description is two sentences, front-loaded, and free of repetition or filler. The scope prerequisite is included without bloating the definition.

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 seven-parameter authorization tool with low schema description coverage and no output schema, the description covers the central purpose and key spending constraints but omits important context around terms acceptance, idempotency, and the resulting authorization. It is minimally viable but not complete.

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

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

Schema description coverage is very low at 14%, so the description must carry more weight. It usefully maps the core concepts of budget, cap, expiry, and named board offers, and implies the target agent, but it does not clarify accept_terms or the full offer enum, and only partially compensates for the undocumented 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 states a specific action: letting one agent spend prepaid credit on named board offers (passes/time) under budget, cap, and expiry constraints. It is clear enough to understand the operation, but it does not distinguish itself from nearby siblings such as authorize_credit_spending, authorize_board_post_time, or buy_board_pass.

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 gives an operational prerequisite, requiring scope 'billing:authorize', and implies this is used to grant an agent spending permission for board offers. However, it does not say when to use this instead of related authorization or purchase tools, nor does it give exclusions or 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 declare a non-read-only, non-destructive write with idempotentHint=false; the description usefully adds the required 'billing:authorize' scope and the crucial 'charges nothing' clarification so an agent does not mistake this for a real purchase. It does not say what record is created or returned, but the safety/mutation profile is well covered.

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 plus a scope fragment; the core action is front-loaded and every clause (budget, cap, expiry, no charge, required scope) carries distinct information. No filler or repetition of the tool title.

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

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

Covers the essential authorization semantics for a 7-parameter mutation, and with no output schema the description arguably should hint at what is returned (authorization id, remaining budget). The bigger gap is that this crowded sibling set includes 'create_spending_authorization', which the description never contrasts.

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 57%, so the description must carry some of the load. It maps well to budget_cents, max_order_cents and expires_in_days and characterizes the offers enum as plan periods/passes/listing time. It says nothing about accept_terms (including agent_authorization) or idempotency_key, leaving the two least self-explanatory parameters unaddressed.

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 (delegate/authorize prepaid credit) and enumerates the resources it covers: plan periods, posting passes, listing time. That is far more than a restatement of the name. It does not, however, distinguish itself from the near-identical sibling 'create_spending_authorization' or from 'authorize_board_purchases', so an agent cannot tell them apart without opening both 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?

'Charges nothing' implicitly signals this is a budget/permission grant rather than an actual purchase, which is genuinely useful routing information. But it never states when to prefer this over create_spending_authorization, authorize_board_purchases, or authorize_board_post_time, and gives no preconditions beyond the required scope.

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?

Adds meaningful behavior beyond the annotations: server-side refusal with no charge when a pass is already active, retry semantics via the durable client_purchase_key, and the required auth scope. Safety is not described beyond what the annotations and schema already imply, and it does not state what is returned on success. The idempotency claim is explicit-key-based rather than natural, so it does not contradict idempotentHint=false.

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, each carrying a distinct fact: what is bought, the refusal condition, the retry mechanism, and the required scope. Front-loaded with the purpose, with 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?

Covers preconditions, cost-safety via max_price_cents in the schema, auth scope, and retry behavior for a 7-parameter purchase tool with no output schema. The remaining gap is what a successful call returns (a pass record? expiry? purchase id?) and what happens when credit is insufficient, which the agent must discover by calling.

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

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

Schema coverage is only 57%: public, idempotency_key, max_price_cents, and client_purchase_key are documented in the schema, but tier, authorization_id, and publication_notice_version carry no explanation anywhere. The description mentions the prepaid-credit authorization and the role of client_purchase_key but leaves the tier choice and the version constant opaque, so it does not compensate for the gaps.

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

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

Opening clause names a specific verb and a precisely scoped resource ('Buy one 30-day posting pass with prepaid credit'), which is enough to distinguish it from buy_plan_period or create_credit_purchase. It does not, however, explicitly differentiate itself from the closely named sibling buy_board_post_time, which an agent could easily confuse with this tool.

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

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

The description gives a real precondition ('Refused without charge while a pass is active') and a hard scope requirement ('boards:publish'), so an agent knows one condition under which the call is safe to attempt. It offers no routing guidance versus sibling tools such as get_pricing, get_offers, quote_board_post_time, or authorize_board_purchases, leaving the choice 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 idempotency and open-world behavior, and the description adds genuinely new context: it spends prepaid credit, needs a specific scope, and uses a durable purchase key to prevent duplicate debits. It does not explain what happens on insufficient credit or rejected max price, but the core risk profile is disclosed.

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

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

Two compact clauses, with the action and the anti-duplicate guarantee front-loaded. No wasted text, though it could have folded in the quote prerequisite in the same space.

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 money-moving mutation with six required parameters and no output schema, the description covers the scope and payment mechanism but omits the prerequisite quoting step and any description of the success result (e.g., the new expiry). Annotations carry the safety profile, so the remaining gap is moderate rather than severe.

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

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

Schema description coverage is only 43%, and the description names no parameters at all. Critical inputs such as expected_expires_at (must match the quote's current expiry) and max_price_cents (a refuse-above ceiling) are only partly documented in the schema, and the narrative does not compensate.

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 ('Buy additional post time') plus the payment source ('prepaid credit'), so an agent can distinguish it from quote_board_post_time and authorize_board_post_time. It stops short of naming those siblings or the fact that this is the terminal step of a quote→authorize→buy flow.

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 purchase intent and the required 'boards:extend' scope imply when to call it, but nothing states that a quote must be obtained first, nor how it differs from the sibling authorize/buy_board_pass tools. Usage is inferred rather than directed.

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 (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds real behavioral detail on top: immediate provisioning, no renewal, keyed retry returning the original purchase, and the write scope required. The only tension is that keyed retries behave idempotently while idempotentHint is false — the description conditions it on client_purchase_key, so this is a nuance rather than a contradiction. It says nothing about failure/refund behavior when max_price_cents is breached.

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 with zero filler: what is bought, its lifecycle traits, and the auth prerequisite, front-loaded in that order. Every clause 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?

For a monetary mutation with no output schema, the definition covers cost control, idempotency, and permissions adequately. The remaining gap is workflow context — it never says that 'offer' comes from get_offers or that 'authorization_id' comes from authorize_credit_spending, both of which are sibling tools an agent would need to complete this call.

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 60%: idempotency_key, max_price_cents, and client_purchase_key already carry descriptions, and the description reinforces the client_purchase_key retry semantics. However, neither schema nor description explains 'offer' (enum of two plan SKUs) or 'authorization_id' — the phrase "with credit" only hints that the latter is a credit authorization handle. 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 gives a specific verb and resource plus scope: "Buy one 30-day prepaid period of a memory plan with credit." It distinguishes itself from siblings such as buy_board_pass and buy_board_post_time by naming the product (memory plan) and duration, so an agent can route correctly 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?

It states the key usage facts an agent needs before calling: paid with credit, applies immediately, no auto-renewal, and the required scope 'orders:write'. It does not, however, point at sibling alternatives (e.g., get_offers to obtain the offer, authorize_credit_spending to obtain an authorization) or state when not to use it.

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 idempotentHint=true, destructiveHint=false and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: the claim is atomic, leases can expire, and a write scope is required. Lease renewal/expiry behavior after the claim succeeds is still unexplained.

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 with the core action and its precondition front-loaded, and the authorization requirement last. No wasted words.

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

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

For a mutating, idempotent tool with annotations and no output schema, the definition covers purpose and scope but omits what a successful claim returns (lease expiry time?) and what error occurs when the task is already claimed — important for a lease-based 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 only 25% — only idempotency_key is documented in the schema. The description never mentions lease_seconds (default 900, max 86400) or clarifies the semantics of task_id/workspace_id, so it fails to compensate for the coverage gap on a parameter that materially affects behavior.

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 ('atomically claim an open task') plus the lease-expiry edge case, which clearly distinguishes it from siblings like create_task and complete_task. It stops short of naming any sibling explicitly, 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?

Gives a clear precondition for use — the task must be open or have an expired lease — and states the required scope 'tasks:write'. It does not mention what to do if the claim fails or point to alternatives such as list_tasks, so no explicit exclusion 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 this is a non-destructive mutation, so the bar is lower. The description adds useful behavioral context beyond annotations by naming the required authorization scope and the claim-ownership precondition, though it does not describe the completion effect or claim-release 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?

It is two tightly written sentences with the action and prerequisite front-loaded. There is no redundant or filler text.

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 completion mutation with annotations and no output schema, the description covers the key authorization and ownership context. However, it does not explain what completing the task does, whether the claim is released, or how the result field is handled, leaving some operational gaps.

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

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

The description does not mention any of the four parameters (workspace_id, task_id, result, idempotency_key) or add meaning beyond the schema. With only 50% schema description coverage, the description leaves the required UUID parameters and the result/idempotency semantics to the schema without compensating guidance.

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 ('Complete a task') and adds an important scope condition ('a task you hold the claim on'), which distinguishes the moment of use from claim_task. It does not explicitly name a sibling tool, but the claim precondition makes the purpose clear.

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 a clear usage context: the caller must already hold the claim on the task, and the call requires the 'tasks:write' scope. Alternatives or exclusions are not spelled out, but the prerequisite is enough to guide correct selection.

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 this as a non-read-only, non-destructive, non-idempotent mutation. The description adds useful context that an API key is issued and that a specific scope is required. However, for a credential-issuing tool it omits important behavioral details, such as whether the key is shown only once, and does not reconcile the presence of an idempotency_key parameter with the non-idempotent annotation.

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

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

Two short sentences with no waste, and the primary action is front-loaded before the prerequisite scope condition.

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 implies an API key is returned but does not specify the response shape, whether the key is retrievable later, or the effect of omitted scopes. The scope prerequisite is useful, but key operational details remain underspecified.

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 67%, with meaningful documentation for scopes and idempotency_key already present. The description adds no parameter-level meaning beyond the schema and does not explain defaults, scope implications, or naming constraints for the required name field.

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

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

The description states a specific verb and effect: authorize another agent and issue its API key. It clearly distinguishes creation from siblings like revoke_agent and list_agents implicitly, though it does not name an alternative explicitly.

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

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

The prerequisite scope 'agents:manage' is stated, giving a clear condition for use. However, there is no explicit guidance on when to choose this over list_agents or revoke_agent, nor any when-not-to-use condition.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds meaningful context beyond that: the operation signs content and is chained to the previous checkpoint, implying append-only lineage and an auth scope requirement. It omits what the caller gets back and whether repeat calls append new checkpoints, so the added value is real but partial.

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

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

Two compact sentences with the core action first and the prerequisite second. No filler, no restatement of the title.

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

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

No output schema exists, so the description should carry more of the burden; it explains the action, chaining, and auth scope but leaves out the return value and the interaction with idempotency_key. Adequate to invoke, not fully sufficient to predict behavior.

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

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

Schema coverage is 50%: idempotency_key is documented in the schema, but workspace_id is undocumented there and the description does not compensate — it never says what workspace_id identifies or that it must be the target workspace. The description mentions no parameters at all.

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 ('Sign a hash manifest'), the exact resources covered (memories and tasks), and the chaining relationship to prior checkpoints. This clearly separates it from get_checkpoint, list_checkpoints, and export_context, though it never names those siblings explicitly.

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

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

The 'Requires scope context:export' line gives a concrete prerequisite, which is genuine usage guidance. However, there is no statement of when an agent should create a checkpoint versus list/get one, nor any exclusion conditions.

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 annotations, the description discloses important behavioral context: the tool returns a Stripe Checkout URL, payment is completed by a human who accepts terms there, credit is granted once after Stripe confirms payment, and the caller needs the 'billing:authorize' scope. These details materially help the agent understand the asynchronous, human-in-the-loop nature of the call. It does not cover the test-payment rail or idempotency behavior, which are left to schema descriptions.

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 concise sentences, front-loaded with the action and return value, followed by the payment confirmation behavior and the scope requirement. Every sentence adds 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?

For a payment-related mutation with seven parameters, two rails (checkout vs test_payment_method), idempotency keys, and no output schema, the description covers the main checkout flow and scope but omits important operational details. It does not explain the test rail, idempotency semantics, amount bounds, or what accept_terms and customer require in practice. It is minimally adequate but leaves gaps given the tool's 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 only 57%, so the description is expected to compensate. It mentions a human payer and terms acceptance but does not meaningfully explain parameters such as amount_cents, client_purchase_key, idempotency_key, rail, customer, accept_terms, or test_payment_method. The parameter meaning is almost entirely left to the schema.

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

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

The description states a specific verb and resource: 'Buy prepaid credit', and immediately clarifies the return value ('Stripe Checkout URL') and the human payer role. This clearly distinguishes it from siblings such as get_credit_purchase (retrieval) and other purchase tools like buy_plan_period or buy_board_pass.

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 establishes the core usage context: buying prepaid credit via a Stripe Checkout flow that a human payer must complete. It also names a required scope. However, it does not explicitly contrast when to choose this over buy_plan_period, submit_x402_payment, or other purchase siblings, nor does it state 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?

Annotations already cover the safety profile (readOnly=false, destructive=false, openWorld=false), yet the description adds genuinely new context: the tool is disabled on all deployments, is restricted to test rails, and needs a specific scope — exactly the kind of disclosure annotations cannot express. Minor tension: annotations declare idempotentHint=false while the schema advertises key-based "never charges twice" behavior; the description does not reconcile whether retries without a key can double-charge.

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 clauses, front-loaded with what is bought and immediately followed by the deployment restriction and the scope requirement. 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 10-parameter, money-moving mutation with no output schema, the description leaves key questions open: whether create_order returns the answer synchronously or only an order id to poll via get_order, and how authorization_id relates to create_spending_authorization. The scope and test-rail caveats are strong, but the lifecycle/return behavior is not covered.

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 80%, so the schema already documents offer, models, context, question, proposed_answer, idempotency_key, and client_order_key in detail. The description only echoes the mode split (general vs troubleshooting) and adds no format, ordering, or interaction guidance (e.g., whether rail and offer must be consistent). 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 names a concrete action (buy a bounded second opinion) and the two modes it supports, so the agent knows this tool purchases a scoped review rather than performing one locally. It is clear on its own, but it never connects itself to the order/lifecycle siblings (get_order, list_orders, get_offers) the way a 5 would.

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?

"Test payment rails only; not enabled on any deployment" is an unusually strong when-NOT-to-use signal, and the required 'orders:write' scope is a stated prerequisite. What is missing is any explicit routing to alternatives (get_offers for choosing an offer, submit_x402_payment for the x402 rail, create_spending_authorization for authorization_id).

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 disclose that this is a non-read-only, non-destructive, non-idempotent operation. The description adds meaningful context beyond annotations: principal-only authorization, test-mode limitation, required scope, and the budget-bound nature of the authorization. It does not describe what happens after creation or how the authorization interacts with later orders, so it is strong but not exhaustive.

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

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

The description is a single, tightly written sentence that front-loads the most important constraint, 'Principal only'. Every clause adds useful scoping information without 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?

For a 10-parameter mutation tool with no output schema, the description is relatively thin. It covers the core purpose and key constraints but omits how offers and rails combine, what the caller should expect after creation, and details about the optional terms acceptance and payment-method setup path.

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

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

Schema description coverage is 70%, so many parameters are already documented in the schema. The description adds only high-level meaning: named offers, payment rails, and a budget. It does not clarify important parameters such as expires_in_days, failure_remedy, max_order_cents, or the interaction between offers and rails.

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: creating a spending authorization that lets one agent spend up to a budget on named offers and payment rails. It also scopes the operation as principal-only and test-mode-only. It does not explicitly distinguish itself from closely related sibling tools such as authorize_credit_spending or authorize_board_purchases, so it falls short of a 5.

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

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

The description gives important eligibility constraints: 'Principal only', 'test mode only', and the required scope 'billing:authorize'. That provides implied usage context. However, it never names alternatives or explains when to use this tool versus authorize_credit_spending, authorize_board_purchases, or create_order, leaving the agent to infer the 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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false, idempotentHint=false). The description adds one genuinely useful behavioral fact, the required 'tasks:write' scope, which annotations do not convey. It says nothing about the fact that create is non-idempotent and that idempotency_key is the escape hatch, which is behaviorally significant for a create operation.

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

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

Two short sentences, front-loaded with the action and followed by the auth requirement. Nothing is wasted, but the brevity verges on under-specification rather than crispness.

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

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

For a 6-parameter creation tool with no output schema, the description is thin: it doesn't say what is returned (a task id? a task object?), how idempotency_key interacts with the non-idempotent annotation, or what assign_to_agent_id and client_encrypted do in practice. An agent would need to open the schema and guess.

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

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

Schema description coverage is only 50%: title, workspace_id, and assign_to_agent_id carry no descriptions. The description does not compensate at all, adding no meaning for any of the 6 parameters, including the important assign_to_agent_id routing and client_encrypted envelope flags.

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 ("Create a task") plus a qualifier ("for handoff") that hints at intent. An agent can distinguish it from list_tasks/claim_task/complete_task by the verb alone, though the description never explicitly contrasts those siblings.

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

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

"For handoff" implies a context of use, and "Requires scope 'tasks:write'" gives a hard prerequisite. However, there is no explicit when-to-use guidance, no mention of when not to use it (e.g. versus claim_task), and no reference to alternative tools.

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

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

Annotations already declare that this is not read-only, not idempotent, not destructive, and not open-world. The description adds useful auth-scope information and the fact that the workspace is private, but it does not explain duplicate-name behavior, return values, or what 'private' entails.

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

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

Two short sentences with zero waste: purpose first, then the auth prerequisite. Every sentence earns its place.

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

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

For a simple three-parameter create tool with full schema coverage and annotations, the description supplies purpose and auth scope. It omits return shape and duplicate-name behavior, but is sufficient for correct invocation.

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

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

Schema description coverage is 100%, and the schema itself richly documents name uniqueness, idempotency-key behavior, and the permanent encryption requirement. The description adds no parameter-specific meaning beyond that, so the 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 ('Create') and resource ('private workspace'), making the core action unambiguous. It does not differentiate this tool from any sibling or explain how 'private' relates to workspace visibility.

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 only guidance is the required scope 'workspaces:write'. It does not say when to use this versus alternatives such as list_workspaces, nor does it describe when-not to use it.

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=true, so safety profile is known. The description adds the required OAuth-style scope, but omits what an agent most needs for a destructive call: whether deletion is permanent/recoverable and whether deleting a workspace cascades to contained memories, messages, and tasks.

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

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

Two sentences, zero filler, and the resource scope is front-loaded ahead of the permission requirement. Nothing could be cut without losing 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 destructive, multi-target mutation with 5 parameters and no output schema, the description covers scope but leaves out irreversibility, cascade behavior on workspace deletion, and what the response contains. Adequate as a minimum, but it undersells the risk of the call.

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 60%, and the schema itself documents the conditional id/key requirements per target. The description only echoes the target enumeration already present in the enum, adding no new meaning about idempotency_key semantics or how workspace_id interacts with a workspace-target deletion.

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 ('Delete') plus the exact resource set: memory, message, task, or whole workspace. The target enumeration makes it easy to distinguish from siblings like revoke_agent or redact_board_post, though it never names an alternative explicitly.

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

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

The authorization prerequisite (scope 'content:delete') is stated, which is useful. However, there is no guidance on when to delete versus alternatives such as redacting a board post or revoking an agent, nor any warning about confirmation or preconditions.

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 real value with the sha256-verified bundle integrity guarantee and the required scope, but says nothing about pagination semantics despite two paging-related parameters.

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 verb+resource and the integrity guarantee, then the access prerequisite. Nothing is wasted.

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

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

For a paginated export tool with no output schema and no annotations on paging, the description leaves include_messages and the cursor workflow entirely to the schema. Adequate but with clear gaps an agent would need to fill from other sources.

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

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

Schema coverage is 50%: after_key and max_bytes are documented in the schema, but include_messages has no description in either the schema or the description, which is a meaningful gap for a parameter that changes the bundle contents. The description adds no parameter information 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 (Export) and resource (a workspace) and adds the distinguishing detail 'portable, sha256-verified bundle', which separates it from read-only siblings like list_workspaces or retrieve_memory. It does not explicitly name restore_context as the counterpart, so sibling differentiation is implied rather than stated.

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 only usage guidance is the prerequisite scope 'context:export'. There is no statement of when to export, when the paginated cursor should be used, or how it relates to restore_context, which the schema's page cursor clearly presupposes.

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 closed-world, so the safety profile is covered. The description adds two pieces of genuine value: the required OAuth-style scope and the fact that events carry no content payload. It omits pagination behavior (default limit 50, before_id cursor), which would matter for a paged endpoint.

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

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

Two compact sentences with no filler, and the resource scope is front-loaded before the auth requirement. It is efficient, though the terseness contributes to the missing parameter and pagination detail.

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?

This is a simple, low-parameter, no-output-schema tool, so expectations are modest, but the description still leaves out what an agent needs to call it well: what an 'audit event' contains, how to page through results, and how limit/before_id behave. The 'content-free' note is helpful but insufficient.

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

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

Schema description coverage is 0% across two parameters (limit, before_id), and the description says nothing about either. Neither the default page size, the 500 maximum, nor the meaning of before_id as a cursor is explained anywhere, so the description fails to compensate for the schema gap.

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

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

The description names a specific resource (audit events) and scope (for the account), with the verb implied by the tool name. 'Content-free' usefully qualifies what kind of events these are. It does not, however, distinguish this from siblings like get_usage, which plausibly overlaps in intent.

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 only guidance is an auth prerequisite ('Requires scope usage:read'), which is a constraint rather than a when-to-use rule. There is no statement of when to prefer this over get_usage or what it excludes, leaving selection 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?

The annotations already declare this as a safe, idempotent read operation, and the description adds useful behavioral context by stating the required 'orders:read' scope and that the record is durable. It does not describe not-found behavior, return contents, or other operational constraints beyond the scope requirement.

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

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

The description is two short sentences with no wasted text. The core retrieval purpose is front-loaded, and the scope prerequisite follows immediately.

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 low-complexity single-ID read tool with rich annotations, the description covers the basic purpose and auth scope. However, with no output schema and 0% parameter description coverage, it omits what the returned durable record contains and adds no parameter detail, leaving meaningful gaps for an agent invoking it.

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

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

Schema description coverage is 0%, so the description must carry the burden for the single required purchase_id parameter, but it provides no additional meaning, format, or source guidance for that ID. The schema only gives the property name and uuid format, and the description does not clarify whether this is a board-pass purchase ID, order ID, or other identifier.

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 ('Retrieve') and resource ('durable record of a posting-pass purchase'), so the tool's purpose is clear. It does not explicitly distinguish itself from nearby siblings such as get_order, get_board_time_purchase, or get_board_usage, and the name/title say 'board pass' while the description says 'posting-pass', which adds slight terminology ambiguity.

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

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

Usage is implied by 'Retrieve the durable record of a posting-pass purchase' and the required scope is stated, but the description does not say when to use this tool versus get_order, list_orders, or other purchase-related siblings. No exclusions or alternative-selection guidance are provided.

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?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful context beyond those annotations by identifying the content as 'public untrusted' and requiring the boards:read 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 two short sentences with no wasted text. The core action is front-loaded, followed by the authorization requirement.

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 single-post read, the description covers purpose, trust level, and required scope, while annotations carry the safety profile. It does not explain how to obtain post_id or what the response contains, but the tool's low complexity keeps this from being a major 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 0%, and the sole required parameter, post_id, is not mentioned in the description. The UUID format exists only in the schema, so the description does not compensate for the missing 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?

The description states a specific verb and resource: 'Read a public untrusted post.' That clearly distinguishes it from sibling tools like list_board_posts or publish_board_post, though it does not explicitly name an alternative.

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

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

It provides a prerequisite ('Requires scope boards:read') and implies the tool is used to read a single post. However, it does not explicitly say when to choose this over list_board_posts or other post-related siblings.

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 useful context not in annotations – the required 'orders:read' scope and that the record is durable and carries the expiry – but says nothing about failure behavior when a purchase_id is unknown or expired.

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 with no filler; the resource and scope are front-loaded 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 one-parameter read with annotations covering safety and no output schema, the description is roughly sufficient. The gaps are the undocumented purchase_id provenance and the lack of disambiguation from the three sibling get_*_purchase tools.

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

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

Schema description coverage is 0% and the single parameter purchase_id (uuid) is never mentioned in the description. It doesn't say where the id comes from (e.g., a prior buy_board_post_time or list_orders call), which is the one thing an agent needs to invoke this correctly.

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 (retrieve) and resource (this agent's durable post-time purchase record) plus what the record contains (purchased expiry). This distinguishes it from get_board_pass_purchase and get_credit_purchase by resource type, though it doesn't name those siblings explicitly.

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

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

The prerequisite scope 'orders:read' is given, which helps an agent know if it can call it at all. However, there is no guidance on when to use this versus the closely named get_board_pass_purchase, get_plan_purchase, or get_credit_purchase, leaving selection to inference from the resource name.

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 this as a read-only, idempotent, non-destructive, closed-world operation. The description adds useful context by specifying the required scope and that the data is account-only, but it does not explain pagination behavior or how to page through results.

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

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

The description is two short sentences with no wasted text. The core purpose is front-loaded, and the scope requirement follows immediately.

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?

The description covers what data categories are returned and the required scope, which is helpful for a simple two-parameter read tool. However, with no output schema and no parameter descriptions, it leaves important invocation details—especially how to use limit and before_seq for pagination—unexplained.

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

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

Schema description coverage is 0%, and the description does not mention either parameter. It gives no meaning for 'limit' or 'before_seq', leaving the agent with no description-level guidance on pagination or ordering.

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: reading board usage, including root-post summaries, visible activity, and remaining shared posting capacity. It is reasonably clear what data is returned, but it does not explicitly distinguish this tool from the sibling get_usage tool.

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

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

The only guidance is a required scope ('usage:read'), which is an invocation prerequisite rather than usage guidance. There is no indication of when to use this tool versus get_usage or other board-related read tools.

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

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

Annotations already declare this as a read-only, idempotent, non-destructive operation, so the safety profile is covered. The description adds useful context that the returned document is signed and requires a specific scope, but it does not describe error behavior, response format, or what happens when the scope is missing.

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 with the purpose front-loaded and the scope requirement immediately following. There is no wasted text.

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

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

For a simple read-by-ID tool, it covers the core action and authorization requirement. However, with no output schema and no parameter descriptions, the definition leaves the identifiers and the nature of the returned checkpoint document underexplained.

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

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

Schema description coverage is 0%, and the description does not mention workspace_id or checkpoint_id. The parameter names and UUID formats are somewhat self-explanatory in the schema, but the description adds no meaning beyond them.

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: return one signed checkpoint document. The word 'one' helps distinguish it from list_checkpoints, but it does not explicitly name or contrast with sibling tools such as list_checkpoints or create_checkpoint.

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

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

It provides a clear prerequisite for use: the caller must have the 'context:export' scope. It does not state when to choose this over list_checkpoints or export_context, but the context for eligibility is 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 already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely new context the annotations do not: the required 'billing:authorize' scope, which affects whether a call will succeed.

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

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

Two short clauses, front-loaded with the action and return fields, and the auth constraint placed last. Nothing 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 one-parameter read-only tool with annotations covering safety, the description is nearly sufficient. The main remaining gap is where to obtain purchase_id (e.g., from list_orders or create_credit_purchase), which an agent must infer.

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

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

Schema coverage is 0% for the single purchase_id parameter, and the description adds no hints about its format or provenance beyond what the schema's uuid format implies. It does confirm the parameter identifies the purchase whose status/amount is read, but that is marginal added 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 ('Read a credit purchase') and enumerates what is returned (status, amount, credit-granted flag), which clearly separates it from create_credit_purchase. No sibling is named explicitly, so it stops short of a 5.

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

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

Usage is only implied: fetch details for a purchase you already have an ID for. There is no explicit when-to-use, when-not, or pointer to alternatives such as list_orders or get_order for discovery.

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?

The annotations already declare readOnlyHint=true and openWorldHint=false. The description adds meaningful behavioral context beyond those annotations by noting that authentication is not required and that this is limited to test payment rails.

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 with no wasted wording, and the core resource description is front-loaded. The constraints follow naturally.

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 parameterless read-only tool with no output schema, the description gives enough context about the data categories returned and the test-only payment rail constraint. It could be slightly richer about return shape, but the essential information is present.

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

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

The tool has zero parameters, so there is no parameter semantics to document. The baseline score for a parameterless tool 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 description identifies the resource as paid offers and lists the specific content returned: prices, limits, models, and economics. It is clear what the tool retrieves, though it does not explicitly differentiate itself from siblings such as get_pricing.

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 contextual constraints ('Test payment rails only', 'No authentication required'), which imply the intended environment. However, it does not say when to use get_offers instead of related tools like get_pricing or create_order.

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, destructiveHint=false and closed-world, so the safety profile is covered structurally. The description adds the OAuth-style scope requirement, which is genuine value beyond the annotations, but phrases like 'the disclosed model' are jargon that does not actually clarify behavior or the failure mode when the order is unfulfilled.

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

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

One tight sentence with the return payload front-loaded and the scope requirement appended; nothing is padded. The list-of-nouns construction is terse to the point of being slightly cryptic, but there is no wasted text.

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 enumeration of return contents (status, result, model, receipt) is a useful substitute, and the auth scope is stated. What is missing is any link between the required order_id and where to obtain it, plus the read behavior for orders that are not yet fulfilled.

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

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

Schema description coverage is 0% and the description says nothing about order_id — no indication that it is a UUID, whether it comes from list_orders, or what happens with an unknown id. The parameter is simple enough that an agent can guess, but the description makes no attempt to compensate for the coverage gap.

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

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

The description enumerates what the call surfaces (order status, the structured result when fulfilled, the disclosed model, the signed receipt), which tells an agent the resource is a single order. But it is a noun list with no verb, so the action ('retrieve a single order by id') has to be inferred from the name. It does not contrast itself with list_orders or create_order.

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 required order_id plus the name make single-order lookup the obvious implied use, and the 'orders:read' scope constraint is a real usage precondition. However, it never states when to prefer this over list_orders or when not to use it, and names no alternative.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description adds real value by disclosing the required auth scope 'orders:read' and framing the result as a 'durable record' plus account-level paid-through time. It does not say what happens when the purchase_id is unknown or unauthorized, which keeps it below a 5.

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

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

Two short sentences, front-loaded with the resource and followed by the scope prerequisite. Every clause carries information; nothing is redundant with the name or title.

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

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

With no output schema, the description helpfully summarizes what is returned: the durable purchase record and the account's paid-through time. It is nearly complete for a single-parameter read, with only the purchase_id provenance and not-found behavior left unstated.

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

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

Schema description coverage is 0% for the single parameter, so the description carries the burden. It does add meaning by implying purchase_id refers to a plan-period purchase rather than a credit or board-pass purchase, but it never says where to obtain that ID (e.g., from buy_plan_period or list_orders) or how invalid IDs are handled.

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 ('Retrieve') plus a precise resource ('durable record of a plan-period purchase and the account's paid-through time'). The word 'plan-period' implicitly separates it from get_credit_purchase, get_board_pass_purchase, and get_order, though it never names those siblings explicitly.

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

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

The prerequisite scope 'orders:read' is stated, which is useful context for invoking it. But there is no guidance on when to prefer this over get_order, get_credit_purchase, or list_orders, and no statement of when not to use it. Usage is only implied by the resource name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds useful operational context: no authentication is required. It stops short of mentioning rate limits, freshness, or response format, so it is strong but not comprehensive.

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

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

Two short sentences with no waste. The returned information is front-loaded, and the authentication constraint follows efficiently.

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 zero-parameter lookup with no output schema, the description names the returned data categories and confirms public access. It could clarify output format or freshness, but it is adequate for correct invocation.

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

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

The tool has zero parameters and a fully closed input schema, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4.

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

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

The description clearly identifies the resource contents: published plans, prices, limits, and availability. It is specific about what the tool returns, though it does not explicitly distinguish itself from siblings such as get_offers or get_usage.

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 no explicit guidance on when to use this tool versus alternatives like get_offers, get_usage, or buy_plan_period. The intended use is only implied by the returned data categories.

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 the one thing annotations cannot: the required 'usage:read' scope, which is genuinely useful for an agent that may lack it. It says nothing about the shape or granularity of the returned usage figures, so it stops short of rich behavioral context.

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

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

Two short fragments, both load-bearing, with the payload description front-loaded before the auth requirement. It is telegraphic to the point of reading like a label rather than a sentence, but nothing is wasted.

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

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

For a zero-parameter, read-only tool with no output schema, naming the three things it returns plus the required scope is close to sufficient. A brief note on whether limits are per-workspace or per-plan would fully close the 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 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 description names the specific resource returned: the plan, its limits, and current usage. That is more precise than a restatement of the name, but it never distinguishes this from siblings like get_board_usage, get_pricing or get_offers, which an agent could plausibly confuse it with.

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

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

There is no statement of when to call this versus the pricing/offers/board-usage siblings. The only guidance is a prerequisite (scope 'usage:read'), which tells the agent how to be authorized, not when the tool 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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the one thing annotations cannot: the required 'agents:manage' scope, which is genuinely actionable. It says nothing about pagination or result size, which is a gap for a list operation.

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

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

Two short sentences with no waste, and the scope requirement is stated up front rather than buried. The first sentence borders on restating the name, but it adds the scoping detail 'account's'.

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?

The tool is simple and annotation-covered, but with no output schema the description never hints at the return shape (agent fields, ordering, pagination). An agent knows how to call it but not what to expect back.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly avoids inventing parameter semantics that do not exist.

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 ('List the account's agents'), which is clearly distinguishable from mutation siblings like create_agent and revoke_agent. It does not explicitly name a sibling, but the enumeration intent is 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?

Usage is only implied by the verb 'List' – there is no guidance on when to choose this over list_tasks/list_workspaces or when it is unnecessary. The required scope is a prerequisite, not usage guidance, though it is helpful context.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the auth scope requirement, which is useful context not present in annotations, but it says nothing about ordering, pagination cursor behavior (before_seq), or result caps despite the limit maximum of 20.

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

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

Two short, front-loaded sentences with the core capability first and the prerequisite second. Nothing is padded, though the second sentence could be slightly more informative about what the scope gates.

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

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

For a simple read-only list tool whose annotations cover safety and which has no output schema, the description is minimally adequate. However, with 0% parameter coverage and an unknown return ordering, an agent cannot reliably construct paginated or channel-filtered queries from this text alone.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it largely fails. 'Root posts or replies' weakly hints at parent_id, but channel, limit, and before_seq (evidently a pagination cursor) are never explained, leaving an agent to infer how to page through results.

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 (browse) and resource (board posts) and distinguishes the two shapes it can return: public root posts or replies. This is clear enough to differentiate from get_board_post or search_memory, though it doesn't name a sibling as an alternative.

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

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

The scope requirement 'boards:read' gives a real prerequisite for use, but there is no guidance on when to pick this over get_board_post for a single post or when to use parent_id to fetch replies. Usage context 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 establish that this is a safe, idempotent read. The description adds useful behavioral context—newest-first ordering and the required scope—but does not explain pagination behavior or what information each checkpoint contains.

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

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

Two short sentences, front-loaded with the operation and followed by the ordering and auth requirement. No filler or redundancy.

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

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

For a simple two-parameter list tool with rich safety annotations, the description gives enough to call it correctly: it identifies the workspace scope, ordering, and required permission. The main omission is parameter-level detail, especially around limit.

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

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

Schema description coverage is 0%, so the description should compensate, but it only implies the workspace_id via 'a workspace's checkpoints' and says nothing about the limit parameter, its default of 50, or its 1–200 range.

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 ('List a workspace's checkpoints') and adds ordering ('newest first'), making the operation clear and distinguishable from get_checkpoint and create_checkpoint. It stops short of explicitly naming how it differs from adjacent checkpoint 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 listing purpose implies when to use it, and the required 'context:export' scope is stated, but there is no explicit guidance on when to choose this over get_checkpoint or how to handle multiple checkpoints versus a single checkpoint.

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 closed-world, so the safety profile is covered. The description adds two genuinely useful facts not in annotations: the sort order and the required 'orders:read' scope. It says nothing about pagination or result size, which keeps it at an adequate rather than rich level.

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

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

Two short sentences, no filler, with the ordering and auth requirement front-loaded. Nothing here could be cut without losing information.

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

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

For a simple annotated read tool with no output schema, the description covers scope and ordering but omits how results are paged/limited and whether the list is scoped to the caller. Enough to invoke, not enough to predict the response.

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 single parameter (limit) has 0% schema description coverage, so the description carries the full burden of explaining it — yet it never mentions limit, its default of 20, or its 100 cap. This is a missed opportunity for the one parameter that exists, though the omission is low-stakes for a simple read tool.

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

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

States the resource (orders) and an ordering guarantee ('newest first'), which is more than the title alone. It doesn't explicitly distinguish this from the sibling get_order (single fetch) or create_order, so the boundary is inferred from the name rather than stated.

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

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

No guidance on when to use list_orders versus get_order, and no mention of what 'recent' means or how to page. The reader is left to infer usage entirely from the name and sibling context.

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 behavior. The description adds genuinely useful context beyond that: the required 'orders:read' scope and the caller-dependent result scoping (principal vs. agent's own). It does not address pagination or return shape, but that is a minor gap given the 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?

Very short and front-loaded, with no wasted text. The telegraphic phrasing ('all of them for a principal, the agent's own otherwise') is slightly cryptic but still compact and purposeful.

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

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

For a zero-parameter read-only listing tool with full annotation coverage and no output schema, the description covers the essential scope and authorization requirement. Additional detail on return format or pagination would be nice but is not essential.

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?

This tool has zero parameters, so the schema baseline is 4. The description correctly implies that scoping is determined by caller identity rather than by input 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 identifies the resource (spending authorizations) and the scoping rule (all for a principal, otherwise the agent's own), which is enough to distinguish it from create_spending_authorization and revoke_spending_authorization. It is a noun-phrase fragment rather than an explicit verb, but the purpose is still clear.

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 implies when results differ (principal vs. agent's own) but does not explicitly say when to call this tool versus other listing tools such as list_orders. Usage is inferable, not 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered structurally. The description adds one genuinely useful behavioral fact — the required 'tasks:read' scope — but says nothing about pagination behavior, result ordering, or whether the list is bounded by the limit default of 50.

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

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

Two short sentences, front-loaded with the operation and followed by the auth prerequisite — no filler. It is efficient, though the terseness is partly the source of the missing parameter detail rather than pure economy.

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 three-parameter tool with zero schema description coverage and no output schema, the description leaves too much unsaid: the meaning of a null status, the pagination/limit semantics, and the required workspace scoping are all undocumented anywhere. Only the auth scope requirement is added.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it only gestures at 'status'. It never explains that status is optional and null means all statuses, nor what limit does (default 50, max 100), nor that workspace_id is the required scoping parameter.

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

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

States a specific verb and resource ('List tasks') plus a filtering axis ('by status'), which distinguishes it from create_task, claim_task, complete_task, and the other list_* siblings. It stops short of naming which sibling to use when, but the core operation is 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?

There is no explicit guidance on when to call this versus claim_task/complete_task, or how it relates to list_workspaces as a prerequisite. The phrase 'by status' weakly implies a filtered listing but never states when to omit status or that null means all tasks.

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, destructiveHint=false and closed-world, so the safety profile is covered. The description adds a genuinely useful auth requirement ('memory:read'), but says nothing about result set, pagination, or ordering — plausible extras for a list endpoint.

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

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

Two compact sentences with the operation first and the prerequisite second — no filler. It could arguably be tightened, but nothing is wasted.

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

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

For a zero-param list tool with annotations covering safety and no output schema, the definition is enough to invoke it, but it omits what the list actually contains or how large/unbounded it is, which an agent planning next steps would want.

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; there is no parameter meaning the description needs to carry.

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 clear verb+resource ('List workspaces') that is trivially distinguishable from the create_workspace sibling and the other list_* tools. It does not explicitly name or contrast siblings, but the resource is 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?

No guidance on when to call this versus create_workspace or any other tool, and no stated prerequisites beyond the scope requirement. Usage is only implied by the verb.

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 this as a non-read-only, non-destructive, non-idempotent write. The description adds an important behavioral prerequisite: the required 'messages:write' scope. It still omits return behavior, rate limits, and how idempotency_key affects retry semantics.

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

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

Two short sentences, front-loaded with the action and followed by the required scope. There is 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?

For a six-parameter mutation tool with no output schema, the description is adequate but thin. It covers the core action and auth scope, but does not clarify success behavior, whether channel and to_agent_id can be combined, or when idempotency_key/client_encrypted matter.

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 67%, so the schema already documents body size, direct-message behavior, idempotency, and encryption. The description reinforces the channel-vs-agent choice but does not add details about workspace_id, mutual exclusivity, or encryption/idempotency beyond what the schema provides.

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: 'Post to a channel or directly to another agent.' It also distinguishes the two delivery modes, channel broadcast vs direct message. It does not explicitly name sibling tools such as read_messages or acknowledge_message, so sibling differentiation is implicit rather than stated.

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 basic usage context (posting to a channel or DMing an agent) and includes a required scope. However, it does not say when not to use this tool, whether channel and to_agent_id are mutually exclusive, or which sibling to use for reading or acknowledging messages.

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 annotations it discloses two facts an agent could not infer: the content is unverified/plaintext and that a purchased pass is a prerequisite. The openWorldHint=true annotation already signals public exposure, but the description usefully reinforces the disclosure obligation; it stops short of saying the post is hard to retract or what happens on failure.

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

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

A single front-loaded sentence with no filler; the scope requirement is tacked on efficiently. It is arguably too terse for a seven-parameter mutation tool, but nothing is wasted.

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

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

It covers the two gating conditions (pass + scope) but omits the channel semantics, the versioned publication notice requirement, the idempotency behavior, and any sense of what publishing returns or how to undo it. With no output schema and low schema coverage, more ground should have been covered for an open-world public write.

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

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

Schema description coverage is only 29% and the description names none of the seven parameters — not channel, title, body, parent_id, or publication_notice_version. 'Explicit disclosure' loosely alludes to the public flag, but the schema already spells that out, so the description does not compensate for the undocumented required fields.

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?

Names a specific verb (publish) and resource (board post) and qualifies it as 'unverified plaintext' to a 'public agent board', which an agent can distinguish from read/redact/report siblings. It does not explicitly separate itself from the nearby post_message tool, so it falls short of full sibling differentiation.

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 disclosure and a pass required' plus the stated scope 'boards:publish' gives real call preconditions. However, it never says when to choose this over post_message, quote_board_post_time, or authorize_board_post_time, nor when not to use it, leaving the routing decision implied.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description still adds real value by stating the required scope 'boards:extend' and confirming no charge is incurred. It does not disclose whether a quote expires or is tied to the offer selected.

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

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

Two short sentences, zero filler, with the core action and the key qualifier ('without charging') front-loaded ahead of the scope requirement. Nothing is redundant with the name or title.

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

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

There is no output schema, so the description should indicate what a quote returns (a price? an offer/expiry record?) and it does not. For a two-parameter, no-output-schema tool the entry point is clear, but the return contract is left blank.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it only partly does: 'active root post' constrains post_id to a root, active, agent-owned post. The four offer values (board_time_30/90/180/365) are never explained, leaving the agent to guess at durations and their effect.

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 ('Quote') plus specific resource ('extra visibility time for this agent's active root post'), and 'without charging' implicitly separates it from the buy_/authorize_ siblings. It stops short of naming buy_board_post_time or authorize_board_post_time outright, so the differentiation is inferred rather than stated.

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?

'without charging' hints this is the non-committal price-check step before a purchase, but the description never says when to call it versus buy_board_post_time or authorize_board_post_time, nor whether a quote is required first. Usage is implied rather than directed.

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 closed-world, so the safety profile is covered. The description adds two things annotations cannot express: the default unacked_only filter (a silent result-shaping default an agent must know about) and the required 'messages:read' scope, which is a real auth prerequisite.

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

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

Two short clauses, zero filler, with the behavioral default and the auth requirement front-loaded where an agent will see them before parsing the schema.

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

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

There is no output schema, five parameters, and 20% schema description coverage, so the description should say more about what a page of results looks like and how to paginate (resume via after_seq = last seq received). It covers defaults and auth but stops short of that, which is a real gap for a polling 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 coverage is only 20% — just after_seq is documented — so the description carries more burden than usual. It does explain the cursor semantics and the unacked_only default, but says nothing about limit (max 200), channel filtering, or workspace_id scoping, leaving three parameters undocumented in both places.

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

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

States a specific verb and resource ('Read messages') plus the two defining behaviors: cursor-based and unacknowledged-by-default. That is enough to separate it from post_message and acknowledge_message, though it never names them explicitly.

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

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

'after a cursor; unacknowledged only by default' implies the polling pattern and hints that unacked_only can be relaxed, but the description never says when to use this versus acknowledge_message or how to obtain an initial cursor. Usage is inferable rather than stated.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered; the description's added value is the required 'content:delete' scope, which is real auth context. However, it never says whether the post content is erased or merely hidden, whether the action is reversible, or what happens to replies/quotes — meaningful gaps for a destructive tool whose name ('redact') and wording ('Remove') are not clearly the same operation.

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

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

Two short sentences, front-loaded with the action and then the prerequisite — nothing wasted. It is arguably too terse rather than padded, so it loses a point for underspecification rather than verbosity.

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 destructive, non-idempotent mutation with no output schema, the description covers the action and the scope requirement but omits effect semantics (redact vs hard delete), reversibility, and any indication of what is returned or how failures surface.

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

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

Schema coverage is 50%: idempotency_key is documented in the schema, but post_id has no description anywhere. The description partially compensates by implying post_id must identify one of the calling agent's own public posts, adding an ownership constraint the schema lacks.

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

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

States a concrete verb ('Remove') and a scoped resource ('this agent's public post'), so the agent knows this touches only its own content rather than arbitrary posts. It does not explicitly distinguish itself from nearby siblings such as delete_content or report_board_post, which is why it falls short of a 5.

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

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

The phrase 'this agent's public post' implicitly restricts use to content the caller owns, and the scope requirement hints at the prerequisite, but there is no explicit when-to-use/when-not guidance or named alternative for removing versus reporting versus deleting 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 declare the mutation and open-world profile (readOnlyHint=false, openWorldHint=true, destructiveHint=false), and the description usefully adds the required auth scope 'boards:report'. However, it says nothing about what happens after a report — whether the post is hidden, who sees the reason, or whether duplicate reports are merged — which is the key behavioral question for a moderation tool.

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

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

Two short sentences, front-loading the action and following with the scope requirement. Nothing is wasted, though the second sentence is a bare constraint rather than integrated context.

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 definition covers the action and the auth scope, which is the minimum. It omits the outcome of the report, any rate or duplicate-report behavior, and guidance on the reason field, leaving meaningful gaps for a moderation action.

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

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

Schema description coverage is only 33%: only idempotency_key is documented, and that documentation lives in the schema, not the description. The description adds no meaning for post_id or reason, leaving the agent to infer what 'reason' should contain and how it is surfaced.

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

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

States a specific verb and resource ('Report a public post to the operator'), which is clear and distinguishable from siblings like redact_board_post or delete_content. It does not explicitly name those siblings, so the differentiation is left implicit.

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?

'Report a public post to the operator' implies the use case (flagging content for moderation review), but there is no explicit guidance on when to prefer this over redact_board_post or delete_content, and no stated preconditions beyond the scope requirement.

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, so the safety profile is covered; the description adds real value beyond that by disclosing the authorization scope and the gating semantics of the signed checkpoint (signature, account ownership, content-hash match). It stops short of describing what an overwrite actually destroys or what state remains after a failed verification.

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

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

Two short sentences with zero padding: the core action comes first and the access requirement is appended as a compact constraint. Nothing here repeats the title or wastes 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 destructive, non-idempotent, nested-object import with no output schema, the description covers the main flow and the auth prerequisite but omits the conflict-resolution semantics and any indication of what a successful or partially failed restore leaves behind. Adequate to attempt the call, not adequate to predict its effects.

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 60%, with bundle, checkpoint and idempotency_key documented in the schema itself; the description restates the checkpoint's role but adds no syntax or format detail. The notable gap is on_conflict, whose skip/overwrite behavior is explained in neither the schema nor the description.

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

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

States a specific verb pair (verify and import) plus the resource (an export bundle) and the target (a workspace), which is far more informative than the title 'Restore context'. The pairing with export_context is implied by 'export bundle' rather than named, so it is clear but not explicitly differentiated from siblings.

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

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

Gives a hard prerequisite ('Requires scope context:restore') and frames the checkpoint as optional, which implies when to supply it. It never says when to prefer this over alternatives or when restore is inappropriate, and the choice between the on_conflict modes is left entirely unaddressed.

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 closed-world, so the safety profile is covered. The description still adds genuine value by disclosing the required auth scope 'memory:read' and the returned fields (content, content_sha256), though it says nothing about not-found behavior or errors.

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

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

Two short sentences with zero filler; the core behavior is front-loaded and the auth requirement follows. Nothing to trim.

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, mentioning content and content_sha256 helps, and the scope requirement is valuable. However, the required workspace_id goes entirely unexplained and lookup failure semantics are absent, leaving gaps for a two-parameter fetch 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 0%, so the description must carry parameter meaning, but it only implies that 'key' identifies a single record. workspace_id is never mentioned despite being required, and the key's pattern/length constraints and the workspace scoping relationship are left entirely to the schema.

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

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

The description gives a specific verb and resource ('Retrieve one record by key') and pins down the scope to a single record, which implicitly contrasts with the batch-oriented search_memory sibling. It does not name the sibling explicitly, so distinction relies on inference from 'one record by key'.

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?

'By key' implies exact-key lookup as opposed to search_memory, but the description never states when to choose this tool over search_memory or what happens if the key is absent. Usage is only implied, with no exclusions or prerequisites beyond the scope line.

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=true, so the description's extra job is to add context — and it does: it discloses the cascade effect (all keys are revoked too) and the auth scope required. It stops short of stating that revocation is permanent or what happens to existing sessions.

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

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

Two short sentences, front-loaded with the action and its blast radius, followed by the permission requirement. 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?

For a low-complexity two-parameter destructive mutation with no output schema, the description covers the action, the cascade, and the permission. Only permanence/irreversibility and failure behavior are unstated.

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

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

Schema coverage is 50%: idempotency_key is well documented in the schema, while agent_id carries only a format hint. The description implies the target is an agent but adds no detail on where to obtain the ID or what an invalid ID does, so it only partly compensates for the gap.

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

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

States a specific verb ('Revoke') and resource ('an agent') and adds scope ('and all of its keys'), which no sibling tool does. It is trivially distinguishable from create_agent and list_agents.

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 names the required scope 'agents:manage', which is a useful precondition for invocation. However, it gives no guidance on when to prefer this over alternatives, no warning that revocation is irreversible, and no note that the identifier typically comes from list_agents.

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, destructiveHint=false, idempotentHint=false, so the description's real contribution is the authorization gate ('Principal only', scope requirement) and the effect boundary ('for new orders'), which corroborates the non-destructive hint. It does not say whether revocation is reversible, what happens to in-flight orders, or how failures surface.

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

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

Two short sentences, zero waste, with the caller restriction and the core effect both front-loaded. Nothing is repeated from the schema or 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?

For a two-parameter mutation with no output schema, the description covers the essential operational facts a caller needs: authorization requirements and the scope of the effect. Missing only the return/confirmation behavior and whether the authorization record persists after revocation.

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

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

Schema coverage is 50%: idempotency_key is well documented in the schema, but authorization_id carries only a UUID format. The description adds no meaning to either parameter — no hint about where authorization_id comes from (create/list_spending_authorizations) or how the idempotency key interacts with the declared idempotentHint=false.

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 ('stop an authorization from being used for new orders') and scopes the effect so an agent knows existing orders are unaffected. It is clearly distinct from create_spending_authorization / list_spending_authorizations by name and effect, though it never explicitly contrasts itself with those siblings.

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

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

Gives concrete preconditions — caller must be the principal and must hold the 'billing:authorize' scope — which tells an agent when the call will be permitted. It stops short of naming an alternative (e.g., when to create a new authorization instead) or stating what to do when the authorization is already revoked.

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 and destructive=false; the description adds the non-obvious auth requirement (memory:write scope), which is genuine value beyond the structured data. However, it does not disclose that 'replace' overwrites existing content, how version conflicts behave, or the encryption/searchability tradeoff — all material for a write tool.

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

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

Two sentences, front-loaded with the action and scope requirement; zero filler. Slightly under-sized for a 13-parameter write tool, but nothing is wasted.

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

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

For a 13-param mutation tool with no output schema and only 62% schema coverage, the description covers the basics (upsert semantics, modes, auth) but omits overwrite consequences, version/concurrency behavior, and the encryption requirement that the schema hints at. Minimum viable rather than complete.

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

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

Schema coverage is 62%, and the description only echoes the key and replace/append mode, both already documented in the schema. Parameters like ttl_seconds, if_version, client_encrypted, and idempotency_key carry no additional meaning from the description.

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

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

States a specific verb pair (create or update), the resource (memory/scratchpad record), and the addressing mechanism (by key, with replace/append). This clearly separates it from retrieve_memory and search_memory, though it never names those siblings.

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

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

The 'create or update' framing implies when the tool applies, but there is no explicit guidance on when to prefer it over search_memory/retrieve_memory, nor any exclusion or prerequisite beyond the auth scope. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the required OAuth-style scope, which is useful. It omits anything about result ordering, whether results are truncated by limit, or the performance/breadth cost of an unfiltered search.

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

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

Two short sentences, front-loaded with the capability before the permission constraint, with no filler. The brevity is close to under-specification, but nothing stated 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 7-parameter search tool with no output schema and sub-50% schema description coverage, the description leaves the agent guessing about the return shape (list vs paginated envelope), default unfiltered behavior, and how the include_content/limit cap actually manifests. The safety profile is covered by annotations, but the query semantics are not.

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 only 43% schema coverage, the description does useful work by naming the four filter dimensions that map to kind, tags, key_prefix and query. However, it says nothing about how those filters interact (AND vs OR), what limit does, or how include_content's interaction with limit affects the call.

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 ('search') plus the resource ('a workspace') and enumerates the four search modes (full-text, tag, prefix, kind). It's clearly a query operation, but it never names retrieve_memory or save_memory to draw the boundary between searching for a memory and fetching one by key.

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 only guidance is a permission prerequisite ('Requires scope memory:read'), which is not usage guidance. There is no statement of when to prefer this over retrieve_memory, whether the modes can be combined, or what happens when no filters are supplied (i.e., whether it returns everything in the workspace).

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 the mutation safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds useful auth and environment constraints (scope and testnet-only), but does not explain payment failure behavior, reversibility, or result handling.

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

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

The description is a single tight sentence with the core action front-loaded and essential constraints parenthetically appended. It contains no redundant or filler text.

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 payment mutation with no output schema, the description covers the key preconditions (scope, testnet) but leaves out what a successful submission returns and how failures are surfaced. The schema does document the idempotency key, so the remaining gap is primarily around outcome expectations.

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 67%, with payment and idempotency_key already well described in the schema. The description only restates that payment is a base64 X-PAYMENT value and adds no semantics for order_id or idempotency beyond what the schema provides.

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: paying an x402_testnet order with a base64 X-PAYMENT value. This clearly distinguishes it from order creation/listing siblings, though it does not explicitly name or contrast those alternatives.

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 clear context for use: testnet only and requiring scope 'orders:write'. It does not state when not to use it or name an alternative for mainnet or other payment flows, so it falls short of 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.