NCUA credit union data

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the date range, YTD reset behavior for income/expense fields, quarter-end balance semantics, ratio formatting, merger_event behavior, and the FTE caveat. These are exactly the kind of behavioral traits an agent needs beyond 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?

The description is dense but justified by nine undocumented parameters and several behavioral caveats. It is front-loaded with purpose and usage, though the single long paragraph could be easier to scan if structured into shorter sections.

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 complex nine-parameter query tool with no schema descriptions, the description covers most required context, including fields, aggregation options, grouping, and data quirks. It still leaves minor gaps around date parameter formatting and explicit routing versus some siblings, but the output schema handles return values.

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%, so the description must compensate, and it largely does: it defines cert, state format, size_band ranges, aggregate values and defaults, group_by behavior, and the full field list with definitions. However, start/end date format and min_assets units are not fully specified.

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 resource and scope: time series of one ratio or reported field for FDIC-insured banks over a defined date range. It also distinguishes the tool from its credit-union sibling by naming metric_series 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?

It clearly explains the two main modes: provide cert for one bank, otherwise aggregate matching banks with optional state, size_band, and min_assets filters. It also gives an alternative for credit unions, but does not explicitly contrast usage with bank_peer_compare or query_metrics.

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 and does well: it reveals the percentile-rank semantics, the direction convention ('for efficiency_ratio lower is better'), the unit system (fractions on YTD flows, annualized over average assets, re-basing each January), and the meaning of each peer_basis band. It omits any statement about permissions, rate limits, or behavior on an invalid cert/quarter, 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?

Information-dense and front-loaded: the return profile comes first, then identity, then peer_basis semantics, then units, then the sibling routing. It is a single heavy block, but each sentence carries distinct content and little is 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?

For a three-parameter read tool with no annotations and no output schema, the description covers the returned fields, the ranking convention, the unit interpretation, and the alternative tool. It does not cover failure modes or access requirements, but the essentials for a correct invocation are present.

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%, so the description fully compensates: cert is defined as the FDIC certificate number with a lookup tool suggested, quarter is described as defaulting to latest, and peer_basis is enumerated with its three values and the full definition of the five asset bands. Every parameter gains meaning that the bare schema does not provide.

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 concrete verb+resource+scope ('One bank against its peers in a quarter') and enumerates the exact outputs (value, peer median, quartiles, percentile rank) and the four metrics covered. It also distinguishes itself from sibling peer_compare by routing credit unions there, so an agent can tell it apart 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 names the alternative tool for a whole class of entity ('For credit unions use peer_compare') and gives the prerequisite path for the required identifier ('find_bank looks it up by name'). The default behaviors (quarter = latest, peer_basis = size_band) further tell the agent when it can omit parameters.

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 and does so well: it discloses the dual net-income computation, the disagreement flag (e.g., merger pushdown accounting), attached merger events, and explicit data-quality behavior (does_not_reconcile_to_qbp labeling in specific quarters, 'nothing is forced to balance'). It omits auth/rate-limit context, but the operational behaviors that matter for interpreting results are covered.

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 what the tool returns before moving to inputs and caveats, and almost every sentence carries usable information. The reconciliation-statistics sentences (106 of 136 checks, 8 quarters) are dense and borderline over-detailed, slightly blunting conciseness.

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 4-param, no-annotation, no-output-schema tool, the description covers purpose, inputs, return semantics, data caveats, and sibling routing. Remaining gaps—output field names and date/quarter string formats—are modest given no output schema exists to explain 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 0%, so the description must compensate; it explains cert as the FDIC cert number and clarifies the quarter-vs-start/end alternative with latest as default. It does not specify the string format for quarter/start/end (e.g., '2023-Q1'), which is a real gap for correct invocation, but it adds substantial meaning over the bare 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 resource and scope: single-quarter net income for one FDIC-insured bank, naming the exact metric (official quarterly net income plus a YTD difference flag). It also names the sibling it is not for ('For credit unions use cu_quarter_income'), so an agent can distinguish it without opening a 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?

Tells the agent exactly what inputs to supply ('Give the FDIC cert number and either one quarter (default latest) or a start-end range') and routes credit-union queries to cu_quarter_income. It does not spell out scope exclusions beyond that one alternative, but the use context is clear.

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 burden and does disclose useful behavior: quarter defaults to latest and null values are returned where NCUA data is absent. It does not state the read-only nature, auth requirements, or any rate/pagination behavior, so it adds some value but not a full behavioral picture.

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 that leads with what it returns and appends the null-handling caveat. Slightly dense in the 'every computed metric with its plain-language definition available through list_fields' clause, but no wasted sentences.

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 no annotations, the description does the work of describing the return contents (attributes, size, metrics with definitions) and null semantics. The main gap is the unexplained required cu_number, otherwise sufficient for a read-style profile fetch.

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%, so the description must compensate. It usefully clarifies the quarter parameter ('default latest'), explaining that omission yields the most recent quarter, but gives no meaning for the required cu_number beyond the implicit 'one credit union'.

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 resource and scope: a full profile (attributes, size, all computed metrics) for exactly one credit union and one quarter. This clearly separates it from siblings like metric_series or peer_compare, though it never explicitly names an alternative to route the agent away from.

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 comparison against alternatives such as query_metrics or peer_compare. The scope ('one credit union for one quarter') loosely implies its purpose, but the agent is left to infer when this tool is the right choice.

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 and does so unusually well: it discloses the derivation method (consecutive YTD 5300 reports, Q1 = reported YTD), the continuity_status taxonomy, and that unverified_no_adjacent_prior rows return null values with a reason. It does not cover auth/permission requirements or date-string input formats, keeping 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?

Dense but every sentence contributes: payload fields, date span, argument pattern, derivation, and the continuity_status semantics. Front-loads purpose before the caveats, though the prose is long and could be tightened into list form.

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, and the description picks up that burden by naming the returned measures and the continuity_status columns plus their meaning (verified / event_contaminated / unverified_no_adjacent_prior). Missing only input date formats and the exact shape of event metadata fields.

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% and all four parameters are bare titles, so the description must compensate. It does define the roles of cu_number, quarter (with default latest) and start/end (mutually exclusive with quarter), but gives no format guidance for quarter/start/end strings, so an agent can still guess wrong.

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: single-quarter income for one credit union, with the exact fields returned (net income, interest/noninterest income and expense) and the date span (2018-03 to latest). It explicitly distinguishes itself from siblings by contrasting with bank_quarter_income (credit union vs bank) and by stating 'no rankings or trailing totals here' (i.e. not peer_compare/metric_series).

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?

States the selection rule concretely: give cu_number plus either one quarter (default latest) or a start-end range, and one credit union per call. It also routes the agent to the sibling needed for prerequisites ('Use find_credit_union to look up a cu_number') and rules out aggregation use cases, leaving nothing to 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?

With no annotations, the description carries the full disclosure burden and does so: it documents case/punctuation-insensitive matching with stopword dropping, ranking order, the 'ambiguous' flag and required user clarification, the historical fallback with match = former_or_closed, the single 'no_match' row, and the quarter coverage range. This is far beyond what the schema conveys.

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-loaded with the core purpose, then layers matching semantics, ranking, fallback behavior and downstream routing in a single dense narrative. Every sentence earns its place, though the length approaches the point where structure (e.g. short bullet-like clauses) would aid scanning.

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?

Given an output schema exists, return-field enumeration is redundant but harmless; the description nonetheless covers every edge case an agent must anticipate — ambiguous matches, historical fallback, and the no-match sentinel. Nothing needed to call and interpret this tool 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 0%, so the description must compensate. It explains name matching mechanics, quarter defaulting to latest, and how city/state disambiguate results, but 'limit' (default 15) is never mentioned and the accepted quarter string format is left implicit. Partial compensation merits the 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 specific verb and resource ('Find FDIC-insured banks') plus the scoping facets (name, state or city, quarter) and the data domain (domestic FDIC-insured filers, 2018-03 to 2026-06). An agent can distinguish it from find_credit_union purely from the text.

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 concrete routing guidance: use the returned cert in bank_quarter_income, bank_metric_series and bank_peer_compare, and instructs the agent to ask the user when 'ambiguous' is true rather than picking the first row. It stops short of an explicit when-to-use-this-vs-find_credit_union contrast, so it is a strong 4 rather than a 5.

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 and does so well: it discloses matching normalization (case/punctuation/'FCU' stripping), former-name and brand-name matching with a match=former_name signal, ranking order, the 'ambiguous' flag, the synthetic 'no_match' row explaining mergers/closures, and the federally-insured-only scope. It omits any statement of read-only/auth/rate-limit behavior, but those are minor for a read-style lookup.

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 purpose and filter set are front-loaded, and the dense sentence on match ranking, ambiguity, and no_match all earn their place for an agent that must interpret results. The list of example brand names and the explicit return-field enumeration are mildly redundant given the output schema, so it is a touch longer than strictly necessary.

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 search tool with an output schema, the description supplies everything an agent needs to call it and interpret results: filters, defaulting behavior, ranking, the ambiguity escalation rule, and the no_match outcome. Re-stating that it returns cu_number, name, location, assets and members is slight redundancy with the output schema but not a completeness 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 0%, so the description must compensate and largely does: it defines the semantics of name (with fuzzy matching rules), state, charter_type (federal/state), peer_group (asset peer group), and quarter (defaults to latest). The only undocumented parameter is 'limit', whose meaning and default the agent must infer, leaving one gap in otherwise strong compensation.

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 (find) and resource (credit unions) plus the exact filter dimensions (name, state, charter type, asset peer group, quarter), and distinguishes itself from siblings by instructing the agent to 'Use the returned cu_number in the other tools.' An agent can tell this is the lookup/entry-point tool versus credit_union_profile or peer_compare without opening any 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?

Clearly implies when to reach for it (locating a credit union by name/state/charter/peer group) and gives an explicit branch rule: when 'ambiguous' is true, ask the user which one they mean using city/state rather than guessing. It routes downstream by name ('the other tools') but never names credit_union_profile or any sibling explicitly, so the when-not/alternative mapping is slightly weaker than ideal.

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 does disclose what the dictionary contains (field names, source, units, employee definitions), which is useful context about the payload. But it never states that this is a safe read-only lookup, whether results are cached or paginated, or anything about the expected size of the dictionary.

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 filler, and the primary purpose leads. The second sentence is a deliberate disambiguation note rather than padding. Slightly terse given the undocumented search parameter, but structurally clean.

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?

An output schema exists, so return values need no explanation in prose. For a simple single-parameter lookup tool this is close to adequate, but the undocumented 'search' parameter and the absence of any when-to-use guidance leave real 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?

There is one optional parameter, 'search', with 0% schema description coverage, and the description never mentions it or explains its matching behavior (substring? fuzzy? case sensitivity?). With a single undocumented filter parameter, the description should have compensated and does not.

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 the resource (bank fields) and enumerates the dictionary's contents — source, units, employee definitions — so an agent knows this returns field metadata rather than data. It also explicitly contrasts itself with the NCUA list_fields sibling, which sharpens the distinction. The verb ('list') is only implied, but the intent is unambiguous.

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 sentence 'Bank fields are separate from the NCUA list_fields dictionary' implicitly routes the agent to the right tool depending on whether the data is bank or credit-union based, which is genuine routing value. However, it never states when to call this tool, whether it requires prior calls (e.g. before bank_metric_series), or any prerequisites.

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 behavioral burden. It adds real domain context (fields marked basis=year_to_date reset each January; metric_series can de-cumulate them), which is useful. But it says nothing about read-only status, result limits/pagination, or permissions that a metadata tool should disclose, and the bulk of the text is domain content rather than tool 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?

It is front-loaded well, but the body is an enormous enumeration of roughly seventy computed metrics, many truncated with ellipses, which dwarfs the actionable guidance and makes the definition hard to scan. Much of this belongs in an output schema or reference resource rather than the description.

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?

An output schema exists, so return values need not be explained, and the description supplies the relevant domain context an agent needs to interpret fields and filters. It is largely complete for a discovery tool, missing only pagination/limit behavior and an explicit read-only statement.

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%, so the description must carry parameter meaning, and it does for two of three: 'table' receives concrete allowed values with interpretation ('metrics' = computed ratios, 'fact_call_report_curated' = reported amounts, 'dim_credit_union' = attributes) and 'search' is described as search text. The 'limit' parameter is never explained, keeping it short of a 5.

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 opening sentence gives a specific verb and resource ('List available fields with plain-language definitions from the data dictionary'), and the table filter values clarify the scope of what can be listed. It partially differentiates from siblings by pointing at metric_series, but does not clearly separate itself from query_metrics or metric_series as the discovery step.

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 explains how to filter (by table, by search text, or both) and hints at a downstream relationship ('metric_series can de-cumulate them'), which implies usage. However, it never states when an agent should call list_fields versus query_metrics or metric_series directly, so usage is left to 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?

With no annotations, the description carries the full burden and does so well: it discloses the data range (2018-03 to latest quarter), the default aggregate per field type, the restriction that sum is disallowed on ratios, the pooled availability list, the CECL break_note, and that rows with no data explain why. Auth, rate limits, and pagination remain undisclosed, keeping 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?

The prose is a single dense wall with a very long run-on metric catalog (dozens of metrics separated by semicolons, some truncated mid-word such as "IRA a…"), and it duplicates cataloging that the sibling list_fields already performs. Key behaviors like the default-aggregate rule are buried mid-paragraph rather than front-loaded, hurting scanability.

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 12-parameter aggregation tool with an output schema (so return values need not be described), the description is nearly complete: modes, filters, aggregation semantics, quarterly handling, and metric definitions are all present. The unexplained year_end_only parameter is the only notable 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 0%, so the description must compensate across 12 parameters, and it largely does: cu_number, state (2-letter code), peer_group (1-6), min_assets, the full aggregate enum with defaults, group_by, quarterly semantics, start/end quarter format, and denominator via the ratio_of_sums example are all explained. The only uncovered parameter is year_end_only, which is never mentioned.

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 opening sentence gives a specific verb and resource ("Time series of one metric or reported field") and immediately splits the two operating modes: single CU via cu_number versus aggregation across federally insured credit unions. This is clear enough to distinguish from peers, though it never names query_metrics or peer_compare, which an agent must infer.

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 effectively states the conditions that select behavior: give cu_number for one credit union, otherwise it aggregates with optional state/peer_group/min_assets filters, and group_by returns one row per group. However, it offers no explicit when-to-use-this-versus-alternatives routing against siblings like query_metrics or peer_compare, so usage is implied rather than guided.

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 behavioral burden. It usefully discloses the return structure (median, 25th/75th percentiles, percentile rank, peer count) and the default quarter/metrics. However, it says nothing about permissions, error behavior for unknown metric names, or limits on the metrics array.

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 first sentence is well front-loaded, but the remainder is a single massive run-on parenthetical enumerating dozens of metrics, several of which are visibly truncated mid-word ('...IRA a…', '...last four quarter-e…', '...over year-end loans;'). Much of that enumeration is schema-like content and the truncation signals poor curation.

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 4-parameter, no-annotation, no-output-schema tool, the description is fairly complete: it covers the comparison output, the peer_basis options, defaults, and metric semantics. It still omits error handling and the meaning/format of cu_number and quarter, but the core call requirements are covered.

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 0%, so the description must compensate, and it largely does: peer_basis is enumerated with its four allowed values and the default, and the metric list supplies the full catalog of valid metric names with definitions (effectively acting as an enum). It leaves cu_number and the quarter string format unexplained, so it is not a 5.

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 opening sentence states a specific verb and resource: compare one credit union against its peers on chosen metrics. It also describes the return payload (value, peer median, percentiles, rank, peer count). It does not explicitly distinguish itself from siblings like metric_series or query_metrics, so it falls 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?

Usage is implied by the comparison framing and by defaults ('default: a standard set', 'default latest'), but there is no explicit when-to-use or when-not-to-use guidance relative to metric_series, query_metrics, or credit_union_profile. The agent must infer that peer benchmarking is the differentiator.

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 and does a good job: it discloses that ordering silently excludes sub-$10M credit unions unless min_assets=0, that affected rows carry assets_floor_applied, that over-limit results end in a truncated row with total_matching and next_offset, and that ratios are fractions. It omits auth/permission and rate-limit 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?

The operational guidance is front-loaded well, but roughly 80% of the text is a metric glossary that duplicates what the sibling list_fields returns, since the description itself states field names come from list_fields. Truncation behavior is also explained twice in slightly different wording, adding redundancy.

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 9-parameter analytical query tool with an output schema (so return shape need not be described), the description covers granularity, filtering syntax, ordering side effects, pagination, and field sourcing. Only the two boolean flags and permission requirements are left 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 0%, so the description must compensate and largely does: it defines filters structurally with the full op enum, limit bounds (1-200), offset paging, quarter granularity, min_assets semantics, and where field names originate. It never explains the descending or quarterly boolean parameters, which is the remaining 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?

States a specific verb and resource with scope: a constrained table query over federally insured credit unions, one quarter at a time, no raw SQL. It partially routes to the sibling list_fields for field names, but never distinguishes itself from metric_series or peer_compare, so an agent cannot fully separate the four query-family tools from this text 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?

Usage context is implied rather than stated: quarter defaults to latest, filters use a documented operator set, order_by changes the asset-exclusion default, and min_assets reverses it. There is no explicit when-to-use-this-vs-metric_series-or-peer_compare guidance and no prerequisite or permission notes.

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 and does so well: it discloses that values are annualized YTD run rates rather than actual full-year revenue, that state filters by headquarters, that banks and CUs use non-identical FTE definitions, that invalid denominators and perimeter breaks are excluded from ranks but counted, and that cert/cu_number keeps the full peer rank. Remaining gaps are pagination and output/auth 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?

It is dense and front-loads the metric and ranking scope, but the body is a choppy sequence of clause fragments rather than organized sentences, making it harder to scan for a specific fact. Little is wasted, but the structure could be tightened into grouped points.

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 9-parameter, annotation-free tool with no output schema, the definition covers the metric, ranking, and caveats competently but omits pagination semantics, result shape, and half the parameters. An agent can call it, but not confidently for paging or quarter/min_assets filtering.

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% across 9 parameters, so the description must compensate. It usefully documents sector values ('both'/'bank'/'credit_union'), revenue_basis ('net' default vs 'gross'), the state=HQ semantics, and the cert/cu_number selection behavior, but leaves limit, offset, quarter, and min_assets entirely unexplained, so it only partially covers the surface.

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 exact metric (revenue per employee/FTE) and the operation (same-quarter state ranking across banks and/or credit unions), which is specific enough to separate it from siblings like bank_metric_series or peer_compare. It stops short of explicitly naming an alternative tool or contrasting scope, so it is clear but not fully 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?

Usage is implied rather than stated: the definitional detail tells an agent this is the tool for the per-employee efficiency metric, and 'No raw SQL' signals a canned query. There is no explicit when-to-use/when-not guidance and no sibling tool named as the alternative for adjacent needs.

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