Skip to main content
Glama

Paraguay Dncp

by io.github.pipeworx-io
OverviewAdmin

Paraguay Search Tenders

paraguay_search_tenders
Read-onlyIdempotent

Search Paraguay government procurement processes (tenders/contracts) from the official DNCP Open Contracting (OCDS) API. Results are date-scoped: the API requires a date range, so if you omit date_from/date_to it defaults to roughly the last 30 days. Returns a paginated list of processes with ocid, id, title, buyer (convocante), procurement method, and dates. Field values are in Spanish; monetary amounts are in PYG. Detailed value/status/items live in the full record — pass an id to paraguay_get_record. Note: the API has no free-text search parameter, so "query" is applied as a case-insensitive client-side filter over the current page of results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (10 processes per page). Defaults to 1.
queryNoOptional keyword to filter the returned page by title/buyer (client-side, case-insensitive). The DNCP API has no server-side text search, so results are still bounded by the date range.
date_toNoEnd date (YYYY-MM-DD), inclusive. Maps to fecha_hasta. Defaults to today if both dates omitted.
date_fromNoStart date (YYYY-MM-DD), inclusive. Maps to fecha_desde. Defaults to ~30 days ago if both dates omitted.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "date_from": "2024-01-01",
+    "date_to": "2024-01-31",
+    "query": "construcción"
+  },
+  {
+    "date_from": "2024-12-01",
+    "date_to": "2024-12-31",
+    "page": 2
+  }
+]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds crucial behavioral context: date scoping, paginated results, client-side filtering, and the fact that field values are in Spanish and amounts in PYG, which annotations do not cover.

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?

The description is a single paragraph that efficiently conveys all necessary information without redundancy. It is front-loaded with the core purpose. Could be slightly more structured (e.g., bullet points), but it remains clear and easy to read.

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?

Given the tool has 4 parameters, no output schema, and moderate complexity, the description adequately explains the return fields, pagination, and date defaults. It does not detail pagination navigation or error conditions, but for a search tool this is sufficient.

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 baseline is 3. The description adds value by explaining defaults for date parameters, clarifying that 'query' is a client-side filter, and mentioning the API parameter names (fecha_hasta, fecha_desde). This additional context warrants a 4.

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?

The description clearly states it searches Paraguay government procurement processes from the official DNCP OCDS API, specifying the returned fields and noting Spanish-language values and PYG currency. It distinguishes from the sibling tool paraguay_get_record by directing users there for detailed records.

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?

The description provides explicit usage guidance: the API requires a date range, defaults to the last 30 days, and explains that 'query' is a client-side filter with no server-side free-text search. It also tells users to use paraguay_get_record for full details, effectively distinguishing when to use which tool.

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

All Paraguay Dncp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources