Modern Treasury MCP by usefulapi

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

Annotations give destructiveHint=true, but the description adds genuinely useful context the annotation cannot: that this is purely a record-creation step that "MOVES NO MONEY" and carries "no bank details." That runtime/scope framing is valuable for an agent reasoning about financial risk. It stops short of describing return values or idempotency, so it is not a 5.

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

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

Three short, front-loaded sentences with zero filler. The most important facts (what it does, what it does not do, the underlying endpoint) come first and each sentence earns its place.

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

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

For a 3-param create tool with one required field, no output schema, and full schema coverage, the description covers purpose, scope, and endpoint adequately. Minor gaps remain: no statement of return shape (the created record id) or what happens on duplicate/invalid input, which an agent calling it would benefit from.

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 three parameters (name, email, metadata); baseline 3 applies. The description adds no format, validation, or constraint detail 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?

Specific verb+resource ("Creates a counterparty (contact) record in Modern Treasury") and it disambiguates from the read-only siblings (get_counterparty, list_counterparties) by being an explicit create. The parenthetical "(contact)" further pins down what a counterparty is. No ambiguity about what operation this performs.

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

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

The scope caveat ("Creates a record only — no bank details, MOVES NO MONEY") implies the tool's role but never states when to use it versus alternatives or prerequisites (e.g., whether it must exist before creating payment orders). No sibling is named or excluded, so usage 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the underlying API mapping (GET /counterparties/{id}), which is useful for an API-wrapper suite but discloses nothing about error behavior (e.g. missing id) or response shape.

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

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

Two short sentences, front-loaded with the action, with no wasted prose. The endpoint line is marginally redundant but is consistent with the API-mapping style of the surrounding toolset.

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

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

For a one-parameter read tool whose annotation already declares readOnly, the description plus schema is essentially sufficient. Only minor gaps remain, such as what a counterparty object contains or what happens on an invalid id.

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

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

With 100% schema description coverage on a single required 'id' parameter, the schema already carries the parameter semantics. The description only restates that lookup is by id, adding no format or sourcing detail.

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

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

States a specific verb and resource ('Get a single counterparty by id'), which cleanly separates it from list_counterparties. It does not explicitly name the sibling it is not, but the singular scoping makes the distinction inferable.

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

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

The description gives no when-to-use or when-not-to-use guidance and does not point to list_counterparties as the way to discover ids. The 'by id' phrasing weakly implies a prerequisite lookup step, but nothing is stated.

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

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

readOnlyHint=true already tells the agent this is a safe non-mutating read, so the bar is lower. The description adds that balances are returned, which partially compensates for the absent output schema, but it says nothing about not-found/error behavior or data freshness.

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

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

Two short sentences, zero filler, with the operation front-loaded and the endpoint appended as a compact reference. 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 read tool with annotations covering the safety profile and no output schema, the description supplies the essentials: what is fetched, that balances come back, and the underlying endpoint. Only minor gaps remain, such as error behavior for an unknown id.

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

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

There is one parameter with 100% schema description coverage ('Ledger account id.'), so the schema carries the full parameter burden. The description repeats 'by id' without adding format, source, or lookup guidance beyond what the schema already 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 ('Get a single ledger account by id') and the word 'single' implicitly separates it from the sibling list_ledger_accounts. It adds that balances are included, which is useful scope detail. It stops short of naming the list sibling explicitly, so it is clear but not maximally 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?

The phrase 'by id' implies this is for fetching one known account rather than enumerating accounts, which is enough to infer usage. However, there is no explicit when-to-use statement, no exclusion, and no pointer to modern_treasury_list_ledger_accounts for discovery-style lookups.

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 set readOnlyHint=true, and the '(READ ONLY)' text merely restates that rather than adding new behavioral context. The endpoint notation (GET /payment_orders/{id}) is a small extra, but nothing is said about error behavior for missing ids, auth requirements, or expandable sub-resources. For a simple read this is acceptable but thin.

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 short sentence, front-loaded with the verb and resource, with the endpoint trailing. The parenthetical '(READ ONLY)' is redundant with the annotations and slightly wastes space, keeping it just short of a 5.

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

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

For a one-parameter read tool with no output schema and no nested objects, the description is sufficient to invoke correctly: the agent knows it fetches one payment order given an id. Nothing essential is missing, though it does not hint at what fields the returned object contains.

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 schema documents the single 'id' parameter at 100% coverage, so the schema already carries the semantics. The description's 'by id' adds no format or sourcing detail beyond what is already there, which matches the baseline 3 for a fully covered single-parameter schema.

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

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

States a specific verb and resource ('Get a single payment order by id'), and the word 'single' implicitly separates it from the list_payment_orders sibling. It does not name that sibling explicitly, so the differentiation is inferential rather than stated.

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

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

Usage is only implied: an agent can infer this is the fetch-one-by-id path when the id is already known, versus list_payment_orders for enumeration. No explicit when-to-use, when-not-to-use, or named alternative is provided.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds only the underlying API route (GET /transactions/{id}), which is mildly useful for mapping but discloses no behavior such as error handling or what happens on an unknown id.

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

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

Two short sentences, front-loaded with the action; nothing is padded. The API-route sentence is arguably redundant for an agent but is compact and does convey the underlying endpoint.

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

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

There is no output schema, so the description carries the burden of indicating what a transaction object contains or returns, and it says nothing about the response payload. Adequate for invocation, incomplete for interpreting results.

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

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

Schema coverage is 100% and the single 'id' parameter is documented in the schema. The description adds no format, prefix, or example detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get a single transaction by id'), and the word 'single' implicitly distinguishes it from the sibling list_transactions. It is clear, but it never names or contrasts with that sibling 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?

No guidance on when to use this versus list_transactions or other get_* siblings. The only implied cue is that an id is required, which the schema already conveys.

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

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

Annotations already declare readOnlyHint=true, and the description restates the read semantics via 'GET /counterparties' without adding anything new. It discloses no pagination behavior, no result ordering, and no filtering combination rules that would go beyond the structured fields.

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

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

Two short, front-loaded sentences with zero filler; the resource is named first and the endpoint follows as supporting 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?

For a simple read-only list tool with a fully documented schema, the essentials are covered, but with no output schema the description could have noted pagination/next_cursor behavior and what fields a counterparty record returns.

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 name, email, per_page, and after_cursor are already fully documented in the schema (including defaults and cursor origin). The description adds nothing beyond that, 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+resource ('List counterparties') and disambiguates the domain term with '(contacts)'. It is clearly distinguishable from other list_* siblings by resource, though it doesn't explicitly contrast 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?

No indication of when to use this list versus get_counterparty for a single record, nor any prerequisite/auth context. The only implied guidance is the resource being listed.

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?

'(READ ONLY)' merely restates the readOnlyHint=true annotation, so it earns no credit. The only added information is the underlying endpoint GET /expected_payments, and the description says nothing about ordering, pagination flow, or result shape.

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

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

Two short sentences, front-loaded with the purpose, with no filler. It is lean but stops at the minimum, offering no structural cues such as pagination notes.

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

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

For a simple zero-required-parameter list tool with fully documented params and no output schema, this is minimally adequate. Pagination semantics and result ordering are left entirely to the schema and are not reinforced, leaving a small gap.

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

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

Schema description coverage is 100%, so status, per_page, and after_cursor are already fully documented in the schema. The description adds no parameter meaning beyond that, 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 ('List expected payments'), which cleanly distinguishes it from sibling list tools such as list_payment_orders and list_transactions. It does not explicitly contrast itself with any sibling, but the resource name does the differentiating work.

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 choose this over list_payment_orders, list_transactions, or the other list siblings, nor any stated prerequisites. The agent must infer usage purely from the resource name.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds only the underlying REST endpoint mapping, not pagination behavior, auth requirements, or return shape, which are the details that would matter here.

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

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

Two short sentences with no padding, and the resource scope is front-loaded. The trailing endpoint note is minor but harmless traceability 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?

For a simple read-only list tool with a fully documented schema and readOnlyHint, the essentials are present. Still missing is any mention of pagination flow or what the response contains, which matters for a list endpoint without an output schema.

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

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

Schema description coverage is 100%, so per_page, after_cursor, and counterparty_id are each documented in the schema. The description adds no filtering or pagination semantics 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 external (counterparty) bank accounts'), which distinguishes it from the sibling list_internal_accounts by the word 'external'. It is clear but does not explicitly name the sibling or contrast the two.

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

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

There is no when-to-use guidance, no prerequisites, and no alternatives named. The reader can infer that this is a read-list operation, but nothing routes the agent between this and list_counterparties or list_internal_accounts.

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 structurally. The description adds the underlying REST endpoint (GET /internal_accounts), which is minor context, but says nothing about pagination behavior or result ordering beyond what the schema params imply.

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 no filler. The API endpoint sentence is marginally useful but borders on redundancy; otherwise tight.

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

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

No output schema exists, so the description carries some burden for describing what is returned, which it does not do (no mention of account fields or pagination shape). For a simple paginated list tool with readOnly annotations, it is adequate but leaves gaps.

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

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

Schema description coverage is 100%, so per_page and after_cursor are fully documented in the schema. The description adds nothing about parameters, which is acceptable at full coverage — 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 clear verb+resource: 'List your organization's internal bank accounts.' An agent knows what it does, but the description never distinguishes 'internal' from the sibling 'list_external_accounts', which is the one distinction that matters here.

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 the closest alternative (modern_treasury_list_external_accounts or list_ledger_accounts). The agent must infer selection 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds only the REST endpoint (GET /ledger_accounts), which is not behaviorally useful; it says nothing about pagination, filtering constraints, or the shape/limits of results.

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

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

Two short sentences, front-loaded with the operation, with no filler. It is terse rather than padded, though the endpoint sentence adds little for an agent.

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 paginated list tool with fully documented parameters and no output schema, the definition is minimally viable. It omits any mention of pagination semantics or how ledger_id scopes results, leaving those entirely to the schema.

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

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

Schema description coverage is 100%, so the schema fully documents per_page, ledger_id, and after_cursor; baseline 3 applies. The description adds no syntax, format, or interaction 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?

The description gives a specific verb+resource ('List ledger accounts'), so an agent knows the operation and target object. It does not differentiate from close siblings such as list_ledgers, list_ledger_entries, or list_ledger_transactions, which all sound nearly identical.

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 list tools, no mention of prerequisites (e.g. needing a ledger_id), and no exclusions. 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?

readOnlyHint=true already tells the agent this is a safe read, so the description's burden is light. It adds the underlying endpoint (GET /ledger_entries) but nothing about pagination behavior, result volume, or ordering 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 terse sentences, purpose front-loaded, with the endpoint reference appended. Nothing is padded or restated.

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

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

For a simple read-only list endpoint with a fully documented schema and no output schema, the definition covers what the tool is. The only gap is the absence of any hint about filtering scope or pagination flow, which the schema largely supplies.

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 parameters (per_page, after_cursor, ledger_account_id) are documented in the schema itself. The description adds no parameter meaning, 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 ('List ledger entries') and adds a clarifying parenthetical defining entries as individual debits/credits, which separates it from siblings like list_ledger_transactions and list_ledgers. It does not explicitly name or contrast those siblings, keeping it short of a 5.

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

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

The description gives no when-to-use guidance, no mention of the filtering/pagination options, and no indication of when a sibling list tool would be preferable. Usage is only weakly 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?

Annotations already declare readOnlyHint=true, so the description needn't restate safety. It adds nothing beyond that: no pagination behavior, no note that results are cursor-paged or that an empty list is possible. The API line is the only extra fact and it is redundant with the annotations/title.

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, purpose front-loaded, zero padding. The 'API: GET /ledgers' clause is mildly redundant but harmless and compact.

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 read-only list tool with full schema coverage and a readOnlyHint annotation, this is functionally adequate, but there is no output schema and the description says nothing about the shape or paging of results, leaving the agent to infer 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 both parameters (per_page, after_cursor) are already fully documented in the schema. The description adds no parameter meaning, which is the expected baseline of 3 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 and resource ('List double-entry ledgers') plus the underlying endpoint, which is enough to distinguish it from siblings like list_ledger_accounts or list_ledger_entries. It stops short of explicitly contrasting itself with those neighbors.

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 the many sibling list/get tools, no prerequisites, no exclusions. The agent must infer usage 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 readOnlyHint annotation already tells the agent this is a safe read, so "READ ONLY — does not post value" is largely redundant; the added clause that it does not post value to the ledger is a small clarification. Nothing is said about pagination behavior, result limits, or ordering beyond what the schema exposes.

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

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

Two short clauses, front-loaded with the operation and resource, with no filler. Slightly terse for a list tool but nothing is padded or buried.

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

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

For a zero-required-parameter list tool with full schema coverage and readOnlyHint annotations, the description is minimally sufficient, but with no output schema it gives no hint about the shape of returned ledger transactions or pagination envelope (next_cursor / X-After-Cursor). Adequate but with clear gaps.

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

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

Schema description coverage is 100% across all three parameters, so the schema already documents per_page limits, ledger_id filtering, and the after_cursor semantics. The description adds no parameter meaning beyond that, 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 (List) and resource (ledger transactions) plus the underlying endpoint GET /ledger_transactions. It does not distinguish itself from close siblings such as modern_treasury_list_ledger_entries or modern_treasury_list_transactions, so an agent must infer the boundary from the resource noun alone.

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 mention of alternatives (e.g. list_ledger_entries vs list_ledger_transactions), and no prerequisites. The only usage-adjacent statement is the READ ONLY marker, which is restated from the annotations rather than routing the agent between tools.

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

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

Annotations already declare readOnlyHint=true, and 'READ ONLY — does not create or approve payments' largely restates that safety profile rather than adding new behavioral context. The GET /payment_orders endpoint reference is metadata, not behavior; pagination semantics (cursor-driven paging) are 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?

Extremely short and front-loaded: the operation and its scope are stated in the first clause with no wasted words. The trailing 'API: GET /payment_orders' is arguably decorative for an agent that already has the tool name and annotations, costing it the top mark.

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-required-parameter read-only list tool with full schema coverage and no output schema, an agent has everything needed to invoke it correctly. Only the pagination flow (using next_cursor from a prior response) is implicit and would benefit from a sentence.

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 five filters (status, per_page, direction, after_cursor, counterparty_id) are already documented with meaning in the schema. The description adds no filter semantics of its own, 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+resource ('List payment orders') that is immediately distinguishable from the singular sibling modern_treasury_get_payment_order. However, it never explicitly contrasts itself with get_payment_order or the other list_* siblings, so differentiation relies on the agent's reading of the name alone.

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 the many sibling list tools (list_transactions, list_returns, list_expected_payments) or versus get_payment_order for a single record. The parenthetical about being read-only constrains scope but is not usage routing.

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

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

readOnlyHint=true already establishes the safe-read profile, so the description's job is lighter. It adds useful domain framing by clarifying what a 'return' is (ACH returns) but says nothing about pagination behavior, result scope, or filtering, leaving those 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?

Two terse, front-loaded sentences with no filler; the primary purpose comes first. The trailing 'API: GET /returns' is marginally useful and doesn't bloat the text.

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

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

A simple, read-only, no-required-param list tool with a fully documented schema and no output schema to explain. Nothing essential is missing, though pagination semantics and result scope remain unstated.

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

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

Schema description coverage is 100%, so per_page and after_cursor are fully documented in the schema already. 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 ('List') and resource ('payment returns'), with a clarifying example ('e.g. ACH returns') that pins down the domain concept. No sibling list tool covers returns, so differentiation isn't needed, but the description also doesn't proactively distinguish itself from the other list_* 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?

Provides no when-to-use guidance, no prerequisites, and no mention of alternatives. The agent is left to infer that this is the endpoint for retrieving payment returns from context 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 readOnlyHint annotation already establishes this is a safe read, so the burden is reduced. The description adds the underlying API endpoint but says nothing about pagination behavior, default result sets, or account scoping beyond what the schema 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?

Two short sentences, front-loaded with the purpose. The endpoint note is marginal but not wasteful. Nothing extraneous.

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

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

For a simple read-only list tool with full schema coverage and no output schema, the description is minimally adequate. It omits any mention of return shape or pagination continuation, but the cursor parameter in the schema partly compensates.

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 three parameters (per_page, after_cursor, internal_account_id) are already well documented in the schema. The description adds no additional parameter meaning. 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 (bank transactions), which is clearer than the bare name. It does not, however, distinguish itself from the sibling modern_treasury_list_ledger_transactions, which an agent could easily confuse with it.

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 get_transaction or list_ledger_transactions, no mention of prerequisites or pagination workflow. The agent must infer the use case entirely.

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 and the bar is lower. The description adds that this validates credentials, not just network reachability, which is meaningful behavioral context. It does not state what a failure looks like, but for a zero-parameter health check that is a minor gap.

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

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

Two short clauses, front-loaded with the purpose and followed by the endpoint. Nothing is padded or repeated.

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

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

For a no-param, no-output-schema, read-only ping, the description covers purpose, credentials validation and endpoint. The only missing piece is whether a successful response confirms auth specifically, but that is a small gap for this trivial 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?

Zero parameters, so the baseline is 4. The description correctly implies the call needs no input beyond ambient authentication, adding nothing misleading.

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: verify connectivity and credentials, plus the underlying endpoint GET /ping. It is clearly distinguishable from the data-fetching siblings, which all concern counterparties, ledgers, payments or transactions.

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 'auth check' in the title and 'verify credentials' implies the context — validating that the API key and connection work before other calls. But it never explicitly says when to use this versus simply calling a real endpoint, nor names any alternative. Usage is implied rather than stated.

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