OptimaYield free bank-treasury tools

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

Beyond the read-only and idempotent annotations, the description discloses that the tool is free, draws on FFIEC filings, and labels each output as filed, derived, or assumed. That provenance detail is meaningful behavioral context, though it does not cover output shape or performance characteristics.

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 dense sentences front-load the core decision and the outputs, with no redundant or filler wording. Every clause contributes information an agent would otherwise have to infer.

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 an eight-parameter financial model with no output schema, the description gives the agent enough to understand what the tool produces and how trustworthy each number is. It could say more about the defend/match/lead comparison or return structure, but the schema and annotations cover the remaining ground.

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 eight parameters thoroughly, including defaults, ranges, and units. The description adds no parameter-specific guidance beyond what the schema provides, which is the expected baseline.

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

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

The description states a specific verb and resource — pricing deposits by holding, matching, or beating the market rate — and names the concrete outputs (annual cost, balances at risk, breakeven retention, sensitivity). An agent can distinguish this from sibling tools like nim_rate_shock or margin_capture 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 description clearly frames the use case as a deposit pricing decision, which tells the agent when the tool applies. It does not explicitly exclude other uses or name sibling alternatives, but the context is unambiguous.

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 establish the safe-read profile (readOnlyHint, idempotentHint, openWorldHint=false), so the description's job is to add context, and it does: the data source (Call Report), the freshness contract ('latest', plus reporting period and source returned), and the guarantee that units are stated on every value. That unit guarantee is genuinely useful for an agent doing downstream arithmetic on ratios. It does not say what happens for an unknown certificate, so the behavioral picture is not complete.

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 sentence, front-loaded with what the tool returns, then the field inventory, then the provenance and units caveat. Nothing is redundant. The long field list is dense but each item earns its place by telling the agent what metrics are available without an output schema.

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

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

For a single-parameter read tool with no output schema, the description compensates well by listing returned fields, the reporting period, the source, and the units convention. Missing pieces are edge behavior on an invalid certificate and whether data can be stale or restated, which matter modestly here. Overall the agent has enough to call it correctly and interpret 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 parameter is documented with both its meaning (FDIC certificate number) and its provenance (from search_banks). The description adds no further meaning beyond that — no format hints, no notes on certificate reuse across charters or mergers. Baseline 3 applies when the schema carries this dimension.

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 resource (headline profile for one bank) and enumerates the exact contents: identity, total assets, deposits, loans, ROA, ROE, net interest margin, capital, liquidity and credit ratios. That makes it easy to distinguish from the sibling scenario tools (nim_rate_shock, maturity_wall_refinancing, etc.), which model hypotheticals rather than report raw Call Report figures. It stops short of explicitly naming those alternatives, so sibling differentiation is implied 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: the word 'headline' and 'latest Call Report data' suggest a quick single-bank snapshot, and the certificate parameter's schema note points back to search_banks as the lookup step. There is no explicit statement of when to prefer this over the scenario/analysis siblings, nor any exclusion such as limits on historical periods. An agent can infer the use case but receives no 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 establish readOnly, idempotent, and closed-world behavior, so the description wisely spends its words elsewhere: it discloses that the tool is free, sourced from FFIEC filings, and that every output number is labelled filed, derived, or assumed. That provenance disclosure is a genuinely useful behavioral trait; only the output shape and peer-selection mechanics remain unstated.

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 essentially no filler, and the core computation is front-loaded before the provenance caveat. The first sentence is densely packed (three computations in one clause), which costs a little immediate readability but not enough to warrant trimming.

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 7-parameter tool with full schema coverage and no output schema, the definition covers what is computed, the data source, and the trustworthiness labelling of results. What is missing is a sketch of the result payload (peer set, ratio headroom presentation), which would matter because no output schema exists.

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

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

Schema description coverage is 100% and the per-parameter descriptions are unusually rich (units, defaults, interpretation of zero, regulatory reference ratios). The description adds framing — allowance-ratio hold, after-tax capital hit, peers — but no parameter-level meaning beyond what the schema already carries, so the baseline 3 applies.

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

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

The description names a specific verb+resource: stress net charge-offs, computing the provision needed to hold the allowance ratio and the after-tax hit to CET1/leverage capital, with peer context. It is clearly a credit-loss stress tool, distinct from rate or liquidity siblings, though it never names an alternative 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?

Usage is implied by 'Stress a bank's net charge-offs' and by the scenario parameters, but there is no explicit when-to-use/when-not guidance or routing to alternatives such as nim_rate_shock for rate-driven questions. An agent must infer the context from the purpose sentence.

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 and idempotentHint, so the safety profile is covered. The description adds two pieces of context beyond that: the tool is free, and every returned figure is labeled as filed, derived, or assumed, which tells an agent how much to trust the numbers. It does not address latency or peer-band definition, so it falls 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?

The definition is a single front-loaded sentence with the primary action first and the provenance detail last. The semicolon-heavy packing of three ideas is slightly dense, but nothing is wasted or redundant.

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

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

With only two parameters at full schema coverage, no output schema, and annotations covering safety, the description needs little more. It covers the source of truth and the provenance labeling of results; only the peer-band definition and any coverage limits are left implicit.

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%, including the cycle enum explanation that both betas share one cycle for comparability, so the baseline is 3. The description contributes nothing additional about the certificate or cycle parameters beyond what the schema already documents.

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 a specific comparison (loan beta vs deposit beta) plus a secondary action (rank the spread against asset-band peers) and the data source (FFIEC filings). This is clearly distinguishable from siblings such as nim_rate_shock or deposit_pricing_decision, which address different analytical questions.

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

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

Usage is implied rather than stated: an agent can infer this is the beta-comparison tool, but the description names no alternatives and gives no condition for choosing it over nim_rate_shock or deposit_pricing_decision. There are also no stated prerequisites beyond the certificate.

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 cover the safety profile (read-only, idempotent, closed-world). The description adds genuinely useful behavioral context beyond them: the data is free, sourced from FFIEC filings, and every output number is labeled as filed, derived, or assumed. That provenance disclosure is exactly the kind of context an agent cannot get from annotations or 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 tight sentences with the core purpose front-loaded and provenance details second. The semicolon-chained second sentence is dense but every clause (free, FFIEC-sourced, filed/derived/assumed labeling) 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?

With four fully documented parameters and no output schema, the description should do more to characterize the result set. It says outputs are labeled by provenance but does not describe the scenario table the renewalRatePercent parameter references, leaving the return shape only partially understood.

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 parameter meaning is already well documented and the baseline is 3. The description's references to renewal assumptions, replacement funding, and tier-specific costs loosely map to the parameters but add no formats, units, or constraints beyond the schema.

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

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

The description names a specific analytical task: measuring time deposits maturing or repricing within a year and testing renewal/replacement assumptions against tier-specific costs. That is far more specific than the title alone. It does not, however, contrast itself with related siblings such as nim_rate_shock or margin_capture, so an agent must infer the boundary.

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 scenario language ('test explicit renewal and replacement assumptions'), which tells the agent this is a what-if refinancing tool. There is no explicit when-to-use versus when-not-to-use guidance and no named alternative among the sibling 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, idempotentHint, and openWorldHint=false, so safety is covered. The description does add genuinely useful behavioral context beyond them: it is free, sourced from FFIEC filings, and labels each output number as filed, derived, or assumed, which tells the agent how much to trust the result. It stops short of describing precision, latency, or failure modes for banks lacking filing history.

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 three compact clauses: what it computes, how it computes it, and how results are labeled. No filler, no repetition of the title, and the most decision-relevant information (the output and its provenance) comes first.

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

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

Five parameters with full schema descriptions and a clear read-only profile; the description covers the computation source, the cost, and the confidence labeling of outputs, which is what an agent needs to select and trust the tool. With no output schema, the extra note that results are tagged filed/derived/assumed fills the main remaining gap.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds a real interpretive layer: 'using its own filed pass-through history' explains what the derived loan/deposit betas are and therefore what the override parameters replace. It does not clarify the regime enum choices or the sign convention on fedMoveBp 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?

The description names a specific verb and output set ('Estimate how a Fed funds move changes a bank's loan yield, deposit cost, and net interest income') and the mechanism ('its own filed pass-through history'), so the resource is unambiguous. It does not name or contrast against close siblings like margin_capture or deposit_pricing_decision, so an agent must still infer the boundary.

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?

Use context is only implied by the purpose (rate-shock scenario on NII); there is no explicit statement of when to prefer this over margin_capture or loss_reserve_scenario, nor any exclusions. The only directional guidance ('Automatic is right for most uses') lives in the schema, not the description.

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, idempotentHint and openWorldHint=false, so safety is covered structurally. The description adds value beyond that by enumerating the return payload (certificate number, city, state, total assets) and the scope limit (US banks only), which the annotations don't convey. It says nothing about result ordering or what happens when the query matches many banks, which is the main remaining 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 tight sentences with zero filler: purpose and return fields first, then the workflow directive, then the optional filter. Every clause earns its place and the most decision-relevant content ("Use this first") is placed early.

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 carries the burden of describing results and does so explicitly. For a simple three-parameter read tool with full annotation coverage, nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the state code format and the note that a city name also matches. The description only restates the optional state narrowing, adding no syntax or semantics beyond the schema. Baseline 3 applies when the schema carries the parameter burden.

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 ("look up a US bank by name") and immediately names the key output ("FDIC certificate number"), which is what distinguishes it from the sibling analytics tools. It also gives concrete query examples ("Chase", "state street"), so an agent knows the input granularity 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?

"Use this first: every other tool needs the certificate" is explicit sequencing guidance that tells the agent to call this before deposit_pricing_decision, get_bank_profile, or any other sibling. It doesn't explicitly state when NOT to use it (e.g., to fetch full profile details, which is get_bank_profile's job), but the prerequisite framing covers the practical decision.

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