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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about mutability semantics beyond the verb. It does not disclose that unknown tags are auto-created, the 6-tag cap, whether duplicates are ignored, whether the operation is idempotent, or what error occurs when the limit is hit — all of which live only in the schema.

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

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

A single front-loaded sentence with zero waste, but it is arguably too terse for a mutation tool — it could have spent one more clause on behavior without becoming bloated.

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?

Because an output schema exists, return values need not be explained, and the schema fully covers both parameters. However, for a mutation tool with no annotations the description leaves behavioral gaps (auto-creation, cap, idempotency) that structured fields alone only partially cover.

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%: the schema already documents that tags are array items, that missing tags are created, and that a transaction holds at most 6 tags, plus the transaction_id meaning. The description adds no parameter 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?

Clear specific verb ("Add") and resource ("tags" to "a transaction"), and plural "one or more tags" signals batch capability. It does not explicitly distinguish itself from the sibling remove_tags_from_transaction or list_tags, but the verb makes the direction of the operation unambiguous.

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

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

The description offers no when-to-use guidance, no prerequisites (e.g., the transaction must exist), and never names the complementary sibling remove_tags_from_transaction for the reverse operation. The agent must infer usage from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses a mutation precondition (is_categorizable) that is absent from the schema, but says nothing about permissions, reversibility of the change, or error behavior when the precondition fails — significant gaps for a write tool.

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

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

Two sentences, no filler, with the core action stated first and the precondition second. Every sentence earns its place.

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

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

An output schema exists, so return values need not be explained, and the schema fully documents parameters. The description supplies the one key gating rule (is_categorizable) an agent would otherwise miss, making it complete for this small two-parameter tool.

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

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

Schema coverage is 100%, so the schema already documents both parameters, including the 'pass null to clear' semantics and the 'parent categories are not accepted' constraint. The description's 'set or clear' merely echoes the schema's null behavior, adding no new parameter detail — baseline 3.

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

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

States a specific verb pair (set/clear) and resource (a transaction's category), which cleanly separates it from the tag-oriented siblings (add_tags_to_transaction, remove_tags_from_transaction) and the read-only get_transaction. It does not name those siblings, so it stops short of explicit differentiation.

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

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

The description gives a concrete precondition (only transactions with is_categorizable: true can be changed), which is real usage guidance. However, it never addresses when to choose this tool over the adjacent tagging tools or what to do when the transaction is not categorizable — alternatives and failure handling 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?

With no annotations, the description carries the full behavioral burden, and it discloses a high-value non-obvious trait: secret_key is returned only once and must be stored immediately. It also names the verification header (X-Up-Authenticity-Signature), which tells the agent what the secret is for. It stops short of stating auth requirements, duplicate-URL behavior, or retry semantics.

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

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

Two sentences, no filler, with the core action front-loaded and the one-time secret warning immediately after. Every clause carries information the agent cannot get elsewhere.

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

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

For a two-parameter creation tool with full schema coverage and an output schema, the description covers the critical operational fact (one-time secret) that a schema cannot express. It is nearly complete; a note on authorization or duplicate registrations would close the remaining gap given the absence of annotations.

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 'url' (publicly reachable HTTPS) and the optional 64-character 'description' are fully documented in the schema. The description adds no parameter-level detail beyond that, 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 ('Register a webhook') plus the event scope ('for transaction events'), which cleanly separates it from the list/get/delete/ping webhook siblings. An agent needs no schema inspection to know this creates a new subscription.

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

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

There is no explicit when-to-use guidance, no prerequisites (e.g. required plan or permissions), and no mention of when to prefer this over ping_webhook or list_webhooks as a next step. The only usage-adjacent content concerns verifying deliveries after the fact, not selecting this tool.

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

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

With no annotations, the description carries the behavioral burden, and it does disclose the key trait: permanence and irreversibility ('cannot be undone'). However, it omits what happens to associated resources (e.g., webhook logs), auth requirements, and whether confirmation is needed, so it is only partially complete.

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

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

Two short sentences with the destructive nature front-loaded and zero wasted words. Every clause earns its place.

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

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

An output schema exists, so return values need not be explained. For a one-parameter destructive tool the description is largely sufficient, with the main gap being the absence of auth/permission or downstream-effect context.

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 parameter is fully documented in the schema, so baseline 3 applies. The description adds no syntax or semantic detail beyond what the schema already provides for webhook_id.

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

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

States a specific verb (delete) and resource (webhook) with the added modifier 'permanently'. It does not explicitly differentiate from siblings like get_webhook or create_webhook, but the verb-resource pairing is unambiguous.

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

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

No guidance on when to use this versus alternatives such as get_webhook, or any preconditions (e.g., confirming the webhook is no longer needed). The description is purely a statement of effect, leaving the agent to infer context.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the basic operation: no error behavior for a missing id, no permission/auth requirements, no note that it is a safe read. For a getter with zero annotation coverage this is a notable gap, though the presence of an output schema offsets some of the load.

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

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

A single, front-loaded sentence with no filler or repetition. It is efficient, though its brevity borders on under-specification rather than optimal conciseness.

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 getter with a complete input schema and an output schema that documents the return, the description is minimally adequate. It omits any operational context (auth, not-found handling) but nothing structurally required to make the call is missing.

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

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

Schema description coverage is 100% with a single, well-documented account_id parameter, so the schema does the heavy lifting. The description's 'by id' adds only a restatement, which is the expected baseline of 3.

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

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

States a specific verb and resource ('Retrieve a single account by id'), and the word 'single' implicitly contrasts with the sibling list_accounts. It stops short of naming the alternative explicitly, so it is clear but not fully differentiated from siblings.

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

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

There is no when-to-use guidance and no mention of alternatives such as list_accounts. The agent must infer that this is for fetching one known account versus browsing all accounts, which is left entirely 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?

No annotations are provided, so the description carries the full disclosure burden. It doesn't say whether the call is read-only (implied by 'Retrieve' but not stated), what happens with an invalid or inaccessible id, or whether any access constraints apply. For a zero-annotation tool this is thin, though the read-only nature of a getter is fairly self-evident.

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 short sentence with the verb and identifier front-loaded and no wasted words. It is efficient, though its brevity contributes to the guidance gaps noted elsewhere.

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 return values, and the tool has only one fully documented parameter. What remains missing is minor behavioral context (failure modes, auth), acceptable for a simple getter.

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

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

Schema description coverage is 100% for the single attachment_id parameter, so the schema already documents it fully. The description adds no format, naming convention, or source-of-id detail beyond what structured data provides, making 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?

States a specific verb ('Retrieve') and resource ('a single attachment'), and the word 'single' implicitly distinguishes it from the sibling list_attachments. However, it never names that sibling or any retrieval scope (e.g., ownership/permissions), so differentiation must be inferred.

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

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

There is no when-to-use guidance and no mention of the obvious alternative, list_attachments. The agent must infer that this is the tool for fetching one attachment when the id is already known.

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

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

No annotations are provided, so the description carries the full burden. It does not state that this is a read-only operation, nor what happens when the id is unknown (error vs empty), nor any auth requirements.

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

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

A single efficient sentence with the verb and resource front-loaded and zero wasted words.

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

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

An output schema exists, so return values need not be explained, and the tool is a trivial one-parameter getter. The only gap is unstated not-found/error behavior.

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

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

Schema description coverage is 100% and the schema documents category_id with a concrete example ('booze'). The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Retrieve a single category by id'), which clearly conveys the operation. It does not differentiate itself from the sibling list_categories, though 'single' and 'by id' implicitly contrast with a listing endpoint.

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

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

No guidance on when to use this versus list_categories or other get_* siblings, and no prerequisites or context of use. The agent must infer the distinction from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Retrieve' implies a safe read-only operation and it discloses the detail fields returned, but it says nothing about lookup failures (e.g., not-found behavior), permissions, or side effects. Reasonable for a simple getter, but thin given zero annotation coverage.

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

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

One compact sentence, front-loaded with the core action and scope and followed by the useful detail about returned fields. Every clause earns its place.

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

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

For a one-parameter getter with a defined output schema, the description needn't explain return values. It covers what the tool fetches and what extra detail is included, leaving only minor gaps around error behavior.

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

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

The single parameter is fully documented in the schema (100% coverage), and the description's 'by id' aligns with the schema's transaction_id. Since the schema does the heavy lifting, the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('Retrieve a single transaction by id') with a clear scope ('single'), which implicitly distinguishes it from the sibling list_transactions. It also names the extra detail returned (hold, round-up, cashback), but does not explicitly call out the sibling 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?

There is no when-to-use or when-not-to-use guidance, and no alternatives are named. An agent must infer from 'by id' that this is the point-lookup counterpart to list_transactions, with nothing stated about preferred usage or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden, yet it discloses nothing about auth requirements, error behavior when the id does not exist, or rate limits. It only restates the read intent already implied by the name.

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

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

A single front-loaded sentence with zero filler. It is arguably too terse for the information an agent may need, but structure and economy are sound.

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

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

The tool is a simple single-resource read and an output schema exists, so return values need not be explained. However, with no annotations at all, the definition leaves the behavioral surface (failure modes, permissions) entirely undocumented, which is a gap even for a trivial read.

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% — the single webhook_id parameter is already documented in the schema as 'The webhook's unique id.' The description adds no format, source, or lookup hints beyond what the schema 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 (Retrieve) and resource (webhook) with the scoping qualifier 'by id', which cleanly separates it from list_webhooks and delete_webhook in the sibling set. It does not explicitly name a sibling alternative, but the single-resource read intent is unambiguous.

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

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

No when-to-use guidance is given; the description never mentions list_webhooks as the alternative for enumerating webhooks, nor any condition or prerequisite for fetching a single one. Usage is inferable only from the tool name.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints that balances are included in the response but says nothing about pagination behavior, auth requirements, or read-only/safe semantics that an agent would otherwise need to confirm.

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

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

A single front-loaded sentence with no filler; every word carries information and the key content (accounts + balances) appears immediately.

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

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

With an output schema present, the description need not explain return values, and all four optional parameters are documented in the schema. The only real gap is the absence of routing guidance relative to get_account, so the definition is nearly but not fully complete for this simple list tool.

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

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

Schema description coverage is 100%, so cursor, page_size, account_type, and ownership_type are already fully documented in the schema, including the rule that other arguments are ignored when cursor is set. The description adds nothing beyond that, making 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 gives a specific verb ('List') and resource ('Up accounts') and adds that balances are returned, so an agent knows exactly what the tool produces. However, it does not differentiate from the sibling get_account (singular, likely one account) or explain the relationship, leaving that distinction to inference.

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

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

There is no statement of when to use this tool versus alternatives such as get_account or list_transactions, and no mention of prerequisites or filtering intent. Usage is only implied by the verb 'List'.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that file URLs are signed and expire shortly, a real operational caveat not in the schema, but it says nothing about read-only safety, pagination traversal, or result shape beyond that caveat.

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

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

Two short sentences with zero padding; the purpose is front-loaded and the expiry caveat follows immediately.

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

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

An output schema exists, so return-value explanation is unnecessary, and pagination is covered by the schema. The description supplies the key non-schema caveat (expiring signed URLs), leaving only minor gaps such as ordering or read-only safety.

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 cursor and page_size are fully documented in the schema, including the important note that cursor overrides other arguments. The description adds no parameter meaning beyond that, 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 ('List transaction attachments'), which clearly separates it from get_attachment, the singular fetch sibling. It does not explicitly name or differentiate against that sibling, but the scope is unambiguous.

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

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

No when-to-use guidance is provided. The sibling set includes get_attachment, but the description never says when to enumerate attachments versus fetch a single one, nor does it mention any prerequisite for paginating through results.

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

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

With no annotations, the description carries the full burden, and it does disclose one meaningful trait: categories are a fixed, provider-controlled taxonomy (i.e., read-only and non-user-defined). It says nothing about ordering, tree depth, or pagination behavior, so transparency is partial.

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

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

Two short sentences with zero filler, and the core action is front-loaded before the supporting constraint.

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 not be explained, and the single optional parameter is documented in the schema. The definition is sufficient to call the tool correctly; only the tree shape and filtering behavior are left implicit.

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

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

Schema coverage is 100% and the sole 'parent' parameter already carries a description with an example id, so the schema does the heavy lifting. The description adds no filtering semantics beyond what the schema states.

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

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

States a specific verb and resource ('List the category tree'), which is enough to distinguish it from the sibling get_category that fetches a single category. It doesn't explicitly name that sibling or clarify the tree-vs-single boundary, so it falls short of a 5.

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

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

Usage is implied by the resource and by the note that categories are fixed by Up, which signals that listing (not creating/editing) is the only relevant operation. However, there is no explicit when-to-use guidance, no mention of when to prefer get_category over list_categories, and no 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?

No annotations are provided, so the description carries the full disclosure burden. It adds one genuinely useful semantic detail (a tag's id equals its label), but says nothing about permissions, whether the list is scoped to the calling customer automatically, ordering, or pagination behavior beyond what the schema already documents.

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

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

Two short, front-loaded sentences with zero filler. The scope statement comes first and the identity detail second, which is the right ordering.

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

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

An output schema exists and the parameter schema is complete, so return values and pagination mechanics do not need restating. However, with no annotations at all, the description could have cheaply closed the remaining gap by stating that this is a safe read scoped to the authenticated customer.

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%: both cursor and page_size are fully documented in the schema, including the 'all other arguments are ignored' caveat and the 1-100 bounds. The description adds nothing about parameters, 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?

Clear specific verb+resource: 'List all tags the customer has created.' An agent immediately knows this enumerates the tag catalog. It does not explicitly differentiate itself from the tag-mutating siblings (add_tags_to_transaction, remove_tags_from_transaction), but the read-vs-mutate distinction is obvious from the verb.

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

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

No guidance on when to use this versus alternatives, or what prerequisites exist. The natural workflow (list tags before calling add_tags_to_transaction) is left entirely to inference. No exclusions, no context statements.

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

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

With no annotations, the description must carry the behavioral load, and it does disclose one real trait beyond the schema: results come back newest first. It does not mention pagination behavior, default page size, or that filters combine, so the disclosure is partial.

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

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

A single front-loaded sentence with zero filler; the verb, ordering and filter dimensions all arrive before any clause ends. Nothing could be trimmed without losing information.

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

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

An output schema exists, so return values need no prose, and all 8 optional parameters are covered by the schema. The only minor gap is that pagination/aggregate behavior isn't mentioned in the description, though the cursor parameter documents 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%, so date formats, cursor semantics, enum values and page-size bounds are already fully documented. The description's filter list (account, status, date range, category, tag) adds no meaning beyond what the schema 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 and resource plus ordering ('List transactions, newest first') and enumerates the filterable dimensions. An agent can distinguish it from get_transaction by the plural scope, 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?

The word 'optionally' implies this is the browse-all entry point and filters are narrowing, which gives implied usage. There is no explicit when-to-use versus get_transaction or the tagging/categorizing siblings, 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?

With no annotations, the description carries the full burden. 'List' and 'recent delivery attempts' imply a safe read of a recent window, but there is no disclosure of ordering, retention limits, permissions, or rate limits. The pagination behavior is left entirely to the schema.

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

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

A single tight sentence with the resource and its debugging purpose front-loaded. No filler or redundancy.

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

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

An output schema exists, so return values need not be described, and all three parameters are schema-documented. The description is nearly sufficient for invoking the tool, missing only a note on pagination/recency semantics.

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 webhook_id, cursor, and page_size are already documented in the schema. The description only loosely ties 'a webhook' to webhook_id and adds no format or constraint detail beyond that, 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 (List) and resource (delivery attempts for a webhook), plus the outcome it serves (debug failing deliveries). It is distinguishable from siblings like list_webhooks and get_webhook, though it does not explicitly name them.

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

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

The clause 'to debug failing deliveries' implies the intended scenario, giving some usage context. However, it never states when not to use it or which sibling to prefer (e.g., get_webhook for config vs. this for delivery history).

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses almost nothing. It does not state that this is a read-only listing operation, does not describe pagination behavior despite cursor/page_size params, and gives no sense of result ordering or volume.

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 short sentence with no filler or redundancy, and the core purpose is front-loaded. Its only weakness is that it is so terse it conveys little more than the tool name.

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

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

The tool is simple (0 required params, output schema present so return values need not be explained), which lowers the bar. Even so, for a listing tool with pagination semantics and several sibling list/get tools, the description is barely complete enough to route an agent 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%, with cursor and page_size fully documented in the schema itself, including the notable detail that cursor makes all other arguments ignored. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a clear verb and resource ("List ... webhooks"), but it essentially restates the title "List Webhooks" and adds only the word "configured." It offers no differentiation from siblings like list_webhook_logs or get_webhook, so an agent cannot tell from the text why it would pick this over the alternatives.

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

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

There is no guidance on when to use this tool versus get_webhook, list_webhook_logs, or ping_webhook. No prerequisites, no mention of the paginated listing context, and no exclusions are given.

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

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

With no annotations, the description carries the burden, and it does disclose meaningful behavior: it verifies auth (token validity) as well as connectivity, implying an auth-failure return mode. It does not state side-effect-free/read-only nature, rate limits, or failure semantics, which for a zero-arg health check is a modest 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?

A single front-loaded sentence with no wasted words that covers both facets of the check (auth validity and reachability).

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 not be described, and the description covers the full scope of this simple no-arg tool. Minor gaps remain around error/auth-failure reporting, but nothing essential for correct invocation is missing.

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

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

The tool takes no parameters, so there is nothing to disambiguate; baseline 4 applies and no schema compensation is 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 (check) and the exact resources verified: the configured Up API token and API reachability. It implicitly distinguishes itself from the similarly-named sibling ping_webhook, though it never names that alternative explicitly.

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

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

The purpose implies a diagnostic/health-check use case (validate credentials, confirm connectivity), but there is no explicit statement of when to call it versus siblings like list_accounts, nor any 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully reveals the nature of the operation by calling the event a 'test PING' (implying it is diagnostic rather than a real delivery), but it says nothing about side effects, rate limits, whether the ping is logged, or what a failure implies.

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

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

One sentence, front-loaded with the action and ending with the purpose; every clause earns its place and there is no filler.

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

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

For a single-parameter diagnostic tool with an output schema covering the response, the description is essentially complete about what the tool does. It could add a note on the return semantics of a failed ping or any rate/duplicate-send constraints, which is the only gap.

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

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

Schema description coverage is 100% and the single parameter is already documented as 'The webhook to send a PING event to.' The description adds no format, identifier, or validation detail beyond that, so the schema does the heavy lifting and 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?

The description uses a specific verb and resource ('Send a test PING event to a webhook'), making the action unambiguous. It implicitly separates itself from the sibling `ping` (which pings something other than a webhook) and from `get_webhook`, but it never names an alternative to make the distinction 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?

'...to verify it is reachable' states the concrete situation in which the tool is the right choice, which is clear usage context. It stops short of naming alternatives (e.g. list_webhook_logs, get_webhook) or stating when not to use it, so it does not reach a 5.

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

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

No annotations are provided, so the description carries the full burden. It implies a mutation but says nothing about idempotency, what happens when a tag is not present on the transaction, permission requirements, or reversibility.

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 efficient sentence with the verb front-loaded and no filler. It is perhaps overly terse, 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. However, for a destructive mutation with no annotations at all, the description should at least cover partial-failure or missing-tag behavior to be fully complete.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description's 'one or more tags' adds minor reinforcement of the array/minItems semantics but no new 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?

Clear specific verb ('Remove') plus resource ('tags from a transaction'), and 'one or more' conveys batch semantics. It distinguishes itself adequately from add_tags_to_transaction by the verb alone, though it does not explicitly name the sibling.

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

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

There is no guidance on when to use this versus related tools such as add_tags_to_transaction or list_tags, and no mention of prerequisites. The context is only implied by the verb.

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