Skip to main content
Glama
pipaacebedo

seace-mcp

by pipaacebedo

Obteniendo fichas en lote

fichas_procesos

Batch-retrieve summaries or full records for multiple Peruvian public procurement processes from the same search in one call, avoiding repeated individual lookups.

Instructions

Lote de fichas o resumenes de procesos de la MISMA busqueda, en UNA llamada (evita repetir ficha_proceso por cada index).

Args: ses: sesion devuelta por buscar_procesos. indices: 'index' globales (0-based) de esa busqueda (ej [0, 1, 2]; duplicados se procesan una sola vez; cap: 50 con 'resumen', 8 con 'completa'). profundidad: 'resumen' trae la fila del buscador (entidad, nomenclatura, objeto, monto, fechas, version); 'completa' trae la ficha entera (items, cronograma, documentos) como ficha_proceso.

Devuelve: {'ok', 'ses', 'profundidad', 'fichas': [...], 'faltas': [{index, motivo}], 'nota'}: los indices fallidos van a 'faltas' con su motivo y el resto se entrega; usa ficha_proceso individual si solo necesitas una.

Input Schema

NameRequiredDescriptionDefault
sesYes
indicesYes
profundidadNoresumen

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations the description carries the full burden, and it delivers real behavioral context: caps of 50 (resumen) / 8 (completa), duplicate indices processed once, and partial-failure semantics (failed indices in 'faltas' with motivo while the rest are returned). It does not discuss permissions or rate limits, which is the only gap.

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

Conciseness5/5

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

Front-loaded purpose sentence followed by tightly organized Args and Devuelve blocks. No filler; every clause carries operational information (caps, dedup, fallback routing).

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?

There is no output schema, so the description correctly outlines the return keys ('ok', 'ses', 'profundidad', 'fichas', 'faltas', 'nota') and the partial-failure model. It stops short of explaining the 'ok'/'nota' fields, a minor omission for a 3-param tool at this complexity.

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

Parameters5/5

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 and does: it defines 'ses' (session returned by buscar_procesos), 'indices' (global 0-based indices, dedup behavior, size caps), and 'profundidad' (values 'resumen'/'completa' and exactly what each yields). Every parameter gets meaning beyond its bare type.

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 action and scope: batch-retrieve fichas/resúmenes for the SAME search in one call, explicitly framed as avoiding repeated ficha_proceso calls. It makes the distinction from the ficha_proceso sibling explicit, and the dependency on a session from buscar_procesos is named.

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

Usage Guidelines5/5

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

Gives the when (batch over one search to avoid repeated per-index calls) and the when-not ("usa ficha_proceso individual si solo necesitas una"). The routing is explicit and actionable, so the agent can choose between the two tools without inference.

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