MetaSearch MCP

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds that the output is a comparison of readiness scores, errors, warnings and issues across packs, but the return shape is already covered by the output schema, so net additional behavioral disclosure is modest.

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

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

A single tight sentence with the verb front-loaded and no filler. Every clause (same feed, multiple packs, compared scores/errors/warnings/issues) carries information.

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

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

With a full-coverage schema, an output schema, and rich read-only annotations, the description supplies everything an agent needs to select and call the tool. Minor omission: no hint about relative cost or latency when fanning out across up to six targets, which is the main behavioral risk of a comparison 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 description coverage is 100% and the schema already documents the format override, 2 MB content limit, and the optional targets list with its enum and 'omit for all targets' default. The description contributes only the general framing of 'multiple platform rule packs', which maps loosely to targets but adds no syntax or constraint detail 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?

Names a precise verb-resource pair ('run the same static feed through multiple platform rule packs and compare readiness scores') and clearly distinguishes itself from the single-target validate_* siblings by virtue of being a multi-pack comparison. An agent can tell it apart from validate_feed or validate_wego_hotel_feed without opening a schema.

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?

Implied usage is clear: use this when you want one feed checked against several platforms at once rather than a single validator. However, it never names an alternative tool (e.g. validate_feed for single-target checks or compare_platform_requirements for requirement-level questions) or states when comparison is not appropriate, so the routing guidance is left to inference.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the framing that results are "documented or readiness-oriented" and does not disclose anything about output shape beyond that; with annotations carrying the load, 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?

A single front-loaded sentence with no filler; the verb, scope and intended timing are all in one clause. Nothing is wasted and nothing important is buried.

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, single-optional-parameter tool with a full output schema, the description covers the essentials. The residual gap is the ambiguity between "documented" and "readiness-oriented" results and how they relate to compare_feed_readiness, which an agent would have to resolve on its own.

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

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

Schema coverage is 100% and the schema already documents the targets enum and the omit-to-use-all behavior. The description's phrase "across supported hotel and catalog platforms" merely echoes what the enum lists, adding no syntax or semantic detail 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?

States a specific verb (compare) and resource (field requirements across supported hotel and catalog platforms) plus the design phase it serves. It is clearly distinct from the validate_* siblings, though it does not explicitly distinguish itself from the very similar compare_feed_readiness.

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?

"Before designing a feed mapping" implies the usage moment, but there is no explicit contrast with the near-identical compare_feed_readiness or with the per-platform validate_* tools. The agent must infer which comparison tool applies when.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered; the description's contribution beyond that is limited to reinforcing that this is a pre-processing detection step. It says nothing about conflict handling when formatHint disagrees with the payload, or about ambiguity/mixed-format behavior. Added value over structured fields is modest.

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

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

A single front-loaded sentence with zero filler; the verb, the resource, the format enumeration, and the pipeline position are all packed in without redundancy.

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

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

With an output schema present, the description need not describe return values, and the two-parameter schema is fully documented. What remains missing is guidance on formatHint-conflict resolution and low-confidence detection, which is minor for a stateless detection utility. Nearly complete for the tool's complexity.

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

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

Schema description coverage is 100% for both parameters, including the 2 MB maxLength and the enum semantics of formatHint, so the schema does the heavy lifting. The description mentions the payload and the format set but adds no syntax, precedence, or edge-case guidance beyond what the schema already states. Baseline 3 applies.

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

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

States a specific verb (Detect) and resource (feed format), enumerates the candidate formats (JSON, NDJSON, XML, CSV, TSV), and positions the tool relative to the validate_* siblings by saying it runs 'before parsing or validation'. An agent can distinguish it from validate_feed and normalize_hotel_feed without opening any schema.

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

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

The phrase 'before parsing or validation' clearly signals the pipeline stage at which this tool belongs, implicitly routing the agent away from the validate_* siblings. It does not name an explicit alternative or state exclusion conditions, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value with 'without changing the source payload', clarifying that normalization is a derived-view operation and the input is untouched. It stops short of describing how aliases are resolved or what the canonical shape contains.

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

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

A single tight sentence that front-loads the action and ends with the key non-mutation guarantee. No filler and nothing redundant with the title.

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

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

An output schema exists, so return values need not be explained, and the input schema is fully described. The only gap is the absence of any guidance on selecting this tool over its many validate_* and compare_* siblings, which matters given the crowded toolset.

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

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

Schema description coverage is 100%, so format, target, and content are already fully documented in the schema. The description adds no format syntax, target semantics, or size limits beyond what the schema provides, making the baseline 3 correct.

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 pair (parse, normalize) and resource (hotel feed), and the phrase 'canonical hotel-record shape' communicates the transformation intent. It distinguishes itself implicitly from the validate_* siblings by being a transform rather than a validator, but never names an alternative to route against.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of the sibling tools (validate_feed, detect_feed_format, suggest_feed_fixes) that an agent must choose between. The usage context is only inferable from the verb 'normalize'.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description usefully adds that the issues are 'deterministic' and that output is remediation actions, but it says nothing about how remediation is scoped, whether suggestions are guaranteed or advisory, or any size/rate constraints beyond the schema's 2 MB cap.

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

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

A single front-loaded sentence: the action and scope come first, the differentiating outcome second. No filler, no repetition of the title or schema fields.

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

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

An output schema exists, so return values need not be described, and the required target/content pairing is implied by 'supplied feed for one target.' However, for a tool sitting in a crowded validation family, the absence of routing guidance leaves the definition only marginally complete.

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

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

Schema description coverage is 100%, so the enum values, format override, and 2 MB content limit are all documented in the schema. The description only restates 'for one target' and 'supplied feed,' adding no meaning beyond what the structured fields already convey — baseline 3 applies.

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

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

The description names a specific verb (validate) and resource (a supplied feed), plus the distinctive outcome of turning issues into 'remediation actions for the affected records.' That remediation angle separates it in spirit from the many validate_* siblings, but the description never explicitly contrasts itself with validate_feed or the per-target validators, so the differentiation must be inferred.

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

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

There is no when-to-use guidance at all. With eleven siblings clustered around validation (validate_feed, validate_wego_hotel_feed, validate_google_hotel_center_list, etc.), an agent is given no rule for choosing this tool over plain validation, and no prerequisites or exclusions are stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds the validation surface (coverage, IDs, URLs, images) but says nothing about how failures are reported or whether it only diagnoses without fixing — relevant since suggest_feed_fixes exists as a sibling.

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

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

A single front-loaded sentence with no filler, leading with the verb and the Criteo scope. It is efficient, though the terse list-style tail leaves room without being 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?

An output schema exists, so return values need not be explained, and annotations cover safety. Still, for a validation tool competing with several platform-specific validators and fix-suggestion siblings, the description omits what a failing result means and when this one is the right choice.

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

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

Schema description coverage is 100% and both parameters (content, format enum) are documented in the schema itself, including the 2 MB limit and auto-detection behavior. The description adds no parameter-level meaning, so the baseline 3 applies.

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

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

States a specific verb ('Check') and resource ('a product or travel catalog') scoped to Criteo import readiness, and enumerates what is inspected (content coverage, IDs, URLs, images). It is clearly distinct from the Google/Meta/Trivago/Wego siblings by naming Criteo, but it never explicitly contrasts itself with the closest sibling validate_feed.

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

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

There is no statement of when to run this versus validate_feed, validate_meta_catalog, or compare_platform_requirements, nor any prerequisite (e.g. run before import, after normalize). Usage can only be inferred from the Criteo-specific name.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety and network profile is covered. The description adds the useful 'static/supplied feed' nuance (content comes from a pasted payload, not a fetched URL), but says nothing about how results are reported, error semantics, or whether validation is purely diagnostic.

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

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

A single front-loaded sentence with no filler, leading with the verb and resource before the qualifiers. The nested 'one selected platform rule pack or the generic hotel master-data audit' phrasing is dense but each clause carries meaning.

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

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

An output schema exists so return values need no explanation, and all three params are fully documented in the schema. The remaining gap is routing: the description never clarifies how this generic validator relates to the per-platform validator siblings sharing the same target values, which is the main thing an agent needs in this tool set.

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

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

Schema description coverage is 100%, so the schema already explains format, target and content, including enums and the 2 MB limit. The description only adds the 'one selected' single-target constraint, which is close to restating the schema; baseline 3 is appropriate.

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

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

States a specific verb and resource ('Validate a supplied static hotel or catalog feed') and scopes it to 'one selected platform rule pack or the generic hotel master-data audit', which signals it is the general-purpose dispatcher. It does not, however, acknowledge the per-platform siblings (validate_wego_hotel_feed, validate_google_hotel_center_list, etc.) that cover the same targets, so an agent cannot fully disambiguate from the text alone.

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

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

Usage is implied by the target selection ('one selected platform rule pack or the generic hotel master-data audit' plus the single-target wording), so an agent can infer it must pick one target. But there is no explicit when-to-use vs when-not, and nothing routes the agent to the equivalent platform-specific validator siblings that share the same target enum.

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 establish this as a safe, read-only, idempotent, non-destructive, closed-world operation, so the bar is lower. The description adds genuine value beyond them by disclosing the validation scope, notably the conditional 'phone or geo requirements' rule, which tells the agent what class of errors to expect.

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

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

A single front-loaded sentence with no filler; the verb and target resource come first. It is slightly repetitive ('Hotel Center Hotel List') and terse enough that it omits useful routing detail, but nothing is wasted.

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 an output schema covering return values and annotations covering the safety profile, the description only needs to convey what is validated and for which feed, which it does. The main residual gap is that it does not say whether validation stops at the first error or reports all issues, but that is likely in the 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?

Schema description coverage is 100%, with both content and the format enum fully documented in the schema itself (format values, auto-detection behavior, 2 MB limit). The description adds no parameter-level detail, so the baseline 3 for schema-driven documentation 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?

States a specific verb (Validate) and a specific resource (Google Hotel Center Hotel List static feed), and enumerates what is checked (identifiers, address, country, phone/geo requirements). This distinguishes it from the generic validate_feed and validate_hotel_master_data siblings by naming the target platform, though it does not explicitly contrast itself 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?

The description implies its usage context by naming the exact feed type it accepts, so an agent knows to use it for Google Hotel Center lists rather than other platforms. However, it gives no explicit when-to-use/when-not guidance and never names the generic validate_feed or detect_feed_format alternatives that a caller might otherwise pick.

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, destructiveHint=false, and a closed-world scope, so the safety profile is covered. The description adds the platform-agnostic framing but discloses nothing else - no validation policy, no failure behavior, no statement of what 'audit' returns. With annotations carrying the load, this is adequate but thin.

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

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

A single front-loaded sentence with no filler or restatement of the title. 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?

With a full output schema, 100% schema coverage, and rich annotations, the description needn't explain inputs or return values. What it lacks is routing context in a crowded family of validators - it never says how it relates to the platform-specific validate_* tools or to normalize/suggest_feed_fixes, which is the main remaining gap.

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

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

Schema description coverage is 100% and both parameters (content, format) are fully documented in-schema, including the 2 MB limit and the auto-detection enum. The description contributes no parameter meaning beyond that, so the baseline 3 is correct.

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

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

States a specific verb plus resource plus scope: a 'quality audit' of 'hotel master-data' that is 'platform-independent'. The 'platform-independent' qualifier implicitly separates it from the platform-specific siblings (validate_google_hotel_center_list, validate_wego_hotel_feed, etc.), but no sibling is named, so the differentiation is inferred rather than explicit.

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

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

Usage is only implied: the word 'platform-independent' signals this is the generic validator to reach for when no platform-specific validator applies. There is no explicit when-to-use, when-not-to-use, or hand-off guidance (e.g., to suggest_feed_fixes or to a platform-specific sibling), which matters given twelve closely related siblings.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description's one addition is the disclaimer that results are not official Meta certification, which is genuinely useful framing about what the output means, but it says nothing about auth needs, limits, or what the check actually inspects.

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

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

Two short sentences, zero filler, with the core purpose front-loaded and the qualification appended. Nothing to trim and nothing buried.

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 an output schema present, return values need no explanation, and annotations carry the safety profile, so the description only needs to cover scope and routing. It covers scope adequately but leaves the agent without any signal on what checks run or how this differs from its eleven sibling validators, which is the main remaining gap.

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

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

Schema description coverage is 100%: both 'format' and 'content' are fully documented in the schema, including the auto-detection enum and the 2 MB limit. The description adds nothing about parameters, so the baseline 3 applies.

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

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

States a concrete verb+resource: checking a hotel/travel catalog for 'Meta mapping and catalog readiness'. The Meta focus implicitly distinguishes it from the Criteo, Google, Trivago, Wego and generic validate_feed siblings, though it never names one to route an agent explicitly.

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

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

Usage is only implied: you call this when you want to know whether a catalog is ready for Meta. There is no stated condition for choosing it over validate_feed or the other platform validators, and no prerequisites. The 'not official Meta certification' caveat is a useful scoping note but not usage guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only that validation is measured against trivago's published requirements; it says nothing about return behavior, partial-pass handling, or error detail, though the output schema exists to carry that.

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

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

A single efficient sentence that front-loads the verb and resource with zero filler. It is appropriately sized, though it sacrifices a little completeness to brevity.

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

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

With an output schema present, return values need no explanation, and the input schema is richly documented. The description supplies the validation target and format scope, which is nearly enough for this low-complexity, two-parameter tool; only the when-to-use routing is thin.

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

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

Schema description coverage is 100%, so both parameters (format override and content) are already fully documented, establishing the baseline of 3. The description's 'CSV or JSON' phrasing is narrower than the format enum and adds no syntax or size guidance 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?

Specific verb (validate) plus resource (hotel inventory) plus the target standard (trivago FastConnect Hotel Data requirements), which clearly distinguishes it from sibling validators like validate_google_hotel_center_list or validate_wego_hotel_feed. The only flaw is that it says 'CSV or JSON' while the schema enum also supports XML, TSV and NDJSON, understating scope.

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

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

Usage is implied by the trivago-specific framing, so an agent can infer this is the validator for trivago feeds versus the other platform validators. However, it never states when to use it, prerequisites, or how it relates to siblings like validate_feed or compare_platform_requirements.

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, non-destructive, and closed-world, so safety is covered. The description adds that validation is against 'published requirements and data-quality checks' and that the feed is static, but does not disclose severity levels, whether all issues are returned or only the first, or any size/rate constraints beyond what the schema states.

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

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

A single sentence, front-loaded with the verb and resource, with no filler or repetition of the title. It is efficient, though the brevity is partly what leaves the usage and behavior gaps.

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 rich annotations and an output schema, return-value explanation is not needed, and the 2-parameter surface is fully described. However, 'published requirements' is left unelaborated (which spec revision, which check categories), so an agent cannot predict what kinds of problems the validator will surface.

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

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

Schema description coverage is 100%, and both parameters (content, format enum) are fully documented in the schema, so the baseline is 3. The description adds only the notion that the feed is 'static' and format-agnostic; it contributes no extra syntax or constraint detail 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?

States a specific verb and resource ('Validate a static hotel feed') and scopes it to Wego-oriented published requirements plus data-quality checks, which separates it from the Google/Trivago/Criteo validators in the sibling list. It stops short of explicitly contrasting itself with generic siblings like validate_feed or validate_hotel_master_data, so it is clear but not maximally differentiated.

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

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

The description gives no when-to-use guidance, no prerequisites, and never names an alternative such as detect_feed_format (to identify format first) or validate_feed (platform-agnostic). The reader must infer from the tool name alone that this is the Wego-specific validator.

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