uetr.ai - UETR and SWIFT Payment Tracking

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

Beyond the annotations (idempotent, non-destructive, open-world), the description discloses that plan tier governs monitoring, that a duplicate UETR returns the existing transfer and consumes no additional plan quota, and that archived transfers come back archived. It omits failure behavior such as plan limits being exceeded or invalid UETR 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?

Three tight sentences, front-loaded with what the tool does and immediately followed by the plan/duplicate consequences. The phrase 'as for an add on the website' is a slightly ambiguous appeal to outside behavior.

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

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

With a rich schema, an output schema, and annotations present, the description supplies the non-obvious parts: plan-driven monitoring and idempotent/archived behavior. Only error and quota-exhaustion paths are left 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 coverage is 100% and already documents every parameter including currency list and date bounds. The description restates the same three inputs without adding format or constraint detail, so baseline 3 applies.

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

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

States a concrete verb and resource: 'Add a transfer to the account by its UETR', with the identifying inputs named. It is distinguishable from get_transfer/update_transfer by the word 'add', though the description never explicitly contrasts 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?

Usage is only implied — the reader infers this is the enrollment/creation path because it adds to 'the account's plan'. There is no explicit when-to-use or when-not guidance relative to get_transfer, recheck_transfer, restore_transfer or update_transfer.

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, but the description goes well beyond them: it discloses which effects occur (checks stop), what is preserved (transfer and timeline), the resource cost (no active transfer place), the precondition for reversal (active subscription plus a free place), and that re-archiving is a no-op. That is exactly the irreversibility and side-effect detail an agent needs before a destructive call.

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

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

Front-loaded with the action and its effects, then the restore caveat, then the no-op case and return value — a logical ordering with no filler. It is slightly redundant, since the 'checks end' consequence is stated twice (once generally, once for free/lapsed accounts), costing a little tightness.

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?

An output schema exists, so the 'Returns the transfer' pointer is sufficient for return values, and the single-parameter schema is fully documented. For a destructive, irreversible-in-some-cases operation, the description covers preconditions, side effects, idempotency, and the restoration path — nothing material is missing.

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

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

Schema coverage is 100% and the single uetr parameter is documented with a full UUIDv4 pattern in the schema, so the schema carries the parameter burden. The description never mentions the uetr argument or any format expectations, adding nothing beyond the structured field — baseline 3.

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

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

The description opens with a specific verb+resource ('Archive a transfer') and immediately defines what archiving does: checks stop, the transfer and its timeline remain in the account, and no active transfer place is consumed. That contrasts implicitly but clearly with delete_transfer (data retained) and restore_transfer (the inverse operation), so an agent can place it among siblings 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 gives real decision context by spelling out the consequence on free or lapsed accounts (checks end and restoration is impossible without subscribing) and the no-op behavior on already-archived transfers. What it lacks is an explicit comparison to alternatives, e.g. 'use delete_transfer instead when you want the data removed' — the agent must infer that from the retention statement.

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 description adds substantial behavior beyond the annotations: the endpoint keeps its id, events, and signing secret; it returns to pending; only test events flow until owner confirmation; old-address deliveries are dropped; pending requests are withdrawn; and non-confirmation within 7 days removes the endpoint. It also discloses authorization and hourly-rate-limit implications.

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

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

The purpose is front-loaded and nearly every sentence carries operational value. The paragraph is dense but coherent; it could be split for readability, but it avoids 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 destructive webhook mutation with an output schema, the description is complete enough to call correctly. It covers the pending-confirmation state, side effects, failure/removal conditions, idempotent repeat behavior, rate limits, and authorization.

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 id and url parameters are already well documented. The description reinforces that the address must be HTTPS but does not add parameter-specific meaning beyond the schema's domain/port and length constraints.

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: sending a webhook endpoint's events to a new HTTPS address. It is clearly narrower than generic endpoint updating, but it does not explicitly distinguish itself from the sibling update_webhook_endpoint 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?

It gives a concrete usage context ('for example after the receiver moved') and explains the confirmation workflow that follows the change. It does not explicitly name when to use update_webhook_endpoint or create/delete_webhook_endpoint instead, so alternatives are left implicit.

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 substantial behavior beyond annotations (readOnly=false, openWorld=true, idempotent=false, destructive=false): the endpoint starts pending and only receives test events until the owner confirms on the website, the owner is emailed, the signing secret is returned only once, deliveries use Standard Webhooks signed headers, and only account-owner API keys or connected apps can create endpoints. This covers lifecycle, auth, and irreversibility that annotations alone do not.

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

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

Front-loaded with purpose, then lifecycle, secret handling, and permissions in four tight sentences with no filler. Some sentences are dense (parenthetical Slack/Teams clause, combined pending/confirmation clause), but nothing is 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?

Covers everything an agent needs for a non-idempotent, open-world create call with a one-time secret and a pending-verification lifecycle: who can call it, what state the endpoint starts in, what deliveries carry, and when the secret is available. An output schema already exists, so return values need no explanation here.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real value by clarifying that the url parameter may be a Slack or Microsoft Teams incoming webhook, not just a custom receiver, which the schema text does not say. It says nothing extra about the events parameter, so it is not a 5.

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

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

States a specific verb and resource ('send the account's transfer events to an HTTPS address') and names the two receiver types (own receiver, Slack/Teams incoming webhook). An agent can distinguish it from siblings like change_webhook_endpoint_url, update_webhook_endpoint, or rotate_webhook_secret without opening schemas.

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

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

Clear context for use: to send transfer events to an HTTPS address, with the accepted receiver types spelled out. It does not explicitly name alternatives such as update_webhook_endpoint or change_webhook_endpoint_url, so an agent still has to infer that this is create-only, not edit.

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; the description goes further by explaining the concrete effect (the pending seat is released without joining the team) and the plan availability. It does not say whether a declined invitation can be re-sent or what happens with an expired/consumed token, which are the remaining behavioral gaps.

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

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

Four short sentences, front-loaded with the action and the token source, then limits, then plan scope. Nothing is redundant and the scope statement comes before the exclusions.

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?

An output schema exists and annotations carry the safety profile, so the description only needs the action, the credential source, and the boundaries. All three are present, and the single required parameter is fully covered by the 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?

Schema coverage is 100% with a single documented token parameter, so the schema carries the parameter burden. The description only restates that the token comes from the invitation link, adding no format, length, or expiration semantics beyond the schema.

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

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

States a specific verb and resource (decline a team invitation) and pins the scope to the invitation addressed to the user behind this key or connection. The added exclusions (cannot decline another person's invitation, cannot remove an active membership) separate it from siblings like remove_team_member and resend_team_invitation.

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?

Makes clear the tool is driven by the token from the recipient's own invitation link and states two explicit when-not conditions. It stops short of naming the sibling tools to use instead (e.g. remove_team_member for active memberships), leaving that routing to inference.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known; the description adds genuine value by specifying what is destroyed (the transfer and its timeline), that the action is irreversible, and that re-adding the UETR later creates a fresh transfer. It doesn't cover secondary effects such as webhook deliveries or watcher state tied to the deleted transfer.

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

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

Three short sentences, front-loaded with the action and its permanence, then the alternative, then the recreation consequence. Every sentence contributes a distinct fact with no filler or repetition of the title.

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

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

For a single-identifier destructive tool with rich annotations and an existing output schema, the definition covers what the agent needs: irreversibility, the archive alternative, and the post-delete recreation behavior. Nothing essential to correct invocation is missing.

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

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

Only one parameter (uetr) exists and schema description coverage is 100%, with the pattern already constraining format in the schema. The description adds no additional semantics about the identifier beyond implying it selects the transfer to delete, so the baseline of 3 applies.

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

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

States a specific verb and resource ("Permanently delete a transfer") plus the scope detail that it applies whether the transfer is archived or not, and that the timeline goes with it. This clearly distinguishes it from sibling operations like archive_transfer, restore_transfer, or remove_team_member.

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

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

It gives a clear when-not signal by contrasting deletion with archiving ("archiving keeps the transfer instead"), which implicitly routes the agent to the archive_transfer sibling. It stops short of explicitly naming that sibling tool or stating any preconditions the caller must confirm first.

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 is not obligated to re-state danger, yet it adds concrete consequences: no further deliveries, the delivery log is removed, and a pending confirmation is closed as withdrawn. It also discloses irreversibility and an authorization constraint that the annotations do not encode.

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

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

Four short sentences, front-loaded with the action, then effects, then irreversibility, then permissions — every sentence contributes. The opening sentence merely restates the title, a small redundancy, but nothing else 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 destructive mutation with full annotation coverage and an output schema, the description supplies the side effects, irreversibility, and auth requirements an agent needs before calling it. The one gap is behavior on repeat invocation (does a second delete on the same id error or silently succeed), which the idempotent hint gestures at but does not clarify.

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

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

There is a single parameter with 100% schema description coverage telling the agent it is the webhook endpoint's UUID id, so the schema carries the load. The description adds no extra meaning about the id (e.g., where to obtain it via list_webhook_endpoints), leaving the baseline of 3 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 opens with a specific verb+resource pair ('Delete a webhook endpoint') that is unambiguous and immediately distinguishable from siblings like create_webhook_endpoint or update_webhook_endpoint. It goes further to spell out what deleting actually means for the resource, so an agent knows exactly what operation it is selecting.

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

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

Usage is implied by the destructive verb, and the final sentence gives a real precondition (only the account owner's API keys and connected apps can delete). However, it never states when NOT to delete, nor does it point at the obvious alternatives (change_webhook_endpoint_url or update_webhook_endpoint) for an agent that merely wants to disable or repoint a webhook.

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 'Reading changes nothing' largely restates them, but the description adds real behavior: page size of 50, UETR ordering, one-row-per-transfer dedupe regardless of repeat adds, and the cursor-chaining loop. It does not say what the final page looks like when no next_cursor remains, which is the main 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?

Front-loaded with the core action and scope in the opening clause, and every sentence carries information (scope, dedupe, page size, pagination). The phrase 'named the API's way' and the layered clauses make it denser than necessary but not padded.

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

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

With an output schema present, return values needn't be spelled out, and the description still covers ordering, page size, dedupe and cursor usage. Only the end-of-pagination condition and any volume/timeout caveats for a full-account export are unaddressed.

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

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

Coverage is 100% and there is a single optional parameter, so the schema already explains the UUID pattern and meaning. The description still adds value by tying it to output semantics ('pass next_cursor as cursor for the next page'), which the schema alone doesn't establish.

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 ('Export every transfer in the account') plus scope ('archived ones included') and content ('the bank reports its records hold'). It implicitly contrasts with listing/getting single transfers via 'the same records the account's export download contains', but never names list_transfers or get_transfer as siblings it differs from.

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: a bulk export of all transfers including archived ones, versus the sibling list_transfers and get_transfer. There is no explicit 'use this when you need a full archive export, use list_transfers for a filtered view' guidance and no stated exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so 'Reading changes nothing' merely restates structured data. The description does add some value by flagging that the account may carry a scheduled deletion date and can change over time, plus which identity the response reflects (API key vs connected app).

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, both front-loaded with the highest-value information: what is returned first, then why to call it. No filler or repetition beyond the brief safety closing.

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?

An output schema exists, so return-value detail is out of scope, and a zero-parameter tool needs no argument guidance. The description covers identity context, payload contents, and the reason to poll it, leaving nothing an agent needs missing.

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

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

The tool takes zero parameters, so the description carries no parameter burden and the baseline applies. Nothing about invocation arguments needs explaining.

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 ('Get the account this API key or connected app acts on') and enumerates the payload (id, role, plan, scheduled deletion date). That scope cleanly separates it from siblings such as get_plan_usage or get_payment_record, which cover narrower slices.

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?

'Check it to notice when that account changes or is ending' gives a clear motivating context for calling it. It stops short of naming an alternative tool or stating when not to call it, so it falls just below the top band.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description's main added value is the authorization constraint that only the account owner can open the link and that teammate keys are refused. The closing clause 'Reading changes nothing' largely restates readOnlyHint, and no rate-limit or link-expiry behavior 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?

A single well-formed sentence, front-loaded with the verb and resource, then purpose, then the access restriction. The only expendable clause is 'Reading changes nothing', which duplicates the readOnlyHint annotation.

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 lookup with an output schema, an agent needs only to know what the link points to and who may call it — both are stated. Failure behavior for non-owner keys is explicitly described, so nothing material is missing.

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

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

The tool takes zero parameters, so there is nothing beyond the schema to explain and the description correctly spends no words on arguments. Its silence on parameters is appropriate rather than a 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 and resource ('Get the address of the account's billing page on the website') and immediately clarifies what that page is for. It is clearly distinguishable from siblings such as get_share_link or get_payment_record, which return different kinds of links or records.

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

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

Gives the operative usage condition: the caller must be the account owner, and a teammate's key is refused. What it does not do is route the agent elsewhere for non-owner cases (e.g. to get_share_link or get_payment_record), but no sibling offers an equivalent billing-page alternative, so the omission is minor.

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. The description goes beyond them with "not counted as a visit to the record" and the not-found behavior for revoked links, both of which are non-obvious traits an agent could not infer from structured fields. It does not describe the shape of the returned record.

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

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

Four short sentences, front-loaded with what the tool does, followed by access rules and the not-found case. Every sentence carries information, though "Reading changes nothing" partially overlaps the readOnlyHint annotation.

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

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

For a one-parameter read tool with full annotation coverage and a fully documented schema, this covers purpose, access rules, and failure behavior. The only gap is the return value, which is acceptable given there is no output schema and the description does describe the resource as "the bank reports on a paid transfer".

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

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

Schema coverage is 100% for the single record_token parameter, including the max/min length and the note that either the token or the whole link is accepted. The description's phrase "from its link" merely echoes the schema, adding no new meaning; 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 uses a specific verb ("Read") plus resource ("a payment record") and frames it as link-scoped ("from its link"), which separates it from the broader get_transfer sibling. It never names that sibling explicitly, so the 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 gives access context ("Any key can read a record it has the link to, from any account") and notes the failure case for replaced or nonexistent links, which helps an agent decide when the call will succeed. It stops short of saying when to choose this over get_transfer or get_billing_link, so alternatives are left to inference.

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

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

Annotations already cover readOnly/idempotent/non-destructive, yet the description adds real behavioral context: free accounts have no active-transfer cap but rate limits still apply, finished paid transfers hold their slot until self-archiving a week after the last check, and archived transfers never count. It also explains what the custom-package variant returns and when the period resets.

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 purpose is front-loaded in the first clause and each subsequent sentence covers a distinct plan tier or rule. It is dense but mostly earns its length, though the trailing 'Reading changes nothing' restates readOnlyHint and could be dropped.

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?

An output schema exists, so return values need no narration, and the description instead covers the semantics an agent needs: what the count means, why it may be nonzero after a transfer finishes, and the extra billing-period figure on custom packages. Nothing material is missing for a no-argument 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 there is no parameter meaning to add and the baseline of 4 applies. The description correctly spends none of its budget on input semantics.

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

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

The first sentence gives a specific verb and resource: it returns the account's plan plus the count of active transfers in use. That clearly separates it from get_transfer or list_transfers, but it never names a sibling like get_account, so the agent must infer the boundary itself.

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

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

Usage is implied rather than stated: checking capacity before adding a transfer, and the note that a transfer 'can be archived sooner to free the place' gestures at archive_transfer. Neither the when-to-call condition nor the alternative tool is named explicitly, so the routing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavior: the link is publicly openable by anyone holding it, recipients can sign up for email alerts while the transfer is still being checked, and the link's stability for the transfer's lifetime has sharing implications. 'Reading changes nothing' restates readOnlyHint but is not contradictory.

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 purpose is front-loaded in the first clause, followed by lifecycle and sharing context in compact sentences. Most clauses earn their place, though 'the page the website shares' and 'Reading changes nothing' are mildly redundant with the first clause and annotations respectively.

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 an output schema for the return value, rich annotations, and a fully documented single parameter, the description only needs to explain what the link is and its exposure risk, which it does. Nothing essential for a correct call is missing, though explicit routing against siblings would complete 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?

There is a single parameter (uetr) with 100% schema description coverage plus a strict UUID pattern, so the schema carries the semantics. The description only implies that the UETR identifies a transfer and adds no format or sourcing guidance, which is the expected baseline when schema coverage is complete.

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

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

The description opens with a specific verb and resource: 'Get the link to a transfer's public status page', and clarifies it is 'the page the website shares'. An agent can distinguish this from get_transfer or share_payment_record by the 'public status page' wording, though no sibling is named explicitly.

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

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

It implies usage by describing what the link is for and cautioning 'share it only with people who should follow it', which hints at when retrieval makes sense. However, it never states when to prefer this over siblings such as get_transfer or share_payment_record, nor any prerequisites.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the closing 'Reading changes nothing' is redundant. The description earns credit elsewhere: it explains that a free transfer returns a different view, that full-view events carry the bank's own reported_at, and it documents a deterministic demo UETR that cycles through searching/reporting/credited states each hour — behavior an agent cannot infer from annotations or schema.

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

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

The opening sentence is well front-loaded, but the body is three very long run-on sentences dense with field-level semantics (free.last_report_at vs free.last_update_at, bank numbers vs counts) that read as response documentation rather than tool-selection guidance. Several clauses, such as 'they are bank numbers, not counts', exist mainly to preempt misreading and would be better placed in the output 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?

An output schema exists, so much of the field-by-field explanation duplicates structured data rather than filling a gap. Real gaps remain: how the full view versus free view is selected (account plan? transfer type?) is never stated, and error behavior for an unknown or unauthorized UETR is unaddressed.

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

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

Schema coverage is 100% and the single uetr parameter is fully specified with a UUIDv4 pattern, so the schema does the heavy lifting and baseline 3 applies. The description adds one useful parameter-level detail — a known-good demo UETR that works for every key — but no format or validation guidance beyond the schema.

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

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

States a specific verb and resource with the exact identifier ('Get one transfer in this account by its UETR') and immediately scopes the response shape (full view vs free tracker view). That distinguishes it cleanly from list_transfers and get_payment_record without needing the schema.

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

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

Usage is implied by the 'by its UETR' framing, and it does route one adjacent need to a sibling ('The number of people who follow the transfer's updates comes from get_watcher_count'), which is genuine routing value. But there is no explicit when-not-to-use guidance versus list_transfers or get_payment_record, and no statement of what happens for an unknown UETR.

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 and non-destructive, yet the description adds real substance: counts are deduplicated per address, only confirmed-and-not-stopped sign-ups count, archived transfers yield zero, and addresses are never returned. 'Reading changes nothing' merely restates readOnlyHint, so it is not a full 5.

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

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

The purpose is front-loaded and the following sentences add edge cases and privacy behavior rather than filler. The main sentence is a long clause chain that takes effort to parse, and the closing 'Reading changes nothing' duplicates the annotation, but overall it is tight.

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

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

For a one-parameter read tool with an output schema and full annotations, the description supplies the domain semantics an agent needs: what is counted, what is excluded, and what is never returned. Return shape is rightly left to the output schema, leaving only minor gaps around usage alternatives.

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

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

There is a single parameter with 100% schema coverage, so the UETR format and requirement are already fully documented. The description only implies the identifier refers to a transfer and adds no new constraint or format detail beyond the schema, matching the baseline for high coverage.

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

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

The description opens with a specific verb and resource: 'Count how many people follow a transfer's updates by email.' That is a narrow, unambiguous purpose distinguishable from get_share_link or get_payment_record. It does not explicitly name a sibling alternative, which keeps 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?

Usage is implied rather than stated: the tool counts email followers, and the description notes an archived transfer counts zero. There is no explicit 'use this when...' guidance, no statement of prerequisites, and no named alternative for related questions (e.g. listing followers or fetching a share 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 establish readOnly/idempotent/non-destructive/closed-world, so the bar is lower; the description still adds real value by disclosing that the signing secret is never returned and that the address is masked, plus the caller authorization scope. 'Reading changes nothing' largely restates readOnlyHint=true but harmlessly reinforces 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 short sentences, front-loaded with the action and its returned fields, followed by security constraints. Every sentence is close to earning its place, with 'Reading changes nothing' the only near-redundancy against 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 single-parameter read tool with an output schema, this covers the things an agent cannot infer: secret redaction, address masking, and caller authorization. Nothing essential is missing, though error behavior for an unknown id is unspecified.

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

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

Schema coverage is 100% and the single 'id' parameter is fully documented in the schema as the webhook endpoint's id, so the description adds no syntax or format detail beyond it. Baseline 3 applies when the schema carries this load.

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

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

The description opens with a specific verb+resource ('Read one webhook endpoint') and enumerates what is returned (masked address, status, events). The word 'one' implicitly separates it from list_webhook_endpoints, though no sibling is named explicitly.

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

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

Usage is implied by 'Read one webhook endpoint' plus the access restriction ('Only the account owner's API keys and connected apps can read webhooks'), which tells the agent whether a call is even permissible. There is no explicit when-not guidance or named alternative for listing vs. single retrieval.

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 the full lifecycle: nothing is sent and no seat is consumed until the owner confirms on the website, the owner is normally emailed, and repeat calls return the open request (reinforcing idempotentHint). It also adds authorization and plan constraints that the annotations do not convey.

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

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

The description is front-loaded with the core action and the confirmation requirement, and each sentence carries useful information. The line about the owner seeing the request on the website slightly repeats the earlier confirmation sentence, costing a bit of tightness.

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

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

For a single-parameter tool with an output schema and rich annotations, the description covers what an agent needs: preconditions, side effects, deferred confirmation, and duplicate behavior. Nothing material is missing.

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

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

There is only one parameter and schema coverage is 100%, with the schema itself saying "The address to invite." The description refers to "someone" and "the same address" but adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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

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

"Ask to invite someone to the team" names a specific verb and resource, and the follow-up sentence clarifies that this creates a pending request rather than sending an invitation. That nuance separates it from resend_team_invitation, though no sibling is named outright.

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 preconditions for use clearly: the caller must be the account owner's API key or connected app and the plan must include team seats. "Asking again for the same address returns the open request" implicitly tells the agent not to re-invoke for duplicates, but alternatives like resend_team_invitation are not explicitly referenced.

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, and 'Reading changes nothing' merely restates them. The genuinely additive parts are the ordering ('newest first'), the status vocabulary (confirmed/declined/unanswered, expired/withdrawn) and the caller restriction, which give real behavioral context. With return values already covered by an output schema, the surplus beyond annotations is modest.

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 short and front-loaded with the resource list before the qualifiers. The single sentence runs long and stacks several clauses ('whether ... and whether ...'), which makes it denser than needed, and 'Reading changes nothing' is padding against readOnlyHint.

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 inputs, rich annotations and an output schema, the description covers what is listed, the result ordering and the status meaning, which is enough to call it correctly. It is silent on pagination or result limits for what is presumably a growing list, the one real gap given zero parameters to control volume.

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

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

The tool takes zero parameters and the schema is fully described, so there is no parameter semantics to explain. Baseline of 4 applies; nothing in the description misrepresents the input surface.

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

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

The description opens with a specific verb plus an enumerated resource set ('team invitations, payment record shares and webhook endpoints that API keys and connected apps asked for') scoped to pending states, which implicitly separates it from list_team_members, list_webhook_endpoints and share_payment_record. It never names a sibling tool, so the differentiation is inferential rather than explicit.

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

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

It states the access prerequisite ('Only the account owner's API keys and connected apps can list them'), which tells an agent when the call will succeed. There is no explicit when-to-use vs. when-not guidance and no pointer to the sibling tools that list confirmed members, endpoints or shares instead.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so 'reading changes nothing' is mostly restatement. The real value added is the access constraint: only the account owner's API keys and connected apps can call this, and the plan must include team seats — context that shapes error handling and preconditions and is not in 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, scope front-loaded before the authorization caveat. The phrase 'while the plan includes team seats' is slightly awkward and reads as a condition buried inside a clause, 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?

An output schema exists, so return values need no explanation, and the description covers scope, authorization and idempotent read semantics. The only omission is any pointer to the overlapping pending-invitation listing 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 no parameters, so there is nothing for the description to disambiguate. Baseline applies: the empty schema plus output schema carries everything needed.

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

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

States a specific verb (list) and resource (team/people sharing the account), and enumerates exactly what comes back: owner, teammates and pending invitations, plus seat counts. An agent can tell this apart from write-side siblings like invite_team_member or remove_team_member without opening the schema.

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

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

Gives a precondition (owner API keys only, plan must include team seats) which helps an agent predict when the call will fail, but never says when to prefer this over the adjacent list_pending_access or get_account tools. Usage is implied rather than routed.

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; 'Reading changes nothing' largely restates readOnlyHint. The description does add real behavior beyond annotations: results are split into paid (full) and unpaid (free) views depending on account tier, archived records are filtered by default, and last_checked_at is explicitly distinguished from a bank report time.

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?

Roughly five sentences, each doing distinct work: scope and ordering first, then view splitting, archive default, pagination loop, and the field-semantics caveat. Only 'Reading changes nothing' is arguably redundant with 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?

An output schema exists so return values need no explanation, and annotations cover safety. Given three optional parameters and no nesting, the description supplies everything an agent needs: ordering, filtering defaults, pagination protocol, and a disambiguation of a potentially misleading timestamp field.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot: cursor should be fed the previous response's next_cursor and repeated until it is null, which documents the pagination lifecycle. The limit and archived parameters are left to the schema, which is adequate.

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

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

The description opens with a specific verb and resource ('List the transfers in this account'), then pins down scope: current status included, newest-first ordering (matching the dashboard default), and one page at a time. It also implicitly separates itself from get_transfer by naming that sibling for single-transfer bank report times.

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 concrete operating instructions (pass next_cursor as cursor until null) and states the default exclusion of archived transfers unless asked for. It routes to get_transfer for bank report times, but it does not explicitly say when to prefer this tool over siblings like export_transfers or list_webhook_deliveries.

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 false, while the description adds retention (30 days), payload omission, auth scope, ordering, and returned status/attempt fields. It also reinforces no mutation with 'Reading changes nothing', though it does not discuss pagination or rate limits.

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

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

Four short sentences front-load the purpose and then add operational constraints with no filler. 'Reading changes nothing' is slightly duplicative of readOnlyHint but is brief and reinforces the safety profile.

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 a single required id, full schema coverage, and an output schema, the definition gives enough information to invoke the tool correctly. Minor omission: it does not describe pagination or a result limit for 'most recent' deliveries.

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

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

Schema coverage is 100% and the sole parameter 'id' is documented in the schema as the webhook endpoint's id. The description confirms the endpoint scope but adds no syntax or format details beyond what the schema already provides, 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 ('List') and resource ('deliveries to a webhook endpoint'), plus ordering ('newest first') and returned fields ('attempt count' and 'last HTTP status code'). This clearly distinguishes it from sibling tools like list_webhook_endpoints, which lists endpoints rather than delivery attempts.

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 makes the inspection context clear and states the auth prerequisite: only the account owner's API keys and connected apps can read webhooks. It does not explicitly name alternatives such as get_webhook_endpoint or send_webhook_test, so when-not guidance is absent, but the use case is not ambiguous.

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 description is not carrying the safety burden alone. It nonetheless adds real behavior beyond them: addresses are redacted to host plus masked path, signing secrets are never returned, and access is restricted to the account owner's keys and connected apps. 'Reading changes nothing' is redundant with readOnlyHint but harmless reinforcement.

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

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

Four short sentences, front-loaded with the core action and ordering before the redaction and auth caveats. Each sentence carries distinct information except 'Reading changes nothing', which restates the readOnlyHint annotation and could be dropped.

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

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

For a zero-parameter read tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what is listed, the order, what is redacted, and who may call it. Return-value shape is covered by the output schema, so nothing material is missing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter meaning left to convey. The description correctly spends its words on return-value behavior instead of inventing parameter 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?

States a specific verb and resource ('List the account's webhook endpoints') plus the fields returned ('status and events') and the ordering ('oldest first'). It does not explicitly distinguish itself from siblings like get_webhook_endpoint or list_webhook_deliveries, though the singular/plural naming makes the split largely 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?

Usage is implied by 'List the account's webhook endpoints' — an agent knows this is the enumerate-everything call — but there is no explicit when-to-use versus get_webhook_endpoint or list_webhook_deliveries. The auth sentence ('Only the account owner's API keys and connected apps can read webhooks') is a useful eligibility gate but is not framed as a routing rule.

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

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

Goes well beyond the annotations by disclosing that this triggers an external bank query, the exact throttle limits (once a minute / 20 a day per transfer; 20 a minute / 500 a day per account, shared across website and API), and the permission requirement (account owner's API keys and connected apps). This is substantial context not present in readOnlyHint/openWorldHint/idempotentHint alone.

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

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

Three sentences, action stated first, then eligibility, then quotas and auth. The rate-limit sentence is dense but every clause carries operational information; nothing is filler.

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

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

With an output schema present, return shape need not be explained, and the description still covers preconditions, side effects, throttling, and authorization. An agent has everything needed to decide and call correctly.

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

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

With one parameter at 100% schema coverage including a regex pattern, the schema already carries the semantics. The description only refers to "this transfer" without adding format or lookup guidance, so baseline 3 applies.

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

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

States a specific verb and resource — "Check the banks' trackers for this transfer now" — and adds the outcome ("return it with any new reports"), which distinguishes it from plain read siblings like get_transfer or list_transfers.

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

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

Gives explicit eligibility conditions: only transfers in the full view, only while monitoring runs, and only while checks have not ended. It does not name an alternative tool (e.g., get_transfer for a plain read), so it falls short of the 5 bar of explicit alternatives.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the description adds real value beyond them: immediate loss of access, API keys and connected apps ceasing to work, and the retention guarantee that transfers stay in the account. It also discloses the owner-only authorization requirement, which no annotation conveys.

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 consequence of removal is front-loaded and the sentences are mostly tight. The closing clause ('while the plan includes team seats') is awkwardly grafted onto the permission statement and muddies an otherwise clear point.

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 destructive annotations and an output schema present, the description only needs to cover consequences, permissions, and data retention, which it does. The garbled final sentence about seats slightly weakens an otherwise complete picture for a single-parameter mutation tool.

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

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

Schema description coverage is 100% and the member_id field already documents itself as 'the teammate's seat id, from list_team_members.' The description adds no further meaning 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 ('Remove a teammate from the account') plus a second mode ('cancel a pending invitation, and free the seat'), so the agent knows exactly what the tool does. It does not explicitly distinguish itself from the sibling decline_team_invitation, which also acts on invitations, leaving a small 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?

Gives clear context for two distinct cases: removing an existing teammate and cancelling a pending invite, and adds a permission prerequisite ('Only the account owner's API keys ... can remove'). It stops short of naming alternatives such as decline_team_invitation or list_team_members for discovering the seat 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 declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the description needn't restate safety. It adds real context beyond them: the clearing semantics (empty, whitespace-only, or invisible-only labels), the authorization restriction to owner API keys and connected apps, and the return value. It stops short of saying explicitly that setting a label replaces an existing one, which is the main behavior behind the destructive hint.

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 paragraph that leads with the action, then validation rules, then prerequisites. The bidi code point enumeration is dense but each clause carries a constraint an agent could otherwise violate, so little 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?

An output schema exists, so the description needn't explain the returned transfer beyond its one-line mention. Authorization, validation, and clearing semantics are all covered for a two-parameter mutation. The only real gap is the absence of error behavior and the overwrite-versus-append question.

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

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

Schema coverage is 100% and the schema already documents both parameters, including null-to-clear and maxLength 64. The description still adds meaning the schema does not encode: empty strings, spaces, and invisible characters all clear the label, tabs and control characters are rejected, and the bidi override ranges U+202A–U+202E and U+2066–U+2069 are forbidden while U+200E, U+200F, and U+061C are permitted.

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

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

The description opens with a specific verb and resource: 'Set or clear a transfer's label,' which tells an agent exactly what the tool mutates. It does not distinguish itself from the sibling update_transfer, which could plausibly also touch labels, so an agent must infer the boundary rather than being told.

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 conditions are implied rather than stated: 'A label can be set once the transfer has been found' and the owner-only API key restriction give prerequisites for calling it. However, there is no explicit guidance on when to prefer this over update_transfer or add_transfer, and no stated 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 only say non-read-only, non-idempotent, destructive and open-world; the description adds real behavioral facts the agent could not infer: per-address hourly throttling, refusal when an invitation is already queued, no seat changes, and an auth/plan gate limited to owner API keys, connected apps and team-seat plans. This exceeds the annotation baseline rather than restating 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?

The delivery-failure condition is front-loaded and every clause carries information (trigger, refusal, rate limit, scope, auth). The telegraphic fragments like "No seat changes." are terse to the point of ambiguity but consume minimal space for the content delivered.

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 an output schema, full annotation coverage and a single well-documented parameter, the description supplies most of what an agent needs for a mutating resend. It still does not say what happens to the prior invitation or its token when a resend occurs, which matters given destructiveHint=true.

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 member_id parameter already documents both its meaning (the teammate's seat id) and its source (list_team_members). The description adds nothing about the parameter, so the standard baseline of 3 applies.

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

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

"Send a pending team invitation again when its delivery was not confirmed" gives a specific verb, a specific resource, and a narrowing condition. The words "pending" and "again" separate it from invite_team_member without requiring the agent to open either schema.

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

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

The trigger condition (delivery was not confirmed) is explicit, and the exclusion (an invitation already queued is refused) tells the agent when this call will fail. It never names invite_team_member as the alternative to use for new invitations, which is the one missing piece of routing guidance.

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

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses prerequisites, the exact monitoring window under three different plan situations, the 5-minute default check interval, and the idempotent behavior on already-active transfers. This is materially more than the structured fields provide.

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

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

The core action is front-loaded and each sentence carries distinct information (prerequisites, duration rules, frequency, no-op case, return). The billing-period enumeration sentence is dense but earns its length given the branching conditions.

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 an output schema present, return details need not be restated, and the description still covers prerequisites, duration semantics, post-restore behavior, and the no-op case. Nothing an agent needs to decide whether and how to call it 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?

There is a single parameter with 100% schema description coverage, so the schema already carries the UETR meaning and format. The description adds no further parameter guidance, which is acceptable at this coverage level.

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 opening sentence gives a specific verb and resource ('Restore an archived transfer') plus the observable effect ('so its monitoring resumes'), which cleanly separates it from archive_transfer, delete_transfer, and recheck_transfer in the sibling list.

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 gating conditions (active subscription, a free active transfer place) and adds a useful no-op case: 'Restoring an active transfer changes nothing.' It also points to set_check_frequency as the way to alter cadence afterward. It stops short of naming archive_transfer as the inverse operation or saying what to do when no place is free.

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 substantial context beyond the destructiveHint=true and non-idempotent annotations: the new secret is shown only once, both old and new secrets sign for 24 hours, a second rotation inside that window terminates the oldest secret immediately, and unrelated endpoint configuration is preserved. These details directly shape correct invocation and post-call 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?

Front-loads the purpose, then moves logically through one-time return, the 24-hour overlap, the re-rotation caveat, invariants, and permissions. Every sentence conveys operational information an agent would otherwise have to guess.

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 an output schema covering the returned secret, the description needs only to explain lifecycle and side effects, and it does so thoroughly, including the overlap window and the one-time visibility constraint. No behaviorally relevant detail is missing for a destructive, non-idempotent operation.

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

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

There is a single parameter with full schema description coverage ('The webhook endpoint's id'), so the schema already carries the semantics. The description confirms the target is a webhook endpoint but adds no format, lookup, or failure-mode guidance about the id beyond that.

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

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

States a precise verb and resource ('Replace a webhook endpoint's signing secret') and implicitly separates it from siblings such as update_webhook_endpoint and change_webhook_endpoint_url, which the description explicitly says do not apply here ('The address, events and status do not change'). An agent can tell exactly what this does without reading the schema.

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

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

Gives a concrete trigger ('for example after it was exposed') and caller eligibility ('Only the account owner's API keys and connected apps can rotate a secret'). It also warns about re-rotating within the 24-hour overlap window. It does not name a sibling alternative for changing URL/events, but the statement that those fields do not change effectively routes that case elsewhere.

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

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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds genuinely new behavior: the event is queued, delivered within about a minute, and carries sample data rather than the account's real transfers. That last point materially softens the destructive hint and is exactly the kind of context annotations cannot convey.

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

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

Four short sentences, front-loaded with the action and payload scope, then timing, then eligibility. Every sentence contributes; the only minor cost is that the auth restriction arrives last rather than up front.

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?

An output schema exists, so return values need no explanation, and the description still covers timing, payload nature, endpoint state requirements, and where to verify the result. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema coverage is 100% with a single well-documented 'id' parameter, so the schema carries the load. The description adds no format or sourcing detail beyond it, which is the expected baseline here.

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

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

States a specific verb and resource ('Queue one test event to a webhook endpoint') and immediately scopes the payload ('about a sample transfer and never one of the account's own'), which cleanly separates it from create_webhook_endpoint and list_webhook_deliveries.

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

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

Gives clear preconditions: pending endpoints can receive tests, and only the account owner's API keys or connected apps may send them. It also routes the agent to 'read the endpoint's deliveries' for the outcome, though it does not name the sibling tool (list_webhook_deliveries) explicitly.

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

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

Goes well beyond the annotations by disclosing the authorization boundary (only the account owner's API keys and connected apps), the domain preconditions that gate the operation, and the fact that it returns the transfer. None of that is derivable from readOnlyHint/destructiveHint/idempotentHint.

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

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

Three tight sentences, front-loaded with purpose then constraints then return value. The only waste is restating the minute enum inline, which the schema already provides.

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?

An output schema exists, so "Returns the transfer" suffices for return behavior. Combined with the unit, allowed values, eligibility gating, and auth requirements, an agent has everything needed to invoke this correctly.

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

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

Schema description coverage is 100% and the enum is already declared in the schema, so the description's repetition of the allowed minute values adds no new meaning. The `uetr` parameter receives no mention at all. Baseline 3 applies since the schema carries the semantics.

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

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

Opens with a specific verb+resource+unit: "Set how often this transfer's own checks run, in minutes." An agent can distinguish it from recheck_transfer (one-off recheck) and update_transfer (general field edits), though neither sibling is named explicitly.

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

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

Gives explicit eligibility conditions that function as when/when-not guidance: only paid, actively monitored, unended transfers have a frequency to set; free, finished, or lapsed transfers keep their schedule. It does not name an alternative tool for those ineligible cases, which keeps it just short of a 5.

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

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

Adds real value beyond the annotations: the request is asynchronous and returns no link until the owner confirms, notification is by email, and re-asking with identical settings returns the open request while different settings replace it — matching idempotentHint=true. It never explains the destructiveHint=true side effect in terms of what happens to an already-shared link when a new request replaces the old, which is the one meaningful 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?

Front-loaded with what is requested and the blocking confirmation requirement, then the idempotency rule and the authorization constraint. Mostly dense, though 'The owner sees the request on the website' partly repeats the preceding sentence and could be folded in.

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?

An output schema exists and the description still usefully points to list_pending_access for the eventual link, plus the confirmation/notification flow and the auth restriction. It is nearly complete for a three-parameter mutation, missing only the fate of an existing share link when a request is replaced.

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 uetr, show_fees, and show_commentary are already documented, including the 'leave out to keep current setting' semantics. The description's phrase 'same settings' hints that the booleans drive replacement vs. reuse but adds no new syntax or format detail.

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

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

States a specific verb and resource: request the payment record link of a paid transfer for sharing bank reports. It is clearly distinct from get_payment_record (fetch the record) and get_share_link, and names the async request/confirm model up front.

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

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

Gives the operational context explicitly: only the account owner's API keys and connected apps can ask, the owner must confirm on the website, and list_pending_access is the retrieval path once confirmed. It does not explicitly contrast with get_share_link, so an agent must infer which of the two to call first.

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

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

Annotations only declare the destructive/idempotent/read-write profile; the description supplies the substantive behavior behind it: a 3-correction quota shared with the website, whole-record replacement semantics, a no-op path that consumes no correction when details already match, and hard refusal conditions (archived transfer, checks ended before a report). The no-op rule is consistent with idempotentHint=true and the overwrite-with-quota rule is consistent with destructiveHint=true.

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

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

The purpose is front-loaded and most sentences carry real information, but the sentence about copies already holding the details is convoluted and hard to parse, and 'Before a report, every save checks the transfer again' is vague about what is actually checked. Tightening these would materially improve readability.

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

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

For a destructive mutation with nested parameters, the description covers quota limits, authorization scope, refusal conditions, replacement semantics and a brief note on the return payload (transfer, outcome, corrections left), while the output schema carries return detail and annotations carry the safety profile. Nothing an agent needs to call it safely is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above that by clarifying that all three details must be supplied as they should stand and are replaced together, i.e. no partial updates — a constraint the required-array alone does not make obvious. It also states the UETR is immutable because it identifies the payment.

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 opening sentence names a specific verb and resource plus the exact fields in scope: 'Corrects the amount, currency or payment date entered for a transfer.' Combined with 'The UETR cannot be changed', it separates this tool from rename_transfer and recheck_transfer without the agent needing to open 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?

It gives unusually explicit when-and-when-not conditions: allowed after a bank report up to 3 corrections, shared with website corrections, refused once archived or when checks ended before any bank reported, and restricted to the owner's API keys and connected apps. The only gap is that it never names an alternative tool (e.g. rename_transfer for name changes, recheck_transfer for re-checks) to route the agent elsewhere.

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 safety profile is covered; the description adds meaningful context the annotations lack - the account-owner-only authorization requirement and the fact that the new endpoint URL must be confirmed by the owner. It never states whether the events array replaces or appends to the existing subscription set, which is the main behavioral gap left.

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, zero padding, with the core action front-loaded before the tool-routing and permission constraints. Every sentence carries information the agent needs.

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

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

An output schema exists and annotations cover safety, so the description only needs to add scope and constraints, which it largely does. However, for a destructive replacement-style update it leaves the replace-vs-append semantics of the events list unstated, which is the one thing an agent most needs before calling 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 100% and the schema itself explains each enum value and the delivered event naming convention, so the description adds no parameter-level meaning. Baseline 3 applies when the schema already does the heavy lifting.

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

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

States a specific verb+resource: it selects which events a webhook endpoint receives, with a title reinforcing the same. It explicitly hands off a related but different operation (address changes) to change_webhook_endpoint_url, so an agent can distinguish it from siblings 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?

Names the alternative tool for the adjacent operation (changing the URL) and states the authorization precondition (account owner's API keys/connected apps only). It does not spell out when to prefer this over create_webhook_endpoint or delete_webhook_endpoint, but the context is clear.

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