Skip to main content
Glama

MCP-iQuesta

by io.github.iQuesta
OverviewDiscussionsAdmin

Server Details

Recherche d'offres de stage et d'alternance en France via le réseau iQuesta.com

Ownership verified
Status
Healthy
Uptime
99.4% over 54 days
Last Tested
Transport
Streamable HTTP · MCP 2024-11-05
URL
Repository
iQuesta/MCP-iQuesta
GitHub Stars
0
Server Listing
iQuesta MCP Server

TDQS

A4.1/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: retrieving a single job by ID, listing filter options, and performing a search. There is no overlap or ambiguity between these operations.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_job, list_filters, search_jobs). The pattern is predictable and immediately conveys the action and resource.

Tool Count5/5

Three tools is well-scoped for a job search server, covering the essential workflow: discover filters, search, and fetch details. No unnecessary or missing tools.

Completeness5/5

For a read-only job search domain, the surface is complete: list_filters enables valid search parameters, search_jobs provides the core query, and get_job retrieves full details. There are no dead ends or obvious gaps.

Available Tools

3 tools
get_jobAInspect

Récupère le détail complet d'une offre par son ID

ParametersJSON Schema
NameRequiredDescriptionDefault
job_idYesIdentifiant de l'offre dans iQuesta

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It states it retrieves 'full details', but does not specify what those details include, nor any rate limits, authentication needs, or side effects. For a simple read operation, minimal but acceptable.

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 a single sentence that is front-loaded with the essential action. No unnecessary words; every part contributes to understanding. Ideal conciseness.

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

Completeness3/5

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

Given no output schema, the description should hint at the return structure. It says 'détail complet' but lacks specifics. For a simple retrieval tool, it is adequate but not rich. Could mention that it returns all fields of the job.

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% with a clear description for job_id. The description adds no additional meaning beyond what the schema provides ('par son ID' is already implicit). Baseline 3 is appropriate as the schema does the heavy lifting.

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 'Récupère le détail complet d'une offre par son ID' clearly states the verb (récupère), resource (offre), and method (par son ID). It effectively distinguishes from sibling tools list_filters and search_jobs, which imply different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving a single job by ID, but does not explicitly state when to use this tool over siblings (e.g., 'Use search_jobs for filtering, list_filters for filter options'). No exclusions or prerequisites are mentioned.

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

list_filtersAInspect

Liste les valeurs possibles pour les filtres de recherche (disciplines, régions, types de contrat). À appeler avant search_jobs si l'utilisateur mentionne un secteur ou une région, pour convertir le nom en ID correct.

ParametersJSON Schema
NameRequiredDescriptionDefault
filterYesQuel filtre lister. 'all' retourne les quatre.

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the action (listing values) but does not disclose details like return format or side effects. For a read-only listing tool, this is adequate but not exhaustive.

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 a single, front-loaded sentence with no wasted words. Every part is relevant and essential.

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?

Given the tool has only one parameter and no output schema, the description is fairly complete. It covers the action, usage context, and parameter purpose, leaving little ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with enums and descriptions. The description adds value by explaining the purpose of the tool (converting names to IDs), which enriches understanding 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 description clearly states it lists possible values for search filters, naming specific filter types (disciplines, regions, contract types). It distinguishes itself from siblings by indicating it should be called before search_jobs.

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 explicitly tells when to use this tool: before search_jobs when a user mentions a sector or region, to convert the name to an ID. It provides clear context but does not mention alternatives or when not to use it.

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

search_jobsAInspect

Recherche des offres de stage, alternance, emploi ou job étudiant sur iQuesta.com. Avant de lancer la recherche, demander à l'utilisateur quel type de contrat il recherche (stage, alternance, emploi, job étudiant) si ce n'est pas précisé dans sa demande. Pour filtrer par région, discipline ou type de contrat, appeler d'abord list_filters pour obtenir les IDs valides — ne jamais deviner un ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
termNoMots-clés recherchés dans le titre de l'annonce (ex: 'développeur web', 'assistant marketing', 'ressources humaines')
beginNoMois de début souhaité de la mission, de 1 (Janvier) à 12 (Décembre). Omettre si aucune contrainte de date.
limitNoNombre maximum de résultats à retourner (défaut: 15, max recommandé: 20)
regionsNoID de région française, obtenu via list_filters(filter='regions'). Exemple : 10 pour Ile de France, 6 pour Bretagne. Toujours vérifier la liste complète avant de choisir un ID, ne jamais deviner.
durationNoDurée maximale de la mission en mois (ex: 3, 6, 12, 24). Omettre si aucune contrainte de durée.
matieresNoListe d'IDs de matières, obtenus via list_filters(filter='matieres'). Plus précis que 'disciplines' (ex: 'Développement web' plutôt que 'Informatique'). Toujours vérifier la liste complète avant de choisir un ID, ne jamais deviner.
contractsNoID du type de contrat. Valeurs : '1' (Stage), '2' (Alternance), '-4' (Emploi), '-5' (Job étudiant). Toujours demander ce critère à l'utilisateur s'il ne l'a pas précisé — ne jamais omettre ce filtre.
descriptionNoMots-clés recherchés dans le texte/descriptif complet de l'annonce (missions, compétences requises, etc.). À utiliser pour cibler des compétences ou détails précis absents du titre.
disciplinesNoID de discipline, obtenu via list_filters(filter='disciplines'). Exemple : 9 pour Informatique, 5 pour Economie/Gestion/Commerce. Toujours vérifier la liste complète avant de choisir un ID, ne jamais deviner.

TDQS

A4.1/5.0
Behavior4/5

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

No annotations are present, so the description carries the behavioral disclosure burden. It adds meaningful interaction behavior: always confirm the contract type with the user, and never guess filter IDs because they must come from list_filters. The verb 'Recherche' also implies a read-only search. It does not describe result shape or error behavior, but these are secondary for a search tool.

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?

Three sentences, all of which earn their place: the tool's purpose, the required user interaction, and the filter-ID prerequisite. It is front-loaded with the core purpose and contains no filler.

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

Completeness3/5

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

It covers the key interaction and filter-prerequisite context well, but with no output schema and no annotations it omits any description of the return shape, pagination, or how results relate to get_job. Good but not fully complete for a complex 9-parameter tool.

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 applies and every parameter is already documented. The description mostly restates the schema's own warnings about obtaining IDs from list_filters and asking for the contract type, adding little per-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 description clearly identifies a search over job offers on a specific site: 'Recherche des offres de stage, alternance, emploi ou job étudiant sur iQuesta.com'. The verb 'Recherche' plus the resource scope makes it unambiguous versus get_job (single lookup) and list_filters (filter metadata).

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 gives explicit procedural guidance: ask the user for a contract type if it was not provided, and call list_filters first before filtering by region, discipline, or contract type. It does not explicitly contrast with get_job for single-job lookups, so it stops short of a 5.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedsearch_jobs1 field changed
      • changedInput schema / properties / contracts / description
        Previous value: -"ID du type de contrat, obtenu via list_filters(filter='contracts'). Valeurs possibles : '1' (Stage), '2' (Contrat en alternance), '-4' (Emploi), '-5' (Job étudiant). Omettre pour rechercher tous types confondus."New value: +"ID du type de contrat. Valeurs : '1' (Stage), '2' (Alternance), '-4' (Emploi), '-5' (Job étudiant). Toujours demander ce critère à l'utilisateur s'il ne l'a pas précisé — ne jamais omettre ce filtre."
  2. 1 tool update
    • Changedsearch_jobs2 fields changed
      • changedInput schema / properties / limit / default
        Previous value: -10New value: +15
      • changedInput schema / properties / limit / description
        Previous value: -"Nombre maximum de résultats à retourner (défaut: 10, max recommandé: 20)"New value: +"Nombre maximum de résultats à retourner (défaut: 15, max recommandé: 20)"
  3. 2 tool updates
    • Changedlist_filters2 fields changed
      • changedInput schema / properties / filter / description
        Previous value: -"Quel filtre lister. 'all' retourne les trois."New value: +"Quel filtre lister. 'all' retourne les quatre."
      • changedInput schema / properties / filter / enum
        Previous value: -[
-  "disciplines",
-  "regions",
-  "contracts",
-  "all"
-]New value: +[
+  "disciplines",
+  "matieres",
+  "regions",
+  "contracts",
+  "all"
+]
    • Changedsearch_jobs4 fields changed
      • addedInput schema / properties / description
        Added value: +{
+  "description": "Mots-clés recherchés dans le texte/descriptif complet de l'annonce (missions, compétences requises, etc.). À utiliser pour cibler des compétences ou détails précis absents du titre.",
+  "type": "string"
+}
      • addedInput schema / properties / matieres
        Added value: +{
+  "description": "Liste d'IDs de matières, obtenus via list_filters(filter='matieres'). Plus précis que 'disciplines' (ex: 'Développement web' plutôt que 'Informatique'). Toujours vérifier la liste complète avant de choisir un ID, ne jamais deviner.",
+  "items": {
+    "type": "integer"
+  },
+  "type": "array"
+}
      • changedInput schema / properties / term / description
        Previous value: -"Mots-clés de recherche (ex: 'développeur web', 'assistant marketing', 'ressources humaines')"New value: +"Mots-clés recherchés dans le titre de l'annonce (ex: 'développeur web', 'assistant marketing', 'ressources humaines')"
      • changedInput schema / required
        Previous value: -[
-  "term"
-]New value: +[]
  4. 1 tool update
    • Removedget_similar_jobs
  5. 1 tool update
    • Changedsearch_jobs7 fields changed
      • changedInput schema / properties / begin / description
        Previous value: -"Date de début dans iQuesta (Mois) (ex: 1 pour Janvier, etc.)"New value: +"Mois de début souhaité de la mission, de 1 (Janvier) à 12 (Décembre). Omettre si aucune contrainte de date."
      • changedInput schema / properties / contracts / description
        Previous value: -"Type de contrat : 1 pour stage, 2 pour alternance, -5 Job étudiant, -4 Emploi"New value: +"ID du type de contrat, obtenu via list_filters(filter='contracts'). Valeurs possibles : '1' (Stage), '2' (Contrat en alternance), '-4' (Emploi), '-5' (Job étudiant). Omettre pour rechercher tous types confondus."
      • changedInput schema / properties / disciplines / description
        Previous value: -"Domaine dans iQuesta (ex: 61 pour Accueil/Hôte(sse), etc.)"New value: +"ID de discipline, obtenu via list_filters(filter='disciplines'). Exemple : 9 pour Informatique, 5 pour Economie/Gestion/Commerce. Toujours vérifier la liste complète avant de choisir un ID, ne jamais deviner."
      • changedInput schema / properties / duration / description
        Previous value: -"Durée maximale en mois dans iQuesta(ex: 3 pour 3 mois)"New value: +"Durée maximale de la mission en mois (ex: 3, 6, 12, 24). Omettre si aucune contrainte de durée."
      • addedInput schema / properties / limit
        Added value: +{
+  "default": 10,
+  "description": "Nombre maximum de résultats à retourner (défaut: 10, max recommandé: 20)",
+  "type": "integer"
+}
      • changedInput schema / properties / regions / description
        Previous value: -"Région dans iQuesta (ex: 1 pour Grand Est,etc.)"New value: +"ID de région française, obtenu via list_filters(filter='regions'). Exemple : 10 pour Ile de France, 6 pour Bretagne. Toujours vérifier la liste complète avant de choisir un ID, ne jamais deviner."
      • changedInput schema / properties / term / description
        Previous value: -"Mots-clés de recherche"New value: +"Mots-clés de recherche (ex: 'développeur web', 'assistant marketing', 'ressources humaines')"
  6. 4 tool updates
    • First observedget_job
    • First observedget_similar_jobs
    • First observedlist_filters
    • First observedsearch_jobs

Related MCP Connectors

Related MCP Servers

  • jobs-scrape-mcp

    XavierBeheydt
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables AI assistants to query a corpus of job offers via natural language, using BM25 search, facets, and trend analysis to answer questions about skills, positions, and timelines.
    -

  • Vocaneo MCP Server

    CIB-PROD
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI assistants to search and retrieve French job profiles, RNCP certifications, training programs, training centers, and skills comparisons in read-only mode without requiring an account.
    MIT

  • Internship Scout & Quality of

    c-r-lewis
    F
    license
    Not graded
    quality
    D
    maintenance
    Integrates Eurostat quality-of-life metrics and real-time job searching to help users find international internships in high-ranking European cities. It enables ranking cities based on personalized criteria like safety or transport and retrieves structured internship listings via the Tavily API.
    1
    -

  • Job Search MCP Server

    Ritesh-sudo
    F
    license
    C
    quality
    D
    maintenance
    Enables searching for AI/ML internships and entry-level positions across multiple job sites including LinkedIn, Indeed, Glassdoor, ZipRecruiter, and Monster. Automatically filters for Python proficiency and relevant AI/ML skills while providing structured job data with application URLs and detailed requirements.
    2
    1
    -
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources