french-admin-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.2.1
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 3.6/5 across 22 of 22 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/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 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description 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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![french-admin-mcp MCP server](https://glama.ai/mcp/servers/mcp-tools-lab/french-admin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mcp-tools-lab/french-admin-mcp)

Score Badge

Copy to your README.md:

[![french-admin-mcp MCP server](https://glama.ai/mcp/servers/mcp-tools-lab/french-admin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mcp-tools-lab/french-admin-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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