Skip to main content
Glama
edwin042331-hue

dgcp-mcp-server

by edwin042331-hue
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Expediente 360 de un proceso de compra (DGCP)

dgcp_inteligencia_proceso
Read-onlyIdempotent

Build a complete tender file in one call: schedule, items, documents, bids, awards, buyer history, and legality checks for a Dominican public procurement process.

Instructions

Arma el expediente completo de una licitacion en una sola llamada, con consultas exactas a la API:

  1. Ficha y cronograma (hora RD) con cuenta regresiva y regimen legal aplicable (Ley 47-25 o 340-06 transitoria).

  2. Articulos solicitados (codigo UNSPSC, cantidades y precio unitario estimado por la institucion).

  3. Documentos del pliego publicados (enlaces directos).

  4. Ofertas recibidas y contratos adjudicados del proceso.

  5. Historial de la institucion: a quien le compra y cuanto (ultimos contratos).

  6. Control de legalidad: plazo minimo del Art. 101, modalidad vs umbral (posible fraccionamiento), fecha limite de aclaraciones.

  7. Garantias, anticipo MIPYME y plazo de pago segun la Ley 47-25 y el Dec. 52-26.

Input Schema

NameRequiredDescriptionDefault
codigo_procesoYesCodigo oficial del proceso, ej. 'MIP-CCC-LPN-2026-0005'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv5.0.0
    • changedInput schema / properties / codigo_proceso / description
      Previous value: -"Codigo oficial del proceso (ej. 'TSS-DAF-CM-2026-0055' o 'HLA-DAF-CD-2026-0121')."New value: +"Codigo oficial del proceso, ej. 'MIP-CCC-LPN-2026-0005'."
    • addedInput schema / properties / codigo_proceso / minLength
      Added value: +3
    • removedInput schema / properties / paginas_historial
      Removed value: -{
-  "description": "Paginas a escanear en contratos y ofertas para buscar antecedentes (default 12 = 1,200 registros)",
-  "maximum": 25,
-  "minimum": 1,
-  "type": "integer"
-}
  2. First observedv4.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds real value beyond that: it discloses the response content (countdown, UNSPSC line items, direct document links, awarded contracts) and that computed legal checks such as the Art. 101 minimum term and possible fraccionamiento are performed — but says nothing about cost, latency, or partial-failure behavior for a call that fans out to many queries.

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 the core purpose in one sentence, then a numbered list of the returned sections. The list is long but every item is load-bearing, since there is no output schema to describe the payload; minor verbosity in the legal-regime phrasing.

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 correctly compensates by enumerating what the dossier contains, which is exactly what an agent needs to decide the call is worthwhile. It is close to complete; only the absence of any note on response size or when partial data may be missing keeps it from a 5.

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 there is a single parameter, so the schema (with format example 'MIP-CCC-LPN-2026-0005') already carries the parameter burden. The description adds no syntax, validation, or lookup guidance beyond what the schema provides — baseline 3.

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 — 'Arma el expediente completo de una licitacion en una sola llamada' — and then enumerates the seven sections it assembles. The 'una sola llamada' framing distinguishes it from the narrow sibling lookups (dgcp_buscar_licitaciones, dgcp_buscar_contratos, dgcp_buscar_ofertas) that this tool aggregates.

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 rather than stated: the agent can infer this is the one-shot dossier builder versus the single-purpose siblings, but there is no explicit 'use this when you need everything at once; use X when you need only offers' routing. No exclusions or prerequisites are given.

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