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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds genuinely new behavioral context: writes are refused rather than attempted, and the return value is AwardWallet's raw JSON, plus a reference URL for the upstream 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?

Three short sentences, front-loaded with what the tool does and its hard constraint, then the discovery source and reference link. 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?

No output schema exists, and the description correctly states the response is AwardWallet's JSON, which is enough. Error handling and pagination behavior are unaddressed, and the nested input object is left entirely to the schema, but for a generic passthrough call the essentials are present.

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

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

Schema coverage is 100%, and the schema already explains that input carries path params plus query/body and that operationId comes from search_api_operations. The description only restates the discovery source, 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 (runs), a specific resource (a read-only AwardWallet API operation), and the mechanism (access=read in search_api_operations). It also explicitly distinguishes itself from the write sibling by stating it 'Refuses write operations'.

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

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

Tells the agent the operation must come from search_api_operations and that writes are rejected, which implicitly routes write intent to call_api_write_operation. It stops short of naming that alternative explicitly or stating when the read path is preferred over the many dedicated get_/list_ 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 destructive/non-idempotent/open-world, but the description adds genuinely non-obvious behavior: secrets are collected via a one-time local link so they never traverse the conversation, and some operations start billable work. This is exactly the kind of context annotations cannot 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?

Front-loaded with the operation class, then the secret-handling caveat, then a reference URL. Dense and purposeful, though the long first clause packs several distinct behaviors into one sentence.

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 mutation tool with no output schema, the description covers the safety profile, the secret round-trip, and billable side effects, and points to the API reference. It does not describe the conditional secure-link return value in detail, but annotations and schema cover most needs.

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 operationId and input are fully documented in the schema; the description adds only an indirect hint about secret collection (related to collectSecrets). Baseline 3 is appropriate when the schema carries parameter semantics.

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 (runs an AwardWallet API write operation) and enumerates the operation classes it covers (create/change/delete, sign-in, billable work), explicitly scoping itself to access=write in search_api_operations. This cleanly separates it from the sibling call_api_read_operation.

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 access=write qualifier paired with the read sibling implicitly tells the agent when to pick this tool, and it directs the agent to search_api_operations for the operationId. It stops short of explicitly naming call_api_read_operation or stating exclusions in prose.

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/openWorld, so the safety profile is covered. The description adds real value beyond them: it discloses that the response includes full tracked properties, sub-accounts, an AwardWallet update link, and paginated transaction history, which tells the agent the payload is broad and history is paged.

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 dense sentence, front-loaded with the core action and result before the field enumeration. The trailing ellipsis makes the field list slightly open-ended, but there is no wasted text.

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 list the main response components and pagination. It is nearly complete for a read tool whose annotations already cover safety, though exact paging semantics and any error/permission behavior are 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 description coverage is 100%, so accountId, historyLimit and historyOffset are already documented in the schema. The description mentions pagination but adds no parameter-level detail (units, paging interaction) 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 ('Returns one loyalty account') and enumerates the payload contents (balance, tracked properties, sub-accounts, transaction history), which clearly separates it from the list_loyalty_accounts sibling by emphasizing a single account. It never names the sibling, so it falls just short of full 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?

There is no when-to-use guidance, no prerequisites, and no alternatives named. The only routing hint ('accountId from list_loyalty_accounts') lives in the schema, not the description, so the agent gets no usage context from the text itself.

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, open-world behavior, so the safety profile is covered. The description adds real value on the read side by disclosing what the payload contains (login fields, tracked properties, elite level count, supported operations like transaction history and reservation lookup) — meaningful context given there is no output schema. It stops short of describing behavior for an unknown or invalid code.

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 front-loaded sentence that leads with the verb and resource before enumerating returned data. The parenthetical list is dense but each item earns its place by describing output, since no output schema exists; there is no filler or restatement.

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

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

For a single-parameter read tool with no output schema, the description compensates well by enumerating returned fields and capabilities, so an agent knows what it gets back. The remaining gap is error behavior for an unrecognized code, which is minor against annotations that already cover safety.

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 single parameter has 100% schema description coverage, including the pattern constraint and a source example, so the schema does the heavy lifting. The description mentions only 'one loyalty program' without adding format or lookup detail beyond what the schema already supplies, which is the baseline case.

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) and a clearly scoped resource (what AwardWallet knows about one loyalty program), then enumerates the kinds of data returned. It implicitly distinguishes itself from get_loyalty_account and search_loyalty_programs by focusing on program metadata rather than an account or a search, though it never names those siblings 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?

No when-to-use guidance, no exclusions, and no routing to alternatives. The only pointer to how a code is obtained (search_loyalty_programs or an account's programCode) lives in the schema, not the description, so the description itself offers no usage context.

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 (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false). The description adds genuinely new behavioral context beyond them: the exact state machine (waiting/completed/failed/cancelled/expired) and the fact that the response payload is only populated once completed, which tells the agent when to stop polling.

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 tightly written sentence with the core action front-loaded and the state enumeration folded into a parenthetical; no filler or restatement of the title.

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 return value (status plus AwardWallet's response once completed). For a simple one-param read tool this is nearly complete, though it omits any polling cadence or error-handling 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?

There is a single parameter at 100% schema description coverage, and the schema already documents that submissionId is the value returned by call_api_write_operation (including its 32-char pattern). The description adds nothing about the parameter, 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?

The description states a specific verb and resource ('Returns the status of a request waiting on the secure input page') and even enumerates the possible states, so the agent knows exactly what it gets. It does not, however, distinguish itself from the sibling get_status, leaving a small ambiguity about which status tool applies.

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 schema note that submissionId comes from call_api_write_operation hints this is the follow-up poll after starting a write flow, but the description itself never says when to call it, when not to, or how it relates to get_status.

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, openWorld and non-destructive traits, so the bar is lower; the description still adds real value by disclosing what the response reveals (which APIs are usable, credential source, mode flags, entity counts) and its diagnostic role. It stops short of 5 only because it says nothing about auth requirements or caching/side effects.

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 packs the return contents and the diagnostic use case without filler. It is slightly dense with enumerations but 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 parameters and no output schema, the description carries the burden of describing what the agent gets back, and it does so (APIs, credential sources, mode, counts) plus the reason to call it. Only missing element is any hint about field naming or error semantics.

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, which sets the baseline at 4; there is no input surface that needs further explanation.

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 clear verb (shows) and enumerates concrete resources: available AwardWallet APIs, credential provenance, demo/read-only mode, and people/account counts. It is distinguishable from the sibling list/search tools, though it never explicitly contrasts itself with them.

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 diagnostic context ('Useful to explain missing data or configuration errors'), telling the agent when this tool is the right call. It does not name alternatives or state when not to use it, so it stops short of the top band.

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 non-destructive behavior, so the description's added value is the access prerequisites (paid Business subscription plus export approval) and the coverage limitation (only connected users who share trips). That is meaningful behavioral context beyond the structured fields, though pagination and rate-limit behavior are left to 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?

Front-loads the core purpose and scoping, then qualifications. The parenthetical enumeration of ten reservation types is bulky but earns its place by pre-empting type questions. Two sentences, 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, default window, ordering, coverage limits and subscription prerequisites for a 7-parameter tool with no output schema. Return shape is partly covered by the detail enum in the schema; overall the agent has enough to call it correctly, with only pagination semantics unaddressed.

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

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

Schema description coverage is 100%, so every parameter is already documented, giving a baseline of 3. The description restates the default window and type list rather than adding syntax or format detail beyond what the schema provides, so it neither clarifies nor detracts.

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 ('Lists trips from AwardWallet's travel timeline'), enumerates the covered reservation types, and specifies ordering ('sorted by start date') and the default date window. An agent can distinguish it from list_people or list_loyalty_accounts 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 concrete activation conditions: only connected users who share trips are covered, and a paid Business subscription with timeline export approval is required. It also implies how to use userId ('from list_people', omit to combine everyone). It stops short of naming alternate tools for overlapping needs, so it falls just shy 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 and openWorld, so safety is covered. The description adds genuinely useful behavioral context: the row-based result shape, the accompanying summary of upcoming expirations and problem accounts, and a pointer to the pagination note tied to peopleOffset. It does not cover rate limits or result ordering nuances beyond the schema, keeping it at 4.

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 result contents, followed by filter axes and the sibling pointer. The first sentence is dense with parentheticals but every clause carries information; slightly heavy but 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 12 optional parameters, no output schema and only annotations for safety, the description carries the return-shape burden well by describing compact rows plus the expirations/problems summary. It stops short of explaining the pagination result note it references, a minor gap for a tool with no output schema.

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 12 parameters with enums, defaults and format patterns. The description restates the filter dimensions (person, program, type, balance, expiration date) but adds no syntax or format detail 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 verb and resource, enumerates what each row contains (balance, elite status, last change, update status, expiring sub-accounts), and explicitly names the sibling get_loyalty_account as the differentiator. An agent can distinguish it from get_loyalty_account and search_loyalty_programs 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?

Explicitly routes the agent: use this tool for listing/row-level views, use get_loyalty_account for one account's full properties and transaction history. It also enumerates the available filter axes, so the agent knows what narrowing is possible.

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 openWorld, so the safety profile is covered. The description adds genuine scope context beyond that: whose data is visible, that per-user account/trip access grants are included, and that each person's account count is reported. It does not mention pagination or result-size limits, keeping it out of 5 territory.

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, front-loaded with the verb and resource, then the population definitions and return values. Every clause carries information; nothing is 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 full load and does explain what comes back (userId, memberId, access grants, account counts). It omits any note on result size, ordering, or pagination, which is a minor but real gap for a list endpoint.

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 nothing for the description to disambiguate. The description correctly spends no space restating parameter semantics and instead documents the output identifiers.

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 (Lists) and resource (people), and crisply enumerates the two populations covered: connected AwardWallet users and members added in the business interface. It also names the key returned identifiers (userId, memberId), making it distinguishable from account-oriented siblings like list_loyalty_accounts.

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 clearly implied by 'Returns the userId and memberId values other tools accept', which tells the agent this is the entry point for obtaining identifiers needed elsewhere. It lacks an explicit when-not or a named alternative, so it stops 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 and closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses the return shape (id, read/write flag, doc link, input JSON Schema) and hints at truncation behavior via 'limit = maximum matches with full schemas' and the brief-listing fallback for empty queries.

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 purpose before the enumeration of covered APIs and return fields. The list of six API names and the doc URL are somewhat bulky but carry genuine routing 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?

There is no output schema, and the description compensates by naming the returned fields and the empty-query fallback, so an agent knows what to expect. Combined with full schema coverage for inputs, nothing essential is missing for a search tool of this 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%, so the baseline is 3. The description echoes the meaning of results and mentions the empty-query case, but adds little syntax or semantics for the four parameters beyond what the schema (including the query examples and enum descriptions) already 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 (searches) and resource (the raw AwardWallet API operations this server can call), and scopes it to the six named upstream APIs. It is clearly a discovery/meta tool, cleanly distinguishable from the call_api_* siblings that execute operations.

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 gives clear usage context: query with intent phrasing, and 'an empty query lists every available operation briefly', which tells the agent how to enumerate. It stops short of explicitly stating when to prefer this over call_api_read_operation or call_api_write_operation (i.e., 'use this first to find the operation 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 read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds real context beyond them: results are scoped to AwardWallet-supported programs and the return value is program codes. It omits pagination/limit behavior and empty-result handling, 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?

Two tight sentences with zero filler, front-loading the core action and ending with the output/routing detail. 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 correctly discloses the return value (program codes), the searchable dimensions, and the consumer tool. It is complete enough to invoke correctly, though limit/pagination and no-match behavior are 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 baseline is 3. The description adds value by giving concrete query examples ('hyatt', 'avios', 'membership rewards') that illustrate acceptable name/code inputs, and notes the optional type filter — beyond what the schema's generic 'Program type'/'Program or company name or code' text conveys.

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 (Searches) and resource (loyalty programs AwardWallet supports) plus the searchable fields (name or code, optionally type). It also distinguishes itself from the sibling get_loyalty_program by explaining that it returns the codes that tool consumes.

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 closing clause 'Returns program codes for get_loyalty_program' implicitly routes the agent: use this to discover codes, then call get_loyalty_program. There is no explicit when-not guidance or naming of alternatives beyond that, so it falls just short of 5.

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