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

There are no annotations, so the description carries the full burden of disclosing behavior. It mentions 'expert answers with current information,' hinting that the tool accesses up-to-date data, but it does not disclose whether this is read-only, what the response format is, whether there are limitations or rate limits, or any side effects. For an unannotated tool, this is insufficient behavioral detail.

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

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

The description is a single, efficient sentence with no filler. The core action ('Ask any travel question') is front-loaded, and the supporting detail ('expert answers with current information') follows naturally. Every word contributes to the tool's 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?

For a single-parameter tool with no output schema, the description covers the basic call pattern (ask a question, get an answer) but lacks essential context: no mention of how the answer is presented, whether the question must be in a particular language or format, or what happens if the question is out of scope. An agent can likely invoke it correctly, but there are gaps in completeness.

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

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

The input schema already documents the 'question' parameter with 100% coverage, providing the baseline of 3. The description adds a list of example topics (destinations, visas, safety, tips), which reinforces the meaning but does not fundamentally extend beyond the schema's own 'Travel-related question' 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 a specific verb and resource: 'Ask any travel question and get expert answers.' It enumerates topic areas (destinations, visas, safety, tips) and the general scope ('any travel question') differentiates it from the sibling tools, which handle specific tasks like itineraries or weather. This makes it unambiguous what the 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 broad utility ('Ask any travel question') but does not explicitly state when to prefer this tool over siblings, nor does it provide exclusions or alternatives. An agent must infer that general Q&A belongs here, while specific tasks belong to sibling tools. There is no clear 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?

With no annotations present, the description must carry the behavioral burden. It does disclose that the tool polls automatically and takes 30-60 seconds, which is important for timeout expectations. However, it doesn't mention potential side effects, whether the created itinerary is automatically saved, or any failure‑mode behaviors, so it is only partially transparent.

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

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

The description is two sentences and front-loaded: the core action appears first, followed by the valuable note about automatic polling and duration. It avoids fluff, but it could be slightly more structured by putting the rationale for the polling in a separate clause. Still, it is concise for the amount of information given.

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 six parameters and no output schema, the description does not fully capture what the caller receives besides an ID. It also leaves ambiguous whether the itinerary is persisted to the user's trips or whether a subsequent call to `save_itinerary` is required. For a creation tool, this is a notable gap in completeness.

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 description coverage is 100%, meaning all parameters (destination, days, budget, travelers, start_date, preferences) are already described in the schema. The description adds no extra semantics beyond that, so the baseline of 3 is appropriate. It doesn't explain any ordering, defaults, or relationship 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: 'Create a new travel itinerary for a destination,' a specific verb and resource. It also mentions the return value (itinerary ID) and the auto-polling behavior, which helps distinguish it from retrieval or modification tools like get_itinerary or modify_itinerary, though it doesn't explicitly contrast them.

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

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

There is no explicit guidance on when to use this tool versus alternatives, no conditions, requirements, or context that would help an agent choose between it and `modify_itinerary` or `save_itinerary`. Usage is only implied by the action 'create'.

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

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

With no annotations provided, the description carries full burden. It states the action but does not disclose whether the deletion is permanent, whether it affects related data, or any required permissions. This is a significant gap for a destructive 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 a single, clear sentence with no unnecessary words. It is front-loaded with the verb and resource. However, it could include a hint about the trip_id parameter without harming conciseness.

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 single-parameter delete operation, the description is minimal but functionally adequate. However, it offers no context about the user scope, confirmation behavior, or potential errors, leaving the agent to discover these from the API or other sources.

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

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

Schema description coverage is 100%, so the input schema already documents trip_id as 'Trip ID to delete.' The description adds no extra meaning beyond naming the action, so a baseline of 3 is appropriate.

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

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

The description uses the specific verb 'Remove' and clearly identifies the resource as 'a trip from user's saved trips.' This makes the tool's purpose unambiguous and distinguishes it from sibling tools like create_itinerary or save_itinerary.

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, nor does it mention any conditions, prerequisites, or exclusions. The agent must infer usage from the tool name and sibling context.

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

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

With no annotations, the description carries the full burden. It only states the outcome (a budget breakdown) but does not disclose how the estimate is computed, whether it requires live data, what factors affect the result, or what the response format looks like. This is a significant gap for a tool that produces an estimate.

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 useful detail about the breakdown categories. It is efficient and front-loads the core purpose, though it lacks additional context that would make it more informative.

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?

This tool has 5 parameters, no output schema, and no annotations. The description is too sparse to fully guide an agent: it does not explain how origin, travelers, or budget_level influence the estimate, nor what the response structure is. More detail is needed for correct invocation and interpretation.

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

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

Schema description coverage is 100%, so all parameters already have descriptive text. The tool description adds no extra semantics beyond listing the budget categories. Since the schema handles parameter meaning, a baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Get') and a clear resource ('detailed budget breakdown'), and enumerates the cost categories (accommodation, food, transport, activities). This distinguishes it from sibling tools like create_itinerary or get_weather_insights.

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 given about when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or conditions that would help an agent select it over other travel-related 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?

No annotations are provided, so the description must fully convey behavioral traits. It only states that the tool generates an AI-powered list, but does not disclose whether this is a read-only operation, whether it modifies any data, what the output format is, or whether it depends on external services. The lack of detail leaves important behavior undisclosed.

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 that front-loads the action and purpose. There is no wasted wording; it conveys the core function efficiently.

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

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

Given the absence of annotations and output schema, the description should explain what the tool returns (e.g., a list format), any prerequisites, and potential side effects. It does none of this, leaving the tool's behavior and expected results under-specified for an agent to invoke it confidently.

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

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

Schema description coverage is 100%, so baseline is 3. The description mentions 'destination, weather, and activities' which loosely maps to destination and trip_details parameters, but it does not add any semantic detail beyond what the schema already provides, such as how 'when' affects weather or the relationship between 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 verb 'Generate' and the resource 'packing list', along with the basis (destination, weather, activities). It is unambiguous and distinct from all sibling tools, none of which focus on packing lists.

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 (trip planning based on destination and activities) but does not explicitly state when to choose this tool over alternatives or mention any exclusions. Sibling tools like ask_travel_expert or get_weather_insights are not referenced, so the agent must infer the appropriate context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool retrieves a complete itinerary, but does not disclose side effects, permissions, data sensitivity, rate limits, or any invariants. For a simple read operation this is minimal but insufficient by the rubric's standard.

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. It is concise, but it omits some useful context (e.g., return details) that might have been included without sacrificing brevity.

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 has no output schema, no annotations, and only a minimal description, the agent is left without information about the return format or any behavioral caveats. The phrase 'all details' is vague and does not enumerate what fields or structure will be returned. The description feels incomplete for a tool that should enable correct invocation and expectation-setting.

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

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

Schema description coverage is 100% (the single parameter itinerary_id is described as 'Itinerary ID to retrieve'). The description adds no extra meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific verb ('Retrieve') and resource ('complete itinerary'), and the phrase 'all details' hints at a distinction from get_itinerary_status. However, it does not explicitly name or contrast the sibling tool, so it stops short of fully differentiating itself.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention get_itinerary_status or list_user_trips, nor any conditions or scenarios that would select this tool. The agent is left to infer usage solely from the name.

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

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

No annotations are provided, so the description carries the full burden. It only states the action without disclosing whether this is a read-only operation, what statuses may be returned, or any side effects or error conditions. For a status-checking tool, this is a meaningful gap.

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 fluff. It is front-loaded with the core action, though it sacrifices some helpful context for brevity.

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 there is no output schema, the description should explain what 'generation status' means or what possible statuses exist, but it does not. An agent checking status would benefit from knowing expected return values or how to interpret the result. The simplicity of the tool is acknowledged, but the missing context is still a notable 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 schema covers the single parameter with a clear description ('Itinerary ID to check'), so the description adds no new meaning. Baseline 3 is appropriate since schema coverage is 100% and the parameter is self-explanatory.

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 ('check') and a specific resource ('generation status of an itinerary'), which clearly distinguishes it from sibling tools like get_itinerary that would fetch the full itinerary. The purpose is immediately obvious.

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 like get_itinerary, nor does it mention contexts such as after creating an itinerary or before retrieving it. The agent is left to infer usage from the name alone.

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 absent, so the description must carry the burden of behavioral disclosure. It does not mention read-only nature, permissions, rate limits, or any side effects. It only says 'check', which implies a query but does not explicitly confirm safety or non-mutating behavior.

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, direct sentence with no unnecessary words. It communicates the core purpose efficiently.

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 lookup tool, the description plus schema may be sufficient, but it lacks details about how date and month interact, what data is returned, or any assumptions. Without annotations or an output schema, a bit more context would improve completeness.

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

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

Input schema coverage is 100%, with each parameter already described in the schema. The description does not add additional meaning to parameters or clarify interactions (e.g., whether date and month are mutually exclusive). Baseline 3 is appropriate since schema handles the heavy lifting.

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

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

Description clearly states the operation (check) and resource (available dates and times for a tour experience). It is specific enough to understand the tool's function, though it does not explicitly differentiate from sibling tools like get_weather_insights or ask_travel_expert.

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 given on when to use this tool versus alternatives, nor any context about prerequisites or typical scenarios. The description is a standalone sentence without situational context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read-style operation ('get') but does not mention return format, data sources, potential limitations, or any side effects. For an unannotated tool, more details about what the agent should expect are needed.

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 efficient—a single sentence that front-loads the core function ('Get detailed weather and climate insights') before adding detail. No unnecessary words, though 'what to expect' is slightly vague but not wasteful.

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 tool with full schema coverage and no output schema, the description conveys the basic purpose. However, it does not clarify how the 'when' parameter affects the results or what 'detailed insights' concretely include (e.g., temperature ranges, precipitation). These gaps leave some ambiguity for an agent deciding whether this tool fits the user's query.

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

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

Schema description coverage is 100%, so both 'destination' and 'when' are already documented in the schema. The description adds no extra parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get detailed weather and climate insights for a destination' with specific mention of 'seasonal patterns and what to expect.' The verb 'get' combined with the weather resource makes it distinct from sibling tools like create_itinerary or get_itinerary, which serve clearly different functions.

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 tool is used when weather info for a destination is needed, but it does not explicitly state when to use it vs alternatives or provide exclusions. There is no mention of scenarios where another tool would be more appropriate, leaving the agent to infer the context.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the operation lists previously saved trips, which implies a read-only retrieval, but it does not mention authentication requirements, pagination behavior, or that no mutation occurs. The description is minimally transparent but lacks proactive behavioral detail.

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

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

A single, clean sentence that states the exact action and scope with no filler. Every word earns its place, and the core behavior is front-loaded.

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

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

For a simple list operation with two optional, well-documented parameters and no output schema, the description is sufficiently complete. It could additionally mention the default limit of 20 or that only authenticated trips are returned, but those details exist in the schema or are obvious, so the coverage is adequate.

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

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

Schema description coverage is 100%, so the schema already fully documents 'limit' and 'offset'. The description adds no extra meaning about these parameters, but per the rubric, baseline 3 applies when the schema carries the semantic load. The description does not harm or supplement the schema.

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

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

The description uses a specific verb ('List') and a clear resource ('saved trips') scoped to the authenticated user. It is immediately distinguishable from sibling tools like create_itinerary, get_itinerary, or modify_itinerary, which clearly involve different operations.

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

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

The description implicitly communicates its purpose but gives no explicit guidance on when to choose this tool over alternatives such as get_itinerary or save_itinerary. It does not state exclusions or the condition for selecting a sibling, leaving the agent to infer usage from the tool name.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It only states that modification happens via natural language, but does not explain whether changes are permanent, whether the itinerary is partially or fully updated, how ambiguous instructions are resolved, or what the tool returns. This is insufficient 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 concise sentence with no wasted words. It is front-loaded with the action and resource, making it easy to parse 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?

Given the lack of annotations and no output schema, the description is too minimal. It does not specify return values, error behavior, or how the natural language instructions should be structured, leaving significant gaps for an agent to know what to expect. Sibling tools do not compensate for this.

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

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

Input schema coverage is 100% (both parameters have descriptions), so the baseline is 3. The description does not add any extra meaning beyond restating the parameters; no additional formatting, constraints, or parameter interactions are provided.

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 ('Modify') and resource ('existing itinerary'), and specifies the mechanism ('using natural language instructions'). It distinguishes itself from siblings like create_itinerary and get_itinerary by clearly indicating it targets existing itineraries for modification.

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 'existing itinerary' implies the tool is not for creating new itineraries, but the description provides no explicit guidance on alternatives or when to prefer this tool over save_itinerary or other related tools. Usage is implied rather than clearly delineated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether saving is idempotent, whether it overwrites existing trips, what authentication or permissions are required, or what the response format looks like. The single sentence provides minimal transparency 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 words, and the key details ('Save', 'itinerary', 'user's trips') appear early. However, its brevity borders on under-specification, omitting important behavioral details that could be included without significant expansion.

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 there is no output schema, no annotations, and the tool performs a write operation, the description is incomplete. An agent lacks information about success/failure indicators, side effects, or how this relates to existing user trips. The tool would benefit from additional context about saving behavior and integration with other itinerary management tools.

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

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

Schema description coverage is 100%, so both parameters (custom_title and itinerary_id) are already documented in the input schema. The description itself adds no extra meaning or context for the parameters, leaving them fully defined by the schema. Baseline 3 applies.

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

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

The description states a clear action ('Save') and resource ('an itinerary to user's trips'), which communicates the core purpose. However, it does not explicitly differentiate from sibling tools like create_itinerary or modify_itinerary, relying on the verb 'save' to imply a distinct operation.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, conditions, or which scenarios call for saving an itinerary versus creating or modifying one.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'search,' which suggests a read operation but does not confirm read-only status, nor does it mention result ordering, default behavior for the limit parameter, or what constitutes a 'guide.' There is no context about how results are returned or whether the search is full-text, keyword-based, or location-filtered.

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, tightly worded sentence with no fluff. It places the action and resource upfront, and the purpose phrase 'destination information and recommendations' adds useful context without wasted words. It earns a top score for brevity and readability.

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 search tool, the description combined with the schema gives a fundamental understanding, but it is incomplete in several respects: no guidance on what search queries work well, no return format or example output, and no behavioral notes (e.g., whether search matches partial text or tags). Despite having only two parameters, an agent would benefit from knowing more about result content to distinguish it from similar utilities.

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

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

Schema description coverage is 100%, with both 'query' and 'limit' having explicit descriptions. The tool description adds nothing beyond what the schema already provides, so the baseline score of 3 applies. It does not clarify query formatting or edge cases for the limit, but the schema is adequate.

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 ('search'), a clear resource (Plantrip's travel guides), and the intended purpose (destination information and recommendations). This distinguishes it from sibling tools focused on itinerary management, packing, or expert Q&A, making its role immediately 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 description implies its use for finding destination information, which gives broad context, but it does not explicitly state when to use it over alternatives such as ask_travel_expert or get_weather_insights. No exclusions or 'use instead of' guidance is provided, leaving the agent to infer the right tool based on the surface-level purpose phrase.

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

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

No annotations are provided, so the description carries the full burden. It discloses the response mechanism (operator will respond via email) and the no-confirmation directive, but does not mention side effects (e.g., creating a record) or whether repeated submissions are possible. 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?

Two concise sentences deliver essential information with no fluff. The core purpose is stated first, and the usage instruction is front-loaded. Every word 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 straightforward submission tool with fully documented parameters, the description covers the critical operational context: when to invoke, what happens next (email response), and a key interaction rule. It lacks output/error details, but no output schema exists and that is less critical for this action.

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

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

Schema description coverage is 100%, so each parameter has its own description. The tool description adds no extra parameter meaning, which is acceptable given the schema's completeness. Baseline 3 applies.

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

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

The description states a specific verb ('Submit') and resource ('inquiry about booking a tour'), clearly distinguishing it from itinerary-management siblings. It is unambiguous and immediately understandable.

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

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

Provides explicit when-to-use guidance ('Call this tool immediately when the user asks you to book') and a clear behavioral rule ('do not ask for confirmation first'). It does not explicitly mention when not to use it or name alternatives, but the context is clear enough.

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