One product: the UCP product object in structuredContent, and the schema.org Product JSON-LD the product page publishes as text.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Product slug, e.g. nord-trail-boot, or a variant SKU. | |
| slug | No | Deprecated alias for id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully states that the result includes both a UCP product object and schema.org JSON-LD text, which is meaningful output information. However, it does not mention read-only behavior, error cases, or what happens when the product is not found.
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?
The description is short and mostly information-dense, but the phrasing 'One product:' is somewhat awkward and not front-loaded with a clear action. It could be more readable as 'Returns a single product as...' while keeping the same length.
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?
Given the simple two-parameter schema and no output schema, the description provides some essential return-value context. However, it relies on unexplained jargon ('UCP product object', 'structuredContent') and omits edge-case behavior, making it adequate but not fully 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 schema already documents both id and slug, including that slug is a deprecated alias for id. The description adds no additional parameter meaning, so the baseline score of 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 communicates that the tool returns exactly one product and specifies the two representations returned (UCP structuredContent object and schema.org JSON-LD text). The singular 'One product' helps differentiate it from list_products and search_catalog, though it lacks an explicit verb like 'retrieves'.
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 guidance on when to use get_product versus siblings like check_stock, lookup_catalog, or search_catalog. It does not state exclusions or preferred invocation contexts, leaving the agent to infer usage from the tool name and singular phrasing.
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.
check_stock and report_problem are clearly distinct, but four product-retrieval tools overlap: get_product, lookup_catalog, search_catalog, and list_products all return product data in similar forms, and search_catalog with no query duplicates list_products. Their descriptions help somewhat, but an agent could reasonably misselect between get_product and lookup_catalog or between list_products and search_catalog.
All six tools use a consistent verb_noun snake_case pattern: check_stock, get_product, list_products, lookup_catalog, report_problem, and search_catalog. There are no mixed conventions or irregular verbs.
Six tools is a reasonable size for a catalog and stock server. The count is neither bloated nor too thin, and each tool has a clear operational role even where retrieval boundaries are fuzzy.
The read-only catalog surface is well covered: search, identifier lookup, single-product details, full listing, and live stock/price are all present. The report_problem tool also covers the main dead-end failure mode for an agent, so there are no obvious missing reads.