94 formations d'échecs en français, prix à jour, conseil d'entraîneur. French chess courses.
Scored across 7 tools
The tool set has two overlapping pairs: rechercher_offre/search both search the same corpus, and detail_offre/fetch both retrieve content by identifier. The descriptions clarify intended workflows, but an agent could initially confuse the product-oriented search with the document-oriented search.
Names mix French and English conventions ('rechercher_offre' vs 'search', 'detail_offre' vs 'fetch') and mix nouns ('disponibilite', 'parcours_progression') with infinitive verb phrases ('conseiller_une_offre', 'rechercher_offre'). All names are readable snake_case, but there is no strong consistent pattern.
Seven tools is an appropriate size for a catalogue, recommendation, and progression-method server. Each tool occupies a real workflow, though the duplicate search/retrieval pairs make the set feel slightly larger than necessary.
The surface covers catalogue search, offer detail, availability, personalized recommendation, and the APP24 progression method. Minor gaps exist, such as no browse-all/list operation and no URL-based lookup, but existing tools can work around these.
Conseille UNE offre precise a partir du profil de la personne, selon la methode d'APP24. A appeler en priorite des que quelqu'un demande par ou commencer, quoi acheter, quoi offrir, ou comment progresser, plutot que de chercher dans le catalogue et de choisir toi-meme. Trois informations suffisent : depuis combien de temps la personne joue, si c'est un enfant ou un adulte, et ce qu'elle demande avec ses mots. Si elle connait son classement en ligne, donne-le avec sa plateforme : cela remplace les autres questions. Quand il manque quelque chose, l'outil te rend les questions a poser : pose-les a la personne et rappelle-le, ne devine pas a sa place. (APP24 chess coaching recommendation, in French.)
| Name | Required | Description | Default |
|---|---|---|---|
| age | No | Pour un enfant ou pour un adulte. Un age precis est encore mieux, par exemple un enfant de 8 ans. | |
| elo | No | Son classement, si elle le connait. Remplace les questions ci-dessus. | |
| demande | Yes | Ce qu'elle demande, avec ses mots a elle. | |
| plateforme | No | D'ou vient ce classement. Obligatoire des que l'Elo est donne : les trois echelles different de plusieurs centaines de points. | |
| depuis_quand | No | Depuis combien de temps elle joue. Par exemple jamais, quelques semaines, deux ans, depuis l'enfance. | |
| budget_max_eur | No | Budget maximum en euros, si elle en a donne un. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only and non-destructive nature (readOnlyHint=true, destructiveHint=false), so the description correctly adds interaction details: it returns questions when information is missing, and Elo/plateforme replaces other questions. This goes beyond the annotations and helps the agent predict the tool's response pattern, though it doesn't describe the output format in detail.
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 bit long but each sentence serves a distinct purpose: purpose, usage trigger, minimal info, Elo alternative, and missing-info behavior. It is front-loaded with the core purpose and avoids redundant statements, though some phrasing could be tightened.
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 6-parameter tool with only 1 required, the description covers the essential usage logic: when to call, what info is needed, and what to do when info is missing. It doesn't explain the output format, but with no output schema and given the tool's interactive nature (returning questions), this is acceptable. The sibling context is clear, and the description fills gaps left by the schema.
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% with each parameter described individually. The description adds semantic context by identifying which three parameters are sufficient (depuis_quand, age, demande) and clarifying that Elo and plateforme replace the others. This relationship is not in the schema, adding real value for selecting and filling parameters correctly.
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's purpose: to recommend one specific offer based on the person's profile using the APP24 method. It explicitly differentiates from siblings by saying 'plutot que de chercher dans le catalogue et de choisir toi-meme', so an agent knows it is not a search tool but a personalized recommendation engine.
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 gives explicit triggers: 'A appeler en priorite des que quelqu'un demande par ou commencer, quoi acheter, quoi offrir, ou comment progresser'. It also tells the agent not to use catalog search as an alternative and explains how to handle missing information (ask questions back). This is highly actionable and leaves no ambiguity about when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Donne la fiche complete d'une offre du catalogue APP24 a partir de son identifiant, obtenu par rechercher_offre. Contient le formateur, le theme, les niveaux vises, le prix, ce qui est inclus et l'adresse de la page.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Identifiant de l'offre, par exemple pack_062 ou club-argent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior, so the description's additional list of returned content (formateur, theme, niveaux, prix, inclus, adresse) adds valuable context. It doesn't disclose potential error behavior or return format, but for a simple read-only tool this is acceptable.
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 with no wasted words. The core purpose is front-loaded, followed by a concise enumeration of the returned fields. It is appropriately sized for the tool's simplicity.
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 single-parameter, read-only tool with full schema coverage and clear annotations, the description is nearly complete. It lists the content fields and the source of the id. It could mention error handling for invalid ids or the exact return structure, but these are minor gaps for a tool of this complexity.
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 input schema already documents the single parameter 'id' with a concrete example, and the description merely restates that the id is needed ('à partir de son identifiant'). Since schema coverage is 100%, the description adds no new parameter semantics beyond what's already structured.
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's purpose: 'Donne la fiche complete d'une offre du catalogue APP24 a partir de son identifiant' — a specific verb, resource, and scope. It also distinguishes itself from siblings by specifying that the identifier comes from rechercher_offre, indicating a follow-up detail view.
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 that the identifier is obtained by rechercher_offre, providing a clear usage context and a natural flow from search to detail. However, it does not mention when not to use it or compare it to alternatives like conseiller_une_offre, so it's not fully explicit on exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Indique si une offre APP24 est disponible a l'achat et sous quel delai. Les formations sont numeriques, donc l'acces est immediat apres achat.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Identifiant de l'offre. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, and the description adds a useful behavioral detail: because the training is digital, access is immediate after purchase. This clarifies what 'delay' means and goes beyond the schema and annotation defaults.
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 short sentences, no filler. The first sentence states the core purpose and the second adds relevant context about immediate access, so every sentence earns its place.
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 simple, single-parameter read-only tool, the description covers the purpose and key behavioral context. It does not specify the exact response structure, but it implies the tool returns availability status and a delay, which is sufficient given the low complexity and absent output schema.
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 only parameter 'id' is fully described in the schema ('Identifiant de l'offre') with 100% coverage. The description adds no further meaning about the id format or expected value, so the schema carries the semantic weight.
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 a specific verb and resource: it indicates whether an APP24 offer is available for purchase and under what delay. It is easy to distinguish from detail_offre and rechercher_offre by its focus on availability and delay, though it does not explicitly mention or differentiate sibling tools.
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 intended use is implied: call this tool when you need to know purchase availability or delivery delay for an APP24 offer. However, it does not explicitly say when not to use it or compare it with alternatives like detail_offre or rechercher_offre.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rend le texte complet d'un document APP24 a partir de son identifiant, tel que rendu par search. Un document est soit une offre du catalogue, soit la methode de progression d'APP24.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | L'identifiant rendu par search, par exemple pack_062, club-argent ou methode-app24. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds the useful behavioral detail that it returns the complete text, not just metadata or a preview. No side effects, auth needs, or error behavior are disclosed, but for a read-only, one-parameter fetch the description is sufficiently transparent.
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 short sentences, front-loaded with the main action, and every phrase earns its place by defining the input, the return content, and the covered document types.
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 single-parameter read-only tool with no output schema, this description is complete: it states what to pass, where the id comes from, what will be returned, and which documents are in scope.
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%: the schema already documents the id as the identifier returned by search with examples like 'pack_062, club-argent ou methode-app24'. The description repeats this provenance but does not add meaning beyond the schema, so baseline 3 is appropriate.
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 names a specific verb and resource: it 'Rend le texte complet d'un document APP24' and scopes documents to catalog offers or the progression method. It is clear, but it never explicitly contrasts itself with sibling tools such as detail_offre, so differentiation is only implicit in the phrase 'texte complet ... tel que rendu par search'.
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 phrase 'tel que rendu par search' gives an explicit usage condition: call this after search, when you have an identifier and need the full document text. It does not list when-not-to-use scenarios or alternatives, 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.
Donne la METHODE DE PROGRESSION d'APP24 en entier : les etapes dans l'ordre, et pour chacune les phrases que disent les joueurs a ce stade, les questions de diagnostic qu'un entraineur pose, le mecanisme en jeu, le test de sortie et les formations qui la traitent. A appeler des que quelqu'un dit qu'il stagne, qu'il debute, qu'il progresse mal, qu'il ne sait pas quoi travailler, ou que c'est pour offrir a un joueur dont on connait le niveau. C'est toi qui situes la personne dans ce parcours : lis les etapes et choisis. Si tu hesites, pose les questions de diagnostic au lieu de deviner. Ce parcours est un parti pris d'APP24 qui ne se deduit pas du bon sens : on y commence par les finales de pions, pas par les ouvertures. Ne le remplace pas par des conseils d'echecs generaux. (APP24 chess progression method, in French.)
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Ce que la personne dit de son jeu, avec ses mots. Sert a situer la demande, la methode est renvoyee en entier dans tous les cas. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, closed-world behavior. The description adds meaningful behavioral context beyond that: the agent is responsible for locating the person in the progression, must not guess if uncertain, and the method is intentionally specific to APP24 rather than general chess intuition. No contradiction with annotations.
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 longer than average but every sentence earns its place: the first sentence front-loads the output contract, and the following sentences provide routing rules, decision behavior, and an important caveat. There is no filler or redundancy.
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?
The tool has no output schema, so the description carries the full burden of explaining what the agent receives: ordered stages with player phrases, diagnostic questions, mechanism, exit test, and formations. It also gives clear invocation triggers and handles ambiguity by prescribing diagnostic questioning. Nothing essential is missing for correct invocation and use.
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 already fully describes the single parameter, including that the method is always returned in full. The description adds only a small clarification that the parameter text is used to situate the user, which is already captured in the schema description. With 100% schema coverage, the baseline of 3 is appropriate.
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 ('Donne la METHODE DE PROGRESSION d'APP24 en entier') and the exact resource, listing the content components: steps, player phrases, diagnostic questions, mechanism, exit test, and formations. This differentiates it from sibling tools that handle offers and searches.
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 gives explicit trigger conditions: stagnation, beginner status, poor progress, not knowing what to work on, or offering a resource to a known-level player. It also provides a when-not-to-use rule ('Ne le remplace pas par des conseils d'echecs generaux') and instructs the agent to ask diagnostic questions instead of guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cherche dans le catalogue APP24 des formations d'echecs en francais et des abonnements au Club d'Echecs. Repond a des demandes en langage naturel comme « un cadeau pour un debutant a moins de 30 euros », « apprendre les finales », « progresser avec un grand maitre ». Renvoie au maximum 10 offres reelles, avec leur prix en euros et l'adresse de leur page. (French-language chess training catalogue. Products and answers are in French.)
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Restreindre aux packs a l'unite ou aux abonnements. | |
| niveau | No | Niveau vise : debutant, amateur, confirme ou avance. | |
| critere | Yes | Ce que cherche la personne, en texte libre. | |
| budget_max_eur | No | Prix maximum accepte, en euros TTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds behavioral detail beyond that: it returns at most 10 real offers, includes price in euros and page address, and handles natural-language queries. It does not mention rate limits or auth, but for a read-only search tool the disclosed behavior is solid.
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 plus a brief language note, all front-loaded with purpose. Each sentence adds value: what it searches, how it responds, what it returns. No fluff or redundant restatement of the schema.
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 search tool with no output schema, the description sufficiently covers what the agent needs to know: scope, input type, result limit, and result fields. It does not explain sorting or pagination, but that is minor for a 10-result max tool. Annotations cover safety, and schema covers parameters, so the description fills the remaining gap well.
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 baseline is 3. The description implicitly informs the 'critere' parameter via example queries and the 'budget_max_eur' via 'a moins de 30 euros', but it does not add explicit parameter-level meaning beyond what the schema already describes. No deduction needed, but no bonus either.
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 a specific action ('Cherche dans le catalogue APP24') and the resource (chess training courses and subscriptions), distinguishes it from generic 'search' by focusing on natural-language queries, and specifies outputs (max 10 real offers, price, page address). This is enough for an agent to differentiate it from siblings like conseiller_une_offre or detail_offre.
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 provides example natural-language requests that imply when to use the tool, but it does not explicitly state when to prefer this over the sibling search or conseiller_une_offre, nor does it mention exclusions. Usage is inferable from examples but not directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche dans le catalogue APP24 : formations d'echecs en francais, abonnements au Club d'Echecs, et la methode de progression maison. Rend une liste de documents avec leur identifiant, leur titre et leur adresse. Passe ensuite chaque identifiant a fetch pour obtenir le texte complet. Meme corpus que rechercher_offre, au format attendu par la recherche approfondie. (French-language chess training catalogue.)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | La recherche, en texte libre. Le francais donne les meilleurs resultats. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive; the description adds meaningful behavioral context: the search returns only document metadata (identifier, title, address), not full content, and full text requires a follow-up fetch call. This prevents an agent from incorrectly treating the search result as the complete answer. No contradiction with annotations.
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 concise and front-loaded: purpose first, then output format, then the fetch follow-up, then the sibling relationship. The parenthetical English gloss is slightly redundant with the French description but not disruptive. Overall, every substantive sentence earns its place.
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 low-complexity, read-only search tool with one parameter, the description covers the essential context: scope, output shape, and the next step to take. There is no output schema, so describing the returned fields is valuable. It could additionally explain paging or result limits, but these are not critical for correct invocation.
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 input schema already fully documents the single query parameter, including the fact that it is free text and that French yields the best results. Since schema coverage is 100%, the description need not compensate. The description adds minor topical context by listing what the catalogue contains, but it does not add parameter-level detail 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 verb ('Recherche') and resource ('catalogue APP24'), and enumerates the covered content types: chess training, club subscriptions, and the in-house progression method. It also specifies the return shape (list of documents with id, title, and address). It references the sibling rechercher_offre, but the actual differentiator—'au format attendu par la recherche approfondie'—is only lightly explained, so it is not as crisp as the standard-setting examples.
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 gives a useful workflow instruction: pass each returned identifier to fetch for the full text. It also notes that the corpus is the same as rechercher_offre, which implies a relationship to that sibling. However, it never explicitly states when to choose this tool over rechercher_offre, detail_offre, or conseiller_une_offre, nor provides conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
conseiller_une_offredetail_offredisponibilitefetchparcours_progressionrechercher_offresearchPedagogical chess intelligence for AI agents: explain positions and games for a target Elo.
Lichess public API: players, ratings, eval, tablebase, opening explorer
Chess MCP for Claude: engine analysis, attack maps, game review. One URL, no install.
Calcul fiscal (IR, IFI, PER, plus-value) et retraite français — 32 régimes, sourcé et daté.
Add one secure layer between your agents and this server.