Skip to main content
Glama
ssolis-ti

Compra Ágil MCP Server

by ssolis-ti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Auditar una compra desierta

auditar_compras_desiertas
Read-only

Audit a failed Compra Ágil process to diagnose why it was deserted, compare quoted market prices from similar tenders, and report official desertion reasons.

Instructions

Audita un proceso de Compra Ágil que haya quedado "desierto" para identificar por qué falló (plazo ajustado, presupuesto bajo, requisitos restrictivos), comparándolo con los precios que el mercado cotizó en procesos similares. Admite el código de la compra o un término de búsqueda para encontrar un proceso desierto reciente. NOTA: la comparación se hace contra precios COTIZADOS por proveedores en procesos del mismo rubro, no contra precios adjudicados: la API de Mercado Público no expone qué oferta ganó (verificado empíricamente). También reporta el motivo oficial de deserción y las cotizaciones declaradas inadmisibles, que suelen explicar el fracaso mejor que el precio.

Input Schema

NameRequiredDescriptionDefault
qNoTérmino de búsqueda de producto/servicio para encontrar y auditar un proceso desierto reciente (ej: "resmas papel"). Opcional.
codigo_compraNoCódigo de la Compra Ágil desierta para auditar (ej: "1057539-228-COT26"). Opcional si se especifica "q".
limite_analisisNoCantidad de procesos comparables con los que contrastar (1-8, default 3). Cada uno es una consulta de cuota y una llamada de detalle — lo lento: medido en septiembre de 2026, 20-25 s cada una, con HTTP 504 intermitentes. Se piden en paralelo, así que subirlo no multiplica el tiempo, pero sí la probabilidad de que alguna falle.
palabras_clave_excluidasNoPalabras separadas por coma que NO deben estar en el nombre de los comparables (ej: "termico,panaderia"). Mismo funcionamiento que las requeridas.
palabras_clave_requeridasNoPalabras separadas por coma que DEBEN estar en el nombre de cada proceso comparable (ej: "nitrilo"). Se aplican sobre el listado antes de pedir los detalles: no gastan cuota extra y evitan mezclar productos distintos.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.7.0
    • changedInput schema / properties / limite_analisis / default
      Previous value: -5New value: +3
    • changedInput schema / properties / limite_analisis / description
      Previous value: -"Cantidad de procesos históricos exitosos con los que comparar (1-8, default 5) para no agotar la cuota de la API."New value: +"Cantidad de procesos comparables con los que contrastar (1-8, default 3). Cada uno es una consulta de cuota y una llamada de detalle — lo lento: medido en septiembre de 2026, 20-25 s cada una, con HTTP 504 intermitentes. Se piden en paralelo, así que subirlo no multiplica el tiempo, pero sí la probabilidad de que alguna falle."
    • addedInput schema / properties / palabras_clave_excluidas
      Added value: +{
+  "description": "Palabras separadas por coma que NO deben estar en el nombre de los comparables (ej: \"termico,panaderia\"). Mismo funcionamiento que las requeridas.",
+  "type": "string"
+}
    • addedInput schema / properties / palabras_clave_requeridas
      Added value: +{
+  "description": "Palabras separadas por coma que DEBEN estar en el nombre de cada proceso comparable (ej: \"nitrilo\"). Se aplican sobre el listado antes de pedir los detalles: no gastan cuota extra y evitan mezclar productos distintos.",
+  "type": "string"
+}
  2. First observedv1.0.2

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint, so the description carries the interesting burden — and it does so well, disclosing that comparison uses QUOTED not awarded prices because the API does not expose the winner, and that it surfaces the official deserción reason plus inadmissible quotes. Quota/perf costs are covered in the schema rather than the description, leaving a small gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, then input modes, then the crucial methodological caveat, then the return content. Every sentence contributes, though the NOTE and final sentence overlap somewhat in explaining why the failure info matters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter, no-output-schema audit tool, the description covers purpose, inputs, comparison methodology and its empirical limitation, and what the response reports (official reason, inadmissible quotes). Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the parameter docs are already rich (limite_analisis even documents the 504s and parallel-call behavior). The description restates the code/search-term option but adds little semantic detail beyond the schema, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Audita un proceso de Compra Ágil que haya quedado desierto') and adds the goal (identify why it failed) plus the method (comparison against market-quoted prices). It is readily distinguishable from siblings like analizar_precios_mercado and buscar_compras_agiles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the input modes (purchase code or search term for a recent failed process) and clarifies the comparison basis, which helps an agent situate the tool among pricing-oriented siblings. It does not name a specific alternative or state explicit when-not conditions, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools