Skip to main content
Glama
edwin042331-hue

dgcp-mcp-server

by edwin042331-hue
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Scorecard de una institucion compradora (DGCP)

dgcp_scorecard_institucion
Read-onlyIdempotent

Generate institutional procurement scorecards by official purchasing unit code to analyze payment terms, supplier concentration, MIPYME compliance, and modality mix.

Instructions

Perfil exacto de como compra y paga una institucion (filtro por su codigo oficial de unidad de compra):

  • Plazos de pago pactados frente al maximo legal de 30 dias (Art. 148 P. III Ley 47-25) y metodo de pago.

  • Concentracion de proveedores: top 5 y HHI.

  • Cumplimiento de la cuota MIPYME del ano (dato oficial DGCP).

  • Mezcla de modalidades (peso de excepciones y compras directas) y auditoria de plazos de convocatoria de sus procesos recientes (Art. 101).

Input Schema

NameRequiredDescriptionDefault
institucionYesNombre, acronimo o codigo de la institucion. Ej: 'MINERD', 'INFOTEP', '141'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv5.0.0
    • changedInput schema / properties / institucion / description
      Previous value: -"Nombre o parte del nombre de la institucion a auditar (ej. 'IDAC', 'Hospital', 'MICM', 'Ayuntamiento')."New value: +"Nombre, acronimo o codigo de la institucion. Ej: 'MINERD', 'INFOTEP', '141'."
    • addedInput schema / properties / institucion / minLength
      Added value: +2
    • removedInput schema / properties / paginas
      Removed value: -{
-  "default": 20,
-  "description": "Paginas de contratos a escanear para calcular la salud de pago (default 20 = 2,000 contratos)",
-  "maximum": 30,
-  "minimum": 1,
-  "type": "integer"
-}
  2. First observedv4.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds value by disclosing the concrete contents of the profile (payment-term vs legal 30-day limit, top-5/HHI concentration, MIPYME quota, modality mix, Art. 101 timeline audit), which tells the agent what behavior to expect beyond a generic read.

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?

Front-loaded with a one-line purpose followed by a compact bullet list of the four computed dimensions; every bullet carries distinct information. Slightly dense but no filler.

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?

With no output schema, the description usefully compensates by itemizing what the scorecard contains. For a read-only, single-parameter tool it is essentially complete; only the choice among sibling analytical tools is left unaddressed.

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?

With a single parameter and 100% schema description coverage, the schema already documents that the field accepts name, acronym or code, with examples. The description's 'filtro por su codigo oficial de unidad de compra' arguably narrows this to codes only, adding little and slightly under-describing the actual flexibility.

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?

The description states a specific analytical artifact (a purchasing/payment profile) and enumerates its dimensions, so an agent knows exactly what this tool produces. It does not, however, name or differentiate itself from the obvious sibling dgcp_radiografia_proveedor (the supplier-side analog), so it stops short of full sibling disambiguation.

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: it is a per-institution analytical scorecard, and the parenthetical tells the agent how to target it (official purchase-unit code). There is no explicit 'use this when...' statement and no mention of when a sibling such as dgcp_inteligencia_proceso or dgcp_radiografia_proveedor would be the better choice.

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