NorthPark Banking API

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

No annotations exist, so the description carries the full burden and it discloses almost nothing: not that OTP from the authenticator app is required and will be consumed, not that this is an irreversible mutation, not whether external payees need validation. Only the split between NorthPark and external payees hints at differing behavior.

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 efficient, though the brevity borders on under-specification for a 5-parameter mutation 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?

With 5 parameters (4 required), no annotations, no output schema, and 40% schema coverage, the definition leaves major gaps: authentication flow, external-vs-bank conditional fields, and failure modes are all unaddressed.

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

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

Schema description coverage is only 40% – bank, name, and account_id have no descriptions at all. The phrase 'external US payee' weakly implies the bank enum's 'external' value and that routing_number applies only there, but the description never explains the required OTP, the account_id format, or the conditional routing number.

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 (Add) and resource (payee) and distinguishes the two payee categories, NorthPark (in-network) vs external US. An agent knows what entity gets created, though it doesn't explicitly contrast with siblings like list_payees or make_payment.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites (an OTP is required, routing number conditional on external), and no note about what happens if the payee already exists. The agent must infer everything from the 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?

With no annotations, the description carries the full burden. It usefully discloses the output format (CSV) and included content (counterparties), but it does not state permissions, read-only behavior, export size/limits, date-range behavior, or delivery method.

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 filler. It is efficient, though it could be structured more explicitly around scope and filtering behavior.

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

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

There is no output schema or annotations, and the description omits critical context for an export tool: date range, whether account_id filters the result, permissions, and handling of large exports. It is insufficiently complete for safe and correct invocation.

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 has one optional account_id parameter with 0% description coverage, and the description does not explain it. Worse, 'for all accounts' may mislead an agent about whether account_id filters the export to a single account.

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

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

The description states a specific verb and resource: 'Export full statements' for accounts, in CSV format, including counterparties. It is clearly different from list_transactions and make_payment, though it does not explicitly name sibling alternatives.

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

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

There is no explicit guidance on when to use this tool versus list_transactions or other siblings, nor are prerequisites or exclusions stated. The intended use is only implied by the words 'Export full statements.'

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a safe read ('List') and hints at return contents ('balances'), but says nothing about permissions, scope of accounts returned, pagination, or rate limits.

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

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

A single front-loaded sentence with no wasted words. It is arguably too sparse, but that is a completeness issue rather than a conciseness flaw.

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 list tool with no output schema and no annotations, the description is minimally adequate: it names the resource and signals balances are returned. It omits account scope, auth requirements, and output shape, which the structured fields do not cover either.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to explain. Baseline 4 applies here.

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

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

States a specific verb ('List') and resource ('accounts and balances'), which is enough to separate it from list_payees and list_transactions by resource alone. It does not explicitly name or distinguish itself from those siblings, keeping it 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?

The intent to view accounts is implied by the verb and resource, but there is no explicit when-to-use guidance, no exclusions, and no mention of the sibling list or payment tools. Usage is inferable but not 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?

With no annotations, the description carries the full disclosure burden, and it delivers almost nothing: no statement of whether these are the authenticated user's own saved payees versus a global directory, whether the list is paginated or truncated, or whether any authorization/linked-account requirement exists. Only the possessive "your" hints at user scoping.

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 with no filler and nothing buried. It is arguably under-specified rather than bloated, which is penalized in contextual completeness rather than here.

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 should at least signal what a returned payee looks like (id, name, account details) or whether the result set is bounded; instead it is silent. For a read tool an agent may chain into make_payment, that is a meaningful 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 there is nothing to document and the baseline of 4 applies. Schema coverage is nominally 100% but vacuous.

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 (payees), and the resource name does implicitly distinguish it from list_accounts and list_transactions. However, the sentence is essentially the snake_case tool name rendered as prose, adding only the word "your" as new information, so it sits at minimum-viable rather than genuinely clarifying.

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 call this, no prerequisites (e.g., auth or connected payment provider), and no reference to any of the three siblings, even though make_payment almost certainly consumes payee identifiers. The agent must infer the relationship to make_payment on its own.

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

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing: not that this is a safe read, not the ordering of results, not whether the list is truncated, and not what 'recent' means in practice. The only behavior hint is the word 'recent', which is too vague to act on.

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 fragment with no filler, which is good for front-loading, but the brevity comes from under-specification rather than tight writing — there is no verb and no complete sentence.

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 annotations, no output schema, and 0% parameter description coverage, the description needed to carry the load and does not. An agent cannot tell what a returned transaction looks like, how results are ordered or paginated, or how the required account_id should be obtained.

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 0% for both parameters, so the description must compensate and largely fails. 'on one of your accounts' implies account_id identifies the account, but the description says nothing about the format of account_id, the meaning of limit, or what the default/maximum result count is — the agent must infer limit's behavior from the schema bounds alone.

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 phrase names the resource (transactions) and implicitly the verb (list), and the sibling set makes the resource distinction obvious (accounts, payees, payments). But it is a noun fragment with no verb, and 'recent' is undefined — no time window, ordering, or default count — so the agent knows roughly what it retrieves but not the 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 when-to-use guidance, no prerequisites (e.g., account_id must come from list_accounts), and no mention of alternatives or when not to call it. The only routing signal is the resource noun itself.

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

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

With no annotations, the description carries full behavioral burden. It adds one useful trait—"Large payments settle instantly"—but omits critical context for a payment mutation: irreversibility, authentication/OTP requirements beyond the schema note, idempotency behavior, limits, and failure handling.

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

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

Two tightly written sentences with no wasted words. Purpose is front-loaded, and the settlement-speed note is compact and relevant.

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 six-parameter payment mutation with no annotations and no output schema, the description is far too thin. It lacks prerequisites, safety warnings, idempotency guidance, authentication details, and any information about what the call 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 coverage is only 17%, with just the otp parameter described in the schema. The description does not explain from_account_id, amount format, payee_id versus external wallet address, idempotency_key, or description, leaving most parameters undocumented.

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

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

The description uses a specific verb, "Pay", and a clear resource scope: an existing payee or external wallet address. The word "existing" helps distinguish it from add_payee, though it does not explicitly name that sibling.

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

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

It implies this is for payments to an existing payee, but gives no explicit when-to-use guidance or comparison to alternatives such as add_payee or list_payees. An agent must infer that add_payee is for creating payees rather than paying them.

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