Prepara un pedido y devuelve el enlace del carrito para que lo complete una persona. Este servidor NUNCA cobra ni contrata. Si el catálogo está rancio o alguna fuente no se pudo leer, no devuelve enlace: con el dato dudoso no se vende.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| quantity | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by explicitly stating that the server never charges or contracts, and that it will not return a link if the catalog is stale or a source could not be read. This adds meaningful safety and failure behavior context. It aligns with the readOnlyHint and destructiveHint annotations rather than contradicting them.
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 concise: two sentences with the primary action and output front-loaded, followed by a short safety/failure policy. Every sentence adds value, and there is no 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?
For a low-complexity tool with an output schema and rich annotations, the description covers the main outcome, safety guarantees, and a key failure mode. It lacks explicit parameter semantics and sibling differentiation, but the tool is simple enough that an agent can still invoke it correctly.
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 has 0% description coverage, and the tool description does not explain what 'name' or 'quantity' mean. An agent must infer that 'name' likely refers to a product or item and 'quantity' to the count, but the description provides almost no clarification or constraints beyond the schema defaults.
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 function: preparing an order and returning a cart link for a person to complete. It also adds a distinguishing purpose ('for a person to complete') and emphasizes that it never charges or contracts. It doesn't explicitly name a sibling alternative, but the behavior is specific enough to identify.
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 a human needs to complete a purchase, and it mentions conditions under which no link is returned. However, it does not explicitly compare with alternatives like 'quote' or 'search_products', nor does it specify when not to use this tool.
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.