eSIM SOS

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

Annotations cover only readOnlyHint and openWorldHint, so the description carries the rest and does so well: it discloses the data source (esimdar.com, CC BY 4.0), an ownership/bias conflict of interest, and a required disclosure + neutral-presentation obligation. This is behavioral context an agent could not infer from structured fields and directly affects how results should be reported.

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 operation and scope; the second sentence carries the provenance and disclosure obligation without 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?

For a two-parameter read-only comparison tool with full schema coverage and annotations covering safety, the description is nearly complete. The one minor gap is that no output schema exists and the description does not sketch the return shape (per-provider price rows), which would help an agent present results neutrally as instructed.

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 (country format, gb as a number), so the schema already documents everything. The description only restates 'country and data size' without adding format or validation detail, which is the expected baseline 3 when 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 ('Compare'), resource ('eSIM prices'), and scope ('several providers for a country and data size'), which cleanly separates it from siblings like list_plans (single catalog) and search_destinations (destination lookup). The dataset source is also named, so an agent knows exactly what is being compared.

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 (multi-provider price comparison keyed on country + data size) and adds a presentation directive, but it never names an alternative or exclusion, e.g. when to prefer list_plans over this tool. Clear context without routing guidance, so 4 rather than 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?

Goes well beyond the annotations by disclosing the payment workflow: the human always pays, the agent must never attempt payment or solicit card details, and the email is the delivery channel for the QR code. Combined with 'creates a real order,' this conveys the non-idempotent, consequential nature of the call.

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 short sentences, each carrying a distinct instruction: what it does, who pays, what to collect first, and when it is safe to call. No filler; the outcome (payment link) 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?

Despite having no output schema, the description names the return value (a payment link) and covers the prerequisites, safety constraints, and sequencing an agent needs to invoke a money-adjacent creation tool 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%, so parameters are already documented; the description's email explanation largely echoes the schema. It does add workflow meaning by framing email as something to request from the user before calling, rather than a passive field.

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 ('Create an unpaid eSIM order') and names the concrete artifact returned ('get a payment link'). This clearly distinguishes it from siblings like list_plans and order_status, which do not create anything.

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?

Provides an explicit precondition — 'call it only after the user picked the plan' — which implies the list_plans sequencing without naming the sibling directly. It also instructs to collect the email first, but does not explicitly route to any alternative tool or state 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=true and openWorldHint=false, so the safe-read nature is covered. The description adds useful context about what the caller receives (a link with QR code plus platform-specific install steps), but says nothing about access control beyond ownership of order_id/email, expiry, or failure modes.

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 outcome, no filler. Minor redundancy: 'Requires order_id and email' repeats the schema's required 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?

No output schema exists, so the description carries the return-value burden, and it does describe the payload (order page link with QR code and install steps). It is nearly complete for a simple read tool; only error/expiry behavior is 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 coverage is 100% and both parameters are documented in the schema, so baseline is 3. The description restates that order_id and email are required but adds no format, lookup, or validation nuance 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 concrete outcome: a link to the order page containing the QR code and step-by-step eSIM install instructions for both iPhone and Android. An agent can distinguish this from order_status (status lookup) and create_order (creates the order). It doesn't explicitly contrast itself with those siblings, keeping 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?

'After payment' gives a clear temporal precondition that implies post-purchase context, but no sibling is named and no explicit when-not guidance is given. The agent must infer that order_status or create_order are the wrong picks for this task.

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 and openWorldHint=false, but the description adds real behavioral context: prices are returned in RUB, normalized to one price per payment method, and ordered local-first. It does not mention pagination or result limits, which keeps 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 compact sentences, zero filler, with the core resource and price semantics front-loaded before the ordering detail. Every clause carries information an agent can use.

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 discloses return semantics (currency, per-payment-method pricing, ordering). For a read-only list tool with full schema coverage this is nearly complete, though it omits any hint of result volume or pagination.

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 days, min_gb, and country are fully documented in the schema, making 3 the correct baseline. The description adds currency context (RUB) but nothing about how filters interact or parameter formats beyond what the schema states.

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 ('List eSIM data plans for a country') and adds scope detail (final prices in RUB, one price per payment method). It distinguishes itself from compare_prices only implicitly via the price/ordering language, never naming the sibling, so it falls 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?

No when-to-use or when-not-to-use guidance is given, and the obvious alternative (compare_prices) is never mentioned. The clause about local vs. regional ordering describes output, not usage, so the agent must infer the tool's place in the workflow.

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 and openWorldHint=false, so the safe-read profile is covered. The description's only added behavioral point is that the email is required alongside order_id, which largely restates the schema's required array; it says nothing about failed lookups, error behavior, or rate limits.

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, the action front-loaded and the precondition immediately after, with no filler or redundancy. 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?

For a simple two-parameter read-only lookup with no output schema, the description adequately covers purpose and prerequisites, and it does name the returned information (payment and delivery status). Minor gap: nothing about failure modes when the order_id/email pair doesn't match.

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 in the schema, so the baseline is 3. The description merely repeats that both fields are required and adds no format, casing, or ID-prefix detail beyond what the schema 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 ('Check') and resource ('payment and delivery status of an order'), clearly distinct from siblings like create_order, compare_prices, or list_plans. It stops short of 5 because it never explicitly contrasts itself with the one sibling an agent might confuse it with (create_order), though the schema field description does that implicitly.

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 states the precondition ('Requires both order_id and the email used for the order'), which is real usage guidance, but it never says when to reach for this tool versus alternatives or what happens if the pair doesn't match. Usage is implied (post-purchase lookup) 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: the search is bounded to destinations eSIM SOS actually sells (a meaningful scope constraint) and it discloses the return format (country codes). It does not cover miss/ambiguity behavior, but that is a minor gap against the annotation coverage.

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 capability and input forms come first, and the downstream consumer (list_plans) is placed at the end where it belongs.

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 a single parameter and no output schema, the description carries return-value disclosure itself, and it does ('Returns country codes'). An agent has everything needed to call it, though behavior on no-match or ambiguous names 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 100% and the schema example ("Turkey", "Турция", "TR") already demonstrates name and ISO-code input. The description's 'name in English or Russian, or by ISO code' largely restates the schema, adding only marginal clarification, 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 (find) plus resource (travel destination/country) and narrows the scope to destinations sold by eSIM SOS. It also says exactly what comes out — country codes — and routes the agent to list_plans, so it is distinguishable from siblings 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?

The workflow is made explicit: this is the lookup step that produces the country codes list_plans consumes. There are no exclusions or 'use X instead' statements, but the context for when to reach for it is clear.

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