MCP-iQuesta
Server Details
Recherche d'offres de stage et d'alternance en France via le réseau iQuesta.com
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 3 of 3 tools scored. Lowest: 3.3/5.
Each tool has a clearly distinct purpose: get_job retrieves job details, list_filters provides filter options, and search_jobs performs searches. No overlap or ambiguity.
All tool names follow the snake_case verb_noun pattern (get_job, list_filters, search_jobs), which is consistent and predictable.
With 3 tools, the server is well-scoped for its purpose of job search and retrieval. It covers the essential operations without being too minimal or too heavy.
The tool set covers the full lifecycle for job searching: prerequisites (list_filters to get IDs), core search (search_jobs), and detail retrieval (get_job). There are no obvious gaps for this domain.
Available Tools
3 toolsget_jobBInspect
Récupère le détail complet d'une offre par son ID
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Identifiant de l'offre dans iQuesta |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits like read-only nature, authentication needs, or response format. The phrase 'full detail' is vague and lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no nested objects), the description is minimally adequate. However, it could detail expected output or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate as the description does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Récupère), the resource (détail complet d'une offre), and the method (par son ID). It distinguishes from siblings like get_similar_jobs and search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_similar_jobs, list_filters, or search_jobs. The description does not mention 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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | Yes | Quel filtre lister. 'all' retourne les quatre. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description adequately conveys a read-only enumeration operation with no side effects. Simple list tool, so high transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded core function and no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers purpose, usage, and parameter semantics for a simple one-parameter tool without output schema. Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter with description, but the tool's description adds real-world context about converting names to IDs, enriching the schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it lists possible values for search filters (disciplines, regions, contract types), clearly distinguishing it from sibling tools get_job and search_jobs which perform different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call before search_jobs if the user mentions a sector or region, to convert name to ID, providing clear when-to-use and how it relates to siblings.
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.
| 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: 10, 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only describes the search action without mentioning read-only nature, auth requirements, rate limits, or any side effects. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, followed by essential usage guidance. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and no annotations, the description covers the search function, filter prerequisites, and parameter examples. It lacks details on return format or pagination, but for a search tool with clear filter guidance, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds meaningful context: reiterates that IDs must come from list_filters, provides example values for contracts, and explains the difference between matieres and disciplines. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for specific job types (stage, alternance, emploi, job étudiant) on iQuesta.com, with a specific verb and resource. It distinguishes from siblings by referencing list_filters for ID retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call list_filters first to obtain valid IDs for filtering, and warns against guessing IDs. It does not explicitly contrast with get_job or state when not to use this tool, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!