Fetch a The Body Shop static page by handle and return normalized page details as clean JSON; the storefront URL is fixed server-side.
Get a The Body Shop static page. Returns normalized static page detail for one The Body Shop (https://www.thebodyshop.com) page handle. The storefront URL is fixed server-side.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | Page handle |
Changes observed during successful MCP inspections.
v1.16.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses that the output is normalized and that the storefront URL is fixed server-side, which tells the agent not to supply a URL. It does not explicitly state read-only behavior or error/edge-case handling, but for a simple lookup this is a reasonable but not comprehensive 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?
Two short sentences with no filler; the key action and resource are front-loaded, and the additional context about normalization and URL handling is placed second. 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?
For a one-parameter tool with no output schema, the description states the essential input and purpose, but it does not explain what 'normalized static page detail' contains or what happens with an invalid handle. This leaves some ambiguity about return structure, though complexity is low.
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 already describes 'handle' as 'Page handle' (100% coverage), so the baseline is 3. The description adds that this is a The Body Shop (thebodyshop.com) static page handle and that the URL is fixed server-side, clarifying that the handle is the only needed input and reducing confusion about URL construction.
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 a specific action ('Get') and resource ('The Body Shop static page'), and further specifies 'one ... page handle' to indicate a singular lookup. This distinguishes it from sibling tools like thebodyshop_pages (list) and thebodyshop_product (product data) without opening schemas.
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 implies usage by describing the input ('one ... page handle') and output ('normalized static page detail'), so an agent knows to call it when a single static page is needed. However, it does not explicitly mention alternatives or exclusions, such as when to use thebodyshop_pages instead, leaving routing somewhat to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.