A
licenseNot graded
qualityC
maintenanceEnables users to find and contact building tradespeople in France, and lets independent tradespeople create free profiles.
Apache 2.0
MCP-iQuesta
Server Details
Recherche d'offres de stage et d'alternance en France via le réseau iQuesta.com
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- iQuesta/MCP-iQuesta
- GitHub Stars
- 0
- Server Listing
- iQuesta MCP Server
Available Tools
3 toolsget_jobAInspect
Récupère le détail complet d'une offre par son ID
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Identifiant 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
| Name | Required | Description | Default |
|---|---|---|---|
| filter | Yes | Quel 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. 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
| Name | Required | Description | Default |
|---|---|---|---|
| term | No | Mots-clés recherchés dans le titre de l'annonce (ex: 'développeur web', 'assistant marketing', 'ressources humaines') | |
| begin | No | Mois de début souhaité de la mission, de 1 (Janvier) à 12 (Décembre). Omettre si aucune contrainte de date. | |
| limit | No | Nombre maximum de résultats à retourner (défaut: 15, max recommandé: 20) | |
| regions | No | 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. | |
| duration | No | Durée maximale de la mission en mois (ex: 3, 6, 12, 24). Omettre si aucune contrainte de durée. | |
| matieres | No | 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. | |
| contracts | No | 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. | |
| description | No | 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. | |
| disciplines | No | 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. |
TDQS
A3.6/5.0
Behavior2/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 of behavioral disclosure. It does not mention whether the tool is read-only, has side effects, or any rate limits or authentication requirements. The only implied behavioral trait is that it is a search operation, but this is not explicitly stated.
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 a single sentence with an additional warning, which is concise and front-loaded with the core purpose. It could be structured slightly better (e.g., separating the usage guidance), but overall it is efficient and earned its place.
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 the 9 optional parameters and no output schema or annotations, the description provides adequate context on tool purpose and prerequisite usage. However, it lacks information about return format, pagination, error handling, or what happens when no results are found, leaving gaps for an agent.
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. The description does not add significant meaning beyond the detailed schema descriptions for each parameter (e.g., term, begin, limit, regions, etc.). The main added value is the guidance on using list_filters, which is not parameter-specific.
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 explicitly states that the tool searches for job offers (stage, alternance, emploi, or job étudiant) on iQuesta.com, and it distinguishes itself from siblings like get_job and list_filters by describing its filtering capabilities and the prerequisite call to list_filters.
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 clearly instructs users to call list_filters first to obtain valid IDs for filtering by region, discipline, or contract type, and warns against guessing IDs. This provides clear context for when to use this tool, though it does not explicitly state 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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
search_jobs2 fields changed- changed
Input schema / properties / limit / defaultPrevious value: -10New value: +15 - changed
Input schema / properties / limit / descriptionPrevious 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)"
2 tool updates
- Changed
list_filters2 fields changed- changed
Input schema / properties / filter / descriptionPrevious value: -"Quel filtre lister. 'all' retourne les trois."New value: +"Quel filtre lister. 'all' retourne les quatre." - changed
Input schema / properties / filter / enumPrevious value: -[ - "disciplines", - "regions", - "contracts", - "all" -]New value: +[ + "disciplines", + "matieres", + "regions", + "contracts", + "all" +]
- Changed
search_jobs4 fields changed- added
Input schema / properties / descriptionAdded 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" +} - added
Input schema / properties / matieresAdded 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" +} - changed
Input schema / properties / term / descriptionPrevious 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')" - changed
Input schema / requiredPrevious value: -[ - "term" -]New value: +[]
1 tool update
- Removed
get_similar_jobs
1 tool update
- Changed
search_jobs7 fields changed- changed
Input schema / properties / begin / descriptionPrevious 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." - changed
Input schema / properties / contracts / descriptionPrevious 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." - changed
Input schema / properties / disciplines / descriptionPrevious 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." - changed
Input schema / properties / duration / descriptionPrevious 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." - added
Input schema / properties / limitAdded value: +{ + "default": 10, + "description": "Nombre maximum de résultats à retourner (défaut: 10, max recommandé: 20)", + "type": "integer" +} - changed
Input schema / properties / regions / descriptionPrevious 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." - changed
Input schema / properties / term / descriptionPrevious value: -"Mots-clés de recherche"New value: +"Mots-clés de recherche (ex: 'développeur web', 'assistant marketing', 'ressources humaines')"
4 tool updates
- First observed
get_job - First observed
get_similar_jobs - First observed
list_filters - First observed
search_jobs
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
French job profiles, RNCP diplomas and 135,000 training programs. Read-only, no account.
Lieux, commerces, artisans et associations en France — 3,7 M de fiches, rangées par code NAF.
Search French companies: financials, directors, ownership, M&A and insolvency events.
French cultural events search with multi-reseller ticket price comparison (theatre, concerts...)
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables 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.-
- AlicenseNot gradedqualityCmaintenanceEnables 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
- AlicenseNot gradedqualityDmaintenanceResume parsing & candidate matching engine (European markets - ONSS/DIMONA compliance).MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A3.9/5.0
Disambiguation5/5
Each tool has a distinct purpose: get_job retrieves a specific job, list_filters provides valid filter IDs, and search_jobs searches for jobs. There is no overlap or ambiguity.
Naming Consistency5/5
All tools use verb_noun snake_case naming (get_job, list_filters, search_jobs), consistent in style and pattern.
Tool Count3/5
With only 3 tools, the set is minimal but covers the core workflow of searching and viewing jobs. It is on the lower end of acceptable for a job search server.
Completeness4/5
The surface covers searching with filters and fetching details. Minor gaps include no sorting or date filtering, but the essential CRUD for job viewing is present.