Wounded Warriors

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that results are estimates (not authoritative determinations), but says nothing about precision, data vintage, or whether figures are annual/monthly — modest added context over the 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?

A single 16-word sentence that front-loads the verb and both calculation modes; every clause carries weight and nothing is padded.

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 must carry more of the return-value burden, yet it never indicates what an estimate looks like (amount only, breakdown, disclaimers). Combined with the implicit-only usage guidance, it is adequate but leaves an agent guessing about 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 description coverage is 100% and the schema already documents 'type' enum, rating range, and serviceYears. The description only re-summarizes which inputs feed which mode, adding no syntax or format detail beyond the schema; 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?

States a specific verb ('Estimate') and resource ('VA disability compensation or GI Bill education benefits') with the driving inputs, so an agent can distinguish it from lookup-style siblings like get_disability_rates or check_eligibility. It does not explicitly name those siblings, which keeps it 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 only implied: the two enrolled benefit types suggest when each mode applies, and the 'rating/service years' phrasing hints at required inputs, but there is no explicit when-to-use or when-to-prefer-an-alternative statement relative to siblings such as check_eligibility or get_disability_rates.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds useful scope context (which program families are evaluated and that multiple checks are combined), but says nothing about permissions, data recency, confidence, or limitations of the matches returned.

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: the first sentence names inputs then outputs, and the second sentence adds the one-call aggregation benefit. Efficient overall, though the enumerated input list duplicates the schema and the program-family list makes the first sentence dense.

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 11-parameter, zero-required tool with no output schema, the description partially compensates by describing the categories of programs returned. But it does not explain behavior when optional inputs are omitted (e.g. is a bare call valid?), nor how matches are ranked or whether results are exhaustive, leaving a real gap for an all-optional-parameter 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?

Schema description coverage is 100%, so all 11 parameters (including eras, discharge characters, and income purpose) are already documented in the schema. The description's parenthetical input list (era, branch, discharge, conditions, state, household income, dependents, current rating, homeless status) restates those fields without adding format, range, or interaction detail beyond what the schema provides. Baseline 3 is correct.

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 (returns matched programs) and resource (benefits eligibility) plus the exact program families evaluated: PACT/Agent Orange/Camp Lejeune/Gulf War presumptives, GI Bill chapters, VA Pension, HUD-VASH/SSVF, VA Healthcare priority group. This breadth distinguishes it from narrower siblings like match_pact_presumptive or calculate_va_benefits.

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?

'Combines several eligibility checks in one call' implies the tool is for broad eligibility sweeps rather than single-program lookups, which is implied usage guidance. However, it never explicitly says when to prefer this over siblings such as match_pact_presumptive or calculate_va_benefits, and no exclusions or prerequisites are given.

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, openWorldHint=false, and destructiveHint=false, so safety is well covered. The description adds return-value context ('Returns category, plain-English definition, and related terms') that is not in any output schema, which is helpful. It does not describe error behavior when a term is unknown, so it stops short of maximum transparency.

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 tightly structured sentences: purpose, coverage/return values, and when to use. It is front-loaded with the core function and the term list, while long, is directly useful for retrieval and recognition.

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 simple, read-only, single-parameter glossary tool with rich annotations but no output schema, the description is complete. It states what the tool does, its scope, what it returns, and when to use it, leaving no critical gap for an agent to call it correctly.

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% for the single 'term' parameter, so the baseline is 3. The description goes beyond the schema by specifying that terms can be acronyms or phrases and by listing many concrete examples (DD-214, C&P exam, MOS, PACT Act, etc.), adding useful matching context. It does not explain matching rules like case sensitivity or partial matches.

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 and resource ('Translate veteran/military jargon to plain English'), which is clearly distinct from siblings like lookup_va_form or search_veteran_resources. However, it does not explicitly differentiate itself from any sibling by name or state what it is not, so it falls short of the top score.

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 provides a clear when-to-use statement: 'Use when someone asks about an unfamiliar military or VA acronym or phrase.' There are no explicit exclusions or named alternatives (e.g., when to use route_query or a broader search instead), so it is not 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?

Annotations already declare readOnly, idempotent, non-destructive and non-openWorld, so the safety profile is covered. The description adds meaningful behavioral context by specifying what is returned (payee, mailing address, EIN, action URLs, matching-gift platforms), which is important since there is no output 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 sentences, front-loaded with the purpose and EIN before the method list and return payload. The enumeration is dense but each item corresponds to a real method or return field, so little is wasted.

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 correctly takes on the burden of stating return fields, and it does so. The method enum is fully documented in the schema, so nothing essential is missing for a read-only lookup 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?

Schema coverage is 100%, so the schema already documents the single method parameter and its enum, establishing the baseline of 3. The description does expand the enum values ('corporate matching' for corporate_match, 'planned giving' for bequest), adding modest meaning but not going beyond restating the options.

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 precise resource (official giving instructions for Wounded Warriors, identified by EIN) and enumerates the giving methods covered, so the agent knows exactly what it retrieves. It stops short of distinguishing itself from siblings like get_donate_options or get_legacy_giving, which clearly overlap.

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, and no mention of alternatives. With visibly overlapping siblings such as get_donate_options and get_legacy_giving (planned giving/bequest), the description leaves the agent to guess which tool to call.

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=true, idempotent=true, non-destructive, closed-world, so safety is covered. The description adds real behavioral value by disclosing the response contract (funded items, tax note, giving link) and the required input pairing (amount + cadence), which annotations do not convey.

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 sentences, front-loaded with inputs then outputs, with no filler. The parenthetical example list is slightly long but earns its place by concretizing the otherwise abstract notion of 'what a gift funds'.

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 only 2 params, the description adequately compensates by enumerating the returned fields and the use trigger. Minor gap: it doesn't clarify how cadence affects the impact estimate or the giving link, which an agent invoking monthly vs once might want to know.

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 50%: amount is documented in the schema, but cadence (enum + default) has no description. The description restates 'cadence (once|monthly)' which the schema already declares via enum, so it adds little semantic meaning beyond confirming the accepted values.

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 (estimate) plus the resource (donor impact / what a gift funds) and enumerates the concrete return payload: funded items, tax-deductibility note, and a pre-filled giving link. An agent can distinguish this from calculate_va_benefits or match_donor_intent 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?

Explicitly routes usage: 'Use when a donor asks what a gift funds.' This gives a clear positive trigger, but it names no alternatives (e.g. get_donate_options, match_donor_intent) or exclusions, so the agent must infer which sibling handles adjacent donation queries.

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/non-destructive, so the bar is low, and the description adds real value on top: it discloses provenance (OGC roster) and a legal constraint (only these people may charge for representation). It does not describe result ordering or pagination, keeping it from 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 tight sentences, front-loaded with the identity of the resource, then source, then usage trigger. Every sentence carries distinct information and nothing is padded.

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 read-only lookup with three simple params and no output schema, the agent has what it needs: what the tool returns, where the data comes from, and when to reach for it. Only the return shape/ranking behavior is unstated, 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?

Schema coverage is 67%, and the description adds nothing about parameters — the 'appeal, CAVC' phrasing gestures at case complexity but never explains type choice or the state requirement. With most parameters self-documented in the schema, this is the baseline case where the schema does the heavy lifting.

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 a precise resource (VA-accredited attorney, claim agent, or VSO representative), plus the authoritative source (VA Office of General Counsel roster). An agent can distinguish this from find_cvso or search_veteran_resources 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?

Gives explicit routing context: use for complex cases (appeal, CAVC, higher-level review) that exceed CVSO capability, which implicitly separates it from the sibling find_cvso. It stops short of naming find_cvso outright as the alternative for simpler cases, which would earn 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one useful behavioral caveat — 'Not every county has its own office' — which sets expectations for empty results. It says nothing about auth needs, result shape, or distance ranking behavior, so the added context is modest.

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 the entity definition, then the coverage caveat, then the when-to-use condition — a sensible order that reads cleanly. Each sentence carries distinct information, though the parenthetical about state/regional officers is slightly more detail than the agent needs to select the 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?

For a simple, read-only, 3-parameter lookup with full schema coverage and no output schema, the description covers purpose, usage trigger, and the empty-result caveat. Nothing critical for correct invocation is missing, though more explicit routing against sibling finders would round it out.

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 (zip, state, county) are already documented in the schema, including the optional/distance-ranked semantics of zip. The description adds no parameter-level guidance beyond that, so the baseline 3 is appropriate.

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 a County Veterans Service Officer') and goes further by defining what a CVSO actually is (free claims helpers, usually county employees, state/regional in some states). This makes the entity legible without opening the schema. It doesn't explicitly contrast itself with the sibling find_accredited_representative, which is the obvious near-neighbor, so it stops short of 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?

Gives an explicit triggering condition: 'Use this when a veteran needs help filing a VA claim but does not want to pay a private attorney.' That is a clear when-to-use signal. It does not name an alternative tool for the adjacent case (e.g., find_accredited_representative), so it lacks the when-not/alternative routing that would earn 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?

Annotations already establish the safe read-only, idempotent, closed-world profile, and the description adds meaningful context: exactly 30 catalog funders, sourcing limited to public ProPublica 990s and foundation websites, and an explicit privacy rule that no personal officer emails are returned. The main gap is that it never states whether results are pageable or truncated beyond the limit parameter.

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 response shape and data scope are front-loaded in the first two sentences, with usage and provenance following. It is dense but every clause (sources, privacy rule, use cases) carries information, with only minor redundancy between the catalog listing and the per-entry field list.

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 available, the description does the necessary work by enumerating the returned fields (EIN, type, public application URL, public contact email, 990-derived grant range, matched /grants pages). That covers an agent's needs well, leaving only pagination/result-count behavior and the unexplained 'grant size' matching unspecified.

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 four parameters are already documented, including the 'all' enum semantics and the HRT sponsorship caveat. The description's phrase 'matching a given focus area + grant size' is not backed by any grant-size parameter in the schema, adding mild confusion rather than new parameter meaning.

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 gives a specific verb and resource ('Returns researched veteran-aid foundation prospects') scoped to focus area and grant size, and the second enumerates the catalog contents. It is clearly distinct from read-only resource lookups, though it never names the adjacent siblings (match_grant_intent, match_donor_intent) it could be confused with.

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?

Two explicit use cases are given: a Wounded Warriors team member identifying outreach prospects, or a foundation officer wanting peer comparisons. That is solid when-to-use guidance, but there are no when-not conditions and no explicit routing against sibling tools such as match_grant_intent.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds real value by disclosing the data sources (ACS rent-burden joined with veteran counts) and the returned payload structure (FIPS codes, veteran density, resource counts). It omits any note on ranking/tie-break behavior or rate/auth considerations.

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 sentences, front-loaded with the core purpose (finding tracts), then data provenance, then the use cases. Slightly dense in the middle sentence but no filler or repetition.

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 documents the shape of returned results and the join behind the ranking, which is what an agent needs to decide and interpret. It leaves the limit/pagination semantics and ranking tie-breaks unaddressed for a 4-parameter query 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?

Schema description coverage is 75%, so the schema already documents state, measure, and min_veterans. The description restates the burden/severe 30%/50% threshold distinction, which duplicates the enum description rather than adding new meaning, and says nothing about limit or its max of 100. Baseline 3 is appropriate.

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 (find census tracts) and a specific scope (veterans facing high housing costs), plus the underlying data join (ACS rent-burden data with veteran counts). It clearly differentiates from siblings like get_tract_demographics and get_housing_context by naming the rent-burden ranking and veteran focus.

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 gives concrete when-to-use contexts: housing-aid planning, HUD-VASH/SSVF outreach, and grant proposals citing tract-level rent burden. However, it names no alternative sibling tool or any exclusion condition (e.g., when to prefer get_housing_context or get_tract_demographics instead).

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/idempotent/non-destructive/closed-world, so the safety bar is low. The description goes beyond that by disclosing the join logic (resource directory × ACS 2020–2024 5-year tract demographics) and the dataset backing (84,365 tracts, 50 states + DC + PR), which tells the agent about scope and freshness.

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 sentences, front-loaded with the purpose and then the mechanics and data provenance. The final coverage sentence borders on marketing but usefully signals geographic scope; overall it is tight, though it could be marginally leaner.

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 steps in to describe the key return fields (gap_score, poverty %, median income, FIPS codes), so an agent knows what comes back. For a read-only query tool over 4 optional params, this is essentially complete, missing only pagination/ordering behavior.

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 75%, with state, min_veterans, and max_resources already documented in the schema; only limit lacks a description. The description explains the gap concept (few or no resources) that underpins min_veterans/max_resources but does not add syntax or interpretation beyond the schema, so the baseline 3 is appropriate.

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 (census tracts where veterans live but few resources serve them), and defines the 'service desert' concept precisely. An agent can distinguish it from siblings like get_tract_demographics (raw demographics) and find_high_housing_burden_tracts (a different gap metric) 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?

Frames the use case clearly — 'highest-impact targets for outreach, partnership development, and grant proposals' — telling the agent what downstream task this serves. However, it never names when NOT to use it or which sibling to prefer for a related question, so the alternative-routing guidance is absent.

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, non-destructive, and closed-world, so the safety profile is covered. The description usefully adds the ranking criterion (completeness score) and the category taxonomy, but says nothing about result volume, pagination, or how ties/empties are handled.

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 tight sentences with the core scope front-loaded and the category list and use case following efficiently. Minor waste in the '{state}' placeholder style, which the required state parameter already conveys.

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 read-only 3-parameter list tool with no output schema, the description covers what is returned (top items per category, 9 categories) and the ranking basis, which is enough to call it correctly. Missing only limit semantics and result-size expectations.

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 67%: state and type are documented in the schema itself, and the description's note that a type filter returns 'top 20-50' merely restates the schema. The limit parameter is undocumented in both places, so the description does not fully compensate for the 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 operation—top resources per category in a state, ranked by completeness score—and enumerates the 9 categories, which separates it from generic siblings like search_veteran_resources. However, the header claim of 'Top 5' sits uneasily against the schema's limit default of 10, leaving the actual count ambiguous.

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 frames the use case: 'recommend the highest-quality starting points for a veteran in {state}.' It gives clear context for when to reach for this tool but never names an alternative (e.g., search_veteran_resources) or states when not to use it.

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, destructiveHint, and openWorldHint, so the safety profile is covered. The description adds useful context beyond annotations: it identifies the data source (live Census ACS, 118th Congress) and describes the fallback mode when cd is omitted. It does not mention rate limits or staleness of ACS data, but the added source and scoping context is solid.

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 and data fields, then use cases, then the fallback behavior. Slightly list-heavy in the data-field enumeration, but every sentence earns its place and there is 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?

Covers purpose, data returned, use cases, and the cd-omission fallback, which is what an agent needs for a two-parameter read-only tool. No output schema exists, so the description appropriately enumerates return fields. It could note data-freshness expectations for live Census data, but overall it is complete for the tool's complexity.

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%: both cd and state are fully documented in the schema, including the 1- or 2-digit format for cd and the 2-letter state code. The description restates the cd omission behavior but adds no new format, validation, or semantic detail beyond the schema. Baseline 3 is appropriate.

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, and scope: returns veteran demographics for a congressional district using live Census ACS data, and explicitly lists the data fields produced. This distinguishes it from siblings like get_tract_demographics and get_state_dashboard by naming the congressional-district unit and the veteran-specific metrics.

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 when to use (congressional staff fact-sheets, foundation grant proposals, local journalism, advocacy targeting) and gives a concrete fallback behavior when cd is omitted ('returns ALL districts in the state ranked by veteran count'). The alternative behavior is spelled out rather than 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, so safety is covered. The description adds useful behavioral context by enumerating the returned hotline set and noting the ordering of the Veterans Crisis Line first.

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 front-loaded with the resource identity but then spends most of its length enumerating hotline names. The critical 'Use when someone is in crisis' guidance is buried near the end, and the list of specific hotlines may be more verbose than necessary for tool selection.

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 identifies the returned hotline directory and filtering options. It is complete enough for a simple, annotation-covered read tool, though it could clarify behavior when no filters are supplied.

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 both optional parameters are already documented in the schema. The description repeats the audience and language filters but omits several enum values (transgender, youth_25_and_under, service_provider), adding little beyond the structured 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 clearly identifies the resource (crisis hotline directory) and scopes it as 'beyond 988,' then lists the returned hotlines. It is specific but does not distinguish itself from the sibling veteran_crisis_resources, so it stops 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?

It gives a clear usage trigger ('Use when someone is in crisis'), which is better than implied guidance. However, it offers no when-not guidance and does not mention the overlapping sibling veteran_crisis_resources, leaving the agent to infer which crisis tool to call.

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 (readOnly, idempotent, non-destructive, not open-world), lowering the bar. The description goes beyond them by disclosing the dataset vintage (2025 published + 2026 COLA est) and the shape of the returned content (base amount, dependent modifiers, annual amount, IU/TDIU/SMC/P&T explanations), which matters since no output schema exists.

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 sentences, front-loaded with what it is before when to use it. Every clause carries information: scope, vintages, return contents, and trigger queries, with 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 carries the return-value burden and does so (amounts, modifiers, explanations). Parameters are fully schema-documented and annotations cover safety, so nothing an agent needs to call this 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 the baseline is 3 and the schema already documents both parameters. The description adds mild context by expanding on dependent modifiers, but it doesn't explain parameter interactions and even references 'parents' modifiers that the dependents enum does not include as a selection.

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 ('VA disability compensation monthly rate tables') with explicit scope (ratings 10-100% × dependent configurations) and two data vintages. An agent immediately knows this is a lookup-the-rate-table tool. It does not, however, explicitly distinguish itself from the sibling calculate_va_benefits, so it stops 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?

Gives concrete triggering queries ('how much is X% rated worth?', 'what does adding a dependent change?'), which is strong usage context. It stops short of naming an alternative or a when-not-to-use condition, so it is clear context without exclusions.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description correctly doesn't repeat it. It does add value beyond annotations by disclosing the shape of the payload — a single response containing all 12 channels, each with action URL, instructions, and tax treatment — which matters because no output schema exists.

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 tight sentences: scope first, then the enumerated channels, then the per-channel payload. No filler, no restatement of the title, and everything an agent needs 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?

With zero parameters, no output schema, and full annotation coverage, the description is nearly self-sufficient — it even compensates for the missing output schema by listing the per-channel fields. The remaining hole is routing relative to the overlapping donation siblings, which is the one thing an agent could still get wrong.

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 confirms the no-argument design by promising every channel 'in one response', and the embedded EIN (86-1336741) gives useful identifying context even though there is no input to document.

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 and enumerates exactly what comes back — all 12 giving channels, with EIN for disambiguation. The only gap is that it never addresses the near-identical sibling donation_instructions_wounded_warriors, so an agent can't tell from the description alone which of the two to pick.

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, when-not-to-use, or alternative routing. 'In one response' hints that this is the aggregate/broad option versus narrower siblings like get_legacy_giving or donation_instructions_wounded_warriors, but the agent is left to infer that, and no prerequisites or exclusion conditions are given.

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, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that results are family-scoped and flags that Vet Center family counseling is free, but says nothing about result count, formatting, or whether the filter is exclusive.

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 fragments with the core purpose front-loaded and the program list doing useful enumeration rather than padding. Acronyms (PCAFC, DEA, MyCAA) are domain jargon but each is paired with a plain-language cue, so little is wasted.

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, no-output-schema lookup tool whose annotations already carry the safety profile, the description provides enough to call it correctly. Only the filter's behavior when omitted (all categories vs. a default subset) is left unstated.

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 the baseline is 3, but the description goes further by mapping program names to filter categories (PCAFC caregiver stipend -> caregiver_support, MyCAA -> spouse_education, DEA/Yellow Ribbon -> children_education, TRICARE -> tricare), helping an agent choose the right enum value.

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 domain (resources for the LIVING family of a veteran) and enumerates the concrete programs covered, which separates it from the survivor-oriented sibling get_survivor_benefits. It lacks an explicit verb, but the caps-locked 'LIVING' does real discriminating work against survivor benefits.

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 enumeration of family programs, so an agent can infer this is the tool for spouse/child/caregiver queries. However, no explicit when-to-use guidance or alternative (e.g. get_survivor_benefits for deceased-veteran families) is named, leaving the boundary 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?

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful return-content detail (Schema.org Event markup, quotable lines, days-until calculation) that compensates for the absence of an output 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 compact sentences, front-loading the resource definition and then the returned artifacts. No filler, though the parenthetical event list is long.

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 summarizes the response shape (Event markup, quotable lines, days-until). Combined with annotations covering the safety profile, the definition gives an agent enough to invoke it correctly, though it lacks sibling routing guidance.

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 single 'upcoming' parameter is fully documented in the schema. The description adds no additional syntax or filtering semantics beyond what the schema provides, 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?

States a specific resource (calendar of veteran-relevant giving events) and enumerates concrete instances (Veterans Day, GivingTuesday, year-end, etc.), making the purpose immediately clear. It does not explicitly contrast itself with giving-adjacent siblings like get_legacy_giving or get_donate_options, so it falls short of the top tier.

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 use this tool versus alternatives, and no prerequisites or exclusions are stated. The agent must infer usage purely from the tool name and the enumerated event list.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds valuable context beyond them — the ACS 2020–2024 5-year vintage, the HUD 30%/50% cost-burden standard and which programs rely on it, and the dual input modes. It does not discuss latency, caching, or behavior when a tract has no data, which would be the remaining behavioral 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?

Front-loads the metric inventory, then the domain rationale, then the input modes — a sensible order with no filler sentences. It is a dense single paragraph, and the metric list is long, but each clause maps to real return content the agent needs since there is no 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?

With no output schema, the description correctly compensates by naming the metrics returned. All four parameters are optional (required: 0), yet the description never states which combination is actually needed to resolve a tract — an agent could plausibly call it with no arguments. That is the one material gap in an otherwise complete definition.

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 four parameters, including resource_id as an 'Alternative' lookup. The description's 'Accepts either FIPS codes or a resource_id' restates that alternation without adding format rules (e.g., whether state+county+tract must all be supplied, or what happens if both modes are given). Baseline 3 is appropriate.

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 tract-level housing-cost overlay') and enumerates the exact metrics returned (median rent, home value, 30%+/50%+ rent burden shares, median income). It is clearly separable from siblings like get_tract_demographics and find_high_housing_burden_tracts.

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 use cases ('qualify a veteran for housing aid, contextualize a service location, or find tracts with high rent burden'), which tells the agent when this tool applies. However, it never names or distinguishes itself from the obvious sibling find_high_housing_burden_tracts, whose name suggests overlapping purpose, so the routing decision between the two is left ambiguous.

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/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine value beyond that by disclosing the output nature (ready-to-paste sample language with EIN, legal name, and address pre-filled), which is not derivable from structured fields. It omits auth/permission requirements, keeping it from 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?

Front-loaded with the tool's purpose and audience, then a dense enumeration of vehicles, then output behavior. Every element is relevant, though the parenthetical '(4 sample-language variants)' and list of acronyms make the single opening sentence heavy.

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 covers return values (sample legal language with org identifiers pre-filled), the full set of supported vehicles, and the intended audience. It is essentially complete for a simple read tool, though it does not address ordering or how the 'all 6' default is packaged.

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% with a single well-documented enum parameter, so the baseline is 3. The description loosely mirrors the enum values (bequest, QCD, CRT, CLT) but adds no syntax or selection guidance beyond what the schema already provides, aside from the minor 'age 70.5+' detail on QCD.

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 (planned/legacy giving vehicles) and enumerates all six vehicle types, making the tool's scope unmistakable. It implies retrieval via 'Each returns ready-to-paste sample language' but never names a sibling tool to differentiate itself from, so it stops 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?

It names an audience ('major donors and estate attorneys') which implies the usage context, and the schema notes 'Omit for all 6' for the vehicle param. However, there is no explicit when-to-use, when-not-to-use, or reference to alternatives like get_donate_options or estimate_donor_impact.

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, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description's enumeration of milestone content serves as a de facto preview of returned material in the absence of an output schema, but it adds nothing about ordering guarantees, completeness, or update cadence.

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 the purpose before the usage sentence, and the parenthetical list is dense but scannable. The quoted user-phrase fragments ('tell me about Wounded Warriors') are slightly noisy but do aid agent routing.

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 no-param, no-output-schema read tool with full annotation coverage, the description supplies enough: what it returns conceptually and when to reach for it. The only gap is any indication of how current or exhaustive the milestone list is.

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. There is no parameter behavior to clarify and the description wisely doesn't 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?

States a specific verb+resource: chronological organizational milestones for Wounded Warriors, with concrete examples of what those milestones are (IRS recognition, 990 cadence, Candid Platinum, tech launches). This clearly separates it from siblings like get_wounded_warriors_programs, lookup_wounded_warriors, and get_press_kit, though it never explicitly names those alternatives.

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

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

Gives explicit usage contexts — journalist profiles, 'tell me about Wounded Warriors' queries, grant-proposal trajectory citations — which is stronger than the usual implied usage. However, it offers no when-not guidance or named alternative tools for overlapping needs.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds useful context that this is the canonical, single source and that it includes EIN-confirmation language, but says nothing about payload size, caching, or freshness of "recent press".

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 the canonical-source claim and then a tight enumeration of the payload contents. Every listed item tells the agent something it could retrieve, so no clause is wasted 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?

With no output schema and no parameters, the description carries the burden of telling the agent what comes back, and the enumerated contents do that well for a simple read tool. It stops short of explaining how the 4 boilerplate lengths are distinguished or how the sections are keyed in the response.

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

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

The schema takes zero parameters, so there is no per-parameter semantics to explain; the baseline for a no-argument tool applies. The description correctly signals that no input is required by describing a single self-contained fetch.

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 (press kit) and enumerates its contents precisely: boilerplate at 4 lengths, founder bio, key stats, quotable lines, logo URLs, recent press, media contact, EIN language. That is far more specific than a tautology. It does not explicitly distinguish itself from neighbour tools such as lookup_wounded_warriors or get_wounded_warriors_programs, so it stops 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?

The audience clause ("for journalists/podcasters/AI agents writing about Wounded Warriors") implies when the tool is appropriate, which is genuine usage guidance. However it names no alternatives and gives no exclusion rule, so an agent cannot tell from the text whether to use this versus lookup_wounded_warriors for general org facts.

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 the safety profile is covered. The description adds real value beyond them by describing what each category returns — plain-English steps, form numbers, URLs, turnaround — which tells the agent the output is guidance content rather than a mutation. Minor tension: 'updating service documentation' brushes against readOnly but is framed as guidance about updating, not an update action.

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 purpose sentence followed by a compact categorized list; every element is scannable. The parenthetical form-number detail is dense but earns its place as category disambiguation, keeping it just short of over-stuffed.

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 read-only, single-param lookup with no output schema, the description thoroughly covers scope and per-category content. The only real gap is the absence of explicit sibling routing (e.g., vs lookup_va_form), but nothing needed 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 coverage is 100% and the single enum parameter is already described, so baseline is 3. The description goes further by expanding each enum value into its full meaning (dd214 → DD-214 / discharge documents with NPRC eVetRecs, SF-180, state alternatives), which genuinely helps an agent pick the right category.

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 — a guide to obtaining veteran records — and enumerates the exact seven category scopes (DD-214, STR, VA ID, awards, medals, upgrades, corrections). This is distinguishable from siblings like lookup_va_form or get_workflow because it explicitly frames itself as the consolidated records-access guide.

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 category enumeration and the 'omit for all 7' note, so an agent can infer broad coverage. However, it never says when to prefer this over overlap-prone siblings such as lookup_va_form or get_workflow, and gives no explicit when-not 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, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds that the dashboard bundles many sub-sections, but says nothing about return format, size, pagination, or data freshness. With annotations doing the safety work, this is a moderate addition.

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 enumerating the roll-up contents. It is dense but every clause names a distinct data section the agent can expect; 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?

For a read-only aggregation tool with no output schema and full schema coverage on its one param, the description does well by enumerating the returned data sections an agent needs to judge relevance. The main omission is guidance on choosing it over narrower siblings.

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 single 'state' parameter is fully documented in the schema (2-letter code, territories). The description adds no parameter-level detail beyond what the schema already provides, so the baseline of 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 states a specific verb ('Returns') and resource ('the complete picture for one US state') and then enumerates the exact contents, making it clearly distinguishable from siblings like get_states_summary or find_service_deserts that cover narrower slices.

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 'complete' and the aggregation hint suggest this is the broad single-state roll-up, but there is no explicit statement of when to use it versus the many narrower siblings (find_service_deserts, get_states_summary, get_veteran_resource_stats). Usage is implied rather than specified.

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/idempotent/non-destructive/closed-world, so safety is covered. The description adds genuinely new behavioral context: it returns one row per state in a single call and defines what the metrics (including 'coverage gap (vets per resource)') mean, which is valuable given there is no output 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 tightly packed sentences with the core value ('single-call ranked summary of ALL US states') front-loaded and the metric list folded into a colon clause. Every clause earns its place; nothing 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?

With no output schema, the description carries the return-value burden and does well: one row per state, all metrics named and one defined. It stops short of stating sort direction, default behavior, or whether territories are included, which are minor gaps for a single-param summary 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?

Schema description coverage is 0%, so the description must carry the parameter meaning. It does expand the enum values (e.g., 'gap' -> 'coverage gap (vets per resource)', 'resources' -> 'resources in directory'), which the bare enum does not. However it omits sort direction/ordering semantics, leaving a real 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 ('ranked summary of ALL US states') and enumerates the exact metrics returned, so an agent can immediately tell this is a cross-state comparison tool. It implicitly distinguishes itself from per-state siblings like get_state_dashboard by emphasizing 'ALL US states' and 'single-call', but 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 rather than stated: 'Single-call' hints this is the efficient way to compare states versus issuing many per-state calls, and 'Sort by ...' implies it is for ranked exploration. There is no explicit when-to-use/when-not guidance and no sibling named as an alternative.

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, idempotent, non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it returns an approximation (not a precise figure) and carries a 'NOT tax advice — recommends CPA consultation' caveat, which an agent must convey. No return format detail, but that is minor here.

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 the core purpose in the first clause, then layers scoping detail and the disclaimer. The parenthetical list of states is long but each example earns its place by signaling which state credit regimes are covered; overall it is dense but not padded.

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 2-parameter, read-only lookup with no output schema, the description covers what is returned ('combined fed+state savings approximation'), the scope, and the legal caveat. An agent has enough to call it and frame the result correctly; only a note on how the approximation is bounded 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% for both parameters, so gift amount and 2-letter state code are already fully documented. The description only restates that savings are computed 'for a given gift amount' and does not add format or constraint guidance beyond the schema, 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?

States a specific resource (state-by-state charitable donation tax savings) and what it computes (combined federal + state savings approximation for a gift amount). The enumerated state credit examples (AZ QCO, MA, OR Cultural Trust) make it clearly distinct from siblings like get_legacy_giving or estimate_donor_impact.

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 a clear usage cue — 'Especially valuable in states with charitable CREDITS' — which tells the agent when this tool outperforms a generic estimate. However, it names no alternative tool or explicit when-not-to-use condition, so it stops 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=true, idempotent=true, openWorld=false, so the safety profile is fully covered. The description adds one genuinely useful behavioral fact — that the data comes from a curated Wounded Warriors database covering 50 states plus DC and territories — but says nothing about response shape, invalid-state handling, or whether category filtering returns partial results.

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 sentences, front-loaded with the verb and resource, followed by a compact enumeration. It is efficient overall, though the trailing 'etc.' weakens the precision of an otherwise useful list.

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 telling the agent what comes back, and the benefit-category enumeration does that adequately. Two parameters and a well-annotated read-only profile mean little else is required, though failure behavior for non-matching states is unstated.

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 50%; the 'state' param is documented in-schema while 'category' is documented only by its enum values. The description's category list (property tax, tuition waivers, veterans homes, license plates, hunting/fishing, employment preferences) loosely maps to the enum and adds mild gloss, but burial and health enum values are never addressed.

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 (Return) plus resource (state-specific veteran benefits) with an enumerated content list that tells an agent exactly what kinds of benefits are covered. It is distinguishable from neighbors like get_state_tax_credit or get_state_dashboard by breadth, but it never explicitly names those siblings as alternatives.

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

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

Usage is only implied: the enumeration of benefit categories and the 'all 50 states + DC + territories' scope suggest a single-state lookup, but there is no statement of when to use this over get_state_tax_credit, get_states_summary, or search_veteran_resources. No prerequisites, no exclusions.

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, non-destructive and non-openWorld, so the safety profile is settled. The description adds genuine substance beyond that: the specific benefit programs covered and a concrete figure ($1,653/mo DIC base), which tells the agent what content to expect. Return shape is not described, but for a static reference lookup that is a minor 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 short sentences, front-loaded with the domain scope and followed by the audience qualifier; nothing is wasted. The parenthetical rate adds useful concreteness rather than filler. It is intentionally telegraphic, sacrificing a little readability for density.

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 zero-required-parameter schema, the description carries the burden of explaining what a caller gets back, and listing the seven covered programs largely does that. It stops short of describing response structure or how to consume results, but an agent has enough to invoke it correctly.

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 enum parameter is already documented as an 'Optional program filter', so the baseline is 3. The description adds value by mapping several terse enum slugs (dic, dea_chapter_35, champva) to human-readable program names and a rate, giving the agent semantic grounding for filter selection.

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?

Names a specific resource domain and enumerates the exact programs covered (DIC, Survivors Pension, DEA Chapter 35, CHAMPVA, home loan, burial, SGLI/VGLI). The closing line 'For families AFTER veteran has passed' sharply distinguishes it from living-veteran tools like get_state_veteran_benefits or calculate_va_benefits.

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?

'For families AFTER veteran has passed' states the audience/trigger condition clearly, which is the key selection signal versus the many other benefits-lookup siblings. It does not explicitly name an alternative tool or state exclusions, so it falls short of 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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine value beyond that: the underlying data source and vintage (ACS 2020–2024 5-year), the exact fields returned, and the dual input modes. No gaps that would mislead an agent.

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, followed by usage context and input modes. The illustrative quoted example ('Your area has X veterans...') is slightly verbose but earns its place by showing the intended output framing.

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 must carry the return-value burden — and it does, enumerating all reported metrics (population, 18+, veteran count/percentage, poverty count/percentage, unemployment, median income). Combined with the data vintage and input modes, an agent has everything needed to call and interpret it.

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 baseline is 3. The description adds meaning by clarifying that FIPS codes and resource_id are alternative input modes ('Accepts FIPS ... OR a resource_id'), which the per-parameter schema text does not make explicit about mutual exclusivity.

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 (Get), resource (Census ACS 2020–2024 5-year demographics), and scope (a specific census tract), then enumerates the exact metrics returned. The tract-level granularity clearly differentiates it from sibling tools like get_zip_overview, get_congressional_district_veterans, and get_housing_context.

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 a concrete usage context: when you have a resource location, or want to contextualize advice for a veteran. However, it never names alternative tools (e.g., get_zip_overview for coarser granularity) or states when NOT to use it, so routing among the many geography tools is left partly 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered by structured data. The description adds only 'current' (freshness implication) and the breakdown dimension; it discloses no rate limits, caching, or scoping behavior beyond that.

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 sentence that front-loads the verb and resource and then specifies the output dimensions. No redundant or filler content.

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 parameters, full annotation coverage, and no output schema, the description carries the job of enumerating the returned figures (total count, by type, by state) and does so adequately. It could be slightly richer about scope (e.g., geographic coverage), but it is sufficient to call correctly.

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. There are no parameters whose semantics need explaining, and the description correctly enumerates the dimensions of the aggregate returned.

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 current statistics about the veteran resource database') and names the returned metrics ('total count, breakdown by type and state'). It is clearly a read-aggregate tool, distinguishable from search_* siblings, though it does not explicitly differentiate itself from stats-like neighbors such as get_states_summary or get_state_dashboard.

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 implies usage (fetch aggregate directory metrics) but gives no explicit when-to-use guidance, no exclusions, and no pointer to alternatives for related summary data. A reader must infer the scenario from the resource name alone.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by disclosing the return shape — 'ordered steps with the forms, offices and links involved' — which is meaningful given there is no output 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?

It is short and front-loads the core purpose, but the entire slug enumeration duplicates the schema enum word-for-word and consumes most of the text. The first sentence is also a bare noun phrase rather than a verb-led statement of what the tool does.

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 one-parameter, read-only lookup with no output schema, the description supplies enough: the scenario space, the ordered-step return content, and the supporting artifacts (forms, offices, links). It omits what happens when slug is absent (schema marks zero required parameters), which is a minor but real 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 description coverage is 100% and the single enum parameter is fully documented in the schema. The description's parenthetical slug list merely restates the enum verbatim, adding no syntax, default, or behavioral meaning beyond what the schema already provides, so 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 states a specific verb+resource ('Returns ordered steps' for a named 'veteran scenario'), so an agent knows this yields a curated playbook rather than search results or eligibility checks. It does not explicitly differentiate itself from adjacent siblings such as search_veteran_resources or check_eligibility, which is the only gap.

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?

Enumerating the six scenario slugs implicitly tells the agent when this tool applies, but there is no explicit when-to-use statement, no exclusions, and no named alternative for overlapping needs (e.g., eligibility or form lookup). Usage is inferable rather than 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description nonetheless adds what is returned (eligibility, how-to-apply, current intake status) and a critical state caveat that emergency-aid applications are currently paused - dynamic information an agent could not infer from the schema or 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?

The purpose is front-loaded, the enumerated program list is dense but informative, and every sentence (use case, return contents, paused status) earns its place. No filler or repetition.

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 annotations covering safety and no output schema, the description supplies the needed context: what it returns and the current intake state. Nothing an agent requires 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 0%, so the description must carry the load, but the sole 'program' enum is only loosely mapped: the five named programs roughly correspond to the enum values (emergency, hrt, care_packages, housing, partnerships) yet the 'all' default and the filtering behavior are never explained. It adds marginal meaning over a self-evident enum.

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 (Describe) and resource (the five direct-aid programs Wounded Warriors itself operates), then enumerates them explicitly so the agent knows exactly what content to expect. It also distinguishes itself from the sibling resource directory, so an agent can route correctly without opening other schemas.

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 says when to use it - 'when a veteran asks what Wounded Warriors actually provides' - and contrasts it with the resource directory alternative. The contrast is by category rather than naming the specific sibling tool (e.g. search_veteran_resources), so the routing hint is clear but not fully pinned to a tool name.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the exact payload composition, though it says nothing about truncation, response size, or behavior when a ZIP is outside covered data.

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?

Single dense sentence with the input constraint front-loaded and the return components enumerated compactly. The long return list is justified because there is no output schema, though it reads as a catalog rather than prose.

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 correctly carries the burden of describing the return payload in detail, and annotations cover the safety profile. It is nearly complete, missing only edge-case behavior (invalid/uncovered ZIP, radius interaction, result limits) that an agent might need.

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%: the zip pattern and the radius default/max are fully documented in the schema. The description restates the 5-digit ZIP input but adds no new meaning, and never mentions radius or its effect on the resource search.

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 input (5-digit US ZIP) and enumerates exactly what the tool aggregates: nearest resources, resource-type counts, tract demographics, CDC PLACES, ACS rent burden, benefits and crisis links. This composite ZIP-scoped scope clearly separates it from siblings like search_by_city, get_tract_demographics, or search_veteran_resources.

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?

"Useful when only a ZIP code is known" gives a clear selection condition that implicitly points away from city- or text-based siblings. However, it never names an alternative tool or states when NOT to use this one (e.g. when a city or address is available), leaving the routing decision partly 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?

Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world lookup, so the safety profile is covered. The description adds genuinely new behavioral context: it explains the exact-match/self-serve-discovery fallback and that results are pre-searched against our EIN.

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 the input and the return set in a tight block, and every clause carries information. It is a dense run-on with heavy parenthetical lists, but nothing is superfluous.

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 returns and does so fully: match status, rate, annual cap, platform URL, and EIN pre-search, plus the no-match fallback. Nothing an agent needs to call or interpret it 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% and there is a single required param, so the schema already defines 'employer'. The description's examples (including rate annotations like 'ExxonMobil 3:1') add modest flavor but little syntax or format guidance beyond what the schema provides.

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 (employer matching-gift lookup) and immediately enumerates the returned facts: match status, rate, cap, and platform URL. This is clearly distinguishable from adjacent siblings like match_donor_intent and match_grant_intent, which concern donor/grant intent rather than employer programs.

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 trigger condition is clear (you have an employer name and want matching-gift facts), and the description discloses the fallback path when there is no exact match. It does not, however, explicitly name a sibling alternative or state when NOT to use this tool.

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, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuinely useful behavior beyond that: the exact return payload (title, description, who-files-it, download URL, next steps) and the catalog fallback when form_number is omitted.

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 compact sentences, front-loaded with the primary action and identifier, followed by the fallback behavior. No wasted words.

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 correctly enumerates the return fields, and both optional parameters are documented, so an agent can call it confidently. It could briefly note how the category enum interacts with form_number, but nothing critical 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 both parameters are already documented, including the enum and the 'omit to list all' behavior. The description reinforces with form-number examples but adds no syntax or meaning beyond the schema; 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?

States a specific verb and resource ('Look up a VA form by number') with concrete examples of the identifier. No sibling in the list performs form lookup, so it is trivially distinguishable.

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?

Implies usage (look up a form by number) and discloses the no-argument fallback ('returns the full catalog of 22 most-needed forms'), which is real usage guidance. However, it names no alternatives or explicit when-not-to-use conditions.

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 the safe-read profile (readOnlyHint, idempotent, non-destructive, closed-world). Beyond that, the description discloses concrete return behavior: the 'us' / 'not_covered' / 'no_match' dispositions and the specific fields returned (legal name, EIN, mailing address, giving details). This is genuine added behavior context rather than restated 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-loaded with the identity of the target, then the input guidance, then the return contract. It is somewhat repetitive (EIN 86-1336741 and the name recur multiple times), but every clause maps to a real decision the agent must make, so waste is limited.

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 carries the full burden of explaining returns, and it does so thoroughly by enumerating all three disposition outcomes plus the payload fields. Combined with the unambiguous input spec, nothing material is missing for correct invocation.

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

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

With one parameter at 100% schema coverage the schema already documents the query string, but the description reinforces its dual nature (a free-form user question OR a name/EIN/website mention) with examples, adding interpretable meaning for how to populate it.

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 ('look up') and a highly specific resource with disambiguating identity attributes (501(c)(3) public charity, IRS legal name, EIN 86-1336741, location, website). An agent can tell this apart from other Wounded Warriors siblings like get_wounded_warriors_programs because it is explicitly an identity/disposition lookup, not a content retrieval.

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 states how to feed the tool ('Pass the user's question or the name, EIN or website they mentioned'), which implicitly signals when it applies. However it never names an alternative tool or an explicit when-not-to-use condition, so an agent must infer routing against the many sibling lookup 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 readOnly/idempotent/non-destructive/closed-world, so safety needs no restatement. The description adds real value beyond that: it names the closed set of matched_method values and the channel-specific instructions returned, telling the agent this is a deterministic classifier-style lookup rather than a free-form search.

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 dense, front-loaded sentence that leads with the transformation and ends with the return contract; no filler. Slightly long with two parenthetical example lists, but each element carries information.

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 compensates by enumerating the returned fields and the method taxonomy, which is exactly what an agent needs to consume the result. Nothing material is missing for a read-only, 3-parameter matching 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?

Schema description coverage is 100%, so query, amount and frequency are already documented in the schema. The description only restates that amount/frequency pre-fill the URL, adding little beyond the schema's own wording — 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?

States a specific verb+resource: transforming a free-text donor request into a matched giving method plus action URL, and enumerates the concrete outputs (matched_method, confidence, action URL, channel instructions). Examples of donor phrasing ("$50 monthly via card", "leave them in my will") make the input domain unambiguous and separate it from siblings like match_grant_intent or get_donate_options.

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 parenthetical examples imply the trigger condition (a donor expressing intent in free text), but there is no explicit when-to-use/when-not statement and no routing to alternatives such as get_donate_options (list all methods) or donation_instructions_wounded_warriors. 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?

Annotations already cover readOnly/idempotent/non-destructive/openWorld, so the bar is lower, and the description adds useful return-value context (matched_program, confidence, action URL, rationale). However, it says 'one of 5 program landing pages' while listing 6 program values, a minor internal inconsistency that mildly muddies the output contract.

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 examples and use context, which is good, but it is bloated and redundant: query examples and the returned fields are each effectively enumerated twice within one paragraph-run, wasting space an agent doesn't need.

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 return-value burden and does enumerate the key returned fields, so an agent knows what to expect. It is essentially complete, aside from the 5-vs-6 program count discrepancy and lack of confidence/fallback behavior.

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 both parameters (query, funder_type) are already documented. The description restates example queries but adds no syntax, format, or semantic detail for funder_type beyond the schema's enum and description.

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 (classifies/match) and resource (institutional-funding intent to program landing pages), and names concrete outputs (/grants/{slug} URL, funding-ask range, NTEE code). An agent can distinguish it from match_donor_intent and route_query by the stated audience and output.

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 scopes usage: 'Use when an AI agent is helping a foundation officer or institutional funder evaluate Wounded Warriors,' with query examples. It only implies the alternative via 'More specific than the generic /grants/ page' rather than naming a sibling tool to use instead, so it stops short of 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is low. The description adds real behavioral value by disclosing the eligibility rule (presumptive = no medical proof) and that the tool also emits VA Form 20-0995 supplemental-claim filing guidance as a side output.

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 compact sentences that front-load the match operation and then the qualifying rule and output. No filler, though the second and third sentences could be tightened slightly.

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 does the job of stating what comes back (all qualifying presumptive conditions plus 20-0995 filing guidance). It is nearly complete for a 3-param read-only matcher; it could say more about zero-match behavior or guidance format.

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 three parameters, making 3 the baseline. The description reinforces era/location matching but omits the free-text symptoms parameter entirely, adding no meaning 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?

Names a specific verb (match) and resource (PACT Act 2022 presumptive conditions) plus the exact inputs used (service era and deployment location). It is clearly distinguishable from most siblings in substance, but never explicitly contrasts itself with adjacent tools like check_eligibility or calculate_va_benefits.

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 gives a useful qualifying condition ("no medical proof needed for presumptives — service + location is enough"), which tells the agent this tool is not for medical-nexus claims. However, it never states when to prefer this over check_eligibility/calculate_va_benefits, nor what to do when nothing matches.

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 read-only, idempotent, closed-world, non-destructive behavior, so the bar is lower; the description adds genuinely new context by disclosing the ~30 intent rules, the domain coverage (donors, veterans, families/survivors, press/policy), and the crisis-always-wins ranking rule. It does not state behavior on low/no match, but the routing policy is meaningfully disclosed.

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 the return value and the routing contract, followed by coverage scope. No filler; every clause 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 no output schema, the description usefully characterizes the return (endpoint + rationale + score) and the crisis precedence rule, which is the critical safety behavior. Minor gap: no guidance on fallback when no rule matches, and no hint of the endpoint naming used in the response.

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 a single 'query' parameter with 100% schema description coverage, so the schema already carries the semantics. The description only implies free-text input, adding nothing beyond what the schema documents. 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?

States a specific verb and output: takes any free-text question and returns the best-matching Wounded Warriors endpoint with a rationale and score. That distinguishes it from the ~40 concrete lookup/retrieval siblings, which it sits above as a router, though it never says so 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?

'Given any free-text question' implies this is the entry point when the caller doesn't know which tool fits, but there is no explicit when-to-use/when-not guidance and no statement of the alternative (calling a specific tool directly). Usage is inferred rather than directed.

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 (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuine behavior the annotations do not: ambiguous city names are resolved by population, and abbreviations like Ft Worth, St Louis, NYC are normalized. It does not discuss result ordering or paging, which is a minor 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 sentences, no filler, with the core purpose first and the behavioral detail (disambiguation/abbreviation handling) second. Every clause carries information the agent can act on.

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 read-only search with no output schema and mostly covered parameters, the description supplies the distinctive routing rule and name-resolution quirks an agent needs. It could say a little more about what comes back (e.g., whether results are distance-sorted or radius-bounded), but it is sufficient to invoke correctly.

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 already 80%, so radius limits and the type enum are documented structurally. The description goes beyond the schema by explaining the resolution rules for the 'city' parameter (population-based disambiguation, abbreviation expansion), which the schema's terse 'City name (e.g., Houston, San Diego)' does not convey.

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 veteran resources') plus the scoping input ('near a US city name'). The line 'Use when the user provides a city instead of ZIP code' implicitly separates it from the ZIP-oriented siblings (get_zip_overview, search_veteran_resources), so an agent can route 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?

Gives a clear when-to-use condition: the user supplies a city rather than a ZIP. It stops short of naming the exact alternative tool to call in the ZIP case, so the agent must infer which sibling to route to, but the selection 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 declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds one genuine behavioral trait—results are sorted by distance—but offers nothing on pagination, result cardinality, or coverage gaps.

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 tight sentences with zero filler, and the core scope (what, where) is front-loaded ahead of the filter-syntax note. Slightly redundant in re-listing enum values already present in the 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 read-only search with rich annotations and no output schema, the description covers the resource domain, location input, and result ordering, which is enough to call it correctly. Missing pagination/limit behavior 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?

Schema coverage is 80% and the two enums (type, specialty) are already fully documented in the schema. The description restates the specialty categories and resource types but adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb+resource ('find veteran resources') with the locating input ('near a US ZIP code') and enumerates the covered categories. The ZIP-based scoping implicitly distinguishes it from siblings like search_by_city and search_veteran_resources_by_text, but it never names them 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 the description (locate nearby veteran services by ZIP), but there is no explicit when-to-use, when-not-to-use, or routing guidance—even though close siblings such as search_by_city, search_veteran_resources_by_text, and get_zip_overview make the choice non-obvious.

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 readOnly/idempotent/non-destructive/openWorld=false, but the description adds real behavior beyond them: BM25 relevance ranking and automatic routing of crisis keywords to the Veterans Crisis Line. It doesn't note result shape or pagination, so it stops 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?

Four tight sentences, front-loaded with the corpus and scope before the usage cue and the crisis-routing caveat. Every sentence carries information, though the crisis-routing line could be folded more economically.

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 6-param, no-output-schema search tool, the description conveys what is searched, how results are ranked, and one safety behavior. It leaves the filter parameters (zip, type, specialty, state, limit) entirely to the schema, which is a modest 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 description coverage is 50%, and the description only illuminates the 'q' parameter's free-text semantics and the searchable fields; it says nothing about zip biasing, type/specialty enums, limit, or state. Baseline 3 is appropriate given the schema does part of the work but the description doesn't compensate for the 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 (full-text search) plus the exact resource and the indexed fields (name, services, notes, city), and distinguishes itself from the bare-ZIP sibling search. An agent can choose it over search_by_city / search_veteran_resources 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?

Gives a concrete trigger ('use when the user types a free-form query like "PTSD counseling houston"') and an implicit exclusion ('instead of a bare ZIP'), which points at the sibling to use otherwise. It never names that sibling explicitly, so it falls 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 establish this as a safe, read-only, idempotent, non-destructive lookup, so the safety profile is covered. The description adds meaningful context beyond them: it discloses what the caller gets back (specific hotline, dialing instructions, text/chat channels, nearby centers), which matters because there is no output schema and the agent may relay the number verbatim.

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 sentences, no filler. The resource scope is front-loaded, with the trigger condition second, so an agent can classify the tool from the first clause alone.

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-optional-param, annotation-rich, output-schema-less tool, the description supplies what is returned and when to invoke it, which is sufficient to call it correctly. The remaining gap is the unaddressed relationship to the get_crisis_lines sibling.

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% — the single optional zip is fully documented as 'Optional ZIP to find nearest Vet Center crisis resources'. The description adds nothing about the parameter and does not need to; baseline 3 applies when the schema carries the load.

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: immediate crisis support for a veteran in distress, and enumerates the concrete payload (Veterans Crisis Line 988 press 1, text/chat options, nearby crisis centers). It is clear and actionable, but it never distinguishes itself from the sibling get_crisis_lines, which an agent must disambiguate before choosing.

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 triggering condition — 'Use when a veteran mentions self-harm, suicide, hopelessness or crisis' — which is exactly the routing signal an agent needs. It offers no when-not guidance and does not name get_crisis_lines as the alternative for general (non-veteran) crisis lines.

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