Skip to main content
Glama
pipaacebedo

seace-mcp

by pipaacebedo

Buscando anuncios de contratación futura

buscar_acf

Search Peru's SEACE future contracting announcements (ACF) by entity, object, type, text, or publication/convention dates to identify upcoming public tender opportunities.

Instructions

Busca ANUNCIOS DE CONTRATACION FUTURA (ACF) publicados por las entidades en el SEACE.

Args: objeto: tipo de objeto (OBLIGATORIO): Bien / Consultoria de Obra / Obra / Servicio. descripcion: texto del anuncio de contratacion futura. tipo: tipo de compra futura (ej 'Licitacion Publica'). entidad: entidad convocante. desde_pub: fecha inicial de publicacion dd/mm/aaaa. hasta_pub: fecha final de publicacion dd/mm/aaaa. desde_conv: fecha inicial de convocatoria aproximada dd/mm/aaaa. hasta_conv: fecha final de convocatoria aproximada dd/mm/aaaa. sigla: sigla de la entidad. pagina: numero de pagina (15 filas por pagina; 'index' global y continuo). paginas: paginas consecutivas a traer en una llamada (1..8). ses: sesion de una busqueda previa para pedir 'siguiente_pagina' o re-buscar; con filtros distintos la busqueda se re-ejecuta conservando el mismo 'ses' (no se emite id nuevo).

Devuelve: Igual que buscar_procesos; cada fila trae entidad, fecha_publicacion, tipo, objeto, descripcion, condiciones, nro_items, plazo_dias y fecha_aprox_conv.

Input Schema

NameRequiredDescriptionDefault
sesNo
tipoNo
siglaNo
objetoNo
paginaNo
entidadNo
paginasNo
desde_pubNo
hasta_pubNo
desde_convNo
hasta_convNo
descripcionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description must carry behavioral disclosure, and it does add real context: pagination granularity (15 rows/page, 1..8 pages), session reuse semantics, and the returned fields. It omits auth requirements, rate limits, and any safety/mutation profile, so it is solid but not complete.

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?

Uses a clear Args/Devuelve structure with the purpose sentence front-loaded, and the length is justified by 12 parameters. No filler sentences, though the arg list is dense rather than prose-optimized.

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 12-parameter, no-annotation, no-output-schema tool, the description compensates well by naming the returned row fields and the pagination/session mechanics. Remaining gaps (auth, rate limits, result count limits) are minor for a read-only search.

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 0%, so the description carries the full parameter burden and mostly succeeds: it marks 'objeto' as OBLIGATORIO, supplies its four allowed values (Bien/Consultoria de Obra/Obra/Servicio), gives dd/mm/aaaa formats for the four date params, and explains pagina/paginas/ses behavior. A few entries (sigla, entidad, tipo) are near-tautological, keeping it from a 5.

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

Purpose4/5

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

States a specific verb (Busca) and a precisely named resource (ANUNCIOS DE CONTRATACION FUTURA / ACF publicados en el SEACE), so an agent can tell it apart from buscar_procesos at a glance. It does not explicitly name or contrast with the sibling tools, which keeps it just below a 5.

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

Usage Guidelines2/5

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

There is no when-to-use/when-not guidance and no mention of the alternatives in the sibling set (buscar_procesos, buscar_pac, etc.). The only usage-like hint is behavioral (the 'ses' reuse rule), not selection guidance.

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