search
Search published English hotel guides. Returns document IDs and canonical source URLs.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Search published English hotel guides. Returns document IDs and canonical source URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the return payload (document IDs and canonical source URLs), which is useful, but says nothing about result ordering, pagination beyond the limit param, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the resource scope front-loaded and the return contract second. No filler, no repetition of the schema, nothing that fails to earn 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 no output schema, the description correctly steps in to name the return fields, and the strong annotations remove the need to discuss safety. However, for a search tool with two wholly undocumented parameters it stops short of explaining query interpretation or how limit shapes results, so it is only minimally 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 the description documents neither parameter. Only 'English' hints at query semantics; the limit parameter's default, max of 20, and effect on result count are never explained anywhere in prose, leaving the schema's bare types to carry both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Search) and resource (published English hotel guides) plus the shape of the result (document IDs, canonical source URLs). It is clear enough to act on, but it never distinguishes itself from the sibling find_hotels or get_destination_guide, both of which plausibly overlap with 'hotel guides'.
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 use this tool versus compare_hotels, find_hotels, or get_destination_guide, and no exclusions or prerequisites. Usage is only implied by the word 'Search'; an agent must guess whether it wants guide documents or hotels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.