DEV Community

Cover image for Plug public tenders into an AI assistant in five minutes
Ahime
Ahime

Posted on Originally published at ahime.net

Plug public tenders into an AI assistant in five minutes

Searching public tenders by hand is repetitive: open a portal, pick a country, guess the right category, scan titles, repeat for the next market. It is exactly the kind of task an AI assistant can take over, as long as it has a reliable tool to call. This article walks through the method, a concrete example and the traps that waste time (and money) when you connect tender data to an assistant.

Why a tool beats a pasted list

You could paste a list of notices into a chat and ask questions. It works once. The list is stale the next day, it only covers what you copied, and the assistant cannot ask for more when your question changes.

A tool is different. With the Model Context Protocol (MCP), the assistant receives a short description of each available tool and its input schema. When you ask "any open IT tenders in Kenya this week?", it decides to call the search tool, reads the structured answer and summarises it. The data stays fresh because it is fetched at question time.

For tender data, three tools are enough to cover most questions:

  • search_tenders: open notices filtered by country, sector and keywords
  • list_sectors: the sector values the search accepts
  • list_countries: the countries that are actually covered

The two listing tools matter more than they look. They let the assistant discover valid values instead of guessing them.

The five-minute method

1. Get a key and keep it out of shared files

Usage-billed APIs identify you by a key. Put it in an environment variable or in your MCP client's local configuration, never in a repository or a shared document.

2. Register the MCP server in your client

Most MCP clients read a JSON configuration that lists servers. The exact shape depends on the client and on how the provider distributes its server, so take the command or URL from the provider's documentation. The structure usually looks like this:

{
  "mcpServers": {
    "tenders": {
      "command": "<command from the provider docs>",
      "env": { "API_KEY": "<your key>" }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Restart the client and check that the three tools appear in its tool list.

3. Let the assistant discover the vocabulary first

Before the first real search, ask the assistant to call the listing tools: "Which countries and sectors can you search?" This gives it the exact codes and labels, and gives you a quick check that the connection works.

4. Ask narrow questions

A good tender question has three parts: where (a country), what (a sector) and a hint (keywords). "Open tenders in Senegal, construction sector, mentioning solar" will produce a far more useful answer than "find me tenders".

5. Decide what happens next

The assistant can sort, summarise and draft a shortlist. The decision to bid, and the reading of the full tender documents, stays with you.

A concrete example

Say you run a small engineering firm and want water projects in two West African countries.

  1. You ask: "List the countries you cover." The assistant calls list_countries and returns the available ISO codes.
  2. You ask: "Which sector fits water supply?" It calls list_sectors and picks the closest label.
  3. You ask: "Open tenders in Ghana and in Côte d'Ivoire for that sector, keywords borehole or pipeline." The assistant makes one search call per country code, which keeps each answer clean and easy to compare.
  4. It returns a short table of the notices it found, grouped by country, with a one-line summary of each.

An illustrative call looks like this (the real argument names are in the tool schema your client receives):

{
  "tool": "search_tenders",
  "arguments": {
    "country": "GH",
    "sector": "<label returned by list_sectors>",
    "keywords": "borehole pipeline"
  }
}
Enter fullscreen mode Exit fullscreen mode

Three calls for the discovery steps, two for the searches: five calls to answer a real business question.

Pitfalls to avoid

Guessing country and sector values

Assistants are confident. Without the listing tools they will invent a sector name that sounds right and get an empty result, then conclude there are no tenders. Always let them list values first, or put the valid values in your prompt.

Forgetting the page size

A response returns a limited number of notices (up to 15 per response with the API described below). If a broad query hits that ceiling, the assistant sees 15 results and may present them as "all the tenders". Narrow the query with keywords or ask it to say when the limit is reached.

Expecting the full dossier

A tender search returns notices, not the complete documents. Specifications, annexes and clarifications live on the buyer's portal. Ask the assistant for the notice reference, find it on the buyer's portal and read the source yourself before any bid decision.

Confusing open notices with awards

Open notices tell you what is being bought now. Award notices tell you who won past contracts. They answer different questions; an open-tenders tool will not tell you who your competitors were last year.

Assuming every source is covered

Coverage depends on which publication sources are open to automated reuse. Some national bulletins, multilateral portals and regional development bank sites are not part of open feeds. If a market matters to you, check list_countries and keep a manual watch on the sources that are missing.

Letting the assistant loop on a paid API

With usage billing, every tool call costs something. An assistant asked to "check all countries" may happily call the search tool dozens of times. Set a monthly cap on the account, phrase questions per country or per group of countries, and prefer one scheduled weekly question over constant ad hoc checks.

A weekly routine that works

  • Monday: ask for open notices in your three priority countries and two sectors.
  • Ask the assistant to flag the notices that match your capacity and to say why.
  • Keep the shortlist in a shared document with the notice references.
  • Read the full documents of the two or three best matches on the buyer's portal.

This keeps the assistant on the boring part (finding and filtering) and leaves the judgement (bid or no bid) to you.

Going further

If you prefer code over chat, the same three operations are usually exposed as a plain REST API, so a script or a spreadsheet integration can run the weekly query without any assistant at all. MCP and REST are two doors to the same data.

If you want a ready-made source for this setup, Tenders API returns the latest open public tenders by country and sector, as a REST API and as MCP tools on the same key, with npm and PyPI clients, a limited free trial and usage billing with a monthly cap: https://www.ahime.net/api-appels-offres/en/


This article was written with the help of AI tools and reviewed before publication. Originally published at https://www.ahime.net/api-appels-offres/blog/public-tenders-ai-assistant-mcp/.

Top comments (0)