Skip to main content
Glama

Projet Ariane — Orientation

Rechercher une formation

rechercher_formation
Read-only

Trouve des formations (BTS, BUT, licences, masters, CPGE, écoles…) par intitulé, ville, niveau ou type, classées par pertinence, avec le taux d'accès Parcoursup et des liens vers les fiches (données Projet Ariane). Avec ville et rayon_km : formations autour de la commune, de la plus proche à la plus lointaine, avec la distance à vol d'oiseau.

Input Schema

NameRequiredDescriptionDefault
typeNoType de filière : BTS, BUT, LICENCE, MASTER, CPGE, INGENIEUR, COMMERCE…
villeNoVille, département ou région (ex. Lyon, Rhône, Bretagne).
limiteNoNombre de résultats (défaut 6, maximum 20).
niveauNoNiveau CEC visé, de 3 (CAP) à 8 (doctorat) — ex. 5 pour un BTS, 6 pour une licence, 7 pour un master.
rayon_kmNoRayon autour de la ville, en km (1 à 300) : résultats triés par distance à vol d'oiseau. Exige ville.
rechercheYesIntitulé ou discipline de la formation (ex. BTS informatique, licence psychologie). Avec ville ou rayon_km, seulement cela : ni la ville, ni la modalité (alternance, apprentissage).
code_postalNoCode postal de la ville, pour départager les homonymes (ex. 93200 pour Saint-Denis).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / ville / description
      Previous value: -"Ville (ex. Lyon, Colmar)."New value: +"Ville, département ou région (ex. Lyon, Rhône, Bretagne)."
  2. Changed3 schema fields changed
    • addedInput schema / properties / code_postal
      Added value: +{
      +  "description": "Code postal de la ville, pour départager les homonymes (ex. 93200 pour Saint-Denis).",
      +  "maxLength": 5,
      +  "minLength": 5,
      +  "type": "string"
      +}
    • addedInput schema / properties / rayon_km
      Added value: +{
      +  "description": "Rayon autour de la ville, en km (1 à 300) : résultats triés par distance à vol d'oiseau. Exige ville.",
      +  "maximum": 300,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • changedInput schema / properties / recherche / description
      Previous value: -"Intitulé, discipline ou mots-clés (ex. BTS informatique, licence psychologie)."New value: +"Intitulé ou discipline de la formation (ex. BTS informatique, licence psychologie). Avec ville ou rayon_km, seulement cela : ni la ville, ni la modalité (alternance, apprentissage)."
  3. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare a safe read operation (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description doesn't need to repeat that. It adds that results are ranked by relevance, include Parcoursup access rates and links, and when ville+rayon_km are given results are sorted by distance with the distance shown. It doesn't mention pagination or rate limits, which is acceptable for a read-only search.

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?

Two efficient sentences: the first describes the core search and output, the second describes the geographic mode. No filler, and key mode-switching info is front-loaded in the second sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description explains the main return fields (relevance, access rate, links, distance) and the geographic sorting mode. It is complete enough for an agent to call the tool correctly; only minor gaps like exact default limits remain.

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 coverage is 100%, so the schema already documents all parameters well. The description reinforces the behavior of ville+rayon_km and the notion of relevance ranking, but it adds little about parameter syntax or defaults beyond what the schema provides. Baseline 3.

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 description states a specific verb (Trouve) and resource (formations) with the covered fields (intitulé, ville, niveau, type), and distinguishes itself from fiche_formation by returning ranked lists with link destinations. It also names sibling-like alternatives to open the fiche details (fiche_formation).

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 description clarifies that ville+rayon_km selects a geographic proximity mode sorted by distance, which is a clear usage context. It does not explicitly say when to use this tool versus fiche_formation or rechercher_ecole, but the context implies it is the search entry point.

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.

Resources