Open Contracting MCP server

@pipeworx/open-contracting

Open Contracting MCP — international public procurement: government tenders and contract awards published under the OCDS (Open Contracting Data Standard). Mirrors bulk OCDS releases from 19 national and subnational publishers — 838,000+ contracting processes — refreshed weekly from the OCP Data Registry.

Part of Pipeworx — an MCP gateway connecting AI agents to 1679+ live data sources.

Tools

free-text search over tender title, buyer and description. See Language matching — the query works in English even where the data is not.

• octendersearch(query, country, status, category, min_value, days, limit) —

out" view.

• oc_recent(country, days, limit) — newest releases first, the "what just came

order, showing the tender → award → contract progression.

• ocprocesshistory(ocid) — every release for one contracting process, in

latest-release freshness. Call it first to see what is actually there.

• oc_coverage() — per-country publisher, release and process counts, and

Auth

None for the caller. The gateway injects the pack's data credentials — it reads the OCDS bulk publications over PostgREST, so a query resolves against one backing store rather than depending on 19 separate upstream APIs being up at once.

Keep the wording here descriptive of WHAT is returned, not of where it is served from: pnpm check:hosting-claims fails the build on published copy that tells callers we hold a copy of upstream data, and this file is published (it generates docs/reference/open-contracting/). That gate red-lined main for nine consecutive pushes on 2026-08-23.

Language matching

Only 7 of the 19 publishers file their tender text in English. The rest publish in their own language, and the tool description and country argument are both in English, so an English question used to hit a silent zero: {"query":"Ministry of Health","country":"Dominican Republic"} returned 0 of 40,740 processes, while "Ministerio de Salud" returned rows.

octendersearch now expands the query instead of translating it. The phrase you passed is always searched; alongside it go its equivalents in the language of the country you filtered to, drawn from a synonym table of the buyer and subject words these corpora actually use (ministry / ministerio / ministria / ministarstvo / ministero / กระทรวง, and ~45 more). Every spelling rides in one PostgREST or=(...), which is a single SQL predicate — the branches union, so a row matching several is still returned once and there is no second round trip.

Three properties worth knowing:

language, so rewriting the query one way would drop whatever is filed the other way. A native-language query keeps working and can only gain rows.

• It expands, never replaces. These corpora are mixed, not consistently one

types Ministerio de Educacion gets the stored MINISTERIO DE EDUCACIÓN, because the unaccented Spanish token resolves through the same table to the accented stored form. That keeps every pattern fully literal, so the trigram index still applies.

• The lookup is bidirectional, which is also the accent fix. A caller who

spellings) and querymatch.publisherlanguage. A zero result returns a hint naming the publisher's language, rather than a bare count: 0 that teaches the caller the data is absent when it is present.

• It says what it searched. The response carries query_match.searched (the

Shortened. The full README is on GitHub.