Catálogo vivo de hosting y servidores cloud en Colombia. Precios en pesos, con fecha de lectura.
Scored across 10 tools
Each tool has a clearly distinct purpose: status checking, comparison, ordering, infrastructure facts, policies, product details, service lines, SLA, quoting, and search. No two tools overlap in function, and the descriptions reinforce their unique roles, eliminating ambiguity.
Most tools follow the verb_noun pattern (get_product, search_products, compare_products, create_draft_order). However, 'catalog_status' is a noun phrase rather than a verb-led name, and 'quote' is a bare verb without a noun object, creating minor deviations from the otherwise consistent convention.
With 10 tools, the server is well-scoped for a catalog and hosting service. Each tool earns its place by covering a distinct aspect of the domain—search, retrieval, comparison, quoting, ordering, and contextual information—without unnecessary bloat or missing essentials.
The tool surface is comprehensive for a catalog server: it covers status checks, search, detailed product/service info, comparison, quoting, draft order creation, policies, SLA, and infrastructure facts. There are no obvious gaps that would prevent an agent from completing typical workflows like finding, comparing, and quoting plans.
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 parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
Compara dos o más planes por nombre, uno al lado del otro. Devuelve además los nombres que no existen en el catálogo, que es información útil y no un error.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral nuance by stating that non-existent catalog names are returned as useful information rather than an error. This goes beyond the annotations without 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 two sentences with the core behavior front-loaded. The second sentence adds a valuable, non-obvious output detail without 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?
This is a simple one-parameter tool with a rich output schema and strong annotations. The description covers the comparison semantics, the required minimum input, and the notable behavior around unknown names, leaving no critical operational gap.
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?
Schema coverage for the only parameter is 0%, so the description must compensate. It clarifies that 'names' refers to plan names and implies at least two are needed ('dos o más planes'). It does not address details like duplicate names or exact matching, but it provides the essential meaning.
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 ('compara'), a clear resource ('planes'), and a concrete method ('por nombre, uno al lado del otro'). This clearly distinguishes it from sibling tools like get_product or search_products, which do not imply side-by-side comparison.
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?
When to use the tool is implied by the comparison verb, but no alternatives are explicitly mentioned and there is no when-not-to-use guidance. It is only inferred that you should use this when comparing two or more plans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 |
|---|---|---|
No output parameters | ||
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.
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 parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
Términos y condiciones, política de tratamiento de datos y demás documentos legales, con sus direcciones canónicas.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds that the return value includes legal documents and their canonical addresses, which is useful context, but it does not disclose more about response format, language, or whether full content or just references are returned.
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 a single concise sentence with no filler. It front-loads the specific legal documents and includes the useful detail about canonical addresses. Every word contributes.
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 parameterless getter with an output schema and strong annotations, the description is nearly complete. The main gap is the absence of usage guidance, but nothing essential for invoking the tool correctly 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 100% schema description coverage, so there is nothing the description needs to explain about parameters. This is a baseline-4 case where parameter semantics are trivially satisfied.
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 identifies a specific resource: legal documents including terms and conditions, data processing policy, and other legal documents, along with their canonical addresses. It lacks an explicit verb like 'retrieves' or 'lists,' but combined with the tool name it is clear and distinguishable from siblings like get_sla.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention exclusions, alternatives, or context such as 'use this for legal documents and get_sla for service agreements.' The usage context is only implied by the content of the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ficha completa de un plan por su nombre exacto: precio de cada período en que se vende (prices), recursos, de qué fuente salió cada dato y cuándo se leyó. Si el plan no está en el catálogo devuelve null: eso significa que no se puede comprar, aunque alguna página lo anuncie.
Los recursos se leen dos veces dentro del sistema de facturación: lo que el módulo entrega y lo que la ficha anuncia. Cuando coinciden se publica el valor; cuando no, el recurso NO va en resources sino en resources_under_review con lo que dice cada fuente, y eso hay que consultarlo, no afirmarlo. resources_note explica los casos en que no hay recursos que dar: un certificado SSL no es alojamiento, y los límites del hosting Windows los define su panel.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses substantial non-obvious behavior: resources are read from two sources, mismatches are routed to `resources_under_review` and must not be asserted as facts, and `resources_note` explains edge cases like SSL certificates and Windows hosting limits. This is exactly the kind of behavioral context an agent needs.
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 first sentence front-loads the core purpose and the subsequent paragraphs add necessary caveats about resource reconciliation and null semantics. It is longer than strictly necessary, but the extra detail is substantive rather than filler, and the structure is logical.
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 description covers input expectations, found and not-found return behavior, resource provenance, reconciliation edge cases, and the meaning of `resources_note`. With an output schema already present, it does not need to re-list return fields, and nothing essential for correct invocation 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 input schema only provides `name` with no description (0% schema coverage). The description compensates by explaining that the name must be exact and that a missing catalog entry returns null. It does not specify formatting or case sensitivity, but for a single string parameter this is reasonable and useful.
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 opens with 'Ficha completa de un plan por su nombre exacto', clearly stating that the tool returns a complete plan record when given an exact name. It specifies the content (prices, resources, source provenance, timestamps) and the null behavior, which distinguishes it from search-oriented siblings like search_products.
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 clear context: use this tool when you need a complete plan record by exact namehola. It also provides an important interpretive rule—if the plan is not in the catalog, null means it cannot be purchased. However, it does not explicitly name alternatives or state when not to use the tool, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
La ficha de una línea de servicio por su categoría: qué es, qué NO es, para quién, diferenciales, detalle técnico y preguntas frecuentes. Úsala antes de describir un producto: evita el error más común, que es presentar esta línea como un fondo de recursos repartido entre vecinos. Si la línea no tiene ficha, devuelve null en vez de inventarla.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description need not repeat those. It adds the behavioral note that the tool returns null if the line has no card, and explicitly says it will not invent one. This is valuable context beyond the 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 long, with the core purpose stated first. It packs the card contents, usage guidance, and null behavior into a tight, front-loaded structure with no wasted words.
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 has an output schema, so the description does not need to explain the return structure. It covers the key behavioral outcome (null if missing), the intended usage (before describing a product), and the card's content. It is sufficient for an agent to call the tool correctly, though it could mention category constraints or examples.
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 one parameter, category, with 0% description coverage. The description mentions 'por su categoría' (by its category), which clarifies the parameter's role but essentially repeats the schema's property name. It does not add details about valid category values or formats, so it only minimally compensates for the schema's lack of description.
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 states a clear verb and resource: it retrieves the service line card by category. It enumerates the card's contents (what it is, what it is not, for whom, differentiators, technical detail, FAQs), which makes the tool's function unmistakable. It also distinguishes it from sibling tools like get_product by referring to 'línea de servicio' vs 'producto'.
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 usage guidance: 'Úsala antes de describir un producto' (use it before describing a product). It also warns against a common error, implying when not to use it. However, it does not name specific sibling tools as alternatives, so it lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
El SLA de soporte técnico: dónde está y cómo usarlo. El documento es la fuente única de las promesas de servicio; no resumas de memoria ni prometas por encima de él.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds context about the document being the authoritative source, which is useful but doesn't disclose additional behavioral traits like return format or potential caveats. The bar is lower due to annotations, and the description meets it without contradiction.
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, with two sentences that convey purpose and usage guidance efficiently. It is front-loaded and contains no filler, though it could be slightly more structured with a clear verb.
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 set of annotations, and an output schema (not shown but present), the description provides sufficient context for the agent to understand the tool's purpose and constraints. The emphasis on the document being the single source is valuable. Minor gap: it doesn't explicitly state what the response will contain, but the output schema likely covers that.
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, so the schema provides no parameter semantics. The description doesn't need to explain parameters. Baseline for zero parameters is 4, and the description fulfills this adequately.
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 identifies the subject as the technical support SLA and states its purpose ('dónde está y cómo usarlo'), indicating the tool provides information about the SLA location and usage. However, it lacks a direct verb like 'get' or 'retrieve', so it's clear but doesn't fully match the highest bar.
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: the document is the single source of service promises, and the agent should not summarize from memory or promise beyond it. This tells the agent when to rely on this tool and what to avoid, though it doesn't reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cotiza un plan por cantidad y período, y devuelve la aritmética, no sólo el total. cycle acepta el código o el nombre del período (monthly o Mensual, annually o Anual…); sin él se cotiza el período principal. Los períodos de cada plan están en prices de get_product, y available_cycles los repite. IMPORTANTE: el subtotal NO incluye impuestos y por lo tanto no es un precio final al consumidor; la respuesta explica por qué. Al presentarlo hay que decirlo.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| cycle | No | ||
| quantity | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it returns arithmetic breakdown, not just the total; it explains why the subtotal is not a final price; and it notes that the response itself explains the tax exclusion. This goes beyond the annotations by disclosing the nature of the output and a caveat about its interpretation.
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 moderately sized but packed with essential information. It front-loads the core purpose, then explains the cycle parameter, then provides the critical tax caveat. Every sentence earns its place, though the tax warning could be slightly more concise. The structure is logical: purpose → parameter semantics → important caveat.
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 an output schema (which likely explains the response structure), the description doesn't need to detail return values. It covers the key contextual aspects: how to determine available cycles, the default behavior, and the tax caveat. It could potentially mention what happens with invalid cycle values, but the description is largely complete for an agent to 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?
Schema description coverage is 0%, so the description must compensate. It does: it explains the 'cycle' parameter in detail (accepts code or name, examples, default behavior), and it clarifies that 'quantity' and 'name' are used for the quote. It doesn't explicitly define 'name' or 'quantity' beyond the schema, but the overall purpose makes them inferable. The cycle parameter gets rich semantic treatment, which is the most complex parameter.
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: 'Cotiza un plan por cantidad y período' (quotes a plan by quantity and period) and explicitly says it returns the arithmetic, not just the total. It distinguishes itself from siblings by mentioning get_product for cycle details, and the verb 'cotiza' is specific to the quoting action.
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 provides explicit usage guidance: it explains how to specify the cycle (code or name, with examples), what happens if cycle is omitted (defaults to main period), and where to find the available cycles (prices in get_product, available_cycles). It also gives a critical usage warning about the subtotal not including taxes, which must be communicated when presenting results. This is clear when-to-use and how-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca planes por categoría, presupuesto y recursos mínimos.
Categorías: · 'cloud' — Servidores Cloud, máquinas virtuales con IP colombiana y acceso completo al servidor. · 'cloud-web-hosting' — el hosting con cPanel sobre CloudLinux. NO es un fondo de recursos compartido: cada cuenta corre en su propio entorno aislado con CageFS y con memoria, CPU, procesos y entrada/salida asignados por CloudLinux, y se sube o baja de plan al instante sin costo adicional. · 'cloud-web-cluster' — el sitio repartido en varios nodos con réplica y balanceo. · 'cpanel-reseller' — recursos para repartir entre clientes propios desde WHM. · 'web-hosting-windows' — plataforma Windows con Plesk. · 'ssl' y 'admindns'.
El precio va en pesos colombianos, y el ciclo NO es el mismo en todas las categorías: mira el campo cycle antes de comparar dos. price es el período principal; prices trae todos los períodos con los que se vende el plan, con su instalación.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| category | No | ||
| min_vcpu | No | ||
| max_price | No | ||
| min_price | No | ||
| min_ram_gb | No | ||
| min_disk_gb | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: prices are in COP, billing cycles vary by category, `price` is the main period, and `prices` includes all selling periods with installation costs.
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 well-structured: a concise purpose statement, a bulleted category list, then a focused pricing caveat. It is somewhat long, but the category detail is genuinely useful because the schema provides no enum values.
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 and safety annotations, the description covers the key domain semantics: valid categories, currencies, cycles, and price fields. Minor gaps remain around price-filter interaction and pagination through `limit`, but they are not severe enough to make the tool hard to use.
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?
With 0% schema coverage, the description compensates by enumerating category values and explaining price currency and cycle behavior. However, it leaves some parameter semantics unclear, such as how `min_price`/`max_price` relate to `price` versus `prices`, and it does not discuss `limit` or resource-unit details.
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 identifies the action and scope: searching plans by category, budget, and minimum resources. It does not explicitly distinguish this from siblings such as get_product or compare_products, though the filtering language strongly implies the difference.
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?
It provides clear operational context: use this to find plans by category, budget, and resource filters, and it warns to inspect `cycle` before comparing plans. It lacks explicit when-not-to-use guidance or alternative routing to siblings like get_product or compare_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_servicequote1 field changedInput schema / properties / cycleAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Cycle"
+}catalog_statuscompare_productscreate_draft_orderget_infrastructure_factsget_policiesget_productget_slaquotesearch_productsLive VPS, bare metal and GPU hosting prices across ~75 providers, rescraped daily.
Hospedagem no Brasil que o agente opera: cria banco, publica, lê log e diz o custo.
Rent offshore VPS, dedicated, RDP and GPU servers in 7 jurisdictions; crypto-only, no KYC
izHost public read-only MCP: service pricing and live domain availability lookup.
Add one secure layer between your agents and this server.
