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

Annotations declare readOnlyHint=true, so the safety profile is already covered. The description adds genuinely useful behavioral detail beyond that: the response carries two distinct balances (cleared = settled, effective = including pending), which prevents misreading the output. It does not cover error behavior for an unknown accountUid.

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, front-loaded with the action and followed by the one detail an agent needs to interpret the result. 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?

The tool is a single-parameter read with an output schema that documents the return shape, so the description need not explain return values; its clarification of the two balance types covers the only ambiguity. Nothing required to invoke it correctly is missing.

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

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

Schema description coverage is 100% for the single accountUid parameter, so baseline 3 applies. The description says 'a specific account' but adds no format or provenance guidance for the UID beyond what the schema provides.

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

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

States a specific verb and resource ('Get the balance for a specific account') and immediately clarifies the scope of the returned data. It is trivially distinguishable from siblings like accounts_list or transactions_list, which cover different resources.

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: an agent needing a balance for one account would pick this, but the description never says when to prefer it over accounts_list or transactions_list, nor any preconditions such as resolving an account UID first. Adequate but with a clear gap.

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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read. The description adds that the payload contains name, address, and other personal details, which is modest extra context, but it does not disclose auth requirements, error behavior, or caching/rate limits beyond the annotation.

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

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

A single front-loaded sentence with no filler. The resource and scope come first, and every clause ('logged in', 'including name, address') 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 parameterless read tool with an output schema covering the return shape and an annotation covering safety, the description is close to sufficient. It could note that no arguments are needed or that the response is the full profile, but nothing critical 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 of 4 applies; the description correctly implies no input is required because it targets the logged-in holder implicitly.

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 detailed information about the logged in account holder') and scopes it to the authenticated user, which cleanly separates it from siblings like account_balance_get, account_identifiers_get, and accounts_list. It does not explicitly name those alternatives, so it stops short of a 5.

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

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

Usage is implied by the purpose: fetch the current account holder's profile when personal details are needed. There is no explicit when-to-use statement, no exclusion, and no pointer to a sibling for related data such as identifiers or balances.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds a little value by enumerating the identifier types returned, but says nothing about auth requirements or the shape of the response beyond that enumeration.

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 parenthetical examples earn their place by clarifying what 'identifiers' means.

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 read-only, single-parameter lookup with an output schema present, the description covers enough; return values need not be explained. Only a brief note on error/empty behavior would improve 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?

Only one parameter exists and schema coverage is 100%, so the schema fully documents accountUid; the description adds no syntax or format detail. Baseline 3 is appropriate when the schema does all the work.

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 (Get) and resource (an account's bank identifiers) with concrete examples (sort code, account number, BIC, IBAN). It is clear enough to distinguish from siblings like account_balance_get or account_holder_get, though it never explicitly contrasts itself with 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?

There is no statement of when to use this tool versus account_balance_get, account_holder_get, or accounts_list, and no prerequisites or exclusions. Usage is only implied by the 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?

readOnlyHint=true already tells the agent this is a safe read, so the description doesn't need to restate safety. It does add that results are scoped to the logged-in holder and that one holder may have several accounts, which is useful context. It says nothing about pagination or result volume, and with an output schema present, return-format disclosure is not required.

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

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

Three short sentences, with the core purpose front-loaded and the usage hint immediately after. The multi-account example sentence is arguably illustrative padding, but it does clarify the expected result shape and is not wasteful.

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 zero parameters, an output schema to describe returns, and read-only annotations, the description covers what an agent needs to select and call this tool. A brief note on pagination or ordering would close the remaining gap.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There are no parameter semantics to clarify, and the description correctly does not invent any.

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

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

The description states a specific verb+resource: 'Get all accounts associated with the logged in account holder.' The scope (all accounts for the authenticated holder) is clear. It does not, however, explicitly contrast itself with sibling tools such as account_holder_get or account_identifiers_get, so an agent must infer the difference.

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?

'This is typically the first call to make to get account information' gives clear sequencing context for when to reach for this tool. It stops short of naming alternatives or stating when not to use it, but the entry-point guidance is genuinely useful.

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 only annotation is readOnlyHint=false, so the description carries the behavioral burden and mostly fails: it does not say whether locking is immediate, whether it is reversible, what permissions are required, or what side effects (e.g., blocked transactions) occur. 'Lock/unlock' merely restates the mutation already implied by the annotation.

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

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

A single short sentence with zero waste and the operation front-loaded. It is terse but not padded; the terseness is under-specification rather than verbosity.

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

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

An output schema exists, so return values need no explanation, and the two-parameter schema is fully documented, making this a low-complexity tool. Still, for a financial card lock the description leaves out the operational meaning of locking and any auth or reversibility notes.

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 both parameters (cardUid, enabled) are documented in the schema, so the baseline is 3. The description maps lock/unlock onto the enabled boolean but adds no extra semantics beyond the schema's own explanation.

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 and resource: enable/disable (lock/unlock) a card. It is clearly distinguishable from the list-oriented siblings (cards_list, accounts_list), though it does not explicitly contrast itself with any of them, which is a minor omission given no other card-mutation tools appear in the sibling set.

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 tool versus alternatives, no prerequisites, and no note on reversibility or authorization. It simply restates the operation with no usage 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?

The readOnlyHint annotation already establishes this as a safe read, so the description need not restate it. It does add that results are scoped to an account holder, but says nothing about pagination, result size, or whether cards are returned for all holders under the credentials — a real ambiguity given the phrase "for an account holder".

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 redundancy. Nothing is wasted and the resource comes first.

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 return values and a readOnlyHint covering safety, the description only needs to state purpose and scope, which it largely does. The remaining gap is the unresolved question of which account holder's cards are returned.

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 are zero input parameters and schema coverage is 100%, so the baseline is 4. The phrase "for an account holder" implies the holder is derived from auth context rather than passed in, which is consistent with the empty schema, though it could momentarily make an agent look for a holder parameter.

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

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

The description gives a specific verb and resource ("Get all the cards") and adds scope ("for an account holder"), which is enough to separate it from card_lock_update and the payee/savings siblings. It stops short of naming any sibling or contrasting behavior, so it is clear but not differentiating.

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

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

Usage is only implied: an agent can infer you call this to enumerate cards, but the description states no when-to-use condition, no alternatives (e.g., card_lock_update for state changes), and no prerequisites. Adequate for a zero-parameter list tool, but nothing explicit.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description needn't re-establish that. It does add the 'all mandates' scope and the account-level restriction, but says nothing about auth requirements, pagination, or result ordering.

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 front-loaded sentence with no filler or redundancy. It is efficient, though the brevity borders on under-specification rather than tight editing.

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 annotation covers the safety profile. Combined with 100% schema coverage, the remaining gap is only the lack of pagination or usage-context detail.

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 required accountUid, so the schema already documents the parameter fully. The phrase 'for an account' merely echoes that scoping without adding format or sourcing detail, making the baseline 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 ('Get') and resource ('direct debit mandates') scoped to an account, which plainly separates it from siblings like standing_orders_list and payees_list. It stops short of explicitly naming or contrasting those siblings, but the resource is unambiguous.

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

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

There is no when-to-use, when-not-to-use, or alternative routing guidance; the description only restates what the tool returns. For a list tool with an obvious sibling set (standing_orders_list, payees_list, cards_list), a sentence on which mandate type this covers would have been cheap and useful.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the useful return detail (base64 encoded data), but discloses nothing about auth requirements, size limits, or error behavior. With annotation coverage present, a 3 is appropriate.

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

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

Two short sentences with zero waste; the core action is stated first and the return format second. Nothing is padded or redundant.

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

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

With no output schema, the description does carry the return-value burden and covers it via the base64 detail. Safety is covered by annotations; only auth/prerequisite context is missing, which is minor for a read-only fetch.

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 all four parameters are already documented in the schema. The description adds no syntax or format detail beyond that, making baseline 3 correct when the schema does the heavy lifting.

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

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

States a specific verb (download) and resource (attachment from a feed item/transaction), so the agent immediately knows what it does. The verb 'download' inherently contrasts with the sibling feed_item_attachment_upload, though neither is explicitly named.

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

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

The description gives no when-to-use guidance, prerequisites, or alternatives. It neither states when to reach for this tool nor points to siblings like feed_item_attachment_upload or feed_item_get.

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 only annotation is readOnlyHint=false, which already signals a write operation. The description adds no behavioral context beyond that, such as permission requirements, whether an existing attachment is overwritten, size limits, or what the response contains. It is consistent with the annotation but does little to enrich the agent's understanding.

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

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

The description is two tight sentences, front-loading the purpose before the input-format note. There is no filler or redundancy, and it is appropriately sized for a simple upload tool.

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

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

Given the tool's simplicity, full schema coverage, and the presence of an output schema, the description is nearly complete for correct invocation. It omits any when-to-use guidance relative to siblings, but the essential purpose and input choice are covered.

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

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

Schema description coverage is 100%, and the description merely repeats the schema's own explanation of filePath and attachmentData. Since the schema already documents all six parameters fully, the baseline score of 3 is appropriate; the description adds no meaning beyond structured fields.

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

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

The description states a specific verb and resource: 'Upload an attachment to a feed item (transaction).' This clearly separates it from the sibling feed_item_attachment_download, but it does not explicitly name the sibling or clarify boundaries with other feed-item tools.

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

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

The description gives input-format guidance ('Provide either base64 encoded attachment data or a file path (recommended)'), but this is parameter usage rather than tool usage. It never says when to choose this tool over alternatives like feed_item_note_update or feed_item_attachment_download, nor does it state prerequisites or 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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds that attachments are included, which is useful behavioral context, but it does not disclose any other traits such as permission needs, error behavior, or response richness beyond what the output schema provides.

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

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

The description is a single front-loaded sentence with no wasted words. It immediately names the resource and the main value-add (attachments).

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

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

For a simple read-only getter with a full input schema, an output schema, and readOnlyHint, the description is nearly complete. It could optionally mention that the output schema defines the returned fields, but no critical calling information is missing.

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

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

Schema description coverage is 100%, and all three required UID parameters are documented directly in the schema. The description does not add format, default, or constraint details beyond what the schema already provides, so 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?

The description states a specific verb and resource: get details of a specific feed item (transaction). It also clarifies that attachments are included, which distinguishes this detail-fetch from list operations like transactions_list and from sibling update/attachment tools.

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

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

The description implies usage by saying it gets details of a specific feed item, but it does not explicitly state when to use this tool versus transactions_list or feed_item_attachment_download. The context is inferable but not spelled out.

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

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

Annotations only declare readOnlyHint=false, leaving the description to carry the rest. It does not say whether the note replaces existing content, what permissions are required, whether the operation is reversible, or what happens on an unknown feedItemUid — meaningful gaps for a mutation 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?

A single short sentence that is front-loaded and wastes no words. It is arguably under-specified rather than over-long, but structurally it is clean.

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 all parameters are documented in the schema, so return values need not be explained. However, for a write operation with only a readOnlyHint annotation, the description omits the overwrite/reversibility semantics an agent would need to call it confidently.

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 all four parameters are already documented in the schema, including the categoryUid hint about the default category. The description adds no meaning beyond that, 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 specific verb (update) and resource (user note for a transaction), which is clearly distinct from the closest sibling, feed_item_spending_category_update. It does not explicitly name or contrast with that sibling, but the resource is unambiguous enough for an agent to select correctly.

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 feed_item_spending_category_update, no preconditions, and no note about whether the update overwrites an existing note or how to clear one. Usage must be inferred entirely from the name and schema.

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 readOnlyHint=false, so the description bears most of the burden for behavioral disclosure. It does not state permission requirements, whether the update is reversible, what happens to the prior category, or any side effects. It adds nothing beyond restating the mutation.

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 action front-loaded and no wasted words. It is appropriately sized, though extremely sparse.

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 annotations plus full schema coverage carry much of the load. Still, for a mutation tool the description could clarify preconditions or effects; it is minimally adequate rather than complete.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, establishing a baseline of 3. The description adds no meaning beyond what the schema provides, so it does not exceed the baseline.

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: update the spending category of a transaction. This is clear and unambiguous. However, it does not distinguish it from sibling mutation tools like feed_item_note_update or other feed_item operations, so it stays below 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer the context entirely from the name and schema.

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 only structured signal is readOnlyHint=false, confirming a write. The description adds nothing beyond that: it does not say whether duplicate payees are rejected, whether bank details are validated, whether the call is idempotent, or what happens on failure. For a mutation with six required fields, that is a 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?

A single short sentence with the verb front-loaded and no filler; the parenthetical earns its place by defining the domain term. It is efficient, though arguably under-specified rather than optimally concise.

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 schema fully documents inputs. However, for a create operation with six required fields and multiple siblings, the description omits prerequisites and duplicate-handling behavior, leaving it only minimally adequate.

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 all seven parameters, including the two enums, are already documented in the schema. The description contributes no additional parameter meaning, which matches the baseline 3 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?

States a specific verb (Create) and resource (payee), and the parenthetical clarifies what a payee is, distinguishing it from the read-only siblings payees_list and payee_delete. It stops short of explicitly naming those siblings or contrasting scope, so it lands just below 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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives like payment_create or payees_list. The intended workflow (create a payee before sending a payment) is only implied.

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

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

Annotations only declare readOnlyHint=false, which the word "Delete" already implies, so the description adds no context beyond the structured data. For a destructive operation it should disclose irreversibility, effects on related records or payments referencing the payee, and any auth requirements; none of this is present.

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 a single short sentence with no wasted words, but the brevity reflects under-specification rather than efficient communication. There is no front-loaded detail to speak of beyond the verb and object.

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, but for a destructive tool with only readOnlyHint=false in the annotations the description is too thin. An agent gets no signal about consequences, confirmation requirements, or side effects before invoking it.

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

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

Schema description coverage is 100% for the single payeeUid parameter, so the schema already documents the input. The description adds no format or sourcing detail (e.g., where to obtain the UID), so the baseline 3 applies.

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

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

The description states a clear verb and resource ("Delete a payee"), so the basic operation is unambiguous. However, it is essentially a restatement of the tool name and title, and it does nothing to distinguish this from siblings like payee_create or payees_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?

There is no guidance on when to use this tool versus alternatives such as payee_create, nor any mention of prerequisites or conditions. Nothing is misleading, but nothing is offered either.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the useful domain gloss on what a payee is, but says nothing about pagination, result size, or filtering behavior beyond the implicit account-holder scope.

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

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

A single front-loaded sentence with no filler; the parenthetical defining 'payees' earns its place by disambiguating the term.

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 list tool with an output schema describing the returns and annotations covering the safety profile, the description is essentially complete. Only minor details like pagination expectations are absent.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There are no arguments whose meaning the description could usefully add.

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 (Get all) and resource (payees) and even defines the domain concept (people/companies you can send payments to). It is easy to tell apart from payee_create/payee_delete by name, but the description itself never explicitly contrasts the listing scope 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?

The phrase 'for the account holder' implies the scope of the query, but there is no explicit when-to-use guidance, no prerequisite notes, and no mention of alternatives. Usage is only inferable from the list-style verb.

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

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

Annotations only declare readOnlyHint=false, so the description must carry the behavioral burden for a money-movement write. It says nothing about irreversibility, whether the payment can be cancelled, idempotency, or required authorization, which are the traits an agent most needs before moving funds.

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, front-loaded sentence with no wasted words. It is efficient, though the brevity reflects under-specification rather than tight information packing.

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 financial write tool with only readOnlyHint=false and no other annotations, the description is too thin: it omits preconditions, irreversibility, and any error/confirmation behavior. An output schema exists, so return values need not be explained, but the safety-relevant context 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 80%, so the schema already documents all five parameters (amount, reference, accountUid, categoryUid, destinationPayeeAccountUid). The description's 'existing payee' phrasing loosely maps to destinationPayeeAccountUid but adds no format or constraint detail beyond the schema, 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?

The description states a specific verb and resource ('Create a payment') plus a constraint ('to an existing payee'), which distinguishes it from the sibling payee_create. It is clear but offers no further differentiation from other mutation siblings such as standing_orders_list or savings_goal_deposit.

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 alternatives, no prerequisites (e.g. the payee must already exist, funds must be available), and no mention of any confirmation or approval flow. The 'existing payee' phrase implies a precondition but never states it as usage guidance.

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

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

Annotations provide only readOnlyHint=false, so the description carries the rest of the burden and delivers nothing: no required permissions, no note that target is optional, no statement about side effects or what the created object contains. It at least does not contradict the annotation.

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

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

A single front-loaded sentence with no filler, which is efficient. However, this brevity stems from under-specification rather than disciplined editing, so it earns no credit above adequate.

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 4-parameter write tool with a nested target object, the description never mentions which fields are required (accountUid, name, currency) or that target is optional. The output schema and full schema coverage carry the structural load, but the description leaves the agent with no behavioral or usage 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 description coverage is 100% and the nested target object is fully documented in the schema, so the baseline of 3 applies. The description adds zero parameter meaning beyond what the schema already provides.

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

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

The description 'Create a new savings goal' is a verbatim restatement of the tool title 'Create savings goal'. It names no scope, no distinguishing behavior, and nothing that separates it from siblings like savings_goal_deposit or savings_goal_update beyond the obvious 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as savings_goal_update for existing goals. The agent must infer everything from the tool 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?

The only annotation is readOnlyHint=false, which already tells the agent this is a write operation. The description adds nothing beyond that: it does not disclose that deletion is irreversible, whether funds in the goal are returned to the account, or what permissions are required. For a destructive tool with no destructiveHint, this is a 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?

Three words, zero waste, and the operation is front-loaded. It is minimal but not tautological, so it avoids the under-specification penalty while remaining appropriately sized for the label it is.

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, but for a destructive delete the description should at least note irreversibility or side effects. With only readOnlyHint=false as annotation coverage, the agent lacks the behavioral context needed to invoke this safely.

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 (accountUid, savingsGoalUid) are documented in the schema, so the baseline of 3 applies. The description adds no format, constraint, or identifier-sourcing detail beyond what the schema already provides.

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

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

States a specific verb (Delete) and resource (savings goal) in a single phrase, so an agent immediately knows the operation. However, it offers no differentiation from siblings such as savings_goal_update or savings_goal_withdraw beyond the name 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no warnings. The description does not even mention the obvious routing distinction against savings_goal_update or savings_goals_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?

Annotations only declare readOnlyHint=false, so the agent knows this is a mutation, and the description adds nothing beyond that bare fact. It omits whether funds move immediately, whether the balance is capped, permission needs, or that the amount is in minor units — all critical for a money-movement 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?

The single short sentence is efficient and front-loaded, but its brevity stems from under-specification rather than disciplined concision. It earns its place as a minimal label but carries no operational 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 3-required-parameter mutation tool with a nested amount object, the description is far too thin; it does not explain the write semantics or the amount encoding. The existence of an output schema relieves it of describing return values, but the remaining gaps are still substantial.

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

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

Schema description coverage is only 67%, and the description supplies none of the missing meaning — it never mentions accountUid, savingsGoalUid, or the currency/minorUnits structure of amount. For a nested-object amount parameter, this leaves the agent dependent on the schema alone with a notable documentation gap.

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

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

The description states a specific verb ('Add money') and resource ('savings goal'), so the action is unambiguous. However, it does not differentiate itself from nearby siblings such as savings_goal_withdraw or savings_goal_create, and it essentially restates the tool name rather than adding scope detail.

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 alternatives like savings_goal_withdraw, nor any prerequisite about the goal or account needing to exist. The agent is left to infer usage entirely from the 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?

readOnlyHint=true already tells the agent this is a safe read, and the description adds nothing beyond that restatement. There is no mention of pagination, result limits, or whether goals from closed/archived states are included, which is the kind of detail a list tool benefits from.

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 tool's scope, but nothing in it 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 not be described, and the sole required parameter is documented in the schema. The description is sufficient for correct invocation, though it stops short of any scoping or ordering 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 description coverage is 100% and there is only one required parameter (accountUid), so the schema already carries the parameter semantics. The description adds no format or sourcing detail beyond what the schema provides, making the baseline 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 and resource ('Get all savings goals for an account'), which clearly separates it from the mutation siblings savings_goal_create/update/delete/deposit/withdraw. It does not explicitly name a sibling to route away from, but the list-vs-mutate distinction 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, no prerequisites, and no mention of alternatives such as account_balance_get or the savings_goal_* mutation tools. Usage is only implied by the word 'all'.

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

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

Annotations declare readOnlyHint=false, consistent with an update operation, so there is no contradiction. However, the description adds nothing beyond that: it does not say whether the update is partial or full-replacement, what happens to omitted fields like the nested 'target', whether permissions are required, or whether the change is reversible.

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 single sentence is front-loaded and contains no filler, so it is efficient. It is under-specified rather than genuinely concise, which caps the score.

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 five-parameter mutation tool with a nested object and four required fields, the description omits the semantics that matter most: partial vs. full update behavior and the treatment of omitted fields. The existing output schema means return values need not be described, but the mutation contract itself is not covered.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters, including the nested target.currency and target.minorUnits, which sets the baseline at 3. The description adds no semantics of its own, notably nothing about whether omitting 'target' clears an existing target amount.

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 verb and resource ('Update ... savings goal'), but it is essentially a restatement of the tool name and title, with 'existing' the only added information. It does not distinguish this from siblings such as savings_goal_create, savings_goal_delete, savings_goal_deposit, or savings_goal_withdraw, nor does it say which fields are updatable.

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 the sibling goal tools, no prerequisites, and no indication of what happens if the goal does not exist. The agent must infer everything 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?

The only annotation is readOnlyHint=false, which already indicates a mutation. The description adds no behavioral context such as reversibility, permissions required, side effects on the savings goal balance, or error conditions.

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 single sentence is concise and front-loaded, but it is under-specified for a financial mutation with a nested amount object. It earns its place but does not provide sufficient structure or detail.

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

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

Given the tool is a mutation with a nested amount object and only a readOnlyHint=false annotation, the description is incomplete. It does not explain prerequisites, side effects, or confirm what happens to the savings goal balance, though the output schema means return values need not be described.

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

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

Schema description coverage is 67%, with accountUid, savingsGoalUid, and the nested currency/minorUnits fields documented in the schema. The description adds no parameter meaning, but the schema carries most of the burden, making this minimally 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 'Withdraw money from a savings goal' is a tautology that restates the tool name and title. It states a verb and resource but offers no differentiation from siblings like savings_goal_deposit or insight into scope.

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 savings_goal_deposit, nor any mention of prerequisites such as sufficient funds or goal state. The description provides no usage context.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the account-category scoping constraint, but says nothing about return contents, pagination, or ordering despite the tool being a list operation. That is adequate but not rich.

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 for a list tool with no usage guidance.

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?

Parameter semantics and return values are handled by the 100%-covered schema and the existing output schema, so the core calling information is present. What is missing is usage context (when to choose this over sibling list tools), leaving the definition minimally viable.

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

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

Schema description coverage is 100%, so both accountUid and categoryUid are already documented in the schema, including the note to use the default category for the main account. The description merely echoes the category scoping and adds no syntax or format detail beyond the schema.

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

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

The description states a specific verb (Get) and resource (standing orders) plus a scoping constraint (for an account category). It is clearly distinguishable from siblings like direct_debits_list or transactions_list, though it does not explicitly differentiate itself from 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The agent must infer its use case purely from the name and one-liner.

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?

readOnlyHint=true already establishes this is a safe read. Beyond that the description adds nothing behavioral: no pagination, no maximum date-range limit, no ordering, and no note on how the required timestamp window affects results. For a date-bounded feed query those traits matter.

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

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

Two short sentences with the core purpose front-loaded and no filler. It is efficient, though the second sentence is largely redundant with the schema.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still, for a timestamp-windowed transaction feed with four required params, the description omits window limits and pagination behavior, leaving it only minimally complete.

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

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

Schema coverage is 100%, so all four parameters (accountUid, categoryUid, min/maxTransactionTimestamp) are already documented in the schema. The description's category guidance duplicates the schema's own categoryUid note rather than adding new meaning, so 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?

The description states a specific verb and resource ('Get transaction feed items for an account category'), which is clear enough to act on. It does not differentiate from any sibling (e.g., feed_item_get), but there is no direct competing list tool, so the gap is minor.

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

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

The only guidance is 'Use the default category UID for main account transactions,' which is a parameter hint rather than a when-to-use rule. There is no indication of when this tool should be chosen over alternatives like feed_item_get, nor any prerequisite or exclusion.

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