Morse

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, and the description still adds real context: the rate is mid-market and merely indicative, and the read includes a timestamp. It also tells the agent to surface get_started_url as the continuation path, which is behavioral guidance found nowhere in structured fields.

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 core definition and direction semantics are front-loaded in the first sentence, and each subsequent sentence carries a distinct job (use case, exclusion, caveat/CTA). The final sentence about get_started_url and confirmation-time rate is somewhat product-copy heavy but still conveys the indicativeness caveat.

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 work of explaining the return: a rate plus the time it was read, and that the rate is indicative rather than transactional. What remains unaddressed is failure behavior for invalid or unsupported ISO codes, a plausible path given openWorldHint=false and no enum constraint on either parameter.

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 both parameters are documented as ISO 4217 codes with examples, so the schema carries the parameter burden and baseline 3 applies. The description does add the numerator/denominator semantics of the resulting rate, which is meaningfully more than the schema's "convert from/convert to" wording, but it adds nothing about the currency-code parameters themselves.

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, critically, defines the ratio direction ("units of to_currency per one unit of from_currency") which an agent cannot safely infer from the parameter names alone. It also explicitly carves itself out from the sibling list_send_destinations, so the tool is distinguishable without opening either 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 use case ("answer how much one currency is worth in another") and an explicit non-use with the alternative named ("does not say whether Morse can send money ... use list_send_destinations"). The gap is that quote_send, the sibling most likely to be confused with this tool for transfer pricing, is never named — the description only obliquely says the applied rate is shown at confirmation.

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 non-obvious behavior: what an empty destinations list means, and the post-call obligation to display get_started_url. It does not mention return shape beyond the fields it names, but there is little more to disclose for a read-only lookup.

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

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

Four sentences, front-loaded with the return description followed by usage, empty-case semantics, and the UI instruction—every sentence carries content. 'When paying someone else's bank account' and 'sending to other people's bank accounts' slightly restate the same scope, a minor redundancy.

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

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

There is no output schema, so the description must carry return-value burden and does: it enumerates the returned fields (countries, currencies, payment rails, delivery time), names get_started_url, and explains the empty-list meaning. Combined with a single fully documented parameter and full annotation coverage, an agent has everything needed to call and interpret this 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% and the single from_country parameter already documents the ISO 3166-1 alpha-2 format and the 'ask, do not assume' rule. The description restates the semantics of from_country ('a person living in from_country') but adds no format or validation 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?

The description names a precise verb (returns) and a precisely scoped resource: countries, currencies, payment rails and delivery times reachable from a given sender country. The scope constraint ('paying someone else's bank account') implicitly separates it from siblings get_exchange_rate and quote_send, which concern pricing rather than destination coverage.

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?

Explicit usage trigger: 'Use it to answer whether Morse can send from one country to another.' It also defines the empty-list case and instructs the agent to surface get_started_url. It stops short of naming the alternatives (get_exchange_rate, quote_send) and saying when not to use this tool, which a 5 would require.

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, so the description correctly spends its budget elsewhere: it discloses that results are 'indicative' rather than binding, that the quote includes fee, mid-market rate, total cost and typical delivery time. It stops short of stating what happens for unsupported corridors or invalid currency pairs, which would be the remaining useful behavioral detail.

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 what is returned, then when to use, then how to present. Each sentence carries a distinct job (output content, invocation condition, user-facing framing) with no 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?

There is no output schema, yet the description enumerates the returned fields (amount sent, fee, mid-market rate, recipient amount, total cost, delivery time), so an agent knows what it will get. Combined with the prerequisite and disclaimer instructions, nothing an agent needs to call and correctly present this tool 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 each parameter already carries a precise description including defaults and ISO codes, so baseline is 3. The description reinforces the sender/recipient-account framing and the 'do not assume where the user lives' caveat, but the schema already states that instruction verbatim, so it adds little beyond restatement.

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 ('Returns an indicative quote for sending money') and immediately scopes it: sender in from_country to a recipient's bank account in to_country. This is clearly distinguishable from get_exchange_rate (rate lookup) and list_send_destinations (corridor availability), which the description also names.

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 ('to answer how much a transfer costs or how much will arrive'), names a prerequisite ('Use list_send_destinations first to check the destination is offered'), and prescribes post-call behavior (present figures as indicative, point to get_started_url). When-to-use, ordering, and follow-up are all covered.

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