Dónde está la infraestructura y qué se puede afirmar sobre ella. Llámalo ANTES de decir nada sobre el datacenter o la ubicación: incluye afirmaciones frecuentes que son falsas y que conviene no repetir.
| 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?
Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description explains that the tool surfaces common but false assertions that should not be repeated. This is valuable behavioral context that helps the agent use the output critically, not just mechanically.
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, front-loaded with the core purpose, and every sentence adds value. The directive about when to call it is placed prominently and aids correct usage without 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 tool has no parameters, a rich annotation set, and an output schema, the description fully covers what an agent needs: what the tool returns, why it matters, and when to invoke it. Nothing critical is missing.
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 tool has zero parameters and an empty input schema, so there is no parameter documentation burden. The description does not need to explain parameters, and the baseline for no-param tools 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 clearly states the tool's purpose: it provides information about where the infrastructure is located and what claims can be made about it. It also distinguishes itself from the sibling tools by focusing specifically on infrastructure facts versus products, policies, or SLAs.
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, actionable advice: call this tool BEFORE making any statement about datacenter or location. It does not name sibling alternatives or provide exclusions, but the directive is strong and context-specific.
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.