Fetch Burberry search-box suggestions for a partial query, returning suggested phrases with live result counts to guide search input.
Get Burberry search-box suggestions. Returns Burberry's own search-box suggestions (typeahead) for a partial query: a flat list of suggested search phrases, each with its own live result count on the search index. Not product data.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Partial search query |
Changes observed during successful MCP inspections.
v1.17.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output structure (flat list of suggested search phrases, each with a live result count) and explicitly excludes product data. It does not detail limits or error behavior, but for a read-only suggestion tool this is a strong description.
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: the first states the core purpose, the second describes output shape and explicitly corrects a likely misassumption. There is no fluff or redundant text, and the most important 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 one-parameter suggestion tool with no output schema, the description adequately explains the return value and what it is not. It lacks details about pagination, limits, or empty-response behavior, but these are less critical for a typeahead endpoint. It is complete enough for an agent to invoke 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 sole parameter 'query' already has 100% schema description coverage ('Partial search query'). The description reinforces that it is for partial queries and adds typeahead context, but it does not add substantive new detail about query formatting, length, or constraints. Baseline 3 applies because the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('Burberry search-box suggestions'), explicitly states the return type (flat list of suggested search phrases with live result counts), and clarifies 'Not product data' to distinguish from product-focused siblings like burberry_product. It clearly delineates this typeahead suggestion tool from a search or product endpoint.
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 partial queries ('for a partial query') and clarifies what the tool is not ('Not product data'), but it does not explicitly name alternative tools (e.g., burberry_search) or state when NOT to use this tool. The intended context is inferable but not fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.