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 inclut une
veille par email, envoyée chaque lundi (rythme : `last_7d`). La veille quotidienne
(rythme : `last_24h`), Teams, webhook et plusieurs veilles relèvent de l'offre Pro,
15 €/mois.
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

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

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 : ce que le récapitulatif du lundi (clé gratuite) contiendrait.
last_24hNoParmi eux, ceux arrivés en 24 h : ce qu'un envoi quotidien (offre Pro) 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / last_24h / description
      Previous value: -"Parmi eux, ceux arrivés en 24 h : ce que le prochain envoi quotidien contiendrait."New value: +"Parmi eux, ceux arrivés en 24 h : ce qu'un envoi quotidien (offre Pro) contiendrait."
    • changedOutput schema / properties / last_7d / description
      Previous value: -"Arrivés dans les 7 derniers jours."New value: +"Arrivés dans les 7 derniers jours : ce que le récapitulatif du lundi (clé gratuite) contiendrait."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, but the description adds material context beyond them: nothing is persisted, no alert is sent, no account is created, it works without a key, and there is a 30-calls/day-per-IP limit surfaced in a `quota` key. That is exactly the extra behavioral disclosure annotations cannot carry.

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 front-loaded and organized with headers and numbered steps, and the core purpose leads. It is nonetheless long, and the pricing/affiliate paragraph (free key URL, Pro at 15 €/mois) sits closer to promotion than operational guidance, though it is tied to the tool's 'preview before subscribing' premise.

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, zero-required simulation tool with an output schema, the description covers what the agent needs: when to invoke, how to interpret the output keys (last_30d, sample, per_criterion, count, quota), iteration behavior, and access limits. Return values are already covered by the output schema.

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% and the schema itself is unusually rich (per-parameter warnings about CPV gaps, region-only-BOAMP behavior, normalization). The description's guidance ('composez les critères à partir du besoin exprimé') does not add parameter-level meaning beyond what the schema already provides, so the baseline 3 applies.

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?

States a specific verb and resource ('Montre ce qu'une veille automatique AURAIT livré avec ces critères, sans rien créer') and explicitly distinguishes itself from the sibling search_tenders by contrasting the questions each answers. An agent can route correctly without opening either schema.

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?

Names the alternative (search_tenders) and the exact condition that selects this tool ('quelqu'un qui envisage de s'abonner'). It then gives an ordered, prescriptive workflow (compose criteria, present last_30d/sample, read per_criterion, iterate if rate is nil) rather than leaving usage 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.