creditunions

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is fully covered. The description adds one useful fact beyond the annotations: only "published" listings are retrievable. It says nothing about behavior for an unknown or unpublished slug (error vs. empty).

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 eight-word sentence with the operation, scope, and key front-loaded. No filler, nothing redundant.

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

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

For a one-parameter read tool with full annotation coverage this is nearly adequate, but with no output schema the description could reasonably indicate what a listing contains or what happens when the slug matches nothing. Those gaps are minor but real.

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 parameter, so the schema already defines the slug format, pattern, and length. The description only confirms slug as the lookup key, adding no syntax or format detail 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?

States a specific verb ("Get"), resource ("one published credit union"), and lookup key ("by its slug"), which cleanly separates it from list_*/search_listings siblings. It stops short of explicitly naming the alternative (search_listings) for multi-result lookups, so it falls just shy 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 singular "one ... by its slug" implies this is the exact-identifier lookup rather than a search, but no when-to-use or when-not-to-use guidance is stated and no alternative is named. Usage is inferable but not spelled out.

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 closed-world scope, so the safety profile is covered. The description still adds meaningful context beyond the schema by disclosing the returned content, notably the 'when the data last changed' freshness signal, though it omits rate limits or response format details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that names the returned metrics immediately, with no filler or redundant restatement of the tool name.

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 parameterless read-only stats tool with no output schema, the description adequately explains what is returned (three counts plus a last-changed timestamp) and lets annotations carry the safety profile. Minor gap: it does not describe the response shape or units, which would help since no output schema exists.

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

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

The tool takes zero parameters and the schema has no properties to document, so there is nothing for the description to compensate for. Baseline 4 applies for a parameterless tool.

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) and the exact resources returned: counts of published credit unions, places and categories, plus data freshness. This clearly distinguishes it from siblings like list_categories and list_places, which enumerate records rather than return aggregate counts.

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

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

Usage is implied rather than stated: an agent can infer this is the tool for summary/dataset-size questions instead of record retrieval. However, no explicit when-to-use or when-not-to-use guidance is given, and no sibling is 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's only added value is hinting that each category is returned with a credit union count, which is a small but real disclosure 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?

A single short sentence with the resource and the key return detail front-loaded. Nothing extra, nothing 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 zero-param read tool this is close to adequate, but with no output schema the description is the only signal about the return shape and it is thin. It also never says what a 'category' represents or how it relates to places/sources/listings in the sibling set.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies since no parameter semantics can be missing.

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

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

States a specific verb (List) and resource (categories) and adds scope detail (credit union counts). It does not distinguish itself from siblings list_places or list_sources, so an agent must infer the distinction from the resource name alone.

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

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

No indication of when to prefer this over get_stats, list_places, or the other list_* siblings, and no prerequisites or exclusions stated. Usage must be inferred entirely from the 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 fully covered externally. The description adds the meaningful scoping detail that results are limited to geographies that actually have credit unions, but says nothing about ordering, return shape, or size of the result set.

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 short sentence with the action front-loaded and zero filler. Every word contributes to the scope statement and nothing needs trimming.

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

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

For a simple no-argument read tool with annotations covering the safety profile and no output schema, the description is nearly sufficient. A brief note on what each entry contains (names, identifiers, nesting of city within region) would fully close the 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?

With zero parameters and 100% schema coverage there is nothing for the description to disambiguate, so the baseline of 4 applies. No parameter-level semantics are needed or missing.

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

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

States a concrete verb ("List") and a concrete resource ("countries, regions and cities that have credit unions"), which is clearly distinct from the sibling tools that list categories, sources, or stats. It doesn't explicitly name a sibling to contrast with, but the scope of the enumeration is unambiguous.

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

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

Usage is implied rather than stated: an agent can infer this is the geographies enumerator, but there is no when-to-use guidance, no mention of when to prefer search_listings or list_categories, and no prerequisites. For a no-parameter enumerator the omission is minor but leaves the choice 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 readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds genuine value beyond them by disclosing what each entry contains — license and refresh cadence — which an agent cannot infer from the annotations or the empty 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?

A single front-loaded sentence with no filler; the verb, the resource, and the returned content all appear in order of importance.

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, no output schema, and safety fully covered by annotations, the description's main remaining job is to say what comes back — which it does. Only minor gaps remain, such as whether the source list is paginated or ordered, which are low-risk for a small static enumeration.

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 no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-param tool is 4.

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

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

States a specific verb ('List') plus the resource ('where the credit union data comes from') and even names the fields returned (license and refresh). The resource is unambiguous against siblings like list_categories, list_places, and search_listings, which operate on entirely different entities.

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 explicit when-to-use statement, no exclusions, and no named alternatives. For a zero-parameter, read-only lister the usage is largely self-evident, so the implied context is adequate but nothing is 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 declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so safety is covered. The description adds one genuinely useful behavioral fact — only 'published' credit unions are returned, i.e. an implicit visibility filter — but says nothing about pagination behavior, empty-query results, or how the closed-world hint interacts with country codes outside the directory (a 400 the schema mentions but the description does not reinforce).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, which is the right shape for a tool whose parameters are fully documented elsewhere. It is arguably thin rather than wasteful, so the size is appropriate though not maximally informative.

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 8 optional parameters and no output schema, an agent gets safety from annotations and semantics from the schema, but the description never states what happens with zero filters (return all published listings?) or how the no-required-params behavior interacts with the sort defaults. For a search entry point covering text/place/category it is adequate but leaves the empty-query case to inference.

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%: q's matching behavior and typo fallback, sort's default logic per q, cursor's opaque resend semantics, and country's 400-on-uncovered-code are all documented in the schema itself. The description only restates the facets and adds no syntax or interaction detail beyond it, so the baseline 3 applies.

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

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

The description gives a specific verb (Search) plus resource (published credit unions) and enumerates the axes it searches on (text, place, category). That separates it from get_listing (single record) and from list_categories/list_places (facet enumerations). It stops short of naming those siblings or explicitly contrasting with them, so it is clear but not fully differentiated.

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

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

Usage is only implied: the word 'Search' plus the facet list tells an agent this is the lookup tool, but there is no statement of when to prefer it over list_places/list_categories (which arguably feed its city/region/category params) or get_listing. No exclusions, prerequisites, or fallback guidance are given.

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