SeaWeb

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds beyond that by detailing that it ranks the query under two rankers, returns a pre-formatted table, and instructs the agent on how to use the result (show verbatim, vote). 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 a single paragraph but efficiently uses four sentences to cover purpose, prerequisite, and workflow. It is front-loaded with the main action. Slightly verbose, but no unnecessary repetition.

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

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

For a tool with moderate complexity (A/B comparison), the description covers purpose, prerequisites (after search), expected output (table), and follow-up actions (vote). Output schema exists, so return values are handled separately. The description is complete for an agent to understand the tool's role in a session.

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% (no parameter descriptions in schema). The description does not explain any of the three parameters (intent, track_b, location). While context implies 'intent' relates to the search query, no explicit meaning is added, leaving the agent to infer. 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 this tool performs an A/B ranking comparison after a normal search session, explicitly identifying the verb (run/rank) and resource (comparison). It distinguishes from sibling tools like search and vote_comparison by specifying the timing and the resulting two-column table.

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

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

The description gives explicit when-to-use guidance ('run AFTER a normal search session'), explains the workflow (show block verbatim, then record verdict via vote_comparison), and mentions the alternative vote_comparison for recording judgments. This fully meets the criteria for when vs. alternatives.

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

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

Beyond annotations, it discloses idempotent behavior (returns deleted=false for unknown/already-deleted/not-yours), ownership verification, return shape, and practical consequences for lapsed accounts. This is comprehensive and adds significant value.

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?

Structured into a direct usage paragraph and a brief rationale paragraph. Every sentence adds value, though the second paragraph is a bit explanatory; still well-organized and not verbose.

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?

Covers behavior, auth, idempotency, ownership, return values, and business rationale. Without an output schema, this description provides all needed context for an agent to invoke 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?

The schema has no descriptions, but the description explains tenant_id as the namespace proving ownership and subscription_id as the target. This fully compensates for the schema's lack of parameter details.

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 deletes one webhook subscription the user registered, specifying the identity requirements and return value. It distinguishes itself from siblings like register_disruption_webhook and list_disruption_webhooks.

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 guidance on ownership (pass same tenant_id), authentication (needs authenticated key), and idempotency behavior. While it doesn't name alternative tools explicitly, the context makes when to use this clear.

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?

Beyond the annotations (destructive, idempotent), the description adds ownership verification, tenant_id requirement, return value {query_id, deleted}, idempotent deletion semantics, and authentication needs. This is rich behavioral context that annotations alone don't 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 somewhat long but every sentence adds critical information (ownership, idempotency, return, auth). It is well-structured with the main action first, followed by constraints and behavior. Minor redundancy could be trimmed but it remains 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?

Despite no output schema, the description covers the operation's functionality, edge cases (unknown/deleted/not-yours), return format, ownership rules, and authentication. For a simple delete tool with rich annotations, this is complete and self-contained.

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 0% description coverage, but the description compensates fully. It explains query_id as the identifier and clarifies that tenant_id must match the one used during registration, adding meaning beyond the raw schema types and defaults.

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 deletes a standing disruption query by query_id, distinguishing it from sibling tools like list_standing_queries and register_standing_query. The verb 'delete' and resource 'standing disruption query' are 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?

It provides clear ownership and tenant_id prerequisites, and explains the idempotent behavior for unknown or not-yours ids. While it doesn't explicitly name alternatives, the context makes it obvious this is for deletion after listing/registering. The description effectively guides when to use the 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 description discloses extensive behavioral details beyond the annotations: the difference between index and live fetching, byte-identical text for indexed pages, noindex refusal, nosnippet returning title/link with empty text, and the unconditional untrusted_content flag. Error cases are also specified. This goes well beyond the readOnlyHint/idempotentHint 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 well-structured: a one-sentence summary followed by focused paragraphs on source types, publisher directives, and error cases. Every sentence adds concrete value without redundancy. Despite length, it remains efficient and front-loaded with 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?

The description is fully complete for the tool's complexity. It explains return fields (title, text, passages, source, fetched_at), edge cases (noindex, nosnippet, non-HTTP errors), and notes about untrusted content. Since there is no output schema, this level of detail is essential and well-executed.

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 only one parameter and no schema description, the parameter semantics are fully covered in the description. It explains the URL input, expected HTTP(S) protocol, and error behavior for invalid URLs. This compensates fully for the 0% 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 tool's function: taking one URL and returning clean readable content (title, text, passages) with a source identifier. It explicitly distinguishes from sibling search_web ('search_web finds pages; this reads one you already have'), providing strong purpose clarity and 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 gives explicit usage guidance: use this when you already have a URL to read, not to search for pages. It explains when the source is 'index' vs 'live', and describes rejection cases (noindex, nosnippet, non-HTTP), making it clear when this tool is appropriate and what to expect.

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 minimal behavioral context beyond what annotations already provide (readOnlyHint, idempotentHint). The mention of 'subset of prior search hits' adds some state dependency but lacks detail.

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

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

The description is extremely short but under-specified; it sacrifices clarity for brevity and does not earn its place by being 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?

For a tool with 7 parameters, no parameter descriptions, and no usage examples, the description is grossly incomplete. It fails to explain filter logic, parameter interactions, or output 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%, and the description does not explain any parameter meaning or valid values. The agent must rely solely on parameter names, which is insufficient.

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 it's a filter tool on a registry or prior search hits, making the purpose clear. However, it does not differentiate from sibling tools like search_restaurants.

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 when-to-use or when-not-to-use guidance is provided. The description only hints at possible use cases (registry or prior hits) without alternatives.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the context of filtering a 'registry or subset of prior search_salons hits,' which is helpful but does not disclose any additional behavioral traits (e.g., performance, authentication). 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 very concise—two sentences that immediately convey the tool's purpose. No wasted words. The structure could be slightly improved by bolding key terms, but it is effective.

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 6 optional filter parameters and an output schema (not shown), the description is too sparse. It does not explain how filters combine (AND/OR), provide examples, or describe the output beyond being a 'structured' filter. The many sibling tools increase the need for clarity.

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 should compensate. It only mentions salon_ids in context, leaving the other 5 parameters (price_range, neighborhood, open_tonight, publisher_id, accepts_reservations) with no additional meaning beyond their names and types. This is insufficient for a filter tool.

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 is a 'structured /grep filter over salons' and mentions it can operate on a subset from search_salons via salon_ids. It distinguishes the tool as a filter, not a search, but could explicitly contrast with search_salons.

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 on when to use this tool versus siblings like search_salons or filter_restaurants. The description does not specify prerequisites or exclusions, leaving the agent to infer usage from 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds value by specifying the return type ('detail slice (menu / service list)') and the vertical-agnostic nature, which goes beyond annotations without 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 sentences, no fluff, front-loaded with the core purpose. The second sentence adds a key distinction efficiently. 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 simple read-only tool with one parameter and no output schema, the description conveys the main purpose but omits details about invalid inputs, possible return values, or error behavior. It is adequate but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'for one entity', implying entity_id identifies an entity, but does not clarify what kind of entity or provide format/validation details. This minimal compensation earns a 2.

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 returns a 'detail slice (menu / service list)' for one entity and explicitly positions itself as the 'vertical-agnostic counterpart of get_menu/get_services'. This is specific, uses strong verbs, and differentiates from 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 to use this tool (for a vertical-agnostic detail slice) versus get_menu/get_services (vertical-specific). However, it does not provide guidance relative to other siblings like get_entity or hours, limiting comprehensiveness but still leaving clear context for key alternatives.

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

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

Annotations already declare readOnly and idempotent hints, so safety is clear. The description adds meaningful context about the 'frozen span-grounded source set', explaining that the evidence is immutable after emission, which goes beyond schema. This provides valuable behavioral detail without contradicting 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 a parenthetical explanation of the frozen source set. Every part adds value, and the structure makes the core purpose clear immediately.

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-event fetch with one parameter and no output schema, the description gives sufficient context about the return content (event plus its frozen source set). It lacks explicit alternative guidance but covers the essential behavior 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?

The schema has one parameter, event_id, with low description coverage. The description merely restates the parameter name ('by event_id') without adding format, semantics, or constraints beyond the schema's 'Event Id' title. Since coverage is 0%, the description should compensate but doesn't.

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 'fetch one disruption event by event_id', clearly identifying the action, resource, and key identifier. It also differentiates from sibling tools like 'get_disruptions' (plural) and 'list_disruption_events' by specifying a single event lookup.

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 for retrieving a single event by its ID, but it does not explicitly contrast with alternatives or state when to use this versus list_disruption_events. No exclusions or preconditions are mentioned.

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 read-only, idempotent, non-destructive behavior, and the description adds substantial context beyond that: the crawler-based poller sync cadence, partial coverage (US-only weather feed, global country-level advisories), the merged travel vertical Product B stream, and the labeling policy (alerts inform, never silently dropped). This is rich behavioral disclosure.

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

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

The description is long but well-structured with a clear headline and paragraphs for coverage, filtering, and return semantics. The historical dates and Product B details add useful context but could be tightened without losing essential guidance.

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 complex filtering semantics, partial coverage, and zero schema descriptions, the description covers all critical aspects: data source geography, how filtering works, what rows contain, and how to interpret empty results. This is fully adequate for an agent to select and invoke 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?

Schema coverage is 0%, so the description must explain parameters; it does for lat/lng (geometry matching for US weather alerts) and ugc (direct US zone code), plus the behavior of omitting all filters. However, the 'limit' parameter is not mentioned at all, leaving one of four parameters undocumented.

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 returns active disruption alerts (weather, safety, travel advisories) for a region, using a specific verb+resource structure. It also distinguishes itself from the sibling list_disruption_events by naming it as the richer filtered surface.

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 vs alternatives: pass lat/lng or ugc for filtered US weather alerts, omit filters to get all alerts, and see list_disruption_events for a richer filtered surface. It also clarifies that an empty result means 'no source covers this place' rather than 'no disruptions', which is critical for interpretation.

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, destructiveHint=false. The description adds value by explaining the return format (full schema.org page) and acceptable id types, but does not disclose additional behavioral traits like pagination 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?

Single concise sentence with no wasted words. The essential information 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 read-only tool with one parameter and annotations covering safety, the description adequately explains what is returned and acceptable inputs. Minor gap: no example or format clarification.

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 lists three id types (canonical, legacy, bare slug), providing context beyond the schema. However, it lacks specific formats or examples, so it only partially compensates.

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 retrieves the full schema.org page for an entity, specifying the identifier formats. However, it does not explicitly differentiate from sibling tools like get_details or get_restaurant.

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 on when to use this tool versus alternatives such as get_details or get_restaurant. The description does not mention prerequisites or 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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that restaurant_id and entity_id are aliases, which is a behavioral trait beyond the schema. However, it does not mention edge cases like conflicting IDs or invalid inputs. With annotations covering safety, a 3 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 concise sentences with no wasted words. The purpose is front-loaded, and the alias information is efficiently stated in the second sentence.

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 with no output schema, and the description adequately covers the core purpose and parameter relationship. However, it omits details about return format, error behavior, or what happens if neither parameter is supplied. For a low-complexity read tool, this is nearly complete but leaves minor 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?

With 0% schema description coverage, the description must compensate. The alias note ('restaurant_id and entity_id are aliases; pass either') provides essential meaning beyond the schema's bare property definitions. It clarifies the relationship between the two parameters, but could also detail parameter constraints or expected formats.

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 'Return opening hours for a restaurant', which includes a specific verb and resource. Though it does not explicitly mention alternatives, the resource is distinct from sibling tools like get_restaurant or check_availability. The alias note adds clarity about parameter use but does not further differentiate 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 implies usage for retrieving opening hours but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool suggestions are given. The alias note is parameter-oriented rather than usage-oriented.

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 provide readOnlyHint=true and idempotentHint=true. The description adds behavioral context by indicating the return format is a structured menu following the schema.org Menu shape, which goes beyond the annotations. It does not introduce 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?

The description is two concise sentences, front-loaded with the core purpose and no filler. Every sentence earns its place, adding the structured shape and alias clarification.

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 and well-covered by annotations. The description mentions the return shape (schema.org Menu) and the alias input, which is sufficient for invoking the tool. It could optionally detail what the menu contains, but referencing an established schema provides adequate 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%, so the description must compensate. It does so by explaining that restaurant_id and entity_id are aliases and only one needs to be passed, which is essential semantic information not clear from the schema alone. However, it does not elaborate on the meaning or format of these identifiers beyond the implicit 'restaurant' 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 states a specific verb ('Return') and a specific resource ('structured menu for a restaurant'), and references the schema.org Menu shape, which distinguishes it from sibling tools like get_restaurant or get_hours. No ambiguity.

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

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

The description clarifies parameter usage ('restaurant_id and entity_id are aliases; pass either'), which is helpful for invoking the tool, but it does not explicitly state when to choose this tool over alternatives like get_restaurant or get_details. It is implied by the purpose but lacks explicit exclusions or comparisons.

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, destructiveHint=false, and idempotentHint=true. The description adds that it returns a 'full' page and explains the alias behavior, but does not disclose other behavioral details like error handling or response format. This is minimal additional value.

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, front-loaded sentences. The first states the purpose, the second gives essential parameter guidance. No wasted words.

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

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

For a simple get-by-ID tool with good annotations and no output schema, the description adequately indicates the return type ('full schema.org Restaurant page') and the alias mechanism. It is sufficient for an agent to select and invoke, though it could mention not-found behavior.

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 clarifies that restaurant_id and entity_id are aliases and that either can be passed, which resolves ambiguity not evident from the schema alone. However, it does not elaborate on each parameter's meaning further.

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 returns a full schema.org Restaurant page, which is a specific verb and resource. It does not explicitly distinguish this from sibling tools like get_entity or get_details, so it misses the top score.

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 compared to alternatives such as get_entity or get_details. The only usage note is about parameter aliases, which is not a usage guideline.

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 cover read-only and idempotent behavior, and the description adds value by explaining that salon_id and entity_id are aliases and that the return is the full schema.org page. This goes beyond the annotations without contradicting them.

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 wasted words. It front-loads the purpose and immediately provides practical alias guidance, achieving excellent conciseness and structure.

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 get-by-id tool with read-only annotations and no output schema, the description adequately conveys the return value and parameter relationship. It could mention error behavior (e.g., not found) but is otherwise complete for its 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?

The schema provides no property descriptions, so the description's statement that the two parameters are aliases partially compensates. However, it does not define the ID types or how they are obtained, leaving some ambiguity given the 0% 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 tool returns the full schema.org page for a salon, specifying both profile and meta. This distinguishes it from siblings like get_restaurant and search_salons by focusing on a specific resource and action.

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

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

The description gives clear context for what the tool does but does not explicitly state when to use it over alternatives. It lacks exclusions or guidance such as 'use search_salons to find IDs first', so usage is implied rather than stated.

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

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

Annotations already cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds value by revealing the return structure ('sections of priced services') and the alias relationship between parameters, which are meaningful behavioral details not present in 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 exceptionally concise: two sentences deliver the core purpose, return format, sibling differentiation, and parameter alias guidance without any redundant or filler content. Every phrase earns its place, making it easy 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 absence of an output schema, the description helpfully outlines the return shape ('schema.org Menu shape: sections of priced services') and clarifies parameter usage. It does not mention edge cases like pagination or limit behavior, but for a straightforward menu-listing tool with good annotations, this is a satisfactorily complete 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 input schema has no parameter descriptions (0% coverage), leaving the description to carry the burden. It explains that salon_id and entity_id are aliases and that either can be passed, which is a key semantic clarification. However, it does not elaborate on what each ID represents conceptually or any formatting/validation expectations, so the compensation is only partial.

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 unambiguously states the tool's function: 'Return a salon's service menu' with a clear schema.org Menu shape. It also differentiates from a sibling by explicitly calling itself the 'Salon counterpart to get_menu', making its purpose distinct among the many 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 gives clear usage context by positioning this as the salon-specific service menu tool and noting 'salon_id and entity_id are aliases; pass either'. It does not explicitly exclude alternative tools like get_salon or get_details, but the 'Salon counterpart to get_menu' phrasing provides enough directional 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, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds valuable context by specifying the exact data types included (allowlisted facts, closure status, typed actions, past actions), which goes 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 a single sentence that front-loads the core purpose ('Compact action pack for ONE entity') and lists the included content efficiently. It has no filler, though the colon-list structure makes it slightly dense but still clear.

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 helpfully enumerates the response contents (allowlisted facts, closure status, typed actions, past actions), which gives a good picture of what to expect. It does not cover error cases or pagination, but for a single-entity retrieval with one parameter, this is 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?

With 0% schema description coverage, the description carries the burden for explaining entity_id. It only references 'ONE entity' and 'this entity', which loosely implies the parameter identifies the entity but does not explicitly define it as a unique identifier or provide format/example. This minimal compensation earns a low 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 the tool provides a 'compact action pack for ONE entity' containing allowlisted facts, closure status, typed actions, and past actions, which conveys a specific retrieve operation. It differentiates itself from siblings like get_entity and get_details by emphasizing the actionable summary nature, though the term 'action pack' is somewhat vague.

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 an agent needs to act on an entity without re-reading full pages, giving a sense of when to use it. However, it does not explicitly name alternatives or state when not to use it, leaving the differentiation to the sibling list rather than the description itself.

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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses crucial behaviors: events are 'FROZEN at emission — no free text, no generated summary anywhere,' records are structured with severity/confidence and span-grounded sources, and pagination truncation is explained ('truncated=true when more matched'). It also clarifies the 'since' filter semantics relative to emitted_at, which is not fully captured by 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 dense but every sentence adds value: purpose, record structure, filters, usage, and sibling differentiation. It is front-loaded with the core action and uses capitalization and parentheticals for scannability without wasting words.

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

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

For a read-only list tool with no output schema, the description is remarkably complete. It covers return record structure, filter semantics, pagination behavior, and the relationship to register_standing_query. The distinction from get_disruptions prevents confusion among 30+ sibling tools. Nothing significant is left unexplained.

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 full responsibility for parameter meaning. It explains 'since (ISO-8601 vs emitted_at — poll with your last poll time),' mentions geo_id and disruption_type, and details 'limit (default 100, max 1000; truncated=true when more matched).' This fully compensates for the schema's lack of parameter descriptions.

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

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

The description opens with a specific verb and resource: 'list emitted disruption events.' It further clarifies the scope with 'Travel Product B' and explicitly distinguishes this tool from the sibling 'get_disruptions' by contrasting their data sources and nature, making its purpose unmistakable.

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

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

The description gives explicit usage guidance: 'Poll this after register_standing_query, or inspect recent disruptions ad hoc.' It also states when not to use it by referencing the alternative: 'Distinct from get_disruptions (US weather/advisory alert feed): this is the corroborated, standing-query travel disruption stream.' This provides both a when-to-use and a when-not-to-use.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral disclosures: secrets are never echoed, the listing is scoped to the calling account, tenant_id cannot reference another account, and an authenticated key is required. These details meaningfully inform the agent about security and access expectations.

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

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

The description is compact and front-loaded, with the core purpose in the first line. Every subsequent sentence adds essential context (secrets, scoping, tenant_id behavior, authentication) without unnecessary fluff. The line breaks improve readability without bloating the text.

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 schema (one optional parameter), rich annotations, and no output schema, the description covers all necessary aspects: what the tool lists, the returned fields, tenant scoping rules, authentication requirements, and data privacy. It is complete for an agent to select and invoke 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?

The schema only provides the parameter name 'tenant_id' with a default of null, but the description thoroughly explains its semantics: it is optional, a sub-label within the caller's namespace, never another account's, and must match the tenant_id used during registration. This fully compensates for the lack of schema-level parameter descriptions.

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 'list YOUR registered webhook subscriptions' with specific output fields (subscription_id, url), making the tool's purpose explicit. It distinguishes itself from sibling tools like register_disruption_webhook and list_disruption_events by focusing on 'your' registered webhooks rather than events or registration.

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

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

The description provides clear usage context: it explains the calling-account scoping, that tenant_id must be the same one used during registration, and that sub-labels are separate namespaces rather than filters. It does not explicitly name alternatives or state when not to use the tool, but the context is sufficiently clear for correct selection.

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 destructiveHint=false, indicating safe, read-only behavior. The description adds that the tool returns entity counts and coverage, which aligns with the annotations. No further behavioral traits (e.g., pagination, limits) are disclosed, so it is adequate but not exceptional.

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 that efficiently conveys the core purpose. It contains no extraneous words and is front-loaded with the key action and resource.

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 zero parameters and an output schema that likely describes the return format, the description is reasonably complete. It could mention if the list is exhaustive or paginated, but for a simple enumeration, it covers the essentials.

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 no parameters, so schema description coverage is 100% (trivially). With zero parameters, the baseline is 4. The description does not add parameter details, but none are needed. It implicitly clarifies that no arguments are required.

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 specific verb 'List' and resource 'indexed publishers', clearly stating the tool's purpose. It mentions 'entity counts and coverage', which adds specificity. However, it does not elaborate on what 'coverage' means, slightly reducing clarity. It is distinct from sibling tools, none of which list sources.

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. It does not mention prerequisites, expected use cases, or exclusions. With many sibling tools, the lack of usage context reduces effectiveness.

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 flag readOnlyHint, idempotentHint, and destructiveHint false, but the description adds crucial behavior: namespacing rules ('sub-labels are separate namespaces, not filters'), that omission lists unlabeled queries, that entries are stored containment-EXPANDED queries, and the auth requirement. This goes well beyond 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 bit dense but every sentence adds value: purpose, scope, tenant_id semantics, return format, and auth. It front-loads the main function and is not bloated.

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 non-obvious namespace semantics and no output schema, the description covers the essential aspects: what is listed (your queries), how tenant_id works, what each entry contains, and the authentication requirement. It could mention error cases or pagination but is largely complete for a straightforward list 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 coverage is 0%, but the description fully explains the only parameter, tenant_id: optional, a sub-label within the caller's own namespace, must match the one used at registration, and omission has specific semantics. This is far more than the schema 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 clearly states the function: 'list YOUR registered standing disruption queries' using a specific verb and resource. It also explicitly scopes to the calling account, distinguishing it from broader list tools and sibling register/delete 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?

It provides context that this lists queries scoped to the calling account and gives precise instructions on tenant_id usage ('Pass the SAME tenant_id you registered with...'). It doesn't explicitly mention alternative tools like register_standing_query, but the 'your' scope and namespace explanation strongly imply when to use.

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

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

Annotations indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns entity counts and searchability, which provides useful behavioral context 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 a single, concise sentence with no unnecessary words, perfectly sized for the tool's simplicity.

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 and an output schema (implied), the description is complete enough to understand the tool's purpose and 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?

Tool has zero parameters, so schema coverage is complete. Baseline score of 4 is appropriate as no parameter description is needed.

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

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

The description clearly states that the tool lists configured verticals with entity counts and searchability, which is specific and distinct from sibling tools that search or filter 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 does not provide explicit guidance on when to use this tool versus alternatives, but the context of sibling tools implies it is for an overview of available verticals.

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 no behavioral info (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It discloses that the tool persists data and is read by future sessions, but does not clarify overwrite vs. append behavior or implications for concurrent sessions. With no annotation support, more detail would improve 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 two sentences, front-loading the core action and outcome list. It is efficient but could be slightly more structured by separating the outcome list from the explanation.

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 (3 params, no output schema), the description covers purpose, possible outcomes, and integration with recall/get_site_skill. It does not address error cases or the nature of persistence (overwrite vs. append), but is mostly complete for a straightforward logging tool.

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 has 0% description coverage for parameters, so the description must compensate. It provides enumerated possible values for 'outcome' and an example for 'note', adding meaningful semantics. However, it does not explain 'entity_id' or the default for 'note'.

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 'Record' and the resource 'outcome for an entity', listing specific possible outcomes (booked, visited, etc.) and explaining its role as an agent-side cookie that future recall/get_site_skill uses, which differentiates it from siblings like 'recall' and 'remember'.

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 (to record an entity outcome for future sessions) and how it relates to recall/get_site_skill, but does not explicitly state when not to use or provide direct alternatives among siblings like 'remember'.

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 destructiveHint=false. The description adds context about the content of the profile but does not disclose additional behavioral traits 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?

Two sentences that are efficient and front-loaded with the core purpose, followed by a usage example. Every sentence 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?

Given no output schema and zero parameters, the description fully explains what the tool does and when to use it, making it complete for an agent's decision-making.

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?

No parameters exist, so schema coverage is effectively 100%. The description does not need to add param information; baseline 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 clearly states it reads the agent profile, listing specific contents like remembered preferences, recent searches, and top entities. This distinguishes it from sibling tools such as 'remember' (which writes) and various search 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?

Explicitly instructs to 'Call at task start' and provides an example of reusing a remembered dietary default, offering clear guidance on when to use this tool versus alternatives.

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

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

Discloses that events are POSTed as structured JSON matching list_disruption_events, HMAC-SHA256-signed, with header format and that secret is never echoed back. This goes beyond annotations, which only provide mutation hints, and adds critical security and delivery 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 paragraph that packs multiple essential details without wasteful repetition. It is front-loaded with the primary action and subsequent sentences add value, though a slightly more structured format could improve scannability.

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

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

The description covers purpose, usage context, security specifics, and parameter semantics. It omits potential error conditions or idempotency but annotations already cover idempotentHint false, so it's reasonably complete for a registration tool.

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 coverage, description adds semantics: tenant_id is an optional sub-label in your account namespace, secret is used for signing, url is the target endpoint. It could be more explicit about url requirements but covers the key 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?

Description clearly states 'register a webhook' and differentiates from sibling tools like list_disruption_webhooks by explaining this is for push delivery instead of polling. It aligns with the tool name and title.

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 says 'Use instead of polling when you want push delivery,' providing a clear when-to-use. Also references passing tenant_id to list_disruption_webhooks for visibility, which guides usage and the alternative listing 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?

Provides detailed behavioral context: geo_ids expand through containment hierarchy, response echoes expanded query, corroboration_policy rejects unknown fields, expires_at format, and tenant_id namespace semantics. This goes well beyond the minimal 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?

Despite being a dense single paragraph, every sentence adds operational value. However, the structure could benefit from bullet points for readability; it's long 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?

Covers the tool's purpose, usage, response behavior, and parameter nuances. Missing details on lang_scope and min_severity prevent a perfect score, but overall it's highly informative for a complex 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?

Description explains geo_ids, disruption_types, expires_at, corroboration_policy, and tenant_id in depth, but does not mention lang_scope or min_severity, which remain undefined by the schema (0% 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 it registers a standing disruption query for continuous real-time monitoring of geo_ids for specific disruption_types. It distinguishes from historical sentiment tools and mentions the response echoes the expanded query, differentiating it from sibling webhook registration.

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 states 'Use when an agent needs ALERTING on future disruptions, not historical sentiment.' Also explains how to retrieve results via list_disruption_events and webhooks, and how tenant_id should be passed consistently to list/delete standing queries.

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?

Beyond annotations (idempotentHint=true, readOnlyHint=false), the description reveals key behavioral traits: persistence across sessions/API-key rotation, account-level scoping, and the security caveat that SeaWeb's credential filter is a backstop, not a guarantee. The warning 'an unlabelled secret in a free-text value will be stored as written' is critical transparency. 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 somewhat long but every sentence earns its place: purpose, examples, exclusion of credentials, and a security caveat. It is front-loaded with the core purpose and then builds context. Could trim slightly but is well-structured 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 simple 2-parameter write tool with no output schema, the description is highly complete. It covers persistence, usage, exclusions, and security behavior. It doesn't mention overwrite semantics, but idempotentHint already implies that. Given the sibling 'recall' handles retrieval, this fully covers the write side.

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 provides only key/value strings with no descriptions (coverage 0%), but the description compensates with examples that clarify key as a short identifier and value as a preference. It also explicitly says what values should NOT be (credentials), adding semantic guidance beyond the raw schema. It does not give naming conventions or length limits, so not a 5.

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

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

The description opens with a specific verb+resource: 'Save a durable preference on YOUR agent profile'. It clearly distinguishes this tool from siblings like 'recall' by emphasizing persistent account-level memory. The examples ('remember("dietary", "vegan")') further cement the intended use.

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

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

It explicitly says when to use: 'Use for defaults worth reusing' and provides three concrete examples. It also gives a clear when-not: 'Never store passwords, session cookies, or other credentials here' and states memory is for preferences, not login state. However, it does not name alternative tools (e.g., 'recall' for retrieval), so it lacks explicit alternative recommendations.

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 mark this as read-only, idempotent, and non-destructive. The description adds detailed behavioral traits: the matching order (exact diacritic-folded alias matches first, then trigram-fuzzy), the presence of similarity scores and containment hierarchy, and the semantic meaning of an empty response. This goes beyond annotations, providing valuable 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 three sentences, front-loaded with an immediate summary ('Travel gazetteer lookup'), and each sentence adds distinct information: scope, matching logic, and response interpretation. No filler 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 no output schema, so the description must explain the return values. It states candidates carry geo_ids, similarity scores, and containment hierarchy, and explicitly covers the empty-list case. This is sufficient for the agent to understand both input and output behavior.

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 0% description coverage for two parameters. The description explicitly characterizes 'text' as 'free-text place name', which adds meaning. However, it never mentions the 'limit' parameter or explains how it controls the number of candidates. This leaves a gap in parameter understanding.

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 begins with 'Travel gazetteer lookup' and clearly states that it maps free-text place names to candidate geo_ids. It specifies the scope (43k-entity gazetteer with admin divisions, cities, airports/IATA, stations) and differentiates from sibling tools as a resolver for the other travel-vertical 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 states this is for 'the other travel-vertical tools', indicating when it should be used. It also clarifies that an empty candidates list means no match, not an error, which is a usage interpretation. However, it doesn't explicitly name alternative tools or explicitly say when not to use it, so it gets a 4.

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?

Beyond the readOnly/idempotent annotations, the description discloses rich behavioral details: [SEAWEB_QUERY] header semantics, degraded mode, location_needed notes, and explicit-vs-extracted constraint precedence. This goes far beyond the annotations and prepares the agent for edge cases.

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 long but front-loaded with a clear summary and organized into focused paragraphs for parameters, location, output, and header parsing. Every sentence provides necessary operational detail, with 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?

Given the tool's complexity, the description covers the full lifecycle: parameter semantics, location handling, constraint validation, output format with canonical IDs, and special header processing. With an output schema present, this is exceptionally 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?

The input schema has 0% property descriptions, but the description thoroughly explains every parameter: vertical, intent, location, goal, constraints, and lat/lng. It also specifies allowed values, defaults, and interaction rules (e.g., explicit constraints override extracted ones, unknown keys rejected).

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

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

The description opens with 'Search any SeaWeb vertical by natural-language intent,' clearly identifying the tool's function and scope. It references list_verticals() and vertical-specific capabilities, distinguishing it from siblings like search_restaurants and search_salons.

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

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

The description provides clear usage context, such as asking for location on proximity queries and using recall() for stored preferences. However, it does not explicitly contrast this generic search with vertical-specific alternatives, 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, idempotentHint, and destructiveHint=false. The description goes beyond by disclosing deduplicated story clusters, explicit zero rows, named empty_aspects, and the cold-start behavior of the embedding model. These are valuable behavioral traits not conveyed by 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?

Although the description is substantial, every sentence carries unique operational information: purpose, exclusions, output grid, data semantics, parameter formats, prerequisite, and performance note. It is densely packed with no filler and is logically ordered, making it easy 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?

With no output schema, the description fully specifies the return structure: aspect × time-bucket grid, cluster_count, weighted mean/variance, polarity histogram, breakdowns, and top-k URLs. It also covers edge cases (zero rows, empty_aspects) and performance characteristics. For a complex 7-parameter tool, this is highly 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 explains geo_id, aspects with an enumerated subset, window_start/end as ISO-8601 with defaults, and bucket values. top_k is implied via 'top-k canonical source URLs', but langs is not explicitly described, leaving a small gap in full parameter 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 identifies the tool as destination sentiment/trend aggregates, with a specific verb ('search') implied and a resource (destination sentiment). It distinguishes itself from siblings by explicitly contrasting with real-time alerts on the standing-query/event side. The purpose is specific and actionable.

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 states exactly when to use it ('how do travelers feel about X over time') and when not to ('never for real-time alerts'), pointing to the alternative side. It also instructs to find geo_ids with resolve_geo, providing a concrete cross-tool dependency. This is explicit guidance with alternatives.

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

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

Builds on annotations (read-only, idempotent) by explaining edge cases like bookable's false meaning unfiltered, and dietary being a hard filter. 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?

Well-structured with a clear opening, then organized parameter guidance. Slightly lengthy but every part is informative; minimal 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?

Covers all necessary aspects: purpose, parameters with extraction rules, and behavioral nuances. Output schema exists, so return values need not be described.

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 compensates for 0% schema coverage by thoroughly explaining each parameter's semantics, extraction rules, and allowed values, adding significant value beyond the schema.

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

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

The description clearly states it searches restaurants by natural-language intent with location and goal filters. It is distinct from siblings like search_salons and filter_restaurants, but does not explicitly contrast with 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?

Provides explicit guidance on when to set structured parameters vs leaving in free text, noting that explicit params are more reliable. Does not address when to use this tool over alternatives like 'search' or 'filter_restaurants'.

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. Description adds value by explaining ranking behavior (same as search_restaurants) and that it returns only salons, plus parameter reuse details. 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?

Well-structured with first paragraph for purpose and bullet points for parameters. Some redundancy in parameter descriptions (e.g., location repeated), but overall efficient 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 8 parameters, 0% schema description, and presence of output schema, the description covers all parameters and adds context on ranking, vertical exclusivity, and parameter reuse. No gaps identified.

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 has 0% description coverage, but description thoroughly explains each parameter: purpose of location, goal, cuisine as service-type, price_max, dietary unused, party_size, bookable, and intent. Fully compensates for missing schema descriptions.

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?

Clearly states the tool searches for hair salons, barbershops, and beauty salons using natural language. Differentiates from sibling search_restaurants by specifying it's a separate vertical that returns only salons.

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 examples of natural-language intents and explains when to use 'bookable' parameter. Implicitly contrasts with search_restaurants, but does not explicitly state when not to use this tool or list alternatives beyond the sibling mention.

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 extensively documents behavior: verbatim quoted passages, lexical (not semantic) coverage semantics, measured drift outside travel vertical, the distinction between empty results meaning 'no retrieval' vs 'no page', error envelope shape ({error} with no coverage key), and .get() guidance. The annotations declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false, and the description is fully consistent with these (read-only, single-domain corpus, idempotent search). No contradiction. This massively exceeds the disclosure bar given annotations present.

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 has informative front-loading (first paragraph states core purpose and preference over generic search) followed by deep sections on coverage semantics, matched_on, error handling, and scope caveats. Every sentence carries signal, but it is long and wall-of-text in places; the coverage enum explanation could be tightened. It's earn-your-place throughout, though at a premium.

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?

Output schema exists, so return-value explanation is not strictly needed, yet the description explains the coverage values, match_quality, matched_on, and error envelope in far more depth than the schema. The complexity of this tool (lexical vs semantic coverage, drift caveats, refusal vs empty-result distinction) is high, and the description addresses all of it. Exceptionally 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%, and there are 2 parameters (query, limit, default 10). The description does not explain query syntax, what qualifies as a searchable term, or how limit behaves, though it does note rate-limit and 'query with no searchable terms' refusal cases. Given 0% schema coverage, the description should compensate more on parameter semantics; it mentions limit implicitly via the cheap-call cost note but never defines its meaning or bounds.

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 first paragraph states a specific verb+resource: full-text search over SeaWeb's own crawled corpus (Destination Pulse), explicitly distinguishing from generic web search and naming its companion get_disruptions. It clearly differentiates from sibling tools like search, compare_search, and search_destination_sentiment by being the owned-corpus read tool. Purpose is unambiguous and well-scoped.

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 directs when to prefer this tool ('travel and hospitality questions'), when to prefer a general web search ('for a non-travel question, prefer a general web search even when this returns covered'), when to use get_disruptions, how to handle empty/unavailable results (answer from another source, never present recollected answer), and when one reworded retry is worth it. Excludes are explicit and 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?

Description discloses that feedback affects SeaWeb's ranking to improve future searches. Annotations show no destructive or read-only hints, and the description aligns. 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 main action, no unnecessary words. Every sentence adds value.

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

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

No output schema, so description should explain return value but doesn't. It omits specifying allowed enum for 'vote' and that 'reason' defaults to empty string. Otherwise adequate for a simple feedback tool.

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%, so description carries the burden. It explains 'entity_id' as the search result, 'vote' as up/down, and 'reason' with examples. However, it does not specify allowed values for 'vote' (e.g., 'up', 'down') or that 'reason' is optional.

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 explicitly states 'Rate a search result you actually used' and defines voting up/down. It clearly distinguishes from sibling 'vote_comparison' by emphasizing feedback on results actually used at task end.

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 says 'Call at the end of a task' and provides criteria for up vs down votes. Does not explicitly exclude alternatives like 'vote_comparison', but the context 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?

The description adds non-obvious behavioral context beyond the annotations: the embedding model loads lazily on the first sentiment search, and specific infrastructure dependencies are checked. Annotations already indicate read-only, idempotent, and non-destructive behavior, so the description's extra detail is valuable, though it omits error/return 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, well-structured sentence with a useful parenthetical. It front-loads the core purpose and adds only necessary detail about what is checked and the lazy-loading behavior, with no redundancy.

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

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

For a zero-parameter health check with read-only annotations, the description is close to complete: it explains what is checked and calls out the lazy-loading behavior. However, since there is no output schema, it does not describe the return value or status details, which is a minor gap but not critical for selecting or invoking the tool.

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

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

The tool has zero parameters, so no parameter semantics are needed. The baseline of 4 applies; the description focuses on behavior rather than parameter details, which is appropriate here.

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 tool as a health check for the travel vertical service's dependencies (elasticsearch, postgres, redis, and embedding model). It is distinct from sibling tools, but it lacks an explicit verb like 'check' or 'report', so it falls short of a perfect 5.

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

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

No guidance is given on when to use this tool versus alternatives, when not to use it, or any required context. The description only states what the tool checks, leaving the agent to infer when it should be invoked.

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 write operation but not destructive. The description adds behavioral context by specifying how judged_by works and the need to pass query and track_b, but does not disclose potential side effects like overwriting or idempotency.

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

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

Two succinct sentences that front-load the purpose and then detail parameters. No unnecessary information; 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 simple record action, the description covers core behavior and key parameters. It lacks explanation of the return value and validation rules, but given the absence of output schema and the tool's simplicity, it is 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?

With 0% schema coverage, the description adds meaning for winner (allowed values), judged_by (options), and mentions query and track_b. However, the 'reason' parameter is not explained, 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 clearly states the tool records an A/B verdict after compare_search, specifying the winner options and the judged_by field. It distinguishes itself from siblings by being the dedicated tool for recording comparison results.

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 instructs the agent to use this tool after compare_search and to pass the same query and track_b. While it doesn't explicitly mention when not to use it, the context of siblings makes the usage clear.

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