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

With no annotations, the description carries full burden and does so: discloses "Nothing is charged — a zero-amount Stripe setup, no charge and no authorization hold," explains the two-step token flow, and states restrictions on payment_method_id (only for cards already enrolled).

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?

Every sentence earns its place: the description is dense but logically ordered, covering outcome, safety, call flow, alternate path, and exclusions without fluff. It is front-loaded with the primary purpose.

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 no output schema, the description explains return values (setup_url, setup_session_id, token) and covers edge cases (headless, re-issue, exclusion of billing account). Given the complexity of a multi-step authentication flow, this is complete and actionable.

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?

Although schema coverage is 100%, the description adds significant meaning beyond schema: card_token is the headless path, setup_session_id comes from a previous call, and payment_method_id is only for re-issuing tokens for already enrolled cards. This clarifies usage context not present in 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?

The description opens with a specific verb+resource+outcome: "Get a LetsFG token by putting a payment method on file." It clearly distinguishes from the sibling tool setup_payment by explicitly stating "Do not use setup_payment for this."

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 explicit step-by-step usage: first call with no arguments, then call again with setup_session_id, or use card_token for headless enrollment. Also gives a clear exclusion: "This does NOT create a Developer API billing account. Do not use setup_payment for this."

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?

With no annotations, the description carries the full burden and excels. It discloses charges ('nothing from LetsFG'), the two result variants (success with order_id, incomplete with booking_url), and warns that incomplete is a normal, non-retryable outcome. It also requires 'REAL passenger details' and explains why (names match passport, email receives e-ticket), providing safety context not inferable from 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?

The description is compact (~130 words) and uses labeled sections (FLOW, CHARGES, RESULT, SAFETY) to front-load critical information. Every sentence earns its place, with no filler or repetition of schema content.

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?

It covers flow, charges, result handling, and safety requirements. The result handling for incomplete bookings is exactly the kind of edge-case detail an agent needs, and the absence of an output schema is compensated by explicit example JSONs. No significant gaps remain for the agent to execute the booking safely and 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 the baseline is 3. The description adds meaningful context: 'passengers with id from search' ties params to search_flights output, and 'names must match passport' clarifies the given_name/family_name fields while 'email receives the e-ticket' explains contact_email/passenger email purpose. This elevates it above baseline, though the description does not systematically walk through each parameter.

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 opens with a clear verb+resource: 'Book a flight from a search result.' The FLOW line positions it as the final step after search_flights, distinguishing it from related tools like book_hotel and unlock_flight_offer. The purpose is unambiguous and 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?

The FLOW explicitly states the sequence authenticate -> search_flights -> book_flight, giving clear when-to-use context. The RESULT section provides a critical 'when not to' instruction: if booked:false, do not retry but pass the booking_url to the user. This is explicit behavioral guidance beyond simple prerequisites.

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?

With no annotations, the description carries full transparency burden and succeeds. It discloses the 10% non-refundable fee, immediate charge, pay link for balance, return of booking_job_id instead of a confirmed booking, polling requirement, declined-card behavior, and non-idempotency. This is exceptionally transparent.

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 description is well-structured with each paragraph serving a distinct purpose: the action and fees, the return/polling behavior, the declined-card case, and the idempotency warning. Every sentence carries essential information with zero fluff, and the most critical detail (booking one rate) 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?

The description covers the core needed information: payment flow, asynchronous processing, return value, polling, error/decline behavior, and non-idempotency. It does not elaborate on possible failure modes (e.g., rate changes, unavailability) but for a booking initiation tool, the provided context is largely sufficient.

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 65%, so the description partially compensates by emphasizing that expected_price and expected_balance must be sent exactly as returned from search. Other parameters rely on their names or schema descriptions, and while most are self-explanatory, the description doesn't add additional meaning beyond a couple of key fields.

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 clearly states the primary action 'Book one hotel rate' and goes beyond to explain the booking flow, distinguishing it from sibling tools such as book_flight and get_hotel_booking. The resource and verb are specific, and the scope is unmistakable.

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 provides clear usage context: send back expected_price and expected_balance from search results, and poll get_hotel_booking for status. It explicitly warns against repeated calls with 'NOT idempotent.' However, it does not explicitly mention alternative tools by name for contrast, though the distinction is implicit.

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?

With no annotations, the description fully discloses key behaviors: the non-refundable 10% fee, the operation taking over a minute, and the critical timeout guidance to not assume failure. This goes well beyond basic mutation notice and offers actionable operational cautions.

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 well-structured sentences: the first states purpose and the cost condition, the second covers fees and timeout behavior. Every sentence provides critical information without redundancy or 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?

For a cancellation tool with one parameter and no output schema, the description covers essential decision factors (cost, timing, non-refundable fee) and operational handling (timeout, re-check). It is sufficient for an agent to invoke 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?

The schema already fully describes the single 'confirmation' parameter as 'From the completed booking' (100% coverage). The description adds no additional meaning about the parameter itself, so the baseline of 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 opens with 'Release a hotel reservation,' a specific verb+resource phrase that clearly identifies the tool's function. It distinguishes itself from siblings like book_hotel and get_hotel_booking by focusing on the cancellation/release action, leaving no ambiguity.

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 provides clear contextual timing: 'Free until balance_due_by; after that the hotel's own ladder applies and can reach 100%.' It advises checking cost first. However, it does not explicitly name alternative tools for checking terms, so it misses the bar for explicit alternatives.

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?

With no annotations, the description carries the burden of disclosing behavior. It states read-only, requires an API key, and explains the PFS token limitation—unexpected behavior that is valuable. It doesn't cover rate limits or error cases, but for a simple getter this is adequate.

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 primary purpose, followed by crucial usage caveats. Every sentence adds value with no 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?

For a zero-parameter, read-only endpoint with no output schema, the description provides the essential context: what it returns (profile, balance, usage stats), auth requirements, and the PFS token edge case. It lacks explicit error behavior but otherwise is complete.

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 are zero parameters, and the schema covers 100% of them trivially. The description adds meaningful auth context (LETSFG_API_KEY) that is not in the schema, which is helpful for correct invocation. Baseline 4 for zero-parameter tools 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 clearly states the tool fetches agent profile, balance, and usage stats with a specific verb and resource. It also distinguishes from sibling tools by explicitly noting PFS bearer tokens have no profile, making the tool's scope clear.

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 explicit context: it is 'Developer API only', requires LETSFG_API_KEY, and clarifies when not to use it (PFS bearer token users). It doesn't name an alternative tool, but the context is sufficient for an agent to decide when to call 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?

No annotations are provided, so the description carries full responsibility. It discloses that the tool is 'Read-only and safe to repeat', describes the three possible statuses ('in_progress, succeeded or failed'), and lists successful return fields. This is substantial, though it doesn't cover failure handling 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?

The description is two sentences, tightly structured. The first sentence states the core purpose and polling frequency; the second summarizes status values and success output. Every word earns its place with no 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?

For a single-parameter polling tool with no output schema, the description provides the essential workflow: when to use it (after book_hotel), how to poll (20s intervals), what statuses to expect, and what a successful result contains. It could mention explicit failure behavior, but the read-only, repeatable nature and sibling cancel_hotel_booking cover most gaps.

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 input schema already provides 100% coverage with 'booking_job_id' described as 'From book_hotel'. The description reinforces the context by referencing book_hotel, but adds no additional semantics beyond what the schema states. 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 clearly states the tool's purpose: 'Collect the result of a booking started with book_hotel.' This specifies a verb (collect), a resource (booking result), and ties it to a specific predecessor tool, distinguishing it from siblings like book_hotel and cancel_hotel_booking.

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 explicitly ties usage to book_hotel ('started with book_hotel') and provides concrete polling guidance ('Poll every ~20s'). It implies the sequential workflow and repeatability, though it doesn't explicitly state when not to use it or mention alternatives.

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?

No annotations are provided, so the description carries full burden. It states the tool loads a guide (read behavior) but does not disclose the return format (e.g., plain text, structured JSON) or any potential side effects. For a simple loader, this is adequate but lacks some 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?

The description is extremely concise with two sentences. The key action and context are front-loaded, and every sentence adds value without 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?

For a documentation-loading tool with no parameters, output schema, or complex behavior, the description is mostly complete. It could mention that the guide is returned in the response, but the purpose and usage are well covered.

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 has zero parameters, so per guidelines the baseline score is 4. The schema coverage is trivially 100%, and the description adds no parameter information as none are needed.

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 explicitly states it loads the LetsFG workflow guide, specifying the content areas (booking flow, pricing, rules, error handling). It clearly identifies the verb-resource pair and distinguishes from sibling tools like book_flight or search_flights.

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 provides explicit guidance: call once at conversation start, and clarifies that clients with MCP resource support get this automatically, so the tool is for those without. This offers clear when-to-use and when-not-to-use 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?

With no annotations provided, the description carries the burden and discloses that the operation is read-only and safe to repeat. It also implies multiple results by referencing 'the first result,' which adds useful behavioral context beyond 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?

The description is three sentences, front-loaded with the main purpose and includes actionable instructions on using the result, with no wasted words.

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 tool with no output schema, the description is thorough: it states what the tool does, when to call it, that it is safe, and how to interpret the response. This makes it complete for agent use.

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 schema already describes the 'text' parameter as a place name with 100% coverage, so the description adds little new information. It reiterates 'place name' and 'city name' without adding format or additional constraints.

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 clearly states the tool converts a place name to the supplier city id needed by search_hotels, using a specific verb and resource. It also distinguishes from siblings by positioning it as a prerequisite for search_hotels.

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 explicitly says 'Always call this first if you only have a city name,' providing a clear when-to-use condition. However, it does not mention alternatives or when not to use it, such as when the city ID is already known.

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?

With no annotations provided, the description carries full burden and explicitly states 'Read-only, safe to call multiple times', clearly indicating no side effects and idempotency.

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 description is two sentences, no redundant words. The purpose is stated first, followed by usage guidance. It is concise and 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?

Given the tool's simplicity (one parameter, no output schema), the description fully covers its purpose and usage context. It also explains its relationship to sibling tools, making it complete.

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% with a clear description for the query parameter. The description adds context by specifying the output (IATA codes) and reiterating the parameter's purpose, adding value 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?

The description clearly states the tool converts a city/airport name to IATA codes, using a specific verb ('Convert') and resource. It also distinguishes itself from sibling tools by explicitly recommending it as a prerequisite for search_flights.

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 explicitly says 'Always call before search_flights if you only have a city name', providing clear when-to-use guidance. It also notes it is read-only and safe to call multiple times, further guiding usage.

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?

With no annotations provided, the description fully discloses critical behavioral traits: 'completely FREE, unlimited, read-only' covers cost, rate, and side effects; 'async (60-90s)' reveals latency and automatic polling; 'Requires LETSFG_BEARER_TOKEN or LETSFG_API_KEY' exposes authentication needs. This goes far beyond what annotations would provide and is highly transparent for an agent.

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 description is only four sentences, with the core purpose in the first sentence and no fluff. Each subsequent sentence adds distinct value: output contents, async behavior, and authentication/workflow. The structure is front-loaded and efficient, with every sentence earning 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?

Given the complexity of 11 parameters and no output schema, the description provides a solid overview: it states the tool is a read-only flight search, returns structured offers with key fields, is async with automatic polling, and requires authentication. It doesn't detail all possible filters or error conditions, but it points to a guide resource for the full workflow, making it sufficiently complete for most uses.

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 main description does not add parameter-level detail beyond mentioning that the output includes prices, airlines, times, durations, and stopovers. It doesn't clarify any parameter semantics that the schema doesn't already cover, so the description's contribution is minimal.

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 opens with 'Search hundreds of airlines for live flight prices,' which is a specific verb+resource combination that clearly states the tool's function. It also explicitly adds 'read-only' to distinguish itself from booking/unlocking siblings like book_flight and unlock_flight_offer, making the purpose 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?

The description provides clear context for when to use this tool by stating it is part of an 'authenticate->search->book' workflow and by emphasizing its read-only nature. It doesn't explicitly mention alternatives, but the workflow and 'read-only' hint at its role as the search step. It also notes required authentication, which is a prerequisite for use.

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?

With no annotations, the description carries the full burden and does so thoroughly: it discloses side effects (opening a real session), prerequisites (payment method), rate filters (free-cancellation, pay-later), result-set size, what the price represents, and the necessity of retaining identifiers for booking. This goes well beyond the schema and gives the agent essential operational knowledge.

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 description is concise and well-structured, with each sentence adding distinct information: purpose first, then prerequisites, then behavioral details and linkage to the booking step. No redundancy or filler, and the length is appropriate for the complexity of the tool.

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?

Given the absence of annotations and an output schema, the description effectively covers prerequisites, side effects, performance expectations, and how the result connects to book_hotel. It clearly sets expectations for the agent, including the need to preserve identifiers and the fact that the search may take minutes. This is complete for the tool's purpose.

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 input schema already provides descriptions for all nine parameters, achieving 100% coverage. The description does not add meaning to the parameters themselves; it mentions output fields like price and session_id, which are outside the input schema. Therefore, a baseline 3 is appropriate, as the schema does the heavy lifting and the description offers no additional parameter-level insight.

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 opens with 'Search real, bookable hotel inventory,' which uses a specific verb and resource. It also clarifies the scoping to free-cancellation, pay-later rates and explicitly notes the result set is smaller than a metasearch, distinguishing it from broader hotel search tools and the sibling search_flights.

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 clearly states the prerequisite of a payment method on file and that this applies to search because a session is opened at the supplier. It also advises preserving session_id and combination_id_v2 for the subsequent book_hotel call and warns about the multi-minute duration, giving the agent explicit context for when this tool should be used.

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?

With no annotations, the description carries the burden of behavioral disclosure. It reveals the potential side effect of creating unnecessary billing accounts, the refusal behavior without LETSFG_API_KEY, and the paid-account implication. It stops short of describing success/failure responses or idempotency, but for a simple payment setup this is substantive disclosure.

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 description is a single compact sentence with a bracketed warning upfront. It packs purpose, target audience, prerequisite, refusal behavior, and rationale without any filler or repetition.

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?

The description covers purpose, audience, and prerequisite with strong warning context. However, the schema lists both parameters as optional and the description doesn't clarify whether the agent must provide at least one of them, which is a meaningful gap for correct invocation. Still, given the simple scope and explicit routing to `authenticate`, this is a minimally viable description with clear gaps.

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?

Input schema descriptions already cover both `token` and `payment_method_id` (100% coverage), so the baseline is 3. The description adds no extra meaning about when to use one parameter over the other or whether at least one is required, which is a missed opportunity but not a penalty below baseline.

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 uses a specific verb ('attaches') and names the exact resource ('card to a PAID prepaid Developer API account'), making the tool's function immediately clear. It also distinguishes itself from sibling authenticate by explicitly warning 'you almost certainly want `authenticate` instead'.

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 explicitly states this is 'Developer API only' and directs users to `authenticate` as the usual alternative. It also discloses a hard prerequisite (LETSFG_API_KEY must be set) and explains why the tool refuses to run, which gives clear when-to-use vs when-not-to-use 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?

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses auth requirements ('requires LETSFG_API_KEY', 'refuses to run on a Bearer token'), potential failure mode ('calling it that way used to 404'), cost ('1% of ticket price (min $3)'), and idempotency ('Not idempotent'). This significantly exceeds basic expectations for a mutation tool without annotations.

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 description front-loads the purpose and then provides necessary details in a structured way. While it is longer than the TDQS 4.3 example, every sentence adds value (auth, cost, idempotency, alternatives). The historical note about the 404 is slightly extraneous but not wasteful, so it remains appropriately concise.

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?

The tool has one simple parameter, no output schema, and no annotations. Despite this, the description covers purpose, usage alternatives, auth constraints, cost, and idempotency. It is fully self-contained and gives an agent everything needed to decide whether and how to invoke the tool. No gaps are evident.

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 for the single parameter offer_id is 100%, and the schema already provides a clear description ('Offer ID from search results (off_xxx)'). The tool description does not add any additional meaning beyond referring to the offer. Per the rubric, high schema coverage yields a baseline of 3, and the description does not elevate it.

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 clearly states the tool's function: 'Confirm live price with the airline and reserve the offer for 30 minutes.' It uses specific verbs and identifies the resource (flight offer), and explicitly distinguishes itself from book_flight by stating 'NOT part of the agent flow and NOT needed before book_flight.' This fully clarifies what the tool does and how it differs from siblings.

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 explicit when-not-to-use guidance: 'NOT part of the agent flow' and 'If you authenticated with `letsfg auth`, go straight from search_flights to book_flight.' It also specifies the required auth context (LETSFG_API_KEY vs Bearer token) and provides an alternative (book_flight directly). This is exemplary usage guidance.

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