What can you do with this server?

This server lets you query El Salvador's public procurement system (COMPRASAL) directly from an AI assistant, providing read-only access to government contract and spending data. * Search awarded procurement processes (search_procurement): Find public contracts by institution, fiscal year, modality, state, date range, or free-text keyword. Returns supplier name, awarded amount, dates, and process code. * Get full process detail (get_process_detail): Retrieve complete information for a specific procurement process, including publication/award dates, awarded amount, contracting form, follow-up state, and the full stage calendar. * Get rich award reports (get_award_report): Access the most detailed view of an award, including bidder lists, planned vs. certified amounts, budget codes, signature date, and contractual term. * Look up a supplier's contract history (get_supplier_contracts): Find all public contracts won by a specific company across government institutions, useful for building a supplier's public-sector track record (bounded to recent records due to API limitations). * Resolve institution names to IDs (list_institutions): Search for government institutions by partial name to get the numeric ID required for filtering other queries. * Browse reference catalogs: List available contracting modalities (list_modalities), procurement process states (list_states), and fiscal years (list_years) to build precise filters for searches. All access is read-only, covering public information published under El Salvador's LACAP procurement law.

How do I use comprasal-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@comprasal-mcp Show me recent contracts from the Ministry of Health." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

comprasal-mcp

by glassbit

Overview Schema Related Servers Score Discussions

TypeScript

Remote

COMPRASAL MCP

Query El Salvador's public procurement data straight from your AI assistant.

This is a Model Context Protocol server that wraps the public COMPRASAL API (comprasal.gob.sv) — the country's electronic public-purchasing system — so you can ask Claude (or any MCP client) things like:

"What did the Ministry of Health award in 2025, and for how much?" "Show me the latest public contracts and their suppliers." "Pull the full detail and stage calendar for process 83743."

All data is public information published by the State under the LACAP procurement law. This server is read-only.

What you can ask

Once connected, your assistant gains these tools:

Tool	What it does
`search_procurement`	Search awarded processes by institution, year, modality, or free text. Returns supplier, amount, dates, code.
`get_process_detail`	Full detail of one process: amounts, dates, and the complete stage calendar.
`get_award_report`	Richest view: bidders, planned vs certified amounts, budget codes, signature date.
`get_supplier_contracts`	A supplier's public-sector track record: contracts won, by company name (bounded recent scan).
`list_institutions`	Resolve an institution name (e.g. "salud") into its id.
`list_modalities` / `list_states` / `list_years`	Catalogs for building precise filters.

Related MCP server: chile-procurement

Install

Requires Node.js 18+.

git clone https://github.com/glassbit/comprasal-mcp.git
cd comprasal-mcp
npm install
npm run build
npm test

Connect to Cursor

This repo ships a project-level MCP config at .cursor/mcp.json. After npm run build:

Open this folder in Cursor.
Go to Settings → MCP and enable the comprasal server (or restart Cursor).
The assistant can call the COMPRASAL tools in Agent mode.

The config runs node dist/index.js against the live COMPRASAL API (cache off by default). To override globally, add the same block to your user MCP settings.

Connect to Claude Desktop

Add this to your claude_desktop_config.json:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "comprasal": {
      "command": "node",
      "args": ["/absolute/path/to/comprasal-mcp/dist/index.js"]
    }
  }
}

Restart Claude Desktop. You'll see the COMPRASAL tools available. Ask it about El Salvador's public spending.

Local cache (opt-in)

By default every request goes to the live COMPRASAL API — a fresh clone behaves identically for everyone. You may opt in to a local, per-user response cache to speed up repeated queries within a session:

Variable	Default	Description
`COMPRASAL_CACHE_ENABLED`	`false`	Set to `true` to cache raw API responses on disk
`COMPRASAL_CACHE_DIR`	`.comprasal-cache`	Cache directory (gitignored, never committed)
`COMPRASAL_CACHE_TTL_MS`	`3600000` (1 hour)	Entry lifetime; expired entries are deleted on read

The cache is not a shared or committed database — it is created at runtime on your machine only. After TTL expiry, the next request fetches live data again. Disable it anytime with COMPRASAL_CACHE_ENABLED=false.

Tests

npm test              # unit + mocked integration only (no network)
npm run test:live     # optional smoke test against real COMPRASAL API (~7s)

Tests cover client-side filters, Zod argument validation, file cache behaviour, and mocked HTTP flows.

Notes & caveats

The upstream government API only filters reliably by institution. This is the single most important thing to understand about this tool:

id_institucion is the only server-side filter that works. Year, free-text search, and date range are silently ignored by the COMPRASAL backend.
This server compensates by filtering client-side (over the real award date fecha_adjudicacion and text fields), scanning newest-first pages up to a bounded limit.
Consequence: deep historical queries are not practical. Asking for "all contracts from supplier X since January 2025" or "institution Y in 2024" can require scanning thousands of records at ~7s/page — so those tools return a bounded recent window and clearly say so in a coverage / filtering block. A bounded result is never presented as exhaustive.
Backend latency is ~7s per request (this is the government server, not the MCP). Tools make one request per page and cap how many pages they scan, so a call may take 10-50s.
get_supplier_contracts cannot filter by supplier upstream, so it scans the most-recent global records and matches locally. Pass id_institucion when you know it — the scan becomes far faster and deeper.
Date filters apply to the award date (fecha_adjudicacion) in this server, even though the raw upstream API filters on the process start date.
get_award_report uses a different id than the other endpoints (a known upstream quirk). Prefer get_process_detail unless you specifically need the bidder/budget breakdown.
The dataset holds ~100k+ awarded processes, current through 2026. Each process may appear as several rows (one per lot/supplier).
Tool arguments are validated with Zod before any upstream call; invalid inputs return a clear error without hitting the API.

Why no local database / committed cache?

This server queries the live public API so that anyone who clones it gets identical results with zero setup — no pre-scraped dataset, no shared state in the repo. A committed database would mean either hosting a central server (defeating the "run it yourself" model) or asking every user to scrape COMPRASAL first (hours of work).

An optional, opt-in file cache is available for convenience: it lives in .comprasal-cache/ on your machine only (gitignored), expires after 1 hour, and is off by default. It does not change what a fresh clone returns on first run. A full local-database variant for deep historical analysis remains a possible separate, opt-in project.

Data, source & legality

Data comes from the public COMPRASAL portal (comprasal.gob.sv), accessed through its public, unauthenticated REST API. Public procurement acts are public by law under the LACAP (Ley de Adquisiciones y Contrataciones de la Administración Pública). Public registries are excluded from the scope of El Salvador's Personal Data Protection Law (Decreto 144, 2024, art. 3). This project redistributes already-public information for transparency and research purposes and performs no scraping of authenticated areas.

License

MIT. Not affiliated with or endorsed by the Government of El Salvador.

Available Tools

8 tools

get_award_reportA

Get the richest award report for a process: contract name, contracting form, contractual term, planned vs certified amounts, signature date, budget codes (cifrados presupuestarios), and the list of bidders (oferentes). CAVEAT: this endpoint's id is NOT the proceso_compra.id used elsewhere; it lives in a different id space. Obtain the correct id from a process detail payload. If you pass the wrong id you will get a different contract. When unsure, prefer get_process_detail.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Award/contract id (not proceso_compra.id).

TDQS

A5/5.0

Behavior5/5

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

Discloses that the endpoint uses a different id space, warns that wrong id returns a different contract, and implies read-only nature through 'Get' verb and report context. No annotations needed.

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?

Very concise: two sentences plus a brief caveat. Every sentence adds value with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, no output schema, the description fully explains what the tool returns, the critical id caveat, and when to use an alternative. Sufficient for effective usage.

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 covers id with description, but the description adds crucial context: id is not proceso_compra.id, and explains how to obtain the correct id from a process detail payload.

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?

Explicitly states 'Get the richest award report for a process' and lists the fields included. Distinguishes from sibling get_process_detail via the caveat about id space.

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?

Provides explicit caveat about id space mismatch with proceso_compra.id, advises to obtain correct id from process detail payload, and recommends using get_process_detail when unsure.

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

get_process_detailA

Get full detail of one procurement process by its proceso_compra id: code, internal code, publication/award dates, awarded amount, contracting form, follow-up state, and the full stage calendar (reception of offers, evaluation, etc.). The id comes from the 'proceso_compra.id' field of a search_procurement result.

ParametersJSON Schema

Name	Required	Description	Default
`id_proceso_compra`	Yes	proceso_compra.id from search results.

TDQS

A4.1/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as read-only status, permissions, or side effects. For a retrieval tool, this lacks transparency.

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?

The description is two sentences, front-loading the purpose and then the parameter source. Every sentence is necessary and concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lists the returned fields comprehensively. It also explains the parameter source. For a single-parameter detail tool, this provides complete context.

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?

There is one parameter with 100% schema coverage. The description adds value by explaining the parameter source (from search_procurement results), beyond the schema description.

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 retrieves full detail of a procurement process by its ID, listing specific fields like code, dates, awarded amount, etc. It distinguishes from siblings by specifying the source ID from search_procurement results.

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

Usage Guidelines4/5

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

The description explicitly states the tool should be used after search_procurement, using the id from its results. It provides clear context for when to use, but does not compare with alternatives like get_award_report.

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

get_supplier_contractsA

Find the public contracts won by a specific SUPPLIER (company), by name, across institutions. Useful to build a supplier's public-sector track record ('what has company X been awarded?'). CRITICAL LIMITATION: the upstream government API cannot filter by supplier, and only sorts newest-first, so this performs a BOUNDED scan of the most-recent records — it does NOT return a supplier's full multi-year history. The response includes a 'coverage' block stating exactly what was scanned and warning when the result is bounded. Always relay that limitation to the user; never present a bounded scan as exhaustive. If you know which institution to look within, pass id_institucion to make the scan far faster and deeper. Each page is ~7s; raising max_pages increases coverage but also wait time.

ParametersJSON Schema

Name	Required	Description
`anio`	No	Optional year filter.
`supplier`	Yes	Supplier name (partial match).
`max_pages`	No	Max pages to scan (default 6, max 30).
`id_institucion`	No	Optional institution to narrow scan.

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, description fully discloses the bounded scan nature, inability to filter by supplier, time per page, and that response includes a coverage block. Excellent transparency about limitations and behavior.

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?

Well-structured: purpose first, then critical limitation, then parameter advice. Every sentence adds value without redundancy. Could be slightly shorter but acceptable.

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?

No output schema, but description mentions coverage block in response. Covers all essential aspects: purpose, limitations, parameters, and response hint. Adequate for the tool's complexity.

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%, but description adds value by explaining how parameters affect behavior (e.g., id_institucion speeds scan, max_pages trades coverage for time). Provides context beyond schema descriptions.

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?

Clearly states the tool finds public contracts won by a specific supplier by name. Distinguished from siblings like get_award_report and search_procurement by focusing on supplier track record.

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

Usage Guidelines4/5

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

Provides clear context: useful for building track record, but critical limitation (bounded scan) is explicitly stated. Advises relaying limitation to user and using id_institucion for better results. Lacks explicit when-not-to-use but covers key usage guidance.

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

list_institutionsA

List/search government institutions registered in COMPRASAL, to resolve a name into the numeric id_institucion used by search_procurement. Pass 'search' with a partial name (e.g. 'salud', 'hacienda').

ParametersJSON Schema

Name	Required	Description
`page`	No	Page, default 1.
`search`	No	Partial institution name.
`per_page`	No	Per page, default 30.

TDQS

A4/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It describes the basic behavior (list/search) and provides an example, but does not disclose pagination behavior, default sorting, or edge cases like empty results. Acceptable for a simple list tool.

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?

Two sentences with no wasted words. The first sentence states the core purpose and link to a sibling tool, the second provides a usage example. Highly efficient and front-loaded.

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 no output schema and simple parameters, the description sufficiently covers the tool's role and invocation. It could mention the returned data includes IDs and names, but the lack is not critical. Completeness is adequate for the tool's complexity.

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 coverage is 100%, so baseline 3 is appropriate. The description adds the example of using 'search' with a partial name, which slightly augments the schema, but page and per_page are not elaborated beyond their schema descriptions.

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 the tool lists/searches government institutions and resolves names to numeric IDs used by search_procurement. It is specific about the verb and resource, and explicitly links to a sibling tool, distinguishing its purpose.

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

Usage Guidelines4/5

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

Provides context for when to use (resolving names to IDs) and how to use (pass 'search' with partial name). However, no explicit when-not or alternative tools mentioned, though the sibling list tools are for different entities.

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

list_modalitiesA

List contracting modalities (formas de contratación: Licitación competitiva, Libre Gestión, Contratación Directa, Comparación de precios, etc.) with their ids, to use as id_modalidad filters.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, but the description accurately describes the tool as a read-only list operation. It does not hide any behavioral traits; the simplicity of the tool (no parameters, no side effects) matches the description.

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?

The description is extremely concise (two short sentences) yet informative, including examples and the use case. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description could be more complete by specifying the format or fields of the returned list. It is functional but minimal.

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?

There are no parameters in the input schema, so the description adds value by explaining the purpose and output content (IDs and names for filtering). This fully compensates for the lack of parameter documentation.

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 the tool lists contracting modalities with their ids, and provides concrete examples. It is distinct from sibling tools which focus on different entities like awards, processes, or institutions.

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

Usage Guidelines4/5

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

The description explicitly mentions using the output as 'id_modalidad filters', providing clear usage context. However, it does not explicitly state when not to use this tool or suggest alternatives.

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

list_statesA

List procurement process states with their ids, to use as id_estado filters.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It correctly indicates a read-only listing operation, but does not disclose any other behavioral traits (e.g., authentication, rate limits) that might be relevant for a listing tool.

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?

A single sentence that front-loads the primary action ('list') and resource ('procurement process states'), then adds relevant context. Every word is purposeful with no redundancy.

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 no parameters and no output schema, the description provides sufficient information for an agent to understand the tool's purpose and output. It could mention the exact fields returned (e.g., id, name), but the current description is adequate for a simple enumeration tool.

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?

The input schema has no parameters and 100% coverage. The description adds value by explaining the output contains ids and implies the items are states, which aids an agent in understanding the response format.

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 the tool lists procurement process states with their ids, and explicitly mentions the purpose of using these as id_estado filters. This distinguishes it from sibling tools like list_institutions or list_modalities by specifying the exact resource and use case.

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?

The description implies usage: 'to use as id_estado filters' suggests when filtering by state, use this tool. However, it does not explicitly state when not to use it or provide alternatives among siblings like search_procurement or get_process_detail.

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

list_yearsA

List the fiscal years (ejercicios) available in COMPRASAL.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, performance, or side effects. The description carries the full burden but adds no such information.

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?

The description is a single sentence that conveys the essential information without any wasted words. It is appropriately sized for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters, no output schema, and no annotations, the description is minimal. It tells the purpose but omits details about output format or any filtering logic, which could be useful for full completeness.

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?

There are no parameters, so the schema coverage is 100%. The description does not need to add parameter semantics, but it could hint at output structure. Baseline for 0 parameters is 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 the action ('List') and the resource ('fiscal years'), with a specific context ('in COMPRASAL'). It is distinct from sibling tools that deal with awards, processes, institutions, etc.

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?

No guidance is given on when to use this tool versus alternatives, nor any prerequisites or limitations. The description only states what it does, not when it is appropriate.

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

search_procurementA

Search awarded public procurement processes from El Salvador's COMPRASAL system. Returns matched awards, each with institution, supplier, awarded amount, dates, and process code. Use list_institutions first to turn an institution name into id_institucion. HOW FILTERING WORKS: the upstream government API only filters server-side by id_institucion. Year, free-text and date-range are applied CLIENT-SIDE by this server over the award date (fecha_adjudicacion) and text fields, by scanning newest-first pages. Because of that, prefer always passing id_institucion to keep the scan focused. The response includes a 'filtering' block: if window_fully_covered is false, increase 'page' to keep scanning older records. fecha_inicio/fecha_fin here DO filter on the actual award date. Each upstream record may represent one lot/supplier line of a larger process. One call scans a bounded number of pages (~7s each upstream), so it may take 10-40s.

ParametersJSON Schema

Name	Required	Description
`anio`	No	Fiscal year (client-side on fecha_adjudicacion).
`page`	No	Scan window start, 1-based.
`search`	No	Free-text, matched client-side.
`per_page`	No	Max matched results (default 20).
`fecha_fin`	No	Award-date upper bound YYYY-MM-DD.
`id_estado`	No	State id from list_states.
`fecha_inicio`	No	Award-date lower bound YYYY-MM-DD.
`id_modalidad`	No	Modality id from list_modalities.
`id_institucion`	No	Institution id from list_institutions.
`nombre_proceso`	No	Process name (client-side).

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: client-side filtering for year/text/date, newest-first page scanning, bounded page scans (~7s each, 10-40s total), the 'filtering' response block with window_fully_covered, and that each record may be a lot/supplier line.

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 long but every sentence adds value—no wasted words. It is front-loaded with purpose, then filtering details, then performance. Could be slightly tighter, but the complexity warrants the length.

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 10-parameter tool with no annotations or output schema, the description covers filtering, pagination, performance, and prerequisite steps (list_institutions). It lacks explicit guidance on id_estado and id_modalidad beyond schema, but siblings provide context. Overall highly complete.

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 the filtering mechanism for each parameter group (e.g., 'year, free-text and date-range are applied CLIENT-SIDE', 'fecha_inicio/fecha_fin here DO filter on the actual award date') and the purpose of per_page as max matched results.

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 explicitly states it searches awarded public procurement processes from COMPRASAL, returning key fields. It distinguishes itself from sibling tools like list_institutions and implies difference from get_process_detail by mentioning lot/supplier lines.

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

Usage Guidelines4/5

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

Provides extensive guidance: recommends using list_institutions first, explains filtering behavior (client-side vs server-side), suggests passing id_institucion to focus scans, details pagination via 'filtering' block, and notes performance. Lacks explicit when-not-to-use, but alternatives are implied through sibling names.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

8 tool updatesv0.2.0Jun 27, 2026
- First observedget_award_report
- First observedget_process_detail
- First observedget_supplier_contracts
- First observedlist_institutions
- First observedlist_modalities
- First observedlist_states
- First observedlist_years
- First observedsearch_procurement

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation4/5

Most tools have distinct purposes, but get_award_report and get_process_detail could be confused since both provide process details. The caveat about different IDs and the distinct focus (richest award vs full detail) help clarify, but there is potential for misselection.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (get_, list_, search_), making the set predictable for an agent.

Tool Count5/5

8 tools is well-scoped for a procurement data retrieval system, covering search, detail views, supplier lookup, and listing of reference entities without unnecessary bloat.

Completeness4/5

The tool set covers the main read operations (search, detail, supplier contracts, reference lists). A minor gap is the lack of a straightforward 'list all processes' tool, but search can be used broadly. Overall, the surface is adequate for the domain.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

TangoOAuth
dev.tango
MCP access to the U.S. federal procurement graph: contracts, opportunities, entities, and more.
Government Data Open Data
2
Ecuador Procurement A
io.github.pipeworx-io
Ecuador Government Procurement MCP — SERCOP / Compras Públicas (keyless).
Government Data Open Data
332
Chile Procurement A
io.github.pipeworx-io
Chile Government Procurement MCP — Mercado Público / ChileCompra (keyless-ish).
Government Data Open Data
332
Israel Tenders A
io.github.pipeworx-io
Israel Government Procurement MCP — public tenders & exemption contracts (keyless).
Government Data Open Data
332

Related MCP Servers

secop-mcp-server
Government Data Open Data
juandavidsernav
A
license
A
quality
D
maintenance
An MCP server to query Colombian public procurement data from SECOP I and II in real time, enabling contract research, transparency oversight, and data journalism.
Updated 6 months ago (2026-03-15 17:12 UTC)
10
2
MIT
chile-procurement
Government Data Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables access to Chile's government procurement data (Mercado Público / ChileCompra) via MCP, allowing AI agents to query public procurement information.
Updated 11 days ago (2026-08-26 16:47 UTC)
16
MIT
mcp-colombia-secop
Government Data Search
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables AI agents to query Colombian government procurement data via MCP tools or natural language questions.
Updated 11 days ago (2026-08-26 16:49 UTC)
16
MIT
MCP Compras.gov.br
Government Data Open Data
opedrosoares
A
license
A
quality
B
maintenance
Integrates public APIs from the Brazilian Compras.gov.br procurement ecosystem to support price research, supplier sanctions, contract analysis, and procurement planning.
Updated 5 days ago (2026-09-01 21:29 UTC)
94
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/glassbit/comprasal-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server