UCP 2026-04-08 catalog lookup: resolve one or more product or variant identifiers (slug or SKU) to UCP product objects.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Product ids (slugs, e.g. nord-trail-boot) or variant ids (SKUs, e.g. MGN-204). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose that input identifiers are resolved to UCP product objects, which indicates a read-style lookup and names the return type. However, it does not describe not-found behavior, partial failure handling, or whether the returned product objects are full or summarized.
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 entire description is one front-loaded sentence that conveys the versioned catalog context, the input types, and the output type with no filler or redundant words. It is appropriately sized for a simple single-parameter lookup tool.
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?
The tool is simple, has one well-documented parameter, and names its output type, so the core invocation context is present. However, the absence of an output schema and the lack of guidance around unmatched identifiers or alternative sibling tools leaves minor but relevant gaps for an autonomous agent.
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 has 100% parameter documentation with clear examples for slugs and SKUs. The description adds the clarifying notion that one or more identifiers are accepted, but this is largely redundant with the array type. There is no meaningful semantic gain beyond the 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 uses a specific verb ('resolve') and identifies both the resource ('UCP 2026-04-08 catalog') and the input/output relationship ('product or variant identifiers (slug or SKU)' to 'UCP product objects'). This clearly differentiates it from search_catalog, which would be query-based, and list_products, which would not resolve specific identifiers.
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 the tool should be used when you have concrete product or variant identifiers to resolve, but it does not explicitly state when to avoid it or name alternatives such as search_catalog or get_product. The usage context is inferable, not stated.
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.