Kaleto

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: the record returned is 'current' and the call deliberately does not validate offerings or availability, which warns the agent about potentially stale or unverified 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?

Two short sentences, no filler. The action and its input source come first, and the scope caveat is placed last rather than burying the primary instruction.

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 an output schema present, return format need not be described, and annotations carry the safety profile. The description covers action, input origin, and a scope limitation, leaving only minor gaps such as behavior on a stale or unknown UUID.

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 schema only gives type/format/pattern with no prose. The description compensates by stating the parameter's provenance ('a UUID returned by search_providers'), which is the key thing an agent needs to supply a valid value; it stops short of naming the field or noting failure behavior for unknown IDs.

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 the current provider record) and anchors it to the sibling tool that produces the required identifier (search_providers). This lets an agent distinguish it from search_providers and open_provider_explorer 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?

'using a UUID returned by search_providers' gives an explicit prerequisite and routing rule, and the closing sentence bounds what the tool is not for (it does not verify offerings or availability). No direct comparison against open_provider_explorer or list_regions, so it falls short of a full when/when-not map.

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 genuine domain context beyond that: regions may overlap and are not distance or service-area boundaries — a caveat that prevents an agent from misinterpreting the IDs as geographic service areas.

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 core capability is front-loaded and the clarifying caveat follows, which is exactly the right ordering.

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 an output schema present, the description need not explain return values, and for a zero-parameter list tool it is nearly self-sufficient. The only mild gap is the absence of any pointer to how these regions relate to the sibling provider tools.

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 per the rubric the baseline is 4. There is nothing parameter-related the description could or should add, and it correctly spends no words on an empty 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 ('List') plus the resource ('supported region IDs') and even describes the payload contents ('included city/state addresses'). It is trivially distinguishable from the provider-oriented siblings (get_provider, search_providers, open_provider_explorer).

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: call this to discover valid region identifiers. There is no explicit statement of when to prefer this over the sibling provider tools, nor any exclusion or prerequisite, so it lands at the minimum-viable level rather than offering real 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, idempotent, non-destructive, and non-open-world, so the safety profile is covered. The description adds behavior annotations don't carry: preserved input order with no reranking, and all-or-nothing failure if any supplied record is missing. It stops short of describing how records are resolved (fresh fetch vs cache) or any per-request latency/limit details beyond the 25 cap already in the schema.

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

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

Four tight sentences, front-loaded with the core action and payload, then edge-case handling, then ordering, then failure mode and exclusions. No repetition of the title or schema constraints beyond what is useful.

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 an output schema present, return values need no explanation, and annotations cover the safety profile. The remaining gaps an agent would care about — optional-parameter edge cases, ordering, hard failure on missing records, and out-of-scope adjacent actions — are all addressed.

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 carries the full burden and does: it distinguishes omitting provider_ids (start with no results) from passing an empty array (only after a confirmed empty search), and specifies ordering semantics for the supplied UUIDs. That is meaning an agent cannot derive from the bare UUID-array 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 concrete verb+resource (open provider exploration) and scopes it to 'current records for up to 25 unique UUIDs returned by discovery,' which implicitly ties it to the search/discovery flow and separates it from a bare lookup. It never names the sibling tools (get_provider, search_providers) explicitly, so routing relies on inference rather than direct differentiation.

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 when-to-use conditions for the optional parameter (omit to start without results, pass [] only after a successful search with no matches) and closes with negative scope ('does not save a list, verify suitability, or make a booking'). The agent knows both the calling convention and what adjacent intents must be routed elsewhere.

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), and the description goes well beyond them: it discloses the mapping/ranking pipeline, a retrieval ceiling of 120 providers, shared rate and concurrency limits across all callers, that search analytics are stored, and that program availability is not verified.

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 action and constraint, and nearly every sentence carries operational information. It is dense, and the internal pipeline detail (Jev mapping, PostgreSQL retrieval) is more implementation exposure than an agent strictly needs, which slightly dilutes it.

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

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

An output schema exists, yet the description still names the salient return fields (selected_types, relevance scores, limitations), plus rate limits, the unverified-availability caveat, and the LOCATION_UNSUPPORTED recovery path. Nothing needed to invoke or interpret the call 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 only 33%, so the description has to compensate. It does for two of three parameters, clarifying that query is natural-language interests mapped to activities and that region accepts a place name or a region ID with the response echoing the region actually searched. The limit parameter (default 10, max 25) is never explained in either place, leaving one 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?

The description states a specific verb and resource — searching enrichment provider records — and immediately scopes it to natural-language interests within a required region. It is clearly distinguishable from get_provider (single lookup), list_regions (region enumeration) and open_provider_explorer by naming the search/rank behavior.

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 an explicit routing rule for the sibling tool: 'call list_regions only after LOCATION_UNSUPPORTED'. It also states when not to rely on part of the input ('location words in the query are not used for filtering') and adds a privacy constraint ('Do not include child names or private details').

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