Skip to main content
Glama

search_tenders

Read-onlyIdempotent

Recherche des appels d'offres publics français (BOAMP) et européens (TED).

Environ 3 millions d'avis, mis à jour plusieurs fois par jour. Accès anonyme et
gratuit, limité à 30 appels par jour et par IP ; chaque réponse indique le solde
restant dans sa clé `quota`.

Cinq pièges, tous rencontrés en production :
1. Filtrez toujours. Sans aucun filtre la recherche porte sur tout le stock depuis
   2015, avis clos compris. Posez au minimum un `keyword`, un `cpv_family`,
   un `country` ou un `status`.
2. `keyword` cherche une sous-chaîne et exige que TOUS les mots soient présents
   dans le même avis. « défibrillateur cabinet » ne rend rien ; cherchez un seul
   mot, puis affinez.
3. Le mot-clé balaie le titre ET la description, noms d'acheteurs compris. Un terme
   métier qui est aussi un toponyme sur-capte donc beaucoup : « littoral » remonte
   une maintenance de portes au « GHT Somme Littoral Sud ». Quand un mot est ambigu,
   préférez un code CPV, ou une expression que ne peut pas porter un nom de lieu.
4. Les avis TED sont indexés dans leur langue de publication : pour couvrir un
   marché européen, interrogez le terme dans chaque langue utile, ou passez par
   le code CPV, qui lui est indépendant de la langue.
5. Environ 40 % des avis BOAMP arrivent sans aucun code CPV : un filtre CPV seul
   les laisse de côté. Croisez avec `keyword` quand la couverture compte.

Chaque paramètre est décrit dans le schéma d'entrée ; les valeurs invalides rendent
une erreur qui liste les valeurs acceptées, et cette erreur ne consomme pas de quota.

Les attributions (qui a gagné, pour quel montant) et le winner intelligence
ne sont PAS disponibles ici : ils demandent une clé. Voir https://tenderapi.fr/?via=mcp

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cpvNoCode CPV exact à 8 chiffres, ex. '72000000' pour les services informatiques. Environ 40 % des avis BOAMP n'ont aucun CPV : un filtre CPV seul les écarte.
pageNoNuméro de page, à partir de 1.
sortNo'date' (antéchronologique, défaut) ou 'relevance' (classement BM25). 'relevance' n'a de sens qu'avec un keyword et est refusé sans lui.
regionNoRégion française en slug, ex. 'bretagne', 'ile-de-france', 'occitanie'. Une valeur inconnue rend une erreur qui suggère le slug le plus proche.
sourceNo'boamp' (avis français) ou 'ted' (avis européens). Sans valeur, les deux.
statusNo'open' (date limite non dépassée, évaluée à l'instant de la requête) ou 'closed'. ⚠️ SANS ce filtre la recherche porte sur tout le stock depuis 2015, avis clos compris (~2,9 millions) : posez 'open' si vous cherchez des avis auxquels il est encore possible de répondre.
countryNoCode pays ISO à 2 lettres, ex. 'FR', 'DE', 'ES'. Utile pour ne garder que le français ('FR') ou cibler un pays sur le corpus TED.
keywordNoRecherche plein texte sur titre et description, insensible aux accents. TOUS les mots doivent figurer dans le même avis : préférez un seul mot puis affinez. L'opérateur OR de FTS5 est accepté, ex. 'BIM OR "maquette numerique"'.
page_sizeNoNombre d'avis par page, 10 par défaut, plafonné à 20 en anonyme. Un avis pèse environ 1 300 caractères : montez à 20 seulement si vous comptez les lire tous.
budget_maxNoMontant maximum en euros.
budget_minNoMontant minimum en euros. Les avis sans budget renseigné sont écartés, sauf include_null_budget=true.
cpv_familyNoPréfixe CPV à 2 chiffres, ex. '72' = toute l'informatique, '45' = travaux.
departmentNoCode de département, ex. '35', '2A', '974'. Plusieurs valeurs séparées par des virgules.
buyer_siretNoSIRET de l'acheteur, 14 chiffres exactement (l'établissement, pas l'entreprise).
descripteurNoCode descripteur BOAMP (nomenclature DILA), alternative au CPV côté français.
buyer_keywordNoFragment du nom de l'acheteur, 3 caractères minimum, ex. 'metropole', 'CHU'.
contract_typeNo'services', 'works' ou 'supplies'. Les formes françaises 'travaux' et 'fournitures' sont acceptées comme alias.
deadline_afterNoDate limite de remise postérieure à cette date ISO (AAAA-MM-JJ).
procedure_typeNoType de procédure, ex. 'open', 'restricted', 'negotiated'. Valeur inconnue = erreur listant les valeurs acceptées.
deadline_beforeNoDate limite de remise antérieure à cette date ISO (AAAA-MM-JJ).
published_afterNoPublié après cette date ISO (AAAA-MM-JJ). C'est le filtre d'une veille quotidienne.
include_planningNoInclure les avis de pré-information (marchés simplement envisagés, non encore ouverts). Exclus par défaut.
published_beforeNoPublié avant cette date ISO (AAAA-MM-JJ).
include_null_budgetNoGarder les avis dont le budget n'est pas renseigné malgré un filtre de montant. Beaucoup d'avis BOAMP n'annoncent aucun montant.
include_null_deadlineNoGarder les avis sans date limite malgré un filtre de date limite. Sans cela, un filtre deadline_* les écarte silencieusement.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNoExplication des raisons pour lesquelles la requête rend peu ou pas de résultats, et comment la corriger. Souvent renseigné sur un total de 0 : LISEZ-LE avant de conclure qu'il n'existe aucun avis, et reformulez en conséquence.
pageNoPage rendue.
quotaNoSolde du palier anonyme : {restant, plafond}. Surveillez-le plutôt que de découvrir le plafond en le heurtant.
totalNoNombre total d'avis correspondant aux filtres, toutes pages confondues.
resultsNoLes avis. Champs utiles : id (entier, à passer à get_tender), title, buyer_name, deadline, budget_max, region, source, source_url.
warningNoAvertissement sur l'interprétation des résultats (filtre ignoré, jeu tronqué).
page_sizeNoNombre d'avis par page.
client_updateNoNotice de mise à jour, uniquement pour le paquet pip `tenderapi-mcp`. Sans objet pour ce serveur hébergé, qui n'a rien à installer.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), so the description's job is to add non-obvious behavior — and it excels: the 30-call/day/IP quota with a `quota` balance returned in each response, several-times-daily updates, invalid values returning errors that list accepted values without consuming quota, and the stock-search-over-everything default. No contradiction with the annotations.

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 long, but every section earns its place: purpose and corpus first, then quota constraints, then five numbered pitfalls, error behavior, and scope exclusions. The numbered list is scannable, and the most critical rule (always filter) is front-loaded as pitfall 1. Each pitfall prevents a costly, silently-bad search, so the density is justified rather than redundant.

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?

For a tool with 25 parameters, two data sources, language-indexing quirks, and rate limits, the description is remarkably complete: it covers update cadence, anonymous access, quota semantics, error behavior, multilingual search, CPV coverage gaps, and feature exclusions. An output schema exists, so return-value documentation is not required of the description. Nothing an agent needs to call this tool correctly is missing.

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%, so the baseline is 3 and the schema fully documents all 25 parameters. The description adds some reinforcement value — pitfall 1 mandates at least one of keyword/cpv_family/country/status, and pitfall 5 reiterates the CPV coverage gap — plus the general statement that invalid values produce errors listing accepted values. This is useful emphasis, but it introduces no substantive parameter meaning beyond the schema.

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 opening sentence states a precise verb and resource: 'Recherche des appels d'offres publics français (BOAMP) et européens (TED)', naming both data sources and the corpus scale (~3M avis). It further delineates scope by explicitly listing what is NOT available ('Les attributions... et le winner intelligence ne sont PAS disponibles ici'), clearly distinguishing this search tool from the sibling get_tender.

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 five production pitfalls provide exceptionally concrete guidance on how to query correctly: always impose at least one filter, use single keywords because all words must match, prefer CPV codes for ambiguous terms, query TED in each relevant language, and combine CPV with keyword due to the 40% missing-CPV gap. It also states when the tool is appropriate (anonymous, quota-limited access) and what requires a key instead. However, it never explicitly names or routes to the siblings get_tender and preview_alerts, so when-vs-alternative guidance is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct operation: searching across tenders, retrieving one tender's full detail, and simulating an alert delivery. The descriptions clearly separate one-shot search from recurring alert preview, so there is little risk of misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: get_tender, search_tenders, preview_alerts. The verbs clearly express the action and the nouns are appropriate, creating a predictable naming scheme.

Tool Count5/5

With only three tools, the server is tightly scoped to its read-only tender search and alert preview purpose. Each tool adds a distinct capability and none feel redundant or missing.

Completeness4/5

The core search-and-retrieve workflow is well covered, and preview_alerts adds useful simulation. However, there is no tool to actually create or manage real alerts, and award/winner data is explicitly unavailable, leaving minor but documented gaps.