outdoorithm

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read-only operation. The description adds value by disclosing the return behavior (categorized items from the gear catalog) and the adjustment logic, which goes beyond the annotations. It does not mention edge cases, but with strong 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 concise: two sentences, with the main action front-loaded. Every sentence earns its place: the first states the core function, the second details the output and influencing factors. No wasted words.

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

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

Given that an output schema exists (context signal), the description does not need to explain return values in detail. The description covers the essential context: what the tool does, what factors it considers, and that it returns categorized items. For a tool with 8 optional parameters, this is complete enough for an agent to select and invoke it 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 100%, so each parameter is well-documented. The description adds meaning beyond the schema by synthesizing the role of parameters: it mentions campground amenities, activities, weather, and group size, which directly map to campground_id, activities, season, adults/children/has_pets. This helps the agent understand how inputs affect output.

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 generates a context-aware packing checklist for a camping trip, which is a specific verb+resource. It mentions returning categorized items from the gear catalog and adjusting for amenities, activities, weather, and group size. However, it does not explicitly differentiate from siblings like get_gear_for_campground or search_gear, so it falls short of a 5.

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

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

The description provides clear context for when to use this tool: when a packing checklist for a camping trip is needed, with adjustments based on campground amenities, activities, weather, and group size. It does not explicitly mention alternatives or exclusions, but the use case is unambiguous, making it a clear context without 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 indicate a read-only, non-destructive operation. The description adds behavioral context by mentioning the use of the Mapbox Matrix API, incorporation of live traffic, and a cap of 9 destinations per request. These details go beyond the annotations, though it does not discuss error handling or broader rate limits.

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

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

The description is relatively concise and front-loaded, with the main purpose in the first sentence. However, it redundantly mentions traffic-awareness ('live traffic' and 'traffic-aware') in the second sentence, which could be trimmed without losing meaning.

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?

An output schema exists, so return values are covered elsewhere. The description sufficiently explains the tool's purpose, method, and a key limitation (max 9 destinations). For a read-only calculation tool with simple parameters, this is adequate even though it omits edge-case handling or prerequisites.

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

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

Schema description coverage is 100% for all three parameters, so the baseline is 3. The description does not add parameter-level details beyond what the schema provides—it repeats the 'max 9' constraint, which is already included in the destinations parameter 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 the verb 'calculate' and the resource 'drive times from an origin to multiple campgrounds', and it specifies the method ('Mapbox routing with live traffic'). This distinguishes it from sibling tools like get_weather or check_availability, which address different concerns.

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 the tool (when drive times to campgrounds are needed) and includes a key constraint ('Maximum 9 destinations per request'). However, it does not explicitly compare to alternatives or state when not to use it, so it lacks explicit 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 readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that queries are real-time and against reservation systems via camply-service, providing some behavioral context. However, it does not disclose potential latency, rate limits, or failure modes, so value beyond annotations is modest.

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 primary purpose, and contains no redundant information. It is well-structured and earns its 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?

For a read-only query tool with complete schema coverage and an output schema present, the description sufficiently conveys purpose and scope. It does not explain what happens when no availability exists, but the output schema likely covers that. Minor gaps like external service dependencies are mentioned, making 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 100% for all 4 parameters, with clear descriptions and formats. The description does not add any additional meaning to the parameters; it relies entirely on the schema, which is already sufficient.

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 checks real-time campground availability for specific dates, with a specific verb ('Check') and resource ('campground availability'). It implicitly differentiates from siblings like get_campground_details and search_campgrounds by focusing solely on availability checking.

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 should be used when checking availability for specific dates, but it does not explicitly say when not to use it or mention alternative tools. It adds context about supporting 30+ providers, but this is informational rather than usage 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 indicate a read-only, non-destructive operation. The description adds meaningful behavioral detail about data sources (Greenbook community safety, enriched alerts) and the red-flag detection purpose, going beyond what annotations provide.

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

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

The description is concise and well-structured: a leading summary sentence followed by three bullet points that enumerate checks. Every word adds value, with no redundancy or fluff.

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 is simple (one parameter), has full schema coverage, and an output schema exists. The description covers what the tool does and why, making it complete for an agent to select and invoke correctly without further explanation.

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 100% coverage for the single parameter, describing it as a list of campground CUIDs. The tool description adds no extra parameter semantics, 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 clearly states the tool checks campgrounds for safety issues, community atmosphere, and active alerts, with a specific list of check categories. This distinguishes it from sibling tools like check_availability and get_campground_details by focusing on safety and alerts.

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 on when to use the tool (when assessing safety before recommending a campground), but it does not explicitly mention alternatives or exclusions like 'use check_availability for availability'. Still, the scope is well-defined.

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 and non-destructive behavior. The description adds the return content (specs, pros/cons, verdicts, comparison summary) and the lookup behavior (unique_id with slug fallback), providing useful context beyond the structured annotations. 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?

Two sentences, front-loaded with the core purpose, and no wasted words. The first sentence states what it does and what it returns; the second adds usage guidance and identifier specifics. Highly concise.

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

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

Given the tool's simplicity (1 parameter, clear schema, annotations) and presence of an output schema, the description is complete. It covers purpose, usage context, and identifier behavior, and the guidance to use search_gear first fills an important contextual 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 100%, with the gear_ids parameter already described as 'List of 2-3 gear item identifiers (unique_id or slug)'. The description repeats the 2-3 limit and mentions slug fallback, but adds no new semantics beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Compare 2-3 gear items side-by-side with specs, pros/cons, verdicts, and comparison summary.' It uses a specific verb ('compare'), identifies the resource ('gear items'), and differentiates from siblings like search_gear by focusing on side-by-side comparison.

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

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

Explicit guidance is provided: 'Use search_gear first if the user hasn't named specific products.' This tells the agent when to use this tool versus the alternative, and the 'supports lookup by unique_id with slug fallback' hints at prerequisite input formats.

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 a read-only, non-destructive operation. The description adds meaningful behavioral context by explaining that pre-computed embeddings are used and that similarity combines semantic and structured attributes, which implies a dependency on precomputed data. 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, front-loads the core purpose, and adds a second sentence to clarify the algorithm without unnecessary fluff. 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?

The tool has a rich schema (100% coverage) and an output schema, so the description does not need to explain return values. It covers the algorithm and key parameters, though it does not mention potential edge cases like what happens if no embeddings exist or if campground_id is invalid. Overall adequate for the complexity.

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 detailed parameter descriptions for result_limit, campground_id, max_distance_km, semantic_weight, and structured_weight. The description adds only a brief conceptual link between the embedding types and the weight parameters, but the schema already explains the meaning and defaults, so the value added is marginal.

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 ('find') and resource ('campgrounds similar to a given campground'), and distinguishes itself from sibling tools like search_campgrounds by detailing the method ('vector embedding similarity'). It is clear and specific.

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 context (when you have a campground and want similar ones) but does not explicitly contrast with search_campgrounds or other alternatives. There is no 'when not to use' guidance, so it falls short of 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 declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: it returns a curated 80-field projection rather than a raw 214-column dump, explains that missing fields mean absence from records (not absence at the campground), and notes that coverage varies by provider. This goes well beyond 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 front-loaded with a summary sentence, followed by a concise bullet-style list of returned categories, and ends with a short but crucial data-coverage caveat. Every section earns its place without redundancy or fluff.

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 is read-only, has a single well-documented parameter, and includes an output schema, the description provides complete context: what the tool returns, which fields are in scope, and how to interpret missing data. No critical operational gaps remain.

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 single parameter campground_id with its CUID format and example, giving 100% schema coverage. The description does not add parameter-level detail, so the baseline of 3 is appropriate—the schema carries the burden.

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 resource ('campground details'), and enumerates the exact content areas (amenities, reviews, safety, seasonal ratings). It clearly distinguishes from siblings like search_campgrounds by focusing on a single specific campground.

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 'for a specific campground' implies the tool is for retrieving details about one known campground, but it does not explicitly state when to prefer this over siblings like search_campgrounds or check_safety. No alternatives or exclusions are mentioned, though the context is clear enough to infer typical usage.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds valuable context about the return structure: pre-computed recommendations across slot types (essential, activity, comfort, amenity_gap) and that each includes product details and purchase links. This goes beyond the annotations and schema, clarifying what the agent can expect.

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 primary purpose, and every clause earns its place. It efficiently communicates the core function, the slot types, and the output contents without any extraneous information.

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 is simple (2 params, 1 required) and has an output schema, so the description needn't detail return fields. It covers the key aspects: what it does, the slot types, and what results include. It does not mention edge cases like invalid campground IDs, but for a read-only lookup with good schema support, this is comprehensive enough.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the slot_type values: essential (must-have), activity (activity-matched), comfort (nice-to-have), amenity_gap (compensates for missing amenities). This is not present in the schema, which only lists the enum-like values without definitions.

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 personalized gear recommendations for a specific campground.' It specifies the resource (campground), the action (get), and the output (recommendations). It also differentiates from sibling tools like search_gear and compare_gear by emphasizing the campground-specific, pre-computed nature and listing slot types.

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 context ('for a specific campground', 'pre-computed recommendations') but does not explicitly state when to use this tool versus alternatives like search_gear or build_packing_list. It lacks exclusions or alternative references, so guidance is implied 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?

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds meaningful context: it discloses the Open-Meteo data source, CC BY 4.0 licensing, and the required attribution field. It also lists output behavior such as safety warnings and best-day recommendations, going beyond the annotation baseline.

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

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

The description is well-structured: a clear opening sentence, a scannable bullet list of outputs, and a concise licensing/attribution note. Every sentence provides useful information, and there is no filler.

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 moderate complexity, the description covers the essential output fields (temps, precipitation, suitability ratings, gear recommendations, warnings, best days) and the attribution requirement. The presence of an output schema further supports completeness, though the description already explains return value semantics well.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add extra meaning to the parameters themselves; for instance, it does not explain how check_in_date/check_out_date influence the forecast, leaving that entirely to the schema.

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

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

The description clearly states 'Get camping-specific 7-day weather forecast with suitability ratings and gear recommendations.' It uses a specific verb and resource, and the 'camping-specific' qualifier distinguishes it from generic weather tools among the siblings.

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

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

Usage is implied through 'camping-specific' but there is no explicit when-to-use or when-not-to-use guidance, nor mention of alternatives like the sibling 'check_safety' tool. It lacks clear exclusions or comparisons to other 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?

Annotations provide readOnlyHint=true, and the description adds behavioral context beyond this by indicating the tool also checks 'connectivity' and returns environment/version info. It does not contradict annotations and gives useful insight into the tool's non-destructive nature and response fields.

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

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

The description is succinct, with a clear front-loaded purpose and a bulleted list of return fields. Every sentence adds value, no filler or redundancy, and it is appropriately sized for a simple health check tool.

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

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

Given the tool has no parameters, annotations cover read-only safety, and an output schema exists for return values, the description fully contextualizes the tool's purpose and behavior. It is complete for the tool's simplicity, and the explicit mention of connectivity and environment rounds out the 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?

The tool has 0 parameters, and the schema is effectively complete with 100% coverage. The description need not add parameter details; baseline of 4 applies for zero-parameter tools.

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 resource 'server health and connectivity', which clearly states the tool's function. It is distinct from all sibling tools, which focus on camping/gear tasks rather than server diagnostics.

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 as a server health diagnostic tool but does not explicitly state when to use it versus alternatives or provide any exclusion criteria. There is no naming of sibling tools or 'use this when' guidance, though the purpose is self-evident given the sibling set.

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 destructiveHint=false. The description adds behavioral context by stating the tool does not actually book (citing third-party booking prohibitions) and returns a deep link plus booking-window context, which are useful beyond the annotation hints.

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 front-loaded, starting with the main purpose and then explaining return value and usage pairing. Every sentence adds meaningful detail; no wasted words.

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

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

The tool has an output schema, so return values need not be elaborated. The description supplies crucial context: it never books, it provides ToS-compliant guidance, and it should be used after check_availability. This is complete for the tool's complexity.

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 each parameter including meaningful descriptions (e.g., 'Check-out date (YYYY-MM-DD)', 'Optional group size...'). The tool description itself does not add parameter semantics beyond what the schema already provides, so 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 it 'prepares a one-tap booking handoff' for chosen campground/dates, with a specific verb and resource. It distinguishes itself from siblings by explicitly noting it 'does NOT book on behalf' and by referencing 'check_availability' for pre-confirmation.

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 usage guidance: 'Pair with check_availability first to confirm the dates are reservable' and specifies when not to use it ('Does NOT book on behalf'). It also names a specific alternative tool, satisfying the when/when-not/alternatives requirement.

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 destructiveHint=false, so the safety profile is known. The description adds the behavioral requirement of a location constraint, which is useful context beyond annotations. It does not describe result characteristics or pagination, but the output schema fills that 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 two sentences and immediately tells the agent what the tool does and a key requirement. It is front-loaded and contains zero filler, making it highly concise.

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

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

Given the tool's complexity (48 parameters), the description covers the essential constraint and filter categories, while the schema details all parameters and the output schema presumably describes return values. It could mention pagination or default limit behavior, but these are in the schema, so the context is adequately 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 every parameter having a description, so the baseline is 3. The description adds a cross-parameter rule that at least one location constraint is mandatory, which is not obvious from individual parameter descriptions. This adds valuable semantic information.

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 'Search' and resource 'campgrounds', and mentions '40+ filters' which conveys the broad search capability. It doesn't explicitly contrast with siblings like find_similar_campgrounds, but the filter emphasis implies a comprehensive search tool, making the purpose 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?

It provides an explicit usage prerequisite: 'Requires at least one location constraint: near_location, latitude+longitude, or states.' This is important for correct invocation. However, there is no guidance on when to use this tool versus alternatives like find_similar_campgrounds or get_campground_details, so the sibbling-differentiation aspect is missing.

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 destructiveHint=false, so safety is covered. The description adds behavioral context by stating the return payload includes prices, verdicts, and purchase links. It does not disclose pagination or rate limits, but the read-only nature is clear.

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: first states purpose and filters, second states output. Efficient, front-loaded, and every word adds value. The alternative-tool pointer is integrated cleanly.

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 (8 optional filters) and the presence of an output schema, the description adequately covers what the tool does, its return contents, and where to go for adjacent use cases. No important 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?

Schema description coverage is 100% with detailed parameter descriptions. The tool description echoes the parameter names (keyword, category, price range, etc.) without adding new semantics beyond the schema. Since schema carries the load, 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 explicitly states the tool 'Search the Outdoorithm gear catalog' and lists multiple search dimensions (keyword, category, price range, kit, necessity, tier). It distinguishes from sibling tool get_gear_for_campground by explicitly directing users there for campground-specific recommendations.

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 clear when-to-use context: searching gear by various filters, and explicitly says 'For campground-specific recommendations, see get_gear_for_campground.' This names the alternative and clarifies scope.

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