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

Annotations already declare destructive=true, idempotent=true, openWorld=true, but the description adds substantial non-structured context: human approval gating, at-most-once execution, the rule that a chain receipt alone never proves bank credit, and the reconciliation requirement for uncertain submissions. It is consistent with idempotentHint rather than contradicting it.

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

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

Three dense sentences, front-loaded with the core action and approval requirement, followed by safety constraints. Every sentence earns its place, though the wording is terse to the point of being clipped.

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, open-world mutation tool with no output schema and a single fully-documented parameter, the description covers approval, at-most-once execution, retry/reconciliation, and credit-claiming semantics. It does not describe failure/error behavior or what an agent should report back after execution, leaving a small gap.

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

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

Schema description coverage is 100% and the payoutId description already carries the key guidance ('never create a replacement to retry'). The description adds no parameter-level syntax or constraints beyond what the schema states, so the baseline 3 applies.

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

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

States a specific verb+resource (execute a prepared payout) with the crucial qualifier 'at most once' and the approval step. An agent can immediately distinguish it from prepare_payout (which produces the quote) and from payout_status (which only inspects).

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

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

Explicitly defines the retry/repeat semantics ('Repeated calls inspect the existing payout'), the reconciliation requirement for uncertain submissions, and the prohibition on resending. It does not explicitly name payout_status or payout_history as alternatives for pure inspection, but the context is clear enough to route correctly.

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

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

Annotations already cover readOnly, idempotent, non-destructive and closed-world, so the bar is lower, and the description still adds meaningful context the annotations cannot express: the values are simulated demo data and no funds move. That is exactly the kind of caveat an agent needs before reporting a balance as real.

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 filler; the resource and the demo-value caveat are both front-loaded. Every clause earns its place.

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

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

For a zero-parameter read tool whose annotations already declare the safety profile and with no output schema required, the description is nearly complete. Only the return shape (a balance figure) is left implicit, which is a minor 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 per the rubric the baseline is 4. There is nothing for the description to clarify about inputs, and it does not need to.

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 and resource (inspect the USDC balance) and scopes it to Arc cashouts, which separates it from the payout/bank siblings. It stops short of explicitly contrasting with any named sibling, 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?

The phrase 'for Arc cashouts' hints at context, but the description never says when to call this versus alternatives like payout_status or payout_history, nor that it should precede prepare_payout/execute_payout. No exclusions or prerequisites are given.

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, non-destructive and closed-world, so the safety profile is covered. The description usefully adds that no bank is auto-selected and that the account ending is masked, which is genuine behavioral context beyond 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?

Two compact sentences, front-loaded with the action and return payload, neither of which is padding. 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?

With no parameters and no output schema, the description carries the burden of conveying the return shape, which it does (bank, name, masked ending). It stops short of stating what happens when no saved bank exists, a minor gap for such a simple read tool.

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

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

The tool takes zero parameters, so the baseline is 4; there are no arguments whose meaning could be clarified. Nothing in the description misrepresents the parameterless contract.

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

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

The description uses a specific verb (Get) and resource (saved recipient's bank) and names the returned fields (bank, name, masked account ending), which lets an agent distinguish it from set_default_bank. It never explicitly names siblings, but the get-vs-set contrast is clear from the naming.

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 when-to-use or when-not-to-use statement relative to prepare_payout, execute_payout, or set_default_bank. The clue that 'no bank is chosen automatically' implies behavior rather than routing guidance, so the agent is left to infer usage.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and non-open-world, so safety is covered. The description adds useful behavior beyond that: results are capped at ten entries, scoped to the local mode/profile, and bank account numbers are masked — the masking note is genuinely valuable context not derivable from annotations.

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

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

Two short sentences, front-loaded with the core action and scope. No filler; every clause (cap of ten, local profile, masking) 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 no-parameter, read-only list tool with full annotation coverage and no output schema, the description is nearly sufficient. It could mention ordering or an empty-history case, but nothing essential for correct invocation is missing.

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

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

The tool takes zero parameters (schema coverage 100%), so the baseline is 4. Nothing about the description conflicts with the empty schema, and no parameter meaning needs to be added.

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

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

States a specific verb (List) and resource (payouts) with a clear scope: the ten most recent in the local profile. It doesn't explicitly contrast itself with payout_status, though the 'history/list' framing versus a single-status lookup is reasonably inferable.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as payout_status or get_balance. The agent must infer the use case entirely from the tool name and 'ten most recent' 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?

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds genuine value beyond them: completion is only reported after the provider confirms, demo completions are simulated with bankPaid=false, and no funds are ever sent. It stops short of describing latency, polling expectations, or error states.

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

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

Three short sentences, front-loaded with the core action and scoping constraint, followed by return-value caveats. 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?

There is no output schema, so the description reasonably covers the most load-bearing return semantics (completion only on provider confirmation, demo bankPaid=false). It leaves the overall response shape unspecified, but for a one-parameter read tool with full safety annotations, the agent has what it needs.

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

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

Schema description coverage is 100% and the single payoutId parameter is fully documented in the schema (including the "never create a replacement to retry" warning). The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource ("Inspect an existing payout") and immediately separates itself from the write siblings with "Never sends funds," so an agent can distinguish it from execute_payout and prepare_payout without opening any schema.

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

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

The description implies the tool is for checking status of an already-created payout (vs. creating/executing one), but it never explicitly names when to use this instead of payout_history or execute_payout. 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?

Adds real context beyond the annotations: it clarifies that despite readOnlyHint=false nothing moves funds, and 'repeated calls create separate quotes' explains the non-idempotent behavior in practical terms. Currency semantics (NGN = exact receive, USDC = max total spend incl. fees) is behavior an agent cannot get from structured fields.

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

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

Four short sentences, each carrying distinct information, with the safety-critical 'no funds move' claim front-loaded. No filler.

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

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

Covers the essential behaviors for a quote tool (no fund movement, currency meaning, bank defaults, non-idempotency). It stops short of describing the quote's lifecycle or expiry, which matters given there is no output schema.

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 33% schema coverage, the description carries needed weight: it defines currency semantics precisely and explains when to omit bank (defaults to saved). Amount format is left to the schema, which already covers it well.

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

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

States a specific action ('Prepare a quote') and immediately scopes it ('no funds move'), which cleanly separates it from execute_payout among the siblings. An agent can tell this is a quote-creation step, not a transfer.

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 routing rules: default to the saved bank, supply a bank only when the user explicitly asks for another destination, and warns that repeated calls make separate quotes. It never explicitly names execute_payout as the follow-up step, which is the one missing link.

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, openWorldHint=true, idempotentHint=false and destructiveHint=true. The description adds genuinely new behavior: human approval is required, the account is verified before saving, and it happens only once. It does not explain why destructiveHint is true or what happens to a previously saved default account, which is the remaining gap.

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

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

Two tight sentences with zero filler; the core action is front-loaded and the approval prerequisite and demo constraints follow in priority order.

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

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

For a three-required-parameter mutation with no output schema and full schema coverage, the description covers the essential non-schema facts: verification, human approval, one-time nature, and demo constraints. It is nearly complete, lacking only what happens to a pre-existing default.

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

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

Schema description coverage is 100%, so the schema already defines each field, including min/max lengths and the 10-digit pattern. The description only repeats demo values, adding no format or validation meaning beyond what the schema documents. Baseline 3 applies.

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

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

The description states a concrete verb+resource: verify and save a default Nigerian bank account. It implies a one-time operation ('once'), which distinguishes it implicitly from the sibling get_default_bank. It does not explicitly name or contrast with that sibling, keeping it just short of a 5.

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

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

It gives a prerequisite ('requires human approval through the MCP client') and demo-mode values, which is useful context, but it never states when to use this tool versus get_default_bank or when not to (e.g., if a default already exists). The set-vs-get distinction must be inferred from the name.

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