Fetch complete details for one product by id (e.g. roller-blockout, venetian-25mm-aluwood). Returns all available colours with in-stock status, materials, features, and maximum supported dimensions. Use before configure_product to confirm a colour exists and is in stock before committing.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does well by listing exactly what is returned: colours with in-stock status, materials, features, and maximum supported dimensions. It implies a read-only fetch operation. It does not cover failure modes or permissions, but the disclosure is solid for a simple read tool.
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 purpose and return payload, the second gives usage context. No wasted words, important details are front-loaded, and the format is easy to scan.
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?
Although there is no output schema, the description enumerates the main return fields and connects the tool to the configure_product workflow. It could mention possible absence of pricing or error behavior, but for a single-parameter retrieval tool, the description is sufficiently 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 schema only defines product_id as a string with no description. The description compensates by explaining that the id is a product identifier and providing realistic examples (roller-blockout, venetian-25mm-aluwood), adding meaningful format context beyond the bare 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 starts with a specific verb and resource: 'Fetch complete details for one product by id,' immediately clarifying the tool's primary behavior. It also provides concrete examples of product IDs, distinguishing it from search or listing siblings like search_products and lookup_catalog.
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 when to use: 'Use before configure_product to confirm a colour exists and is in stock before committing.' This is clear contextual guidance, though it doesn't mention alternatives (e.g., check_colour_stock) or explicit when-not-to-use scenarios.
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.
Most tools have clearly distinct purposes, but search_products and lookup_catalog overlap significantly in filtering by category and dimensions, which could confuse an agent. The three search/filter tools have subtle differences described, but the overlap lowers the score from perfect.
All tools use consistent snake_case with verb-noun structure (e.g., cancel_cart, get_product, update_checkout). There is no mixing of conventions, and the verbs clearly indicate the action, making the set predictable and easy to parse.
26 tools is slightly above the typical well-scoped range of 3-15, but the domain of an e-commerce blinds shop with additional services like AR, swatches, and price matches justifies the count. A couple of legacy tools (create_order, submit_enquiry) add minor bloat.
The core purchase flow (search, configure, cart, checkout, payment, order tracking) is fully covered. Additional services like AR visualization, swatches, price match, and WhatsApp handoff are present. Missing features like order listing or coupon application are minor gaps.