nomadpoint

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

Annotations already indicate a write operation (readOnlyHint: false) and non-destructive behavior (destructiveHint: false). The description adds meaningful beyond-annotation context by noting the tool works without a scan and, crucially, that it also adds the country to the user's nationalities—an important side effect for visa computations. This goes beyond the basic write/read flags, though it doesn't cover all possible behaviors like duplicate handling.

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, each contributing essential information: the primary action and the key side effect. There is no fluff or redundant restatement of the tool name, making it highly concise and well-structured.

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 conveys the core action and an important side effect, but given there is no output schema and only partial parameter documentation, it leaves gaps about return values, parameter usage, and edge cases. It's adequate for a straightforward create operation but not fully complete for an agent to understand all consequences.

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

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

Schema coverage is only 33% (only issue_date and expiry_date have descriptions), and the description does not mention any parameters by name or explain their semantics. The phrase 'from its details alone' is vague and does not help an agent understand required vs optional fields or what each parameter represents. With low schema coverage, the description was expected to compensate but did not.

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 records a passport from details alone, which is a specific verb and resource. It distinguishes from potential scan-based workflows by adding '(no scan needed)' and highlights the side effect of adding the country to nationalities. However, it doesn't explicitly differentiate from sibling create_* tools beyond the resource type, so it's clear but not maximally distinguishing.

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 implies usage when passport details are available and no scan is required, but it doesn't explicitly state when not to use it or name alternative tools. The side-effect note ('adds the country to the user's nationalities') provides some cautionary context, but there's no direct comparison to other tools like create_visa or update_* functions.

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 are minimal and do not describe behavior beyond non-read-only status. The description adds only that the accommodation is 'booked' and is a 'place to stay,' but it does not disclose important behavioral aspects such as required prerequisites (e.g., journey existence), failure modes, or how the created record behaves for the trip.

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, front-loaded sentence with no wasted words. It would benefit from more detail given the tool's complexity, but as far as conciseness and structure, it is efficient and readable.

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 tool with 17 parameters, low schema coverage, and no output schema, this description is too thin to fully orient an agent. It omits required-field context, relationships to sibling tools, and any sense of expected outcome or constraints.

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 low at 41%, so the description should compensate by explaining parameter meaning, but it does not. The type examples overlap with the schema's type enum, and the description gives no additional semantics for the 17 parameters or the two required 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 action ('Add') and resource ('booked place to stay ... to a trip'), with type examples (hotel/hostel/apartment). However, it does not distinguish create_accommodation from the sibling create_stay, so the tool's unique role among siblings remains unclear.

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 guidance is provided about when to use this tool versus create_stay or the other creation tools. The word 'booked' implies a post-booking context, but no explicit when-to-use or when-not-to-use scenarios are given.

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 indicate a non-read-only, non-idempotent write operation. The description says 'Add', which aligns with creating a new entity. However, it does not mention potential side effects (e.g., required fields beyond journey_id and title, validation rules, or linkage to journeys/stops). The annotations cover the basic safety profile, but the description adds little beyond the action itself.

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, concise sentence with no redundant information. It efficiently conveys the core function without unnecessary elaboration, making it easy for an agent to parse.

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 complexity (18 parameters, dual purpose), the description is under-specified. It does not explain the difference between an activity and a travel leg, nor does it mention required vs. optional fields beyond what's in the schema. There is no indication of return values, errors, or integration with journeys, limiting the agent's ability to use the tool effectively.

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 has many fields (18), and only a few have descriptions (stay_id, travelers, start_datetime, end_datetime, transport_mode). The description does not clarify the purpose of most parameters (e.g., emoji, price, category, currency, booking_url, place_name, country_code). It provides a high-level hint about 'thing to do' or 'travel leg' but fails to explain which parameters are relevant for each case, leaving significant ambiguity.

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: adding a 'thing to do' or a 'travel leg' to a trip, optionally attached to a stop. This distinguishes it from sibling creation tools (e.g., create_accommodation) which serve different entity types. The mention of 'travel leg between places' adds specificity about one of its dual use cases.

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 implies usage for activities and travel legs but does not explicitly state when to choose this tool over alternatives. It lacks guidance on scenarios such as when to attach to a stop or how to differentiate between activity and travel leg inputs. The sibling tool names provide context, but the description itself does not offer clear selection criteria.

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 are minimal (readOnlyHint=false, etc.) and the description carries the burden. It discloses that doing both double-counts, that a source_ref makes a re-run idempotent, and that setting amount_usd to a guessed historical rate freezes it forever (while omitting it lets the app use the honest live rate). This adds real behavioral context beyond the schema and annotations, with no contradictions.

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, well-structured paragraph that front-loads the core purpose, then gives the key usage rule, then the source_ref caveat. Every sentence earns its place — no fluff or redundancy. The warning about double-counting is placed early where it matters.

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 create tool with 10 parameters and no output schema, the description covers all critical nuances: when to use vs. siblings, how attribution works (omitting stay_id lets the date determine the stop), the amount_usd honesty rule, and idempotency via source_ref. Nothing essential is missing, and the high schema coverage fills in the rest.

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 90%, so most parameters are documented. The description adds semantics for amount (total actually paid, not deposit or per-night rate), amount_usd (only set when source states a USD figure, else omit), and source_ref (unique per user, repeat import refused). It clarifies a few non-obvious fields without repeating the schema, which is above the baseline for high coverage.

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 'Record one thing the user spent money on' — a specific verb and resource. It immediately scopes the tool to spend with no itinerary item of its own and distinguishes it from the update_flight/update_accommodation/update_activity siblings, so an agent can tell them apart without examining schemas.

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 states when to use this tool (spend that isn't already on the itinerary) and when not to (if the purchase is already on the itinerary, use the update_* tools, and warns that doing both counts it twice). It also mentions passing source_ref for imports to prevent duplicates — clear, actionable guidance with an explicit alternative.

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?

The description 'Add a flight' implies a write operation, consistent with the annotations (readOnlyHint=false). However, it adds no information about side effects, permissions, rate limits, or validation behavior beyond what annotations already hint. No contradictions exist.

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 and does not waste words. However, its brevity borders on under-specification, lacking essential details for a tool with nearly 20 parameters.

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 complexity (19 params, 4 required, no output schema), the description is woefully incomplete. It does not explain how to use the fields, what constitutes a valid request, or what the response might look like, leaving significant gaps for an agent.

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 description provides no explanation of parameters. While some parameters have descriptions inline in the schema (e.g., departure_airport_code explains IATA codes), the description itself adds no value to understanding the 19 parameters or their relationships.

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 action of adding a flight to a trip, which is a specific verb and resource. It distinguishes from sibling tools like creating activities or accommodations, though it could be more explicit about what constitutes a flight.

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 guidance is provided on when to use this tool versus alternatives such as update_flight or delete_flight, or any contextual scenarios. The description lacks any indication of prerequisites or typical usage cases.

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?

The annotations indicate a write operation (readOnlyHint false) and no destructive flags, but the description does not elaborate on side effects, permissions, or idempotency. Since annotations are present, the bar is lower, but the description adds minimal behavioral context beyond saying it creates a new trip, so a neutral score is appropriate.

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 short sentences with no redundant or unnecessary information. It is well-structured and to the point, making it easy for an agent to parse and act upon quickly.

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 provides sufficient context for a simple creation tool, including when to use it and what it accomplishes. It does not explain return values or error handling, but given the lack of an output schema and the straightforward nature of a create operation, the description is largely 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 50% (start_date and end_date have descriptions, name and description do not). The tool description does not mention any parameters or provide additional meaning beyond the schema. Since coverage is not below 50%, a baseline score of 3 is applied.

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 creates a new trip (journey), using the verb 'start' and resource 'trip'. It also distinguishes this action from adding to an existing trip, which sets it apart from potential alternatives like updating or extending a journey.

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 indicates when to use the tool: when the user wants a separate trip rather than adding to an existing one. This provides clear guidance versus other tools that might modify or extend existing journeys, and it's concise and directly actionable.

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 are all false/noisy (readOnlyHint=false, destructiveHint=false, etc.), so they provide little signal; the description carries the burden and adds useful workflow context by clarifying the conceptual difference between a stay and accommodation. The only gap is not describing what happens on duplicate calls or how the stay relates to check-in/checkout dates, but since annotations don't declare idempotency or safety, there's no contradiction and the description does enough.

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 dense sentences, zero wasted words. The em-dash aside is genuinely useful, not decorative, and the pointer to create_accommodation serves double duty as both usage guidance and differentiation. Every phrase 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 create tool with 9 params, no enums, no nested objects, and no output schema (so nothing to describe about return values), the description covers the essential workflow context well. It fully explains the conceptual model needed to use the tool correctly. Slightly more emphasis on preconditions (e.g., does the trip need to exist? what happens with overlapping stays?) would push it to a 5, but the current coverage is solid.

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 67% (6/9 params documented), just under the 80% threshold for a baseline-3. The description itself contributes no parameter-level semantics, and the undocumented params (journey_id, notes, checkout_flexible) are relatively self-explanatory. The description stays within its lane — neither helping nor hurting — landing at a solid 3 for acceptable-but-unremarkable parameter support.

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?

Uses a specific verb-resource pair ('Add a stay...to a trip') and immediately clarifies the domain meaning with the parenthetical 'a stop in a city'. It distinguishes itself from its closest sibling (create_accommodation) by explaining that a stay gets a destination onto the itinerary, which is exactly the kind of scoping the rubric rewards.

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 positions the tool within the workflow ('This is how a destination gets onto the itinerary') and names the exact alternative ('book lodging for it with create_accommodation on the same dates'). This tells the agent when to use this tool versus the confusable sibling, and even implies a temporal relationship between the two calls.

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?

The annotations already establish that this is a write operation, non-idempotent, and non-destructive. The description adds little beyond that: it does not describe duplicate behavior, persistence effects, required ownership, status implications, or what happens after creation.

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, clear, front-loaded sentence with no filler. It efficiently communicates the basic purpose, and any missing detail is a completeness issue rather than a conciseness issue.

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 tool with 14 parameters, only 2 required, and no output schema, this description is too thin. It does not explain which parameters belong to held visas versus applied-for visas, how entries and costs relate, or how the tool should be invoked correctly in different scenarios.

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 only 36% and the tool description does not mention any parameter names, required fields, formats, or relationships. It does not compensate for underspecified fields like max_entries, entries_allowed, cost_paid, cost_currency, or passport_country_code.

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 what the tool does: it records a visa the user holds or has applied for. It is specific enough to distinguish from non-visa tools like add_passport or create_flight, but it does not explicitly contrast with update_visa or delete_visa, so it stops 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?

No when-to-use guidance is given relative to sibling tools such as update_visa, delete_visa, or list_visas. The phrase 'holds or has applied for' gives useful context but does not explain when an agent should choose create_visa instead of another tool.

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?

The annotation sets 'destructiveHint' to true, and the description says 'Remove', which implies a destructive operation. However, there is no statement about whether the action is reversible, permanent, or has side effects on other trip data. The absence of such details reduces transparency for a delete operation.

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 to the point, consisting of a single clear sentence. It avoids unnecessary verbosity, making it easy to read. However, it could be structured to include more details without losing conciseness, but overall it is appropriately brief for a simple delete action.

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 provides minimal context: it mentions 'the trip', implying a travel-planning domain, but does not clarify the relationship between the accommodation and the trip, or what happens after deletion. There is no output schema, and the parameter's format is unspecified, leaving a significant completeness gap.

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 'accommodation_id' is not described in the schema (0% coverage), and the description only refers to 'a booking' without explaining that this ID is required. While the parameter name is self-explanatory, the description does not explicitly map it to the booking, leaving room for ambiguity about what exactly is removed.

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 action ('Remove') and the object ('a booking from the trip'), which unambiguously conveys that this tool deletes an accommodation booking. The tool name 'delete_accommodation' reinforces this intent, so there is no confusion about the tool's purpose.

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 no guidance on when to use this tool, what prerequisites exist (e.g., the booking must already be added to the trip), or what the effect is on the overall trip plan. It is a bare statement of action, leaving the user without context on how or when to invoke 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 indicate destructiveHint=true and readOnlyHint=false, so the agent knows it's a destructive operation. The description adds the scope (an activity from a trip) but does not disclose side effects like cascading deletions or irreversibility beyond the annotation's implication. Given the strong annotation coverage, 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?

The description is a single sentence, highly concise, and front-loaded with the action. Every word is necessary and provides clear meaning. There is no verbosity or 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?

Given the simplicity of the tool (one parameter, no output schema, no nested objects), the description is sufficiently complete. It states the action and the resource. It could mention that the deletion is permanent or that the activity must exist, but the annotation (destructiveHint) covers the destructive nature. Overall, it meets the needs for a simple delete operation.

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

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

Schema description coverage is 0%, but the tool has only one parameter (activity_id). The description implicitly conveys that the parameter is the identifier of the activity to delete, but it does not explicitly state the format or source. Since the schema provides the name and type, and the tool's purpose is clear, the description adds enough context for a single simple 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 'Remove an activity from the trip.' clearly specifies the action (remove) and the resource (activity from a trip). It is distinct from sibling tools like delete_accommodation or update_activity, so the agent can easily identify what this tool does.

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 implies when to use the tool: when you need to remove an activity from a trip. It does not explicitly state when not to use it or mention alternatives (e.g., for deleting other resources). However, the context is clear enough for a simple delete operation.

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 mark this as destructive (destructiveHint: true). The description adds no additional behavioral context (e.g., permanence, cascading effects, permissions). Since the bar is lower with annotations present, it still earns only a 2 because it adds nothing beyond the name and annotation.

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, concise sentence with no fluff. It is well-structured 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?

For a destructive operation with a single parameter, the description is too minimal. It does not clarify what constitutes a 'travel document' (visa? passport?) or whether this overlaps with delete_visa. It lacks any indication of the deletion's permanence or side effects. Given no output schema, more detail is needed.

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 0% and the description fails to explain the document_id parameter. There is no mention of how to obtain it, its format, or that it should reference a document from list_documents. The description provides zero additional meaning beyond the parameter name.

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 verb (Delete) and resource (user's travel documents). It distinguishes from sibling delete_* tools by focusing on 'travel documents', though it does not specify which types (e.g., passport vs. visa) are included. This is a clear but not fully specific purpose.

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 no guidance on when to use this tool versus alternatives like delete_visa or delete_accommodation. It does not specify exclusions or context for when this should be preferred.

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 mark the tool as destructive (destructiveHint: true) and not read-only (readOnlyHint: false). The description adds the specific detail that the action is 'Irreversible', which is a behavioral trait beyond the general destructive hint. This warns the agent that deletion cannot be undone, providing valuable context for decision-making.

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 at two short sentences: 'Remove a recorded expense. Irreversible.' It states the core action first, then adds a critical warning. Every word earns its place, with no fluff or 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 simple tool with one parameter and no output schema, the description covers the essential information: what it does and that it is irreversible. It does not mention what happens if the expense does not exist, permission requirements, or side effects, but these are not strictly necessary for calling the tool correctly. The minimal nature of the tool makes this adequate, though it could have mentioned the parameter explicitly.

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 has a single required parameter, expense_id (string), but schema description coverage is 0%. The description does not explain what expense_id is or how to obtain it. Since the description must compensate for the lack of schema documentation, and it provides no parameter guidance, this is a significant gap. The parameter name is self-explanatory, but the description adds no value in explaining its semantics or usage.

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 action: 'Remove a recorded expense.' It identifies the resource (expense) and the operation (remove/delete), distinguishing it from sibling tools like create_expense, update_expense, and list_expenses. The verb 'Remove' is specific and 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 implicitly communicates when to use this tool (when an expense needs to be permanently deleted). It includes the explicit warning 'Irreversible', which conveys that this is a permanent action and not to be used for temporary changes. While there is no explicit mention of alternatives, the tool's name and sibling set make its purpose clear. It provides enough context without needing exclusions.

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 destructiveHint: true, so the description's 'Remove' is consistent. However, it adds no extra behavioral context beyond what annotations provide (e.g., irreversibility, impact on related data). The description is adequate but not enhanced.

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, concise sentence with no redundancy. It is front-loaded with the verb and object, and every word is necessary.

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) and that annotations cover the destructive nature, the description is minimally complete. However, it could mention that the operation is permanent or that the flight must exist, though not strictly required. It is adequate but lacks any extra context.

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

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

Schema description coverage is 0%. The description does not mention the flight_id parameter or its purpose. Although the parameter name is self-explanatory, the description fails to compensate for the lack of schema coverage, leaving the agent to infer the identifier's role.

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 'Remove a flight from the trip' clearly states the action (remove) and the resource (flight) within the trip context. It is specific and distinguishes from sibling delete tools for other entities.

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 the purpose but no explicit guidance on when to use this tool vs alternatives or any prerequisites. The context (deleting a flight) is implied but no exclusions or alternative references are provided.

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 indicate destructiveHint=true and readOnlyHint=false, but the description goes further by detailing the exact consequences: it deletes stops, flights, bookings, activities, and affects every member. It also adds 'Irreversible' and 'Owner only' which are not in annotations. This provides substantial behavioral context beyond the structured data, warning agents about the permanent and broad impact.

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, perfectly concise. The first sentence states the core function and scope, the second adds permissions and a warning. No redundant words or filler. It is front-loaded with the most critical information and earns every word.

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 delete tool with one parameter and no output schema, the description covers all essential aspects: the exact effect (deletes the trip and all sub-items), the scope (for every member), the permission requirement (owner only), and the irreversibility with a confirm-first instruction. This is complete given the tool's simplicity and the presence of destructiveHint.

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 lists only journey_id as a string with no description, and the tool description has 0% schema coverage. However, the description mentions 'a trip' which implies that journey_id is the trip's identifier, adding some semantic context. It does not explicitly explain how to obtain the ID or format expectations, but for a single simple parameter, the implied meaning might be sufficient. Still, it falls short of fully documenting the parameter's purpose.

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: 'Permanently delete a trip and everything on it — stops, flights, bookings, activities — for every member.' It specifies the verb (delete), resource (trip), and scope (everything on it, for every member), and distinguishes it from sibling delete_* tools that target individual items. The inclusion of 'travel' and the specific list of sub-items makes it 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 usage context: 'Owner only' indicates who should use it, and 'Irreversible; confirm with the user first' gives a clear prerequisite. While it doesn't explicitly name alternatives like 'use delete_flight for a single flight' or 'use leave_journey to leave without deleting', the emphasis on 'everything on it' for every member implicitly contrasts with lighter deletion or leave options. This is strong but not fully explicit about 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?

The description adds the key behavioral trait: the tool refuses deletion if a booking is attached, suggesting the need to delete the booking first. This complements the destructiveHint annotation by clarifying the refusal condition, which is critical for the agent to avoid errors.

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 sentence with no wasteful words. It concisely states the action and the key condition, making it highly scannable 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 a single parameter, no output schema, and a straightforward mutation, the description covers the essential usage and a critical edge case. It is complete for the tool's complexity, though it doesn't mention other potential effects (e.g., cascading changes), which are not necessary based on the provided 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?

With schema description coverage at 0%, the description doesn't detail the stay_id parameter beyond the schema. However, the single parameter is self-explanatory: it identifies the stop to delete. No enums or nested objects exist, so minimal additional semantics are needed. 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 removes a stop from a trip, a specific verb and resource. It distinguishes from sibling delete tools targeting other entities (accommodation, activity, flight, etc.) and from update_stay.

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 implies usage for deleting stops and explicitly mentions when to use an alternative: 'delete the booking instead' when a booking exists. It lacks explicit exclusions for other scenarios, but the clear contrast with the booking deletion provides practical 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?

The annotations explicitly declare destructiveHint: true, and the description's 'Delete' is fully consistent with that, so there is no contradiction. However, beyond that alignment, the description discloses nothing additional — no mention of irreversibility, cascade effects on related journeys, or any confirmation behavior. Annotations already carry the safe-destructive profile, and the description adds no further behavioral color.

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, front-loaded sentence with zero filler — 'Delete a recorded visa.' Every word is purposeful and the statement is immediately scannable. The brevity is a genuine strength, and the structure could not reasonably be improved for this trivial delete operation.

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 minimally complex tool (one string parameter, no output schema, no enums), the description is close to sufficient — the destructiveness is covered by annotations and the purpose is clear. However, in the context of a travel-app domain (create_journey, list_visas, etc.), a note on whether deleting a visa cascades to journeys or whether it can be undone would materially improve completeness. The core use case is served, but edge-behavior questions remain unanswered.

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?

With 0% schema description coverage, the description carries the burden of explaining visa_id, but 'a recorded visa' is all it offers. It never explains that visa_id is an identifier, what format it follows, or where to obtain it (e.g., from list_visas). A single clarifying phrase like 'the ID returned by list_visas' would have turned this into a 4, but as-is the agent is left to infer the ID's provenance and type.

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 'Delete' as the verb and 'a recorded visa' as the resource, precisely matching the tool's name and unambiguously distinguishing it from the sibling delete_document, delete_flight, and delete_* tools targeting other entities. The word 'recorded' adds a small but meaningful scope qualifier, making the purpose crystal 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?

There is zero guidance on when to use this tool versus alternatives. No exclusions are provided (e.g., 'use this instead of update_visa to remove a visa'), no prerequisites are mentioned, and there is no pointer to related tools like list_visas for finding the visa_id. The description offers no context for the decision of when to invoke this tool.

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 idempotentHint=true, covering safety. The description adds behavioral nuances: 'if they set one' indicates conditional existence (possibly null/not found if unset), and 'no one else's is readable' discloses a privacy/permission boundary. These go beyond the annotations and inform the agent about expected behavior and authorization.

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, front-loaded with the core action, and wastes no words. It efficiently conveys the tool's purpose and key constraints 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 tool with one parameter, read-only annotations, and no output schema, the description covers the essential aspects: what it retrieves, that it's personal, conditional existence, and privacy. It doesn't specify the exact return format (e.g., whether it returns null when unset), but 'spending target' suggests a value, and the tool's simplicity makes it reasonably 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 description coverage is 0%, so the description carries the burden of explaining journey_id. The description mentions 'for a trip', which implicitly ties journey_id to the trip identifier, but it does not explicitly state the parameter's role or expected type. Given the simplicity, this indirect reference provides some meaning but not full compensation for the schema's lack of description.

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 what the tool does: it retrieves the user's own spending target for a trip. It also distinguishes from shared budgets by emphasizing 'Personal, not shared' and 'no one else's is readable', which differentiates it from any shared or other-member budget tools. This is a specific verb+resource with clear sibling 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?

The description provides context on when to use this tool: to get your own budget for a trip. It explicitly states that others' budgets are not readable, which implies a limitation and guides against using it for non-personal budgets. It does not explicitly name alternatives like set_budget, but the context is sufficient for an agent to understand the scoping and avoid misuse.

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 and idempotentHint, so the description adds value by specifying the result is 'based on their primary passport,' clarifying that output is user-specific. It does not disclose return format or edge cases, but the annotation coverage lowers the burden.

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, front-loaded sentence with no redundant words. Every phrase adds functional context, and the structure is perfectly scannable.

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 one-parameter lookup tool with strong annotations, the description sufficiently conveys the core output (country reference info and visa requirement). It doesn't enumerate what 'reference info' includes or behavior without a passport, but the simplicity and annotation support make it mostly 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 country_code already described as 'ISO country code, e.g. TH.' The description adds no additional parameter meaning, so baseline 3 applies without further credit.

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 provides country reference info and the user's visa requirement based on their primary passport. It distinguishes itself from siblings like get_visa_status and list_visas by focusing on country-level info tied to the user's passport, though it lacks an explicit verb like 'retrieve'.

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 implies usage: use this tool when you need country reference info or a visa requirement derived from the user's primary passport. However, it does not explicitly say when not to use it or mention alternatives, leaving room for confusion with similar sibling 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?

The description explains the return structure including the nuance of booked stays appearing in both lists, complementing the readOnly and idempotent annotations. No side effects are implied, and the closure is appropriate.

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, well-structured, and uses clear punctuation. It conveys essential information in two sentences without unnecessary verbosity.

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 main output components and the filtering capability, and the annotations handle safety aspects. It does not specify error handling or default behavior, but these are not critical for completeness given the tool's simplicity.

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 optional date parameters are clarified with their purpose, and journey_id is implicitly understood. The schema descriptions for dates are minimal, but the description adds meaningful context.

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 ('Get one journey's itinerary') and lists the included components (stays, flights, booked accommodations, activities), distinguishing it from sibling tools that operate on multiple journeys.

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 practical guidance on using date parameters ('Pass from_date/to_date to read one window of a long trip instead of all of it'), though it does not explicitly compare with alternatives like list_journeys.

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 the operation read-only and idempotent; the description adds a meaningful behavioral detail: anyone who opens the link joins immediately, and there is no separate acceptance step. This clarifies the practical impact of sharing the link without contradicting the 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 is a single focused sentence with no filler, restating none of the annotations. It front-loads the essential idea and adds one necessary behavioral nuance about the invitation flow.

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 simple single-parameter input, no output schema, and robust annotations, the description gives the agent key behavioral context (immediate join, no accept step) in an economical way. It still omits an explicit statement that the tool returns the link itself, but the purpose remains inferable from name and description.

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 only parameter, journey_id, has no schema description, and the description itself never explains what value to provide. The phrase 'onto a trip' loosely connects the share link to a journey, but with 0% schema coverage the description should compensate much more explicitly.

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 identifies the resource as the share/invite link for a trip and clarifies its role as a co-editor invitation. It relies on the tool name for the action verb ('get') and uses 'trip' instead of 'journey', so it stops just short of a fully explicit 'returns/retrieves' statement.

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 implies the use case: an agent needs the invite link to add a co-editor, and the link alone is sufficient since there is no separate accept step. It does not explicitly contrast this with sibling tools like list_journey_members or get_journey, so usage guidance remains inferred rather than prescriptive.

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 idempotentHint=true, so the description doesn't need to repeat that. It adds value by explaining what data is returned (profile, passports, documents) and why it matters ('which decide every visa answer'). This goes beyond the annotations by providing domain-specific context.

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, front-loaded with the core purpose, and every word earns its place. It's concise, informative, and well-structured.

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 (no parameters, no output schema), the description is complete. It explains what the tool returns and why it's important. The only minor gap is that it doesn't explicitly state the return format, but that's not necessary for a zero-parameter 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?

The tool has zero parameters, and the schema coverage is 100% (empty properties). The description doesn't need to explain parameters, but it does explain the output semantics (what the user gets). Since there are no parameters, a baseline of 4 is appropriate, and the description adds value by clarifying the content of the response.

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: to retrieve the user's profile, passports/nationalities, and passport documents. It uses a specific verb ('get') and resource ('me'), and distinguishes itself from siblings like get_country_info and get_visa_status by focusing on the user's identity data.

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: 'Worth reading before planning anything.' It implies this is a foundational tool to call before other actions, but it doesn't explicitly mention alternatives or when not to use it. However, given the tool's unique purpose, this is sufficient.

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?

The annotations already signal read-only and idempotent behavior, so the bar is lowered. The description adds context about the output (used and remaining days) without contradicting the annotations. No side effects are mentioned, but given the annotations, this is sufficient.

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, concise sentence that packs the essential information without any fluff. It is well-structured and immediately understandable.

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?

Since there is no output schema, the description explains what the tool returns (used and remaining days). It also gives a real-world use case. However, it omits details about error handling or edge cases, which might be acceptable for a simple read operation but leaves some context 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?

The schema has zero coverage for parameter descriptions. The description refers to 'a country' and 'this year' but does not explicitly connect them to the country_code and year parameters. It leaves the mapping implicit, which is insufficient for a tool with undocumented parameters.

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: to report used and remaining days of a visa allowance in a country, directly answering the question 'how much longer can I stay.' It is specific and distinct from sibling tools like get_country_info or get_journey.

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 implies when to use it (when needing visa allowance information) and provides a concrete use case. However, it does not explicitly contrast it with alternative tools or provide exclusion criteria, so it falls slightly short of 'explicit when/when-not' guidance.

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

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

Annotations already declare destructiveHint=true, covering the safety profile. The description adds a permission constraint (owners can't leave) which is useful context. However, it does not disclose side effects such as removal from the member list or potential failure conditions. Given the annotation coverage, this is adequate but not rich.

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, front-loaded sentence with a clarifying clause, conveying the essential action and a key exclusion with no wasted words. It is concise and well-structured.

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 tool with one parameter and no output schema, the description covers the core purpose and a critical restriction. It does not describe return values or failure modes, but these are less critical given the tool's simplicity and the presence of destructiveHint annotation. The description is complete enough for the agent to use the 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?

With 0% schema description coverage, the description must compensate. It does not explicitly define journey_id, but the tool name and purpose make it inferable as the ID of the shared trip. For a single simple parameter, this is acceptable, though more explicit documentation would improve clarity.

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 action (leave) and the resource (a trip shared by someone else), and explicitly distinguishes from deletion: 'Owners can't leave their own trip — they delete it.' This differentiates it from sibling tools like delete_journey and makes 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 a clear when-not by stating owners cannot use this tool and should delete instead. It implies when to use (when you are a non-owner of a shared trip) but does not explicitly mention alternative tools like remove_journey_member, though that tool is likely intended for owners to remove others. The guidance is solid but not exhaustive.

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 declare readOnlyHint=true and idempotentHint=true, which already communicate safety. The description adds that only metadata is returned, not files, providing behavioral context beyond what annotations cover. This is useful and does not contradict 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 is a single clear sentence that conveys the essential information without fluff. It is front-loaded and efficient, earning a top score.

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 list tool with good annotations and a well-described schema, the description is adequate. It clarifies the return scope (metadata not files) but does not explicitly state the output is a list, which is obvious from the context. No significant 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 schema includes a single optional parameter with a complete description of allowed values, giving 100% schema coverage. The tool description adds no extra meaning about the parameter, so the baseline score 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 clearly states the tool lists the user's travel documents (passports, visas, etc.) and specifies it returns metadata only, not files. This distinguishes it from sibling tools like add_passport or delete_document, 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 implies this is for retrieving document metadata, but does not explicitly contrast it with alternatives like creating or deleting documents. The context (metadata vs files) and the tool name make usage clear, though explicit alternatives are not 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, openWorldHint=false, and idempotentHint=true, so the description doesn't need to restate those. It adds valuable context beyond the annotations by clarifying the scope (recorded spending vs. booked prices) and the presence of source_ref, which helps set expectations about the data returned. No contradiction with 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 is two sentences with no filler. It promptly states the core distinction (recorded spending vs. booked prices) and then adds the source_ref detail. Every sentence earns its place, and the structure is clear and efficient.

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 it's a simple list tool with read-only annotations and no output schema requirement, the description covers the essential semantics: what data is returned and how it differs from related tools. It doesn't mention pagination or sorting, but those are minor for this context and not expected from the annotations or schema. Overall, the description is adequate for correct usage.

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 covers 67% of parameters with descriptions (to_date and from_date), and journey_id lacks a description but is self-explanatory from the tool name. The description adds no parameter-specific information, so it doesn't supplement what the schema already provides. Since coverage is moderate and the remaining parameter is obvious, a 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 precisely what the tool returns: recorded spending (hand-entered or imported), explicitly distinguishing it from booked prices on flights and hotels. It mentions the source_ref field, giving a clear and distinct purpose that differentiates it from get_journey and other tools.

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 on when to use this tool versus alternatives: it clarifies that booked prices come from get_journey, and mentions source_ref for importers to avoid re-importing. This effectively tells the agent when to choose this tool over siblings.

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?

The annotations indicate read-only and idempotent behavior, and the description does not contradict this. It adds a hint about the output fields (user ids, roles, profiles) but does not mention potential errors, rate limits, or other behavioral aspects. Since the tool is read-only, no side effects are expected, but the description could be clearer about the nature of the operation.

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, consisting of two short sentences without unnecessary jargon or repetition. It efficiently conveys the purpose and a key use case, fitting within the typical length for tool descriptions.

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 mentions the output fields (user ids, roles, profiles) but does not specify the structure (e.g., whether it's a list of objects) or any pagination or ordering. It also omits error scenarios or edge cases. For a simple listing tool, this may be sufficient, but it lacks full detail about the response format and limitations.

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 defines journey_id as a string but provides no description. The description does not explicitly explain what journey_id represents, though it is implied to be the identifier of the trip. There is no additional detail about format, constraints, or how to obtain it, leaving the parameter semantics under-specified.

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 that the tool lists who is on a trip, including user IDs, roles, and profiles. It also provides a specific use case for retrieving IDs needed by set_item_travellers, which adds some context. However, the phrasing is slightly vague ('who is on a trip' could be interpreted loosely) and could be more direct.

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 a specific scenario for using the tool (to get IDs for set_item_travellers) but does not explain when to choose this tool over other list tools like list_journeys or list_visas. It also lacks guidance on when not to use it, such as when only basic journey info is needed.

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 and idempotentHint, so the description does not need to repeat safety. It adds useful scope and output context ('they own or have joined, with dates and whether they own it'), but does not disclose additional behavior such as ordering, pagination, or what happens with an empty trip list.

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, well-structured sentence that immediately states the action, scope, and key output fields. It contains no filler or 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 simple, parameterless list tool, the description is fully complete: it identifies what is listed, whose journeys are included, and what information is returned. No output schema exists, but the description covers the essential return-value expectations at the appropriate level of detail.

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, and the schema already fully reflects this with an empty properties object. The description therefore has no parameter semantics to clarify, and a baseline of 4 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 uses a specific verb ('List') and identifies the resource ('the user's trips (journeys) they own or have joined'), plus the key output details (dates and ownership). This clearly distinguishes it from sibling tools like get_journey or list_journey_members.

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 implies the usage context: it is for listing all of the user's journeys rather than a single journey or members. However, it does not explicitly mention alternatives or provide exclusion guidance, so the usage guidance remains implicit rather than explicit.

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?

The readOnlyHint and idempotentHint annotations already cover behavioral safety. The description adds no extra information about side effects, data sources, or potential errors. It only confirms the scope (user holds), which is minimal added transparency.

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, concise sentence that lists the key attributes. It is efficiently written and avoids redundancy, though the dash-separated list feels slightly telegraphic. No unnecessary 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?

The description names the fields but does not specify the output structure (e.g., array of objects, ordering, or any filtering). Since there is no output schema, the description should ideally clarify the expected response format. It is partially complete but leaves some ambiguity.

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 no parameters, so there is nothing to describe. The absence of parameters is clear and requires no additional explanation. Perfect score.

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 that the tool lists visas the user holds and enumerates key fields (type, number, validity, entries used). This is specific enough to distinguish from create/update/delete operations, though it could be more explicit in saying 'list' or 'retrieve'.

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 explicit guidance is provided on when to use this tool. There is no mention of alternatives like get_visa_status or get_visa (if such exists), nor any context about querying a single visa vs. all visas. The description relies solely on the tool name for intent.

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?

The description adds 'Owner only,' a permission-based disclosure beyond what the annotations (destructiveHint: true, readOnlyHint: false) provide, which is genuinely useful. However, it stops short of disclosing what happens upon removal (e.g., access revocation, cascade effects on highlights or documents shared with that member). The annotations carry the safety profile, and the description contributes the authorization context, but behavioral details are still thin.

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: 'Remove someone from a shared trip. Owner only.' The most critical information is front-loaded in the first four words, and every word serves a purpose. There is zero fluff or 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 simple two-parameter mutation with no output schema, the description covers the essential purpose and access rules adequately. Gaps include no connection to related operations (e.g., how it differs from `leave_journey`) or post-removal effects, but given the tool's simplicity, the description meets the minimum bar. It's mostly complete but doesn't exceed expectations.

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?

With 0% schema description coverage and no parameter context in the description, the agent must infer that user_id refers to the member being removed and journey_id to the shared trip. The parameter names are common enough to be guessable, but given the low coverage, the description should have compensated per the rubric. The 'Owner only' hint does imply user_id is not the owner, adding slight disambiguation, but that's a stretch to count as meaningful parameter guidance.

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 the specific verb 'Remove' with the resource 'someone from a shared trip,' clearly identifying the action and target. The qualifier 'Owner only' adds a useful access constraint. While it could more explicitly contrast with the sibling `leave_journey` tool, the action and resource are unambiguous and distinguishable.

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?

'Remove someone' implies a distinction from self-removal, but no explicit alternatives or when-not-to-use guidance is provided. The ownership condition is stated but the description doesn't tell the agent when to choose this over `leave_journey` or `delete_journey`. Context for when another tool would be more appropriate must be inferred from sibling names.

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, idempotentHint=true, and openWorldHint=false, covering the safety profile. The description adds search criteria but no additional behavioral context such as result limits, no-results behavior, or pagination. This is adequate but not rich.

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, front-loaded sentence with no filler or redundant information. Every word contributes to understanding the tool's purpose and primary parameter semantics.

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 read-only search tool with two parameters and strong annotations, the description is mostly complete. It covers the core query semantics and purpose, though it omits limit behavior and explicit sibling differentiation, which would make it fully 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 description coverage is 0%, so the description must compensate. It does clarify that the 'query' parameter accepts an airline name or IATA code, which is valuable. However, the optional 'limit' parameter is left completely unexplained, leaving a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Find') and resource ('airlines') with clear search criteria ('by name or IATA code'). It clearly distinguishes this tool from sibling search tools like search_airports and search_cities.

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 implies this tool is for looking up airlines by name or IATA code, which gives enough context for when to use it. However, it does not explicitly mention alternatives or when not to use it, though sibling names make the distinction obvious.

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 idempotentHint=true, so the description doesn't need to restate that. It adds value by implying the tool returns airport codes and that guessing is not acceptable, which is useful behavioral context. However, it doesn't describe the return format or any pagination, but given the annotations, this is sufficient.

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, front-loaded with the purpose, and every word earns its place. It's concise and structured effectively.

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 (2 params, no output schema, read-only annotations), the description is complete enough. It explains the purpose, usage context, and the critical requirement to not guess codes. It could mention the limit parameter, but that's a minor gap.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions the query parameter implicitly ('by city, name or IATA code') but doesn't explain the 'limit' parameter. The description adds some meaning for 'query' but not for 'limit', so it partially compensates but leaves a gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Find airports by city, name or IATA code.' It specifies the resource (airports) and the search criteria, and it distinguishes itself from siblings like search_airlines and search_cities by focusing on airports and mentioning IATA codes.

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 tells when to use this tool: 'Use this to get the codes create_flight requires — never guess them.' This provides clear context and an exclusion (never guess codes), and it names the sibling tool create_flight as the consumer of the output.

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 and idempotentHint, so the safe/read-only nature is covered. The description adds value by clarifying the purpose (resolving city names for create_stay) but doesn't provide deeper behavioral details like pagination, error cases, or rate limits. It's consistent with annotations, so no contradiction.

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, information-dense sentences. The most critical information (what it does and why to use it) is front-loaded. Every word earns its place without unnecessary elaboration.

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 read-only search tool with 3 simple parameters and no output schema, the description covers the primary intent (finding cities by name). However, the tool is part of a travel ecosystem where country_code could be important for disambiguation, and the description doesn't mention filtering capabilities or limitations.

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 description's phrase 'by name' implies the 'query' parameter is for name-based search, which is the main parameter. However, there's no mention of what 'limit' or 'country_code' do, and with 0% schema coverage, those remain ambiguous. The description does some work but not enough to fully compensate for the missing schema documentation.

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 clear verb ('find') and resource ('cities') and provides a specific use case ('confirm the exact city name'). It distinguishes itself from the search_airports and search_airlines siblings by focusing on cities, though the tool name already makes this 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?

The phrase 'Use it to confirm the exact city name create_stay expects' gives explicit guidance on when to use this tool. It doesn't explicitly contrast with other search tools or state when not to use it, so it misses the top score.

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?

Adds behavioral detail beyond annotations: 'Replaces any existing target.' Annotations declare idempotentHint=true and destructiveHint=false, which align with replacement behavior. It also clarifies the scope ('user's own') and period semantics, enriching the agent's understanding of 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?

Two sentences with no filler. The primary action is front-loaded, and the period explanation is essential and efficiently worded. Every sentence contributes to correct usage.

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?

Adequate for a simple setter: covers scope (own trip), period semantics, and replacement behavior. It does not mention response format or error handling, but given no output schema and the idempotent annotation, the description 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?

Schema description coverage is 50%, so the description must compensate. It explains the 'period' parameter ('month' vs 'journey') and gives meaning to 'amount' as a spending target. However, it does not detail amount units or clarify journey_id format beyond its type. It partially complements the schema but not fully for all parameters.

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 action: 'Set or replace the user's own spending target for a trip.' Clear verb (set/replace), resource (spending target), and scope (user's own, for a trip). Distinguishes from the read-only sibling get_budget by its explicit write semantics.

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?

Implicitly guides using this for setting or replacing a budget, with no direct setter alternative among siblings. It clarifies the period parameter meaning (per month vs whole trip) and the scope ('user's own'), giving clear context. It does not explicitly name get_budget as the read counterpart, but that is not critical since there is no competing setter.

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 indicate a non-read-only, idempotent, non-destructive tool, and the description adds useful behavioral context: omitting travellers or passing an empty list means everyone, with everyone being the common case. It does not mention overwriting existing assignments or prerequisites, but the idempotent annotation reduces some of that need.

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 tight sentences with no filler. It front-loads the core action and immediately gives the most important behavioral default, making it easy for an agent to parse.

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 setter with no output schema, the description covers the essential behavior and default, while the schema supplies the enum values and traveler-source guidance. It could explicitly mention that this modifies an existing item, but the sibling create/update tools and tool name make that reasonably inferable.

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 only 33%, but the description adds meaningful semantics for the travelers parameter, including empty-list behavior and the default-to-everyone rule. It provides little meaning for item_id or item_type beyond what the enum values themselves show, so it only partially compensates for the low schema coverage.

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 gives a concrete outcome ('say which people... an item is for') with helpful examples like 'one person's separate flight, one person's room.' It clearly identifies the resource (item travellers) but does not explicitly state 'assign' or 'update' and does not distinguish itself against sibling tools.

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 tells the agent when subsetting travellers is appropriate by explaining that omitting them means everyone, and that everyone is the default for most items. It does not name alternative tools or state exact when-not-to-use conditions, so it falls 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 readOnlyHint=false (modifying), destructiveHint=false (non-destructive), and idempotentHint=true. The description's 'Change' is consistent and adds no contradiction. However, it does not disclose partial-update semantics (e.g., 'only specified fields are updated') or potential failure modes like missing accommodation_id. Given annotations cover safety, this is acceptable but not enriching.

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, concise sentence with no wasted words. It is well-structured and front-loaded with the action and main targets, making it easy to scan.

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 tool with 16 parameters, low schema coverage, and no output schema, the description is too sparse. It does not clarify that only provided fields are updated, what 'property' refers to, or what constitutes a successful response. The tool's complexity demands more context to guide correct invocation, making this description inadequate.

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 low (38%), so the description should compensate. It groups parameters into broad categories ('property', 'dates', 'price', 'confirmation', 'notes'), which gives some meaning but omits many fields (latitude, longitude, provider, booking_url, etc.). It does not clarify ambiguous terms like 'property' (name vs. address) or how partial updates work. The description adds marginal value but insufficiently covers the parameter space.

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: 'Change a booking's property, dates, price, confirmation or notes.' It uses a specific verb ('Change') and resource ('a booking's...'), and implicitly distinguishes from sibling update tools by being accommodation-specific. The listed fields align with the schema, 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?

Usage guidance is only implied. The description says what the tool does but does not explicitly state when to use it (e.g., 'Use this when you need to modify an existing accommodation') or contrast with creation/deletion. No alternatives or exclusions are mentioned, leaving the agent to infer that it applies to existing bookings.

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=false, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat those. However, it adds no extra context about side effects, partial update behavior, or what happens to unspecified fields. It does not contradict the annotations, but it does not enhance transparency either, leaving uncertainty about the update semantics.

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, efficient sentence with no filler or repetition. It is front-loaded with the action and clearly structured. It earns its place by being concise, even though it may be under-specified.

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 17 parameters, only 24% schema coverage, and no output schema, a tool of this complexity needs a richer description. The current one-sentence description does not explain return values, update behavior, or provide any usage context. It is far from complete for an agent to correctly invoke the tool, especially given the lack of guidance on how to use the many parameters.

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 only 24%, so the description must compensate for undocumented parameters. It mentions 'title, timing, place, or notes' but does not explain those or the other 13 parameters (e.g., price, emoji, stay_id). It adds little beyond the schema's few descriptions, and given the low coverage, this is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: changing an activity's title, timing, place, or notes. It distinguishes this from create_activity and delete_activity by using the verb 'change'. However, it only mentions a subset of the fields in the schema (title, timing, place, notes) while the schema includes many more properties like price, emoji, and address, so it is not fully comprehensive but still 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 gives no guidance on when to use this tool versus alternatives. It does not mention that it is for modifying existing activities or that create_activity should be used for new ones. No exclusions, prerequisites, or contextual advice is provided. The only hint is the name and existence of siblings, which is not explicit guidance.

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

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

Annotations already disclose the non-read-only, non-destructive, and idempotent nature. The description adds no behavioral context beyond listing updatable fields—it doesn't explain partial-update semantics (only provided fields are modified), whether other fields are preserved, or any side effects. No contradiction with annotations, but the additional value is minimal for a mutation tool.

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, efficient sentence that front-loads the action ('Correct a recorded expense') and lists fields in a natural list. No filler or redundant wording, and it stays appropriately short for the level of detail conveyed.

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 tool with 9 parameters and only 1 required, this description is too sparse. It doesn't state the update semantics (partial vs. full replacement), doesn't call out the required expense_id, and doesn't mention related_event_id or amount_usd's special rule. It also lacks any statement about when to use this vs. create_expense. An agent would need to rely heavily on the schema and inference for correct usage.

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?

With schema description coverage at only 44%, the description carries a heavier burden. It maps several parameters: 'amount' to amount, 'currency' to currency, 'date' to spent_on (ISO date), 'title' to title, 'category' to category, and 'which stop' to stay_id. However, it omits expense_id (the required field), related_event_id, and amount_usd (which has a schema description but isn't mentioned in the description). The description partially compensates but doesn't clarify all parameters.

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 ('Correct') and resource ('recorded expense'), and enumerates the editable fields: amount, currency, date, title, category, or which stop it belongs to. This clearly indicates an update operation on an existing expense, distinguishing it from create_expense. However, it doesn't explicitly differentiate from sibling update_* tools beyond resource type, though the tool name already provides that context.

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 offers no guidance on when to use this tool versus create_expense or delete_expense, nor any mention of prerequisites like requiring an existing expense_id. There is no explicit when-to-use or alternatives, and no exclusion criteria. The implied usage ('recorded expense') is present but not elaborated.

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 indicate idempotent, non-destructive, and non-read-only. The description adds no extra behavioral context (e.g., side effects, validation, or failure conditions).

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, succinct sentence with no redundant information or unnecessary details.

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 many parameters and sibling operations, but the description does not mention what it returns, how it interacts with search tools, or any side effects. Given no output schema, more context is needed for complete understanding.

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 has 18 parameters with only 33% descriptions. The description loosely maps some fields (route, times, seat, confirmation, notes) to parameters but does not cover all (e.g., price, currency, airline_code). It provides minimal compensation for the low schema coverage.

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 action ('Change') and the resource ('a flight'), listing specific attributes (route, times, seat, confirmation, notes). It is distinct from create_flight and delete_flight.

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 explicit guidance on when to use this tool versus alternatives. It does not mention that it is for existing flights or require flight_id as a prerequisite, nor does it contrast with create/delete operations.

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?

The description discloses permission requirements ('Owner only') and a notable behavioral consequence ('no missing-stay warnings' for home-base countries). It also mentions archiving as an action. Combined with annotations (idempotentHint=true, destructiveHint=false), this provides good transparency, though it omits details on return values or error handling.

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, well-organized sentence listing actions and a clarifying note. It avoids repetition and fluff, making it easy to parse. The structure is efficient and direct, suitable for an agent.

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 presence of annotations (idempotent, destructive) and absence of an output schema, the description provides necessary context: what actions are possible, permission requirements, and a specific behavioral nuance. It does not address edge cases or error handling, but that is not always required. Overall, it is sufficiently complete for typical usage.

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 description explicitly covers all parameters: 'rename' for name, 'change dates' for start/end dates, 'change description' for description, 'archive' for is_archived, and 'set home-base countries' for home_base_country_codes. It adds context for home_base_country_codes ('no missing-stay warnings') and aligns with schema descriptions for dates and country codes. The schema covers 43% of parameters descriptively, but the tool description fills in the rest with meaningful actions.

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 specifies the resource (journey/trip) and lists actionable verb-object pairs: rename, change dates, change description, archive, set home-base countries. It distinguishes itself from other update_* tools by focusing on journey-specific fields and mentions 'Owner only' to clarify access.

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 implicitly indicates when to use this tool (for updating journey attributes) and provides a usage constraint ('Owner only'). However, it does not explicitly contrast with alternative tools or state when not to use it, but the scope is clear enough for an agent to select it appropriately among siblings.

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 indicate idempotent, non-readOnly, non-destructive. The description adds no further behavioral context, such as whether omitted fields are left unchanged or reset to defaults. It doesn't explain the effect of partial updates despite all parameters being optional. With low annotation coverage, it should elaborate more.

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 all relevant info with no redundancy. It efficiently communicates the tool's purpose and main parameters.

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 11 optional parameters and no output schema, the description is relatively complete but leaves gaps: it doesn't mention whether updates are partial or whole, how the tool handles conflicting values (e.g., budget_min > budget_max), or any defaults. The field list is helpful but not exhaustive, and there's no note about idempotency behavior or return value.

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 only 18%, but the description compensates by grouping parameters semantically: 'where home is' (home_city, home_country_code), 'home airport' (home_airport_code), 'currency', 'nightly budget' (budget_min/max), 'travel pace', and 'working hours' (work_start/end/timezone). It covers most fields, though temperature_preference is omitted. This adds meaning beyond the bare 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?

Description clearly states the action ('Set') and the resource ('standing facts every trip should respect'), listing specific fields like home, home airport, currency, nightly budget, travel pace, and working hours. This distinguishes it from sibling tools that target individual trips or resources.

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 explicit guidance on when to use this tool versus alternatives, such as update_journey or other update tools. While it implies it's for global preferences, it never contrasts with siblings or states exclusions (e.g., 'not for per-trip settings'). No when/when-not advice.

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 indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, and the description's 'Change' is consistent with those. However, the description adds no behavioral context beyond the action itself, such as whether unspecified fields are preserved, whether at least one field must be supplied, or what the response contains.

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, front-loaded sentence with no filler or redundancy. It efficiently communicates the core 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?

With 8 parameters, no output schema, and no usage guidance, the description is too thin. It does not explain partial-update semantics, required stay_id, or what happens when multiple fields are updated together, leaving important operational context 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 description coverage is 63%, so the schema carries most parameter meaning. The description summarizes the main editable fields ('city, country, dates or notes') but does not explain checkout_flexible, city_code, or stay_id semantics 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?

The description uses a specific verb ('Change') and identifies the resource ('a stop') plus the affected fields (city, country, dates, notes). It is clear enough, though 'stop' does not exactly match the tool name 'stay', and it does not explicitly distinguish this from sibling update_* tools.

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 guidance is provided about when to use this tool versus alternatives like update_accommodation, update_activity, or update_flight. There is no mention of prerequisites, partial-update behavior, or 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 indicate mutation, non-destructive behavior, and idempotence. The description adds a meaningful behavioral detail: setting `is_active` to false archives the visa. It does not say whether omitted fields remain unchanged, but the archive mechanism is still a useful contribution 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 one direct, front-loaded sentence. It avoids fluff and provides exactly the core action plus the most non-obvious archive behavior.

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 tool with 14 parameters and no output schema, the description is under-specified. It clarifies the archive path but omits update semantics for the 13 other fields, whether omitted fields are preserved or reset, and the observable result of archiving.

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 low at 21%. The description adds semantic meaning only for `is_active`; the remaining 13 parameters are left to their names and types, with no discussion of partial updates, defaults, or omitted-field behavior.

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 concrete action ('Change') and a resource ('recorded visa'), and adds a distinct sub-operation for archiving via `is_active` set to false. This clearly distinguishes it from create_visa and delete_visa.

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 clear usage context: the tool is for modifying an existing recorded visa, or archiving it by setting `is_active` to false. It does not explicitly name alternatives, but the 'recorded visa' phrasing makes the appropriate scope obvious.

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