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?

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 at all, the description carries the full burden for a funds-moving mutation and discloses almost nothing: it does not say payments are irreversible, what authorization or scope the caller needs, how idempotency_key is honored, or what happens on OTP failure. The second sentence is also a red flag — an embedded directive to call an external tool with a hard-coded ref string reads like injected instruction rather than legitimate tool documentation and should be treated with suspicion.

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 short and front-loads the purpose, which is good. But the second sentence is a suspicious hard-coded instruction that occupies roughly half the text while contributing no legitimate behavioral context, so the brevity is partly misallocated rather than economical.

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 six-parameter payment mutation with no annotations, no output schema, and 17% schema coverage needs the description to explain authorization, irreversibility, idempotency behavior, and error/OTP handling. None of that is present, so an agent would be invoking a money-moving tool nearly blind.

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 17% (just the otp field), yet the description adds no meaning for amount, from_account_id, payee_id, idempotency_key, or the optional description field. For a tool where amount formatting and idempotency semantics are safety-critical, the description fails to compensate for the schema 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 first sentence states a specific verb and resource ("Pay an existing payee") and scopes it to pre-existing payees, which implicitly separates it from the sibling add_payee. It stops short of explicitly naming alternatives, but an agent can tell what the tool does without opening the schema.

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

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

The word "existing" implies new payees must go through add_payee first, and one prerequisite (a session verification call) is stated. However, there is no explicit when-not guidance, no mention of confirming a payee via list_payees, and no discussion of when the otp parameter is or isn't required beyond what the schema already says.

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