open_catalog_selectorOpens the catalog selector — a graphical product picker (MCP Apps widget) that shows active products with prices (ARS) and stock. Side-effect-free (no sale, no charge).
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional name filter (case-insensitive substring match). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Side-effect-free (no sale, no charge)', which reinforces and clarifies the annotations (readOnlyHint=true, destructiveHint=false). It also discloses what the widget shows (active products with prices and stock), adding behavioral context beyond the structured annotations. No contradiction with annotations.
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 two sentences, front-loaded with the verb and resource, and contains no filler. It efficiently conveys purpose, content, and safety in a compact form.
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 tool's simplicity (one optional parameter, no output schema), the description adequately covers purpose, displayed data, and safety. It lacks explicit connection to the sales flow or alternatives, but these are not essential for basic usage. The absence of an output schema is acceptable since the tool opens a UI widget rather than returning structured data.
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 input schema fully describes the single 'search' parameter with 100% coverage (case-insensitive substring match), so the description adds no additional parameter semantics. The description does not mention the parameter, but the schema already provides sufficient detail, warranting the baseline score of 3.
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 the tool 'Opens the catalog selector' and identifies it as a 'graphical product picker (MCP Apps widget)', distinguishing it from data-query siblings like query_catalog. It specifies the resource (active products) and the displayed attributes (prices in ARS, stock), making the purpose unambiguous.
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 when a graphical, UI-based product picker is needed, but it does not explicitly contrast with alternatives such as query_catalog or state when not to use it. The 'Side-effect-free' note hints at safe usage, but there is no explicit when/when-not guidance.
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.
Several tools duplicate the same underlying data in different presentation modes (get_payment_intent_status vs open_cobro_status, query_catalog vs open_catalog_selector, connection_status vs open_onboarding), creating ambiguity. Descriptions mention 'widget' vs JSON but an agent could easily pick the wrong one for a given task.
Tool names mix Spanish and English (caja_consultar_saldo vs validate_cuit) and use varying verb prefixes (open_, query_, get_, list_, find_, track_, quote_, validate_); only the open_ prefix is consistent.
22 tools sits at the high end of the borderline range; the server covers multiple domains (catalog, shipping, payments, fiscal) which justifies many tools, but some widgets and query equivalents could be consolidated.
The surface is heavily read-only: there are no create/update/delete tools for customers, suppliers, or products, and the only way to register a sale is through a widget that fires an internal function. There are also no tools to actually create a payment link or charge, leaving transactional workflows incomplete.