Estado del catálogo: cuándo se generó, si está fresco, y si cada fuente se pudo leer. Consúltalo antes de afirmar un precio. «No hay discrepancias» y «no se pudo leer la fuente» son cosas distintas y aquí se ven distintas.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds an important behavioral nuance: distinguishing 'no discrepancies' from 'source could not be read'—a subtle trap that could mislead an agent. This goes beyond what annotations state.
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 are packed with essential information: what the tool reports, when to call it, and the critical interpretation caveat. No redundancy or filler.
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 output schema exists and annotations cover safety, the description supplies all necessary operational context. It explains the key semantic distinction and the correct trigger scenario, making the tool fully callable by an 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?
There are no parameters, so schema coverage is effectively 100%. The description correctly focuses on output semantics rather than parameters, and the baseline of 4 applies for a zero-parameter tool.
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 reports catalog status: generation time, freshness, and whether each source was readable. It uses a specific resource (catalog) and provides a concrete use case, distinguishing it from the sibling pricing/ordering tools.
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 explicit guidance on when to use it: 'Consúltalo antes de afirmar un precio' (consult it before asserting a price). It does not list exclusions or alternatives, but no sibling tool overlaps with this status-check function, so the context is sufficient.
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.
Cada herramienta tiene un propósito claramente diferenciado: estado del catálogo, búsqueda, comparación, ficha, cotización, pedido, infraestructura, políticas y SLA. Aunque varias empiezan por get_, sus dominios no se solapan y las descripciones refuerzan cuándo usar cada una.
La mayoría sigue el patrón verbo_sustantivo en snake_case (search_products, compare_products, create_draft_order, get_product). Se desvían quote, que es solo un verbo, y catalog_status, que parece un sintagma nominal en lugar de get_catalog_status; son desviaciones menores y no generan confusión.
Nueve herramientas es un tamaño adecuado para un catálogo de hosting: cubren consulta, comparación, cotización y pedido sin llegar a ser un servidor de administración. Cada herramienta tiene un rol claro y ninguna sobra.
El flujo principal está completo: conocer la frescura del catálogo, buscar, comparar, obtener fichas, cotizar y crear un pedido en borrador, además de las consultas legales, de SLA e infraestructura. No se echan en falta operaciones de escritura porque el servidor es explícitamente de consulta y no cobra ni contrata.