Skip to main content
Glama
ssolis-ti

Compra Ágil MCP Server

by ssolis-ti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Radar de oportunidades

radar_oportunidades_calientes
Read-only

Scans published Compra Ágil processes in Chile and ranks them by zero bids, budget, time to close, and second-call status to surface opportunities worth reviewing.

Instructions

Escanea procesos de Compra Ágil publicados y los ordena con un puntaje. El puntaje usa datos del listado: 0 ofertas, el presupuesto, las horas hasta el cierre (hora de Chile, contra el reloj oficial del SHOA) y si el proceso va en segundo llamado. 0 ofertas y la falta de adjuntos no son hechos de la ficha. Cada resultado incluye "llamado" (1 = primero, 2 = segundo) y los factores del puntaje. Si q no está en el título, la fila lo dice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoTérmino de búsqueda opcional para acotar a un rubro o producto específico (ej: "licencias").
regionNoCódigo de la región para filtrar (1-16). Ej: "13" para Metropolitana.
max_paginasNoCuántas páginas de 10 resultados escanear antes de rankear (1-10, default 3 = hasta 30 procesos). Cada página es una consulta secuencial de unos 8 s (medido el 1 de octubre de 2026: publicada + región, tamano_pagina=10). La misma búsqueda con tamano_pagina=50 responde HTTP 504. Más páginas dan más cobertura y cuestan cuota y tiempo de forma lineal.
limite_resultadosNoCantidad máxima de oportunidades destacadas a retornar (1-20, default 10).
presupuesto_minimoNoFiltrar solo procesos con presupuesto disponible mayor o igual a este monto en CLP.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.7.0
    • addedInput schema / properties / max_paginas
      Added value: +{
+  "default": 3,
+  "description": "Cuántas páginas de 10 resultados escanear antes de rankear (1-10, default 3 = hasta 30 procesos). Cada página es una consulta secuencial de unos 8 s (medido el 1 de octubre de 2026: publicada + región, tamano_pagina=10). La misma búsqueda con tamano_pagina=50 responde HTTP 504. Más páginas dan más cobertura y cuestan cuota y tiempo de forma lineal.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "number"
+}
  2. First observedv1.0.2

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description goes further by disclosing the scoring inputs (offer count, budget, hours to close, second-call flag), the time source (Chile time vs SHOA clock), and an important data caveat (0 offers and missing attachments are not ficha facts). Only rate-limit/cost behavior is left to the schema rather than the description.

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?

Three sentences, front-loaded with the core action, no filler. Slightly dense/awkward in the caveat sentence ('no son hechos de la ficha'), but every sentence carries signal and nothing is redundant.

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

Completeness4/5

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

For a 5-param ranking tool with no output schema and minimal annotations, the description explains the scoring, the called-round field, and the q-matching disclosure, which covers most of what an agent needs. A short sketch of the returned result structure beyond 'llamado' and 'factors' would complete it.

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

Parameters4/5

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

Schema coverage is 100%, so a baseline of 3 would be defensible, but the description adds real meaning: it clarifies that q matches the title and that non-matching rows are flagged, and it ties presupuesto to the scoring. These nuances go beyond the schema's field descriptions.

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 (scans published Compra Ágil processes and ranks them by a score), which cleanly separates it from siblings like buscar_compras_agiles (plain search) and obtener_detalle_compra (single-record detail). The scoring mechanism is described concretely enough that an agent knows exactly what this tool produces.

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

Usage Guidelines3/5

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

Usage is implied (find prioritized 'hot' opportunities) but never made explicit against alternatives. There is no 'use this instead of buscar_compras_agiles when...' guidance nor any when-not-use condition, so the agent must infer routing from sibling names alone.

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