Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@french-admin-mcp Simule mes impôts pour 45000€ salaire, marié avec 2 enfants"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Avertissement : Estimation indicative uniquement. Ne constitue pas un conseil fiscal ou juridique. Consultez un expert-comptable ou un avocat. Tous les résultats (simulations d'impôts, charges, aides, factures, courriers) doivent être vérifiés indépendamment. Voir TERMS.md et PRIVACY.md.
Serveur MCP (Model Context Protocol) pour l'administration francaise. Aide les citoyens et entreprises a naviguer la bureaucratie francaise avec l'IA.
Impots, URSSAF, CAF, factures, courriers administratifs, conventions collectives, retraite.
Product | Price | Description |
€29 | Everything to create your own MCP server — template, CLI, docs, examples | |
€49 | Complete Android 3D + AR app template — 4 screens, ready to customize | |
€9.99/mo | Premium MCP tools and priority support |
⭐ Sponsor on GitHub — Help us build the future of 3D/AR development
Related MCP server: French Law MCP Server
npm install -g french-admin-mcpOu dans votre configuration Claude Desktop / MCP :
{
"mcpServers": {
"french-admin": {
"command": "npx",
"args": ["-y", "french-admin-mcp"]
}
}
}simuler_impotsSimule l'impot sur le revenu (bareme 2025/2026). Prend en compte la situation familiale, le quotient familial, les abattements par type de revenu, et la decote.
Parametres : revenu brut annuel, type de revenu (salaire, BNC, BIC, foncier), situation familiale, nombre d'enfants, charges deductibles.
calculer_charges_aeCalcule les charges sociales URSSAF d'un auto-entrepreneur / micro-entrepreneur.
Parametres : chiffre d'affaires, type d'activite (services BIC/BNC, commerce, liberal CIPAV), periode, option versement liberatoire, ACRE.
generer_factureGenere une facture conforme au droit francais avec toutes les mentions legales obligatoires (art. L441-9 du Code de commerce).
Parametres : emetteur (nom, SIRET, adresse), client, lignes de facturation, franchise en base TVA.
declaration_urssafPrepare la declaration trimestrielle URSSAF. Calcule les cotisations et fournit les etapes a suivre.
Parametres : type d'activite, trimestre, annee, CA par mois.
aide_cafEstime les aides de la CAF : prime d'activite, allocations familiales, APL.
Parametres : situation familiale, enfants, revenus, loyer, zone APL.
demarche_adminGuide etape par etape pour les demarches administratives : carte d'identite, passeport, permis de conduire, declaration d'impots, creation auto-entrepreneur, carte grise.
rediger_courrierRedige un courrier administratif formel : contestation, resiliation, reclamation, mise en demeure, demande, signalement.
verifier_convention_collectiveVerifie les droits sous une convention collective : preavis, periode d'essai, conges speciaux, indemnites. Couvre Syntec (1486), Metallurgie (3248), Commerce (2609), Transport (0016), Particulier employeur (3239).
simuler_retraiteSimulation simplifiee de la retraite : pension de base (CNAV), complementaire (Agirc-Arrco), taux de remplacement. Prend en compte la reforme 2023.
"Combien d'impots je vais payer si je gagne 45000 euros en salaire, marie avec 2 enfants ?"
"Calcule mes charges auto-entrepreneur pour 5000 euros de CA en prestations BNC"
"Genere une facture pour une prestation de developpement a 3000 euros"
"Quelles sont les etapes pour renouveler mon passeport ?"
"Redige un courrier de contestation pour un PV de stationnement"
"Quels sont mes droits sous la convention Syntec ?"Plan | Prix | Requetes |
Gratuit | 0 EUR | 20/mois |
Premium | 9,99 EUR/mois | Illimite |
Pro (comptables) | 29,99 EUR/mois | Illimite + API |
Baremes fiscaux 2025/2026
Taux URSSAF 2025
Seuils CAF 2025
Reforme retraites 2023
Avertissement : Les calculs sont indicatifs et ne constituent pas un avis fiscal, juridique ou comptable. Pour les montants exacts, consultez les sites officiels (impots.gouv.fr, urssaf.fr, caf.fr) ou un professionnel.
git clone https://github.com/mcp-tools-lab/french-admin-mcp.git
cd french-admin-mcp
npm install
npm run build
npm testMIT
SceneView Tools
Estime les aides de la CAF : prime d'activité, allocations familiales, APL. Fournit les démarches à effectuer.
| Name | Required | Description | Default |
|---|---|---|---|
| situationFamiliale | Yes | Situation familiale | |
| enfants | Yes | Nombre d'enfants à charge | |
| enfantsDePlus14Ans | No | Nombre d'enfants de plus de 14 ans | |
| revenusMensuelsActivite | Yes | Revenus mensuels d'activité nets en euros | |
| autresRevenus | No | Autres revenus mensuels (allocations, pensions, etc.) | |
| revenusFiscauxAnnuels | No | Revenus fiscaux annuels du foyer (RFR) | |
| loyer | No | Loyer mensuel en euros (pour estimation APL) | |
| zoneAPL | No | Zone APL : zone_1 (Paris), zone_2 (grandes villes), zone_3 (reste) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden for behavioral disclosure. It does not mention that estimates are approximate, depend on actual CAF rules, or that the tool does not access real-time data. This lack of transparency could mislead users about reliability.
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 efficiently convey the main action and a secondary purpose. Front-loaded with the core estimation task. Could be slightly more concise by omitting 'Fournit les démarches à effectuer' if not essential, but overall well-structured.
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?
No output schema exists, and the description does not explain what the tool returns (estimated amounts, eligibility status, or steps). With 8 parameters and only 3 required, the description fails to guide on when optional fields are necessary, leaving gaps for effective 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?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions; it only lists example aids. It does not clarify how parameters map to specific estimates or optional fields like 'autresRevenus' and 'zoneAPL' are needed.
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 estimates CAF aids (prime d'activité, allocations familiales, APL) and provides steps to take. However, it does not explicitly distinguish from sibling simulations like 'simuler_aides_logement' or 'simuler_chomage', which overlap in purpose but target different aid types.
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 explicit guidance on when to use this tool vs. alternatives. The description implies usage for CAF aid estimation but does not provide context for when not to use or mention prerequisites like having specific personal information ready.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcule les charges sociales (URSSAF) d'un auto-entrepreneur / micro-entrepreneur. Inclut cotisations sociales, CFP, versement libératoire optionnel, et ACRE.
| Name | Required | Description | Default |
|---|---|---|---|
| chiffreAffaires | Yes | Chiffre d'affaires de la période en euros | |
| typeActivite | Yes | Type d'activité : services_bic (artisan, services commerciaux), services_bnc (libéral, conseil, dev), commerce (achat-revente), liberal_cipav (CIPAV) | |
| periode | Yes | Période du CA déclaré | |
| versementLiberatoire | No | Option pour le versement libératoire de l'IR | |
| acre | No | Bénéficie de l'ACRE (réduction 50% la 1ère année) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states what is calculated, not whether the tool is read-only, requires authentication, or has side effects. For a calculation tool, this is insufficient.
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 sentence that front-loads the purpose and key inclusions. It is concise with no redundant information, though a bit more structure (e.g., listing parameters) could improve clarity.
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?
With 5 parameters and no output schema, the description provides only high-level semantics. It does not explain default behaviors for optional parameters or calculation assumptions. Adequate but missing details like rate application.
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 parameters are documented in schema. The description adds context by mentioning ACRE and versement liberatoire, which map to boolean parameters. However, it does not explain enum values or number format beyond 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 identifies the tool as calculating social charges for auto-entrepreneurs/micro-entrepreneurs, specifying which components are included (cotisations sociales, CFP, versement liberatoire, ACRE). This distinguishes it from sibling tools like simuler_chomage or declaration_urssaf.
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 implies usage for calculating auto-entrepreneur charges but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned despite siblings like declaration_urssaf or simuler_impots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcule les indemnités de congés payés selon les deux méthodes légales (maintien de salaire et dixième). Compare les deux et indique la plus favorable. Inclut l'estimation des charges sociales.
| Name | Required | Description | Default |
|---|---|---|---|
| salaire_brut_mensuel | Yes | Salaire brut mensuel en euros | |
| jours_acquis | Yes | Nombre de jours ouvrables de congés acquis (max 30) | |
| methode | Yes | Méthode de calcul : maintien_salaire ou dixieme (1/10ème) | |
| jours_pris | Yes | Nombre de jours de congés à indemniser |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently states the tool compares methods and estimates social charges, but does not disclose behavioral traits like side effects (presumably read-only) or permission requirements. The description is adequate but not rich.
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-loads the purpose, and contains no redundant or irrelevant information. 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?
Given the tool's moderate complexity (4 parameters, no output schema), the description covers the core calculation and output (comparison, most favorable method, social charges). It could mention the output format or structure, but the information provided is largely sufficient for an AI agent to understand usage.
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%, with each parameter having a description in the schema. The tool description adds minimal extra meaning (e.g., naming the methods) but does not provide substantial value beyond the schema. 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 explicitly states the tool calculates paid leave indemnities using two legal methods (maintien de salaire and dixième), compares them to indicate the most favorable, and includes social charges estimation. This clearly differentiates it from siblings like 'calculer_indemnites_licenciement'.
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 implies usage context (calculating paid leave indemnities) but does not provide explicit guidance on when to use this tool over alternatives, nor does it mention prerequisites or exclusions. Sibling tools cover distinct topics, so the context is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calcule l'indemnité légale de licenciement selon le Code du travail. Prend en compte l'ancienneté, le salaire de référence, et le motif. Inclut le régime fiscal.
| Name | Required | Description | Default |
|---|---|---|---|
| salaireBrutMensuel | Yes | Salaire brut mensuel moyen des 12 derniers mois | |
| salaireBrutMensuelAvecPrimes | No | Salaire brut mensuel moyen des 3 derniers mois (primes incluses au prorata) | |
| ancienneteAnnees | Yes | Années complètes d'ancienneté | |
| ancienneteMois | No | Mois supplémentaires d'ancienneté (0-11) | |
| motif | Yes | Motif de la rupture |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool calculates legal indemnity and includes tax regime, but does not mention behavioral traits such as being read-only, requiring specific authorization, or handling edge cases. For a calculation tool, this is adequate but not comprehensive.
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 three sentences, front-loaded with the main action ('Calcule...'), and each sentence adds essential information. It is concise and to the point with no wasted words.
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 and the description does not explain the return format (e.g., calculated amount, breakdown). For a legal calculation tool with 5 parameters, the agent needs to know what output to expect. The description lacks this critical information.
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 has 5 parameters, all with descriptions (100% coverage). The description adds context ('according to French Labor Code, includes tax regime') but does not provide details beyond what the schema already states. With high schema coverage, baseline is 3, and the description adds marginal value.
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 calculates legal severance pay according to the French Labor Code, specifying it accounts for seniority, reference salary, reason, and tax regime. This is a specific verb+resource, distinguishing it from sibling tools like 'calculer_indemnites_conges' (vacation pay) and others that deal with different calculations.
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 implies usage for calculating legal severance but does not explicitly state when to use this tool vs alternatives. No exclusion criteria or alternative tools are mentioned, leaving the agent to infer usage from the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prépare la déclaration trimestrielle URSSAF d'un auto-entrepreneur. Calcule les cotisations et fournit les étapes à suivre sur autoentrepreneur.urssaf.fr.
| Name | Required | Description | Default |
|---|---|---|---|
| typeActivite | Yes | Type d'activité | |
| trimestre | Yes | Numéro du trimestre (1 à 4) | |
| annee | Yes | Année de la déclaration | |
| chiffreAffairesMois1 | Yes | CA du 1er mois du trimestre | |
| chiffreAffairesMois2 | Yes | CA du 2ème mois du trimestre | |
| chiffreAffairesMois3 | Yes | CA du 3ème mois du trimestre | |
| versementLiberatoire | No | Versement libératoire de l'IR | |
| acre | No | Bénéficie de l'ACRE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the tool as preparing and calculating, implying a non-destructive operation. However, it does not disclose side effects, authentication needs, or what happens with the provided steps (e.g., external link). Some transparency exists but is incomplete.
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 concise sentences that front-load the main purpose and then add a secondary detail (providing steps). Every word is meaningful with no redundancy or 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?
Given the complexity (8 parameters, no output schema), the description is somewhat incomplete. It mentions providing steps but does not specify the output format or what exactly is returned. The calculation logic is implied but not detailed. Adequate for a basic tool but leaves room for ambiguity.
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% with all 8 parameters having descriptions. The tool description adds no additional parameter-level meaning beyond enumerating what the tool does. Baseline of 3 applies as the schema already documents parameters adequately.
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 prepares the quarterly URSSAF declaration for auto-entrepreneurs, calculates contributions, and provides steps. It uses a specific verb ('prépare') and resource ('déclaration trimestrielle URSSAF'), distinguishing it from sibling tools like calculer_charges_ae or simuler_impots.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or specific contexts. Sibling tools like calculer_charges_ae could be confused, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guide étape par étape pour les démarches administratives françaises courantes : carte d'identité, passeport, permis de conduire, déclaration d'impôts, création auto-entrepreneur, carte grise.
| Name | Required | Description | Default |
|---|---|---|---|
| demarche | Yes | Nom de la démarche : carte_identite, passeport, permis_conduire, declaration_impots, creation_auto_entrepreneur, carte_grise. Ou un mot-clé pour rechercher. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it is a guide, implying read-only behavior, but no annotations are provided to confirm. It does not disclose output format, limitations, or whether any side effects occur. For a tool with no annotations, more transparency is needed.
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 sentence that efficiently conveys the tool's purpose and lists key procedures. It is front-loaded and concise, though could be structured as a list for clarity.
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 a simple tool with one parameter and no output schema, the description adequately explains the scope but lacks details on output format (e.g., text steps, links). It is minimally sufficient for an AI agent.
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 a clear parameter description. The tool description repeats the list of démarches, adding no new semantic information beyond what the schema already provides.
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 it is a step-by-step guide for common French administrative procedures, listing specific examples like identity card, passport, etc. This distinguishes it from sibling tools that perform calculations or simulations.
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 explicit guidance on when to use this tool versus siblings. The description implies use for step-by-step guides, but does not contrast with alternatives like simuler_impots or declaration_urssaf.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Récupère les détails complets d'une entreprise française à partir de son numéro SIREN (9 chiffres) ou SIRET (14 chiffres). Retourne raison sociale, adresse, forme juridique, activité, effectifs, état administratif. Données SIRENE officielles.
| Name | Required | Description | Default |
|---|---|---|---|
| sirenOuSiret | Yes | Numéro SIREN (9 chiffres) ou SIRET (14 chiffres) |
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 mentions the output fields but does not disclose behavioral traits such as authentication needs, rate limits, or whether it is read-only. The description implies a safe data retrieval but provides no explicit behavioral cues.
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, front-loaded with the purpose and followed by output fields. Every sentence adds value with no wasted words.
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 data retrieval tool with one parameter and no output schema, the description is fairly complete: it states what it does and what it returns. However, it lacks any behavioral context (e.g., usage limits, authentication) which would be beneficial.
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 the parameter description already specifying it as a SIREN (9 digits) or SIRET (14 digits). The tool description adds the same detail, providing no additional meaning 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 retrieves complete details of a French company from a SIREN or SIRET number, listing specific output fields. This distinguishes it from siblings like 'rechercher_entreprise' (search) and 'verifier_siret' (verify).
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 implies usage when full details on a known SIREN/SIRET are needed, but does not provide explicit guidance on when not to use or mention alternatives. It lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Génère une facture conforme au droit français avec toutes les mentions légales obligatoires. Idéal pour les auto-entrepreneurs et TPE.
| Name | Required | Description | Default |
|---|---|---|---|
| nomEmetteur | Yes | Nom ou raison sociale de l'émetteur | |
| siret | Yes | Numéro SIRET de l'émetteur (14 chiffres) | |
| adresseEmetteur | Yes | Adresse complète de l'émetteur | |
| emailEmetteur | No | Email de l'émetteur | |
| telephoneEmetteur | No | Téléphone de l'émetteur | |
| nomClient | Yes | Nom ou raison sociale du client | |
| adresseClient | Yes | Adresse complète du client | |
| siretClient | No | SIRET du client (si professionnel) | |
| numeroFacture | Yes | Numéro de facture (ex: F-2025-001) | |
| dateFacture | No | Date de facturation (ISO, défaut=aujourd'hui) | |
| dateEcheance | No | Date d'échéance (ISO, défaut=+30 jours) | |
| lignes | Yes | Lignes de la facture | |
| franchiseEnBaseTVA | No | true si franchise en base de TVA (auto-entrepreneur sous seuil) | |
| conditionsPaiement | No | Conditions de paiement personnalisées | |
| mentionsParticulieres | No | Mentions particulières à ajouter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully convey behavior. It mentions 'conforme au droit français' but lacks details on output format (PDF? text?), side effects (does it save?), or validation. The description is too terse for a complex tool.
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, front-loaded sentences. Every word adds value—no redundancy or filler. Highly concise.
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 high complexity (15 parameters, no output schema), the description lacks completeness. It doesn't specify return value format, constraints, or preconditions (e.g., need valid SIRET). The tool's behavior is under-described for effective 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?
Schema description coverage is 100% (all parameters described in schema). The description adds no extra parameter information 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 clearly states the tool generates invoices compliant with French law with all mandatory mentions, and specifies target users (auto-entrepreneurs, TPE). No sibling tool duplicates this function, so it's well-differentiated.
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 a target audience ('auto-entrepreneurs et TPE') but no explicit guidance on when to use vs alternatives or when not to use. Since no sibling is an invoice generator, usage is implied but not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trouve l'adresse française correspondant à des coordonnées GPS (géocodage inverse). Retourne l'adresse complète, la commune, le code postal. Basé sur la Base Adresse Nationale (BAN).
| Name | Required | Description | Default |
|---|---|---|---|
| longitude | Yes | Longitude (ex : 2.3088 pour Paris) | |
| latitude | Yes | Latitude (ex : 48.8534 pour Paris) |
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 discloses that the tool returns the full address, commune, and postal code, based on the Base Adresse Nationale. However, it does not mention any limitations, error handling, data freshness, or potential rate limits, leaving some behavioral gaps.
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 sentence that efficiently conveys the purpose, input, and data source, with no extraneous words. It is well-structured and front-loaded with the key action.
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 (2 required parameters, no output schema), the description adequately explains what the tool does and what it returns. It covers the essential aspects such as the data source (BAN) and the returned fields (address, commune, postal code). However, it could optionally mention coordinate format or error handling for completeness, but it is sufficient for most use cases.
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 clear parameter descriptions (e.g., 'Longitude (ex : 2.3088 pour Paris)'). The tool description adds no additional semantic value beyond what the schema already provides, so the baseline score of 3 applies without enhancement.
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 'Trouve' (finds) and the resource 'l'adresse française correspondant à des coordonnées GPS' (reverse geocoding). It specifies the exact functionality, which is distinct from all sibling tools that focus on administrative or simulation tasks.
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 implies usage for converting GPS coordinates to French addresses but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. Since no sibling tool performs similar functions, the context is clear, but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Informations sur une commune française : population, superficie, codes postaux, département, région. Recherche par nom, code postal ou code INSEE. Données officielles de la Geo API.
| Name | Required | Description | Default |
|---|---|---|---|
| nom | No | Nom de la commune (ex : « Marseille ») | |
| codePostal | No | Code postal (ex : « 13001 ») | |
| codeInsee | No | Code INSEE de la commune (ex : « 13055 ») | |
| limite | No | Nombre maximum de résultats (défaut : 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies a read-only query via 'Informations' and 'Recherche'. It mentions the data source ('Données officielles de la Geo API'). No contradictory statements. Could mention that it is non-destructive, but it is obvious.
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, no wasted words. First sentence states the purpose and output fields. Second sentence adds search methods and data source. Perfectly front-loaded and concise.
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 no output schema and no annotations, the description is sufficient for a simple information retrieval tool. It covers what the tool returns, how to search, and data source. Could add that results may be empty if not found, but not required.
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?
Input schema has 100% description coverage, so baseline is 3. The description adds context by grouping search parameters (nom, codePostal, codeInsee) and mentioning the limite parameter, but does not add significant new semantics beyond the schema descriptions.
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 it provides information about French communes (population, area, postal codes, department, region). It specifies three search methods (by name, postal code, INSEE code) and mentions official data source. No sibling tool covers commune info, so it is well-distinguished.
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 tells when to use: to get commune details. It does not explicitly exclude cases or mention alternatives, but the context is clear. The sibling tools list confirms it is the right tool for commune lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recherche une entreprise française par nom, activité ou localisation via l'API SIRENE (INSEE). Retourne SIREN, SIRET, adresse du siège, forme juridique, date de création, effectifs. Données officielles et à jour.
| Name | Required | Description | Default |
|---|---|---|---|
| recherche | Yes | Nom de l'entreprise, mot-clé ou activité à rechercher | |
| codePostal | No | Filtrer par code postal (ex : 75001) | |
| activitePrincipale | No | Filtrer par code NAF/APE (ex : 62.01Z pour programmation informatique) | |
| page | No | Numéro de page (défaut : 1) | |
| parPage | No | Nombre de résultats par page (défaut : 5, max : 25) |
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 returned fields and data freshness but omits details on authentication, rate limits, error handling, or read-only/destructive nature.
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 concise sentences front-loaded with key purpose, no extraneous words, and efficiently communicates the core functionality.
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 description covers basic purpose and returned fields but lacks details on pagination behavior (despite pagination parameters), output format, or error scenarios, which are important for a search tool.
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 marginal value by summarizing the search criteria but does not elaborate on parameter syntax or defaults beyond what the schema already provides.
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' (searches) and resource 'une entreprise française' via the SIRENE API, distinguishing it from sibling tools like 'details_entreprise' or 'verifier_siret' that handle specific lookups or validity checks.
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 implies usage for searching French companies by name, activity, or location but provides no explicit guidance on when to use alternatives (e.g., 'details_entreprise' for a specific company) or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rédige un courrier administratif formel en français : contestation, résiliation, réclamation, mise en demeure, demande, signalement.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type de courrier | |
| expediteurNom | Yes | Nom de l'expéditeur | |
| expediteurAdresse | Yes | Adresse de l'expéditeur | |
| expediteurTelephone | No | Téléphone de l'expéditeur | |
| expediteurEmail | No | Email de l'expéditeur | |
| destinataireNom | Yes | Nom du destinataire | |
| destinataireAdresse | Yes | Adresse du destinataire | |
| destinataireService | No | Service du destinataire | |
| objet | Yes | Objet du courrier | |
| contexte | Yes | Contexte / exposé des faits | |
| demandeSpecifique | Yes | Ce que vous demandez précisément | |
| piecesJointes | No | Liste des pièces jointes | |
| recommande | No | Envoi en recommandé avec AR |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It only states the purpose and does not mention output format, side effects, or any operational constraints like required permissions or rate limits.
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 sentence that effectively conveys the core purpose and supported types. It is concise and front-loaded, though could be slightly more structured.
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 13 parameters and no output schema, the description lacks information about the tool's return value, formatting behavior, or any limitations. It is insufficient for setting complete expectations.
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 each parameter has a description. The tool description does not add additional meaning beyond the schema; it merely lists letter types. 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 clearly states that the tool writes formal administrative letters in French and lists the supported types. It effectively distinguishes from sibling tools by specifying the action and domain.
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 no guidance on when to use this tool versus alternatives like 'demarche_admin' or 'generer_facture'. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simule les aides au logement (APL, ALF, ALS). Estime le montant mensuel selon le loyer, la zone géographique, la composition du foyer et les revenus. Barème 2025-2026.
| Name | Required | Description | Default |
|---|---|---|---|
| loyer_mensuel | Yes | Loyer mensuel en euros (charges non comprises) | |
| zone | Yes | Zone géographique : 1 (Île-de-France), 2 (grandes agglomérations), 3 (reste de la France) | |
| situation | Yes | Situation de logement : locataire, colocataire, ou foyer/résidence | |
| revenus_annuels | Yes | Revenus annuels nets du foyer en euros (N-2) | |
| nb_personnes_foyer | Yes | Nombre total de personnes dans le foyer | |
| type_logement | Yes | Type de logement |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions estimation based on inputs and rate schedule (Barème 2025-2026) but does not disclose limitations, precision, or output format.
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 concise sentences, front-loaded with core purpose; efficient but could benefit from slightly more structure without becoming verbose.
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?
Missing output schema; description says 'estimates monthly amount' but does not specify return type, individual vs combined amounts, or caveats for a complex simulation with 6 parameters.
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 covers all parameters with descriptions (100% coverage); the tool description reiterates parameter categories without adding new semantic meaning beyond 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?
Clearly states the tool simulates housing benefits (APL, ALF, ALS) and estimates monthly amount, distinguishing it from sibling simulators like unemployment or taxes.
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?
Implies usage for housing aid simulation through benefit names, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estime l'allocation chômage (ARE — Aide au Retour à l'Emploi). Calcule le montant journalier/mensuel, la durée d'indemnisation et les démarches France Travail. Barème 2026.
| Name | Required | Description | Default |
|---|---|---|---|
| salaireBrutMensuelMoyen | Yes | Salaire brut mensuel moyen des 24 derniers mois | |
| moisTravailles | Yes | Nombre de mois travaillés sur les 24 derniers mois (minimum 6 pour être éligible) | |
| age | Yes | Âge au moment de la fin de contrat | |
| motifRupture | Yes | Motif de la rupture du contrat |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'Estime' implying a simulation, but does not explicitly state if it is read-only or safe. It adds no details on preconditions or side effects.
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 concise sentence that front-loads the main purpose and includes key details (2026 rates, ARE). Every word 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?
Given four required parameters and no output schema, the description covers what the tool does (estimates and calculates) and offers reasonable completeness. Missing output format details but adequate for a simulation tool.
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%, so parameters are already documented. The tool description adds context on what is calculated (e.g., daily/monthly amount) but does not add meaning beyond what the schema provides for individual parameters.
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 explicitly states the tool estimates unemployment benefits (ARE), calculates daily/monthly amounts, duration, and steps, distinguishing it from sibling tools like verifier_droits_chomage_demission which verifies rights for specific cases.
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 context (estimating ARE with 2026 rates) but lacks explicit guidance on when to use this tool vs alternatives (e.g., checking eligibility or verifying specific rights). No exclusions or when-not-to-use are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simule l'impôt sur le revenu français selon le barème 2025/2026. Prend en compte la situation familiale, le quotient familial, l'abattement selon le type de revenu, et la décote.
| Name | Required | Description | Default |
|---|---|---|---|
| revenuBrutAnnuel | Yes | Revenu brut annuel en euros | |
| typeRevenu | Yes | Type de revenu (salaire, BNC profession libérale, BIC services, BIC commerce, foncier micro-foncier, autre) | |
| situationFamiliale | Yes | Situation familiale | |
| enfants | No | Nombre d'enfants à charge | |
| enfantsEnGardeAlternee | No | Nombre d'enfants en garde alternée | |
| chargesDeductibles | No | Charges déductibles annuelles (pension alimentaire, PER, etc.) | |
| anneeRevenus | No | Année des revenus (2024 ou 2025, défaut=2024) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions using the tax bracket and several factors but fails to state limitations, assumptions, return format (e.g., a single tax amount or breakdown), or whether the simulation is simplified. This leaves significant gaps in understanding the tool's behavior.
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 consists of two concise sentences, with the main action in the first sentence and supporting detail in the second. It is front-loaded and efficient, though a more structured format (e.g., bullets) could improve scanability.
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 7 parameters, no output schema, and no annotations, the description should offer more completeness. It lacks information about return values (e.g., estimated tax amount vs. marginal rate), prerequisites (e.g., need for revenu net), and accuracy or constraints. The agent lacks enough context to fully trust or interpret the output.
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 adds context by linking parameters to tax concepts (e.g., children affect quotient familial), but does not deepen semantic meaning beyond the schema's own descriptions. It is adequate but not exceptional.
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 simulates French income tax using the 2025/2026 tax bracket. It specifies the key factors considered (family situation, quotient familial, deduction, discount), making it distinct from sibling tools like simuler_aides_logement or simuler_chomage.
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 implies use for French income tax estimation but does not explicitly provide when to use versus alternatives like other simulation tools. No recommendations or exclusion criteria are stated, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulation simplifiée de la retraite : pension de base (CNAV), complémentaire (Agirc-Arrco), taux de remplacement. Prend en compte la réforme 2023.
| Name | Required | Description | Default |
|---|---|---|---|
| ageActuel | Yes | Âge actuel | |
| salaireAnnuelBrutMoyen | Yes | Salaire annuel brut moyen de carrière en euros | |
| anneesCotisees | Yes | Nombre d'années déjà cotisées | |
| anneesRestantesEstimees | No | Nombre d'années de cotisation restantes estimées | |
| statut | Yes | Statut professionnel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists what the tool computes but does not mention any side effects, data requirements (beyond parameters), or limitations (e.g., approximations, reform applicability). This is insufficient for a simulation tool.
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 sentence that efficiently conveys the tool's purpose and key features. It is front-loaded with the main simulation components and includes the 2023 reform mention, making it concise without unnecessary elaboration.
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 5 parameters (4 required) and no output schema. The description provides an overview of what is simulated but lacks details on the output format, error handling, or assumptions (e.g., whether calculations are approximate). Given the moderate complexity, the description is minimally adequate but could be more 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?
The input schema provides 100% description coverage for each parameter. The tool description does not add additional semantic context beyond the schema, such as parameter interdependencies or interpretation of values. A baseline score 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 identifies the tool as a simplified retirement simulation that computes base pension (CNAV), complementary pension (Agirc-Arrco), and replacement rate, accounting for the 2023 reform. It distinguishes itself from sibling tools like simuler_chomage or simuler_impots which address different domains.
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 implies usage for retirement simulation but does not explicitly state when to use this tool versus alternatives (e.g., simuler_chomage). No guidance on prerequisites or conditions for effective use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Valide et géocode une adresse française via la Base Adresse Nationale (BAN). Retourne l'adresse normalisée, les coordonnées GPS, le score de confiance, la commune et le code postal. Utile pour vérifier une adresse avant envoi de courrier ou facturation.
| Name | Required | Description | Default |
|---|---|---|---|
| adresse | Yes | Adresse à rechercher (ex : « 20 avenue de Ségur Paris ») | |
| codePostal | No | Code postal pour affiner la recherche | |
| type | No | Type de résultat : housenumber, street, locality, municipality | |
| limite | No | Nombre maximum de résultats (défaut : 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return fields (normalized address, GPS, score, commune, postal code) but does not mention rate limits, authentication, or error handling.
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: first explains function and outputs, second provides a concrete use case. No wasted words.
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 description covers the output fields (important since no output schema) and a use case, but lacks details on error responses, defaults for optional params, or handling of ambiguous addresses.
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 having a description. The tool's description adds no extra meaning beyond the schema, meriting the baseline score.
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 the specific verb (valide et géocode) and resource (adresse française via BAN), clearly distinguishing it from sibling tools like geocodage_inverse or info_commune.
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 implies usage for verifying addresses before mailing or billing, but does not explicitly exclude other use cases or compare to alternatives. Siblings include reverse geocoding and commune info, but no direct comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vérifie les droits sous une convention collective française : préavis, période d'essai, congés spéciaux, indemnités. Couvre les CC les plus courantes (Syntec, Métallurgie, Commerce, Transport, Particulier employeur).
| Name | Required | Description | Default |
|---|---|---|---|
| recherche | Yes | IDCC (ex: 1486 pour Syntec) ou mot-clé (ex: 'informatique', 'transport', 'commerce') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists covered rights and CCs but omits details on side effects, authentication, rate limits, or behavior for unsupported CCs.
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, no unnecessary words. Efficiently conveys purpose and scope.
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?
Adequately explains functionality and input format given single parameter and no output schema. Could improve by describing return format 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% with a clear description of the single parameter. The description adds value by specifying covered CCs, clarifying the scope of valid inputs 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?
Clearly specifies verb 'Vérifie' and resource 'droits sous une convention collective française', lists examples of rights and covered CCs. Distinguishes from siblings by topic but lacks explicit differentiation.
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?
Implies usage for checking collective agreement rights but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vérifie l'éligibilité au chômage (ARE) après une démission. Analyse le motif, détermine si c'est une démission légitime ou reconversion, estime le montant et la durée, détaille les démarches France Travail.
| Name | Required | Description | Default |
|---|---|---|---|
| motif_demission | Yes | Motif de la démission | |
| anciennete_mois | Yes | Ancienneté en mois dans l'emploi quitté | |
| salaire_brut_mensuel | Yes | Dernier salaire brut mensuel en euros |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and details the analysis: motif, legitimacy/retraining determination, amount and duration estimation, and France Travail steps. It lacks mention of limitations or indicative nature, but covers main behaviors well.
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 three sentences, each adding value: purpose, analysis details, and outputs. No wasted words, front-loaded with the core function.
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 no output schema, the description mentions estimating amount/duration and detailing steps, which indicates return content. Lacks explicit output format or error conditions, but is sufficient for a tool with three required parameters.
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% but the description adds meaning: explains that motif_demission determines legitimacy, and anciennete_mois and salaire_brut_mensuel are used for estimation. This context goes beyond the schema's property descriptions.
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: verifying unemployment eligibility (ARE) after a resignation. It specifies the verb 'vérifie' and the resource 'éligibilité au chômage après une démission', distinguishing it from sibling tools like 'simuler_chomage' and 'verifier_eligibilite_rsa'.
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 implies usage for post-resignation scenarios but does not explicitly state when to use vs. alternatives or exclude other separation types. No mention of when not to use, nor references to sibling tools like 'simuler_chomage'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vérifie les droits au CPF (Compte Personnel de Formation). Estime le solde, les plafonds d'utilisation (2026), le reste à charge obligatoire (103,20 €), et les abondements possibles.
| Name | Required | Description | Default |
|---|---|---|---|
| anneesTravaillees | Yes | Nombre d'années travaillées au total | |
| tempsPlein | Yes | Travail à temps plein (true) ou partiel (false) | |
| quotiteTempsPartiel | No | Quotité temps partiel (ex: 0.8 pour 80%). Ignoré si temps plein. | |
| niveauQualification | Yes | Niveau de qualification : bac_plus, bac_ou_moins, sans_diplome | |
| travailleurHandicape | No | Reconnaissance travailleur handicapé (RQTH) | |
| montantCPFConnu | No | Montant CPF déjà connu (consultable sur moncompteformation.gouv.fr) | |
| typeFormationEnvisagee | No | Type de formation envisagée (pour vérifier les plafonds) | |
| coutFormation | No | Coût de la formation envisagée en euros |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It mentions estimates (balance, limits, etc.) but does not discuss safety (read-only vs write), authentication needs, rate limits, or side effects. The description lacks depth on what the tool does beyond its outputs.
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 with two sentences, front-loading the tool's purpose. It efficiently communicates key functions without redundancy. Could be slightly more structured but overall well-sized.
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?
Without an output schema, the description should explain return value format or structure. It lists estimated items but lacks detail on data types, error handling, or edge cases. For an 8-parameter tool, the description is insufficiently comprehensive.
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 description adds limited value beyond the already clear parameter descriptions. The description mentions 'solde' and 'plafonds' but does not map them to specific parameters. Baseline of 3 is appropriate as the schema carries the semantic burden.
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?
Description clearly states the tool checks CPF rights and estimates balance, limits, mandatory contribution, and additional funding. It specifies the resource (CPF) and the action (vérifie, estime), making it distinct from sibling tools like verifier_convention_collective or verifier_droits_chomage_demission.
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 implicitly indicates usage for CPF rights checks but does not explicitly state when to use or avoid this tool, nor does it mention alternatives. While the sibling tools cover different domains, clear usage guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vérifie l'éligibilité au RSA (Revenu de Solidarité Active) selon les critères 2026. Calcule le montant estimé en fonction de la composition du foyer, des ressources et de la situation. Inclut les montants forfaitaires à jour, le calcul des droits, et les démarches CAF/MSA.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | Âge du demandeur | |
| situationFamiliale | Yes | Seul(e) ou en couple | |
| enfants | Yes | Nombre d'enfants à charge | |
| enceinte | No | Femme enceinte (majoration isolement) | |
| parentIsole | No | Parent isolé (majoration) | |
| ressourcesMensuelles | Yes | Total des ressources mensuelles du foyer en euros (salaires, allocations, pensions, revenus du patrimoine) | |
| allocationLogement | No | Perçoit une allocation logement (APL, ALS, ALF) ou hébergé gratuitement | |
| nationalite | No | Nationalité / situation administrative (défaut : français) | |
| activite | No | Situation d'activité |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool verifies eligibility and calculates estimates, implying read-only behavior, but does not explicitly confirm no side effects or mention authentication needs or rate limits.
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 and front-loaded with the main action. It has no wasted words, but could optionally include a usage note. Overall concise and structured well.
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?
With 9 parameters and no output schema, the description explains the calculation and includes current rates, but does not describe the return format (e.g., eligibility boolean, estimated amount). This lack of output specification reduces completeness.
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%, so baseline is 3. The description adds a high-level grouping ('composition du foyer, des ressources et de la situation') but no additional detail beyond the already detailed parameter descriptions.
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 verifies RSA eligibility and calculates estimated amount, using specific verbs and resource names. It distinguishes itself from siblings by focusing on RSA specifically, with no ambiguity.
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 does not provide any guidance on when to use this tool versus siblings such as simuler_chomage or simuler_aides_logement. No explicit when/when-not or alternative scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vérifie la validité d'un numéro SIRET (14 chiffres) ou SIREN (9 chiffres) français. Effectue trois vérifications : format, algorithme de Luhn (contrôle INSEE officiel), et consultation de l'API SIRENE pour confirmer l'état de l'établissement (actif/fermé). Utile pour valider un partenaire commercial, un client ou un fournisseur avant de signer un contrat.
| Name | Required | Description | Default |
|---|---|---|---|
| numero | Yes | Numéro SIRET (14 chiffres) ou SIREN (9 chiffres) à vérifier, espaces optionnels tolérés | |
| verifierEtat | No | Consulter l'API SIRENE pour vérifier l'état administratif de l'entreprise (défaut : true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description reveals three checks but omits output format, error handling, or rate limits. Some behavioral context is provided but not fully comprehensive.
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?
Concise, front-loaded with main purpose, no superfluous sentences. Efficient communication.
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?
No output schema and description does not explain return values or what the agent should expect (e.g., boolean or structured result). Missing crucial completeness for a verification tool.
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 good descriptions; the tool description adds context on how parameters are used (e.g., numero for format/Luhn, verifierEtat for API call), enhancing understanding beyond 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 verifies French SIRET/SIREN numbers, specifies three verification steps (format, Luhn, API), and distinguishes it from sibling tools like rechercher_entreprise.
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?
Provides explicit usage context (validating partners before contracts) but lacks explicit when-not-to-use or comparisons to alternatives.
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. Dates show when Glama detected each change.
v2.2.1aide_cafcalculer_charges_aecalculer_indemnites_congescalculer_indemnites_licenciementdeclaration_urssafdemarche_admindetails_entreprisegenerer_facturegeocodage_inverseinfo_communerechercher_entrepriserediger_courriersimuler_aides_logementsimuler_chomagesimuler_impotssimuler_retraitevalider_adresseverifier_convention_collectiveverifier_droits_chomage_demissionverifier_droits_formationverifier_eligibilite_rsaverifier_siretEach tool targets a distinct French administrative function (e.g., CAF aids, unemployment simulation, company search, address validation). No two tools have overlapping purposes; descriptions clearly differentiate them.
All tools use a consistent French verb_noun or noun_noun pattern with lowercase underscores (e.g., calculer_indemnites_conges, simuler_impots, valider_adresse). No mixing of conventions.
22 tools is slightly above the typical 3-15 range, but each tool serves a unique and necessary function for comprehensive French admin support. The count is proportional to the domain scope.
The tool set covers a wide range of essential French administrative tasks: benefits, business, taxes, legal documents, address validation, and more. No obvious gaps for common user needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered bookkeeping and tax filing for entrepreneurs at the heart of the European economy.
French company and procurement data APIs for AI agents, with x402 payments in USDC on Base.
French & European company registry for AI agents: KYB, sanctions, annual accounts. x402, no API key.
Agent-native document parsing: PDF, scans and FR/EU invoices to structured JSON or Markdown.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mcp-tools-lab/french-admin-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
