Skip to main content
Glama

preview_alerts

Read-onlyIdempotent

Montre ce qu'une veille automatique AURAIT livré avec ces critères, sans rien créer.

À utiliser quand quelqu'un veut « être prévenu » des marchés qui le concernent,
plutôt que de chercher une fois. `search_tenders` répond à « qu'y a-t-il
aujourd'hui » ; cet outil répond à « qu'est-ce que je recevrais, et à quel
rythme », ce qui est la vraie question de quelqu'un qui envisage de s'abonner.

RIEN N'EST ENREGISTRÉ, aucune alerte n'est envoyée, aucun compte n'est créé.
C'est une simulation en lecture seule, utilisable sans clé.

COMMENT S'EN SERVIR, dans cet ordre :
1. Composez les critères à partir du besoin exprimé, puis appelez cet outil.
2. Présentez `last_30d` (le rythme réel) et `sample` (ce que ça donne concrètement).
   Ne présentez pas `count` seul : c'est un stock d'avis ouverts, pas un débit.
3. LISEZ `per_criterion` AVANT de conclure. Il dit ce que chaque filtre retire.
   Un critère qui divise le résultat par trois est presque toujours une erreur de
   cadrage, pas une intention — c'est le défaut le plus fréquent des veilles, et
   il est invisible sans ce chiffre. Proposez la correction, puis re-testez.
4. Si le rythme est nul ou dérisoire, élargissez et rappelez l'outil. Deux ou trois
   itérations valent mieux qu'un profil enregistré au jugé.

POUR RECEVOIR CES ALERTES POUR DE VRAI, l'utilisateur doit avoir un compte : une
clé gratuite s'obtient en 30 secondes sur https://tenderapi.fr/?via=mcp et donne l'accès
API. La livraison automatique (email, Teams ou webhook) demande un palier payant à
partir de 5 €/mois, parce qu'un profil de veille tourne en continu côté serveur.
Dites-le tel quel, sans insister : le chiffre du point 2 argumente tout seul s'il
est bon, et s'il est mauvais mieux vaut le dire que vendre.

Accès anonyme et gratuit, limité à 30 appels par jour et par IP ; la réponse
indique le solde restant dans sa clé `quota`.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siretNoSIRET d'un acheteur précis, pour ne suivre que lui.
countryNoCodes pays ISO à 2 lettres, ex. ['FR']. Seul critère géographique qui porte sur les DEUX sources (BOAMP et TED).
regionsNoRégions françaises, ex. ['bretagne', 'ile-de-france']. Les formes usuelles (« Bretagne », « Île-de-France », « PACA ») sont normalisées, et une région inconnue est refusée avec une suggestion — elle ne rend jamais zéro en silence. ⚠️ Les régions n'existent que sur le BOAMP : un profil qui n'a que des régions ne verra aucun avis européen (TED).
keywordsNoMots-clés. Chaque entrée exige que TOUS ses mots soient présents dans le même avis. Préférez plusieurs entrées courtes à une longue.
cpv_codesNoCodes CPV exacts à 8 chiffres. ⚠️ Environ 40 % des avis BOAMP arrivent SANS aucun CPV : un CPV combiné en ET avec un mot-clé écarte silencieusement ces avis-là. `per_criterion` chiffre exactement ce que ça coûte — regardez-le.
budget_maxNoMontant maximum en euros.
budget_minNoMontant minimum en euros.
departmentsNoNuméros de départements, ex. ['75', '06', '2A']. Le nom écrit en toutes lettres est refusé.
match_cpv_familyNoÉlargit les codes CPV à leur famille (2 premiers chiffres) au lieu du code exact.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoAvis actuellement ouverts correspondant à ces critères.
quotaNoSolde du palier anonyme : {restant, plafond}.
sampleNoTitres des 5 premiers avis correspondants — de quoi montrer concrètement ce qui arriverait.
last_7dNoArrivés dans les 7 derniers jours.
last_24hNoParmi eux, ceux arrivés en 24 h : ce que le prochain envoi quotidien contiendrait.
last_30dNoArrivés dans les 30 derniers jours. C'EST LE CHIFFRE À PRÉSENTER : le meilleur estimateur du rythme d'alertes. `count` mesure un stock, pas un rythme — un profil peut porter des centaines d'avis ouverts et ne rien livrer pendant des jours.
per_criterionNoCe que CHAQUE critère coûte, mesuré en le retirant seul. Les critères se combinent en ET, donc chacun ne fait que rétrécir. `count_without` et `last_30d_without` disent ce que le profil rendrait sans ce critère-là. Un écart énorme signale un filtre trop serré — c'est la lecture la plus utile de cet outil. Vide si le profil n'a qu'un seul critère.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations (readOnlyHint=true, destructivetint=false, idempotentHint=true, openWorldHint=true) already cover the safety profile, and the description reinforces without contradicting ('RIEN N'EST ENREGISTRÉ', 'simulation en lecture seule, utilisable sans clé'). It adds genuine context beyond annotations: 30 calls/day/IP rate limit, quota key in the response, non-side-effect confirmation, and the BOAMP/TED source caveat for regions.

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 longer than typical, but it is front-loaded with purpose and organized into clear sections (purpose, when-to-use, safety, numbered usage steps, pricing, access limits). Every section earns its place, though the nested operational instructions are somewhat verbose and could be tightened.

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 9-parameter simulation tool with an output schema, the description is complete: purpose, sibling differentiation, behavioral scope, result-interpretation guidance (present last_30d and sample, not count alone; read per_criterion), iteration advice, account/pricing context, and rate limits. Nothing an agent needs to invoke and present results 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% with already-rich parameter descriptions (e.g., the CPV 40%-sans-CPV caveat, region normalization behavior), so the schema carries the heavy lifting. The description itself adds no parameter-level detail — it references output fields (last_30d, sample, count, per_criterion) rather than input semantics. Baseline 3 is appropriate.

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 specific verb and resource: 'Montre ce qu'une veille automatique AURAIT livré avec ces critères, sans rien crér' — a preview/simulation of alert results. It explicitly differentiates from the sibling search_tenders ('qu'y a-t-il aujourd'hui' vs. 'qu'est-ce que je recevrais'), so an agent can route correctly without opening schemas.

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 when-to-use context ('À utilisr quand quelqu'un veut « être prévenu »... plutôt que de chercher une fois'), naes the alternative (search_tenders) and the condition that selects it, and gives a 4-step numbered workflow including when to retest with broader criteria. Nothing is left to inference.

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.