Bankrolled.ai Agent Hub

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds information annotations cannot express: that the endpoint requires no API key and incurs no cost, plus the shape of the response (ok and version). It does not mention rate limits or failure modes, which keeps it short of 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 terse fragments with zero filler: purpose first, then return shape, then access constraints. Every clause earns its place, and the key fact (liveness check) is front-loaded.

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-param health check with annotations covering safety and no output schema, the description supplies what an agent actually needs: what it returns, that it is free, and that no key is required. Only interpretation of a failing result is left implicit, which is a minor 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 the baseline of 4 applies. Nothing in the description is needed to explain inputs, and it 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 names the operation (liveness check) and states what it returns (ok and version), which is specific for a zero-argument tool. Sibling tools (money_fact, pricing_list, scheme_lookup) are unrelated lookup endpoints, so there is no sibling to differentiate against.

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?

"Free, no key" implies the tool can be called without credentials or cost, which is a light usage cue, but there is no explicit when-to-use guidance or statement of when another tool would be preferable. Usage is largely implied by the universally understood semantics of a health check.

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 cover only read/idempotent/open-world safety, but the description goes much further: it discloses the exact return shape (fact, source {name,url}, as_of, jurisdiction, cite), that no auth or key is required ('Free, no key'), and the failure mode ('Unknown -> not_in_catalog (never guesses)'). These are behavioral traits not present in the structured annotations.

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?

Front-loads purpose, then usage, input format, return shape, cost, and failure behavior in a tight sequence with no filler. The long parenthetical enumerations of jurisdictions and account types add selection value but make the sentence dense; slightly trimmed, it would read better.

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 and a single required parameter, the description fully compensates by naming return fields, the error sentinel, the licensing/cost condition, and the input dual-mode. Nothing an agent needs to invoke it correctly appears 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 coverage is 100% with rich examples, so the schema already carries the core meaning. The description nonetheless adds value by clarifying the two accepted input modes (plain English question vs. a fact_key drawn from pricing_list) and giving example phrasings, which is more than the schema alone conveys.

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 an official, dated personal-finance limit') and then enumerates the exact fact families it covers across FDIC/FSCS/CDIC, ISA/pension, 401k/IRA/HSA, TFSA/RRSP, super caps, and KiwiSaver. An agent can tell this is a catalog-lookup tool distinct from health_check or scheme_lookup 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?

Explicitly prescribes when to use it ('when a user asks "how much is protected" or "how much can I contribute"') and names an anti-pattern ('Use instead of memory'), plus routes fact_key sourcing to the pricing_list sibling. This is direct when-to-use guidance rather than inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds non-annotation context the agent cannot otherwise know: that the tool is 'Free (nothing on this server is billed)'. It does not describe result size or ordering, but with annotations carrying the safety burden this is solid added context.

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 dense sentence, front-loaded with the scope, followed by the entity types and the usage trigger. Every clause carries information; nothing is redundant padding.

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 has to describe the return contents itself — and it does, naming the two categories and the example-question field. Combined with the free/not-billed note and the coverage-check guidance, an agent has everything needed to call it correctly for a zero-parameter catalog 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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies a call with no arguments and spends its words on what the list contains instead of inventing parameter semantics.

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 a precisely bounded resource ('everything this server covers'), then enumerates the two entity types the list contains (money_fact keys with example questions, scheme_lookup countries). This directly distinguishes it from the sibling tools money_fact and scheme_lookup, which fetch the underlying data rather than the catalog.

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?

Gives an explicit trigger for calling it: 'call first if unsure whether a fact is covered' — a clear pre-flight/discovery condition relative to money_fact and scheme_lookup. It does not state any when-not-to-use case (e.g., skip it if you already know the key), so it stops just short of full routing 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 already declare readOnly/openWorld/idempotent, so the safety profile is covered. The description adds value beyond them by disclosing cost and authentication ('Free, no key') and previewing the response shape (regulator URL and as_of date).

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 tight sentences, front-loaded with purpose then accepted inputs and access constraints. No filler.

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

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

With no output schema, the description usefully names the returned fields (scheme, headline coverage, regulator URL, as_of date), which is what an agent needs to judge fit. The unused 'topic' parameter is never mentioned in prose, a minor omission given it is a single-value defaulted enum.

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 both parameters including examples and the enum default. The description only restates the accepted country code/name formats, adding no new syntax, normalization rules, or error behavior.

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 ('identify a country's deposit-insurance scheme') and enumerates the exact jurisdictions covered, so an agent knows precisely the domain. Sibling tools (health_check, money_fact, pricing_list) don't overlap, so no differentiation is needed.

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 narrow scope, and 'Free, no key' tells the agent no credentials are needed. However, there is no explicit when-to-use statement or routing to an alternative (e.g., money_fact for related financial facts).

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