French Tax MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as calculate_income_tax for computations and get_tax_brackets for data retrieval, but get_tax_info_from_web and get_cached_tax_info overlap in providing tax information, which could cause confusion in selection. Overall, the descriptions help differentiate them, but minor ambiguity exists.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as calculate_income_tax, get_tax_article, and search_tax_law. There are no deviations in naming conventions, making the set predictable and easy to understand.
Tool Count5/5
With 11 tools, the count is well-scoped for a French tax server, covering key areas like calculations, information retrieval, and procedures. Each tool appears to serve a specific function without redundancy, fitting typical server sizes of 3-15 tools appropriately.
Completeness4/5
The tool set provides comprehensive coverage for tax-related tasks, including calculation, reporting, information fetching, and legal searches. Minor gaps may exist, such as lack of tools for updating or deleting tax data, but agents can likely work around these given the server's focus on retrieval and computation.
Average 3/5 across 11 of 11 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions generating a 'detailed report' but doesn't specify if this is a read-only operation, whether it modifies data, requires authentication, has rate limits, or what the output entails (e.g., file creation, format defaults). This is a significant gap for a tool with 5 parameters and no annotation coverage.
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, efficient sentence that front-loads the core action ('Generate a detailed report'). There's no wasted verbiage, but it could be more structured by hinting at key parameters or usage context. It's appropriately sized for a basic tool but lacks depth.
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 complexity (5 parameters, nested objects, no annotations) and the presence of an output schema, the description is incomplete. It doesn't address behavioral aspects like mutation risks or auth needs, and while the output schema might cover return values, the description should still clarify the tool's role versus siblings and parameter semantics. For a tool with this level of complexity, it's inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters like 'tax_data', 'topic_name', 'output_file', 'format', or 'ctx', leaving their purposes, formats, or constraints unclear. For example, it doesn't explain what 'tax_data' should contain or how 'topic_name' relates to the report. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Generate[s] a detailed report about a specific tax topic', which provides a clear verb ('generate') and resource ('report'), but it's vague about what constitutes a 'detailed report' and doesn't differentiate from siblings like 'get_tax_article' or 'search_tax_law' that might also provide tax information. It's adequate but lacks specificity about the report's nature or format.
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 guidance is provided on when to use this tool versus alternatives. With siblings like 'get_tax_article' or 'search_tax_law', the description doesn't clarify if this is for synthesized reports, official documents, or user-specific analyses. There's no mention of prerequisites, such as needing tax data input, which is implied by the schema but not stated in the description.
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 full burden. It mentions retrieving information from 'service-public.fr', implying an external API/web source, but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what format the information returns. For a tool with external dependencies and no annotation coverage, 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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be more front-loaded with distinguishing features if they existed.
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 2 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is minimally adequate. The output schema reduces the need to explain return values, but the description lacks crucial context about external dependencies, error cases, and parameter usage that would be needed for reliable tool 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 0%, so the description must compensate. It mentions 'tax procedure' which aligns with the 'procedure_name' parameter, adding semantic context about what kind of name to provide. However, it doesn't explain the 'ctx' parameter or provide format/example details for either parameter, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get information about a tax procedure from service-public.fr', which provides a clear verb ('Get information') and resource ('tax procedure') with source context. However, it doesn't differentiate from sibling tools like 'get_tax_info_from_web' or 'get_tax_article', leaving ambiguity about what specific type of information or procedure scope this covers.
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. With multiple sibling tools for tax information retrieval (e.g., get_tax_info_from_web, get_tax_article, get_form_details), there's no indication of what distinguishes this procedure-focused tool from others, leaving the agent to guess based on tool names alone.
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 the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but does not mention potential side effects, authentication needs, rate limits, or response format. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the purpose without unnecessary details. It could be slightly more structured by including usage hints, but it earns its place by clearly stating what the tool does.
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 tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It states the purpose but lacks behavioral context and parameter guidance. The output schema reduces the need to explain return values, but the description should do more to compensate for missing annotations.
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 description does not mention parameters at all, and schema description coverage is 0%, so it adds no meaning beyond the input schema. However, with only 2 parameters and an output schema present, the baseline is 3 as the schema handles the heavy lifting, though the description fails to compensate for the coverage gap.
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 verb ('Get') and resource ('detailed information about a specific tax form'), specifying what information is retrieved ('fields and instructions'). It distinguishes from siblings like 'get_tax_brackets' or 'get_tax_deadlines' by focusing on form details, though it could be more explicit about differentiation.
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 'get_cached_tax_info' or 'get_tax_info_from_web'. It implies usage for retrieving form details but lacks explicit context, exclusions, or prerequisites, leaving the agent to infer based on tool names alone.
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 of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns structured data, or handles errors. The description adds minimal behavioral context beyond the basic action, leaving gaps for an AI agent.
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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes the data source. Every part earns its place, making it easy to parse quickly 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?
Given the tool's moderate complexity (retrieving specific legal information), no annotations, and an output schema (which handles return values), the description is minimally adequate. It states what the tool does and the source, but lacks details on parameters, behavioral traits, and usage context, leaving the agent to rely heavily on the output schema and inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'a tax law article' but doesn't explain the 'article_id' parameter (e.g., format, examples, or source) or the optional 'ctx' parameter. It adds minimal semantic value beyond what's inferable from the tool name, failing to compensate for the schema gap.
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 action ('Get information about') and the resource ('a tax law article from legifrance.gouv.fr'), which is specific and unambiguous. It doesn't explicitly differentiate from siblings like 'search_tax_law' or 'get_tax_info_from_web', but the focus on retrieving a specific article by ID is implied. No tautology with the name/title.
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 'search_tax_law' or 'get_tax_info_from_web'. It mentions the source (legifrance.gouv.fr) but doesn't specify prerequisites, exclusions, or comparative contexts. Usage is implied only by the verb 'Get', with no explicit when/when-not instructions.
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 the full burden of behavioral disclosure. It implies a read-only operation by using 'Get', but doesn't specify whether it involves web scraping, API calls, rate limits, authentication needs, or potential delays. This leaves critical behavioral traits undocumented for a tool interacting with external websites.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core purpose without unnecessary elaboration, making it easy to parse quickly.
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 tool's complexity (interacting with external websites), lack of annotations, and 0% schema coverage, the description is incomplete. While an output schema exists (which reduces the need to explain return values), the description doesn't cover behavioral aspects like data freshness, error handling, or usage constraints, leaving gaps for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'tax information' and 'official French government websites', which loosely relates to 'tax_topic', but provides no details on format, examples, or constraints for either parameter. The 'year' parameter isn't addressed at all, failing to add meaningful semantics beyond the bare 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?
The description clearly states the action ('Get') and resource ('tax information') with specific sources ('official French government websites'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_tax_article' or 'get_cached_tax_info', which might retrieve similar information through different means.
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. It doesn't mention when to prefer it over siblings like 'get_cached_tax_info' (for cached data) or 'get_tax_article' (for specific articles), nor does it specify prerequisites or exclusions, leaving usage context unclear.
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 the full burden of behavioral disclosure. It states the tool searches for articles but doesn't describe what the search returns (e.g., list of results, full text, metadata), whether it's a read-only operation, any rate limits, authentication needs, or how results are formatted/paginated. This leaves significant gaps for an AI agent to understand 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with zero wasted content, making it easy for an AI agent to parse quickly.
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 that there's an output schema (which should document return values), no annotations, and low schema coverage, the description is minimally adequate but incomplete. It specifies the source (legifrance.gouv.fr) but lacks details on behavior, parameters, and usage context that would help an AI agent invoke it correctly, especially compared to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for the two parameters ('query' and 'ctx'). The description adds no information about what the 'query' parameter should contain (e.g., keywords, phrases, filters) or how the optional 'ctx' parameter is used. It fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.
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 action ('Search for tax law articles') and the target resource/source ('on legifrance.gouv.fr'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_tax_article' or 'get_tax_info_from_web', which might have overlapping purposes.
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. It doesn't mention when to prefer this over siblings like 'get_tax_article' (which might retrieve specific articles) or 'get_tax_info_from_web' (which might search broader web sources), nor does it specify any prerequisites or exclusions for usage.
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 the full burden of behavioral disclosure. It states the calculation purpose but lacks details on permissions, rate limits, error handling, or output format. It doesn't clarify if this is a read-only calculation or if it has side effects like caching results, which is insufficient for a tool with potential financial implications.
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, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates what the tool does without redundancy or fluff, making it easy to parse quickly.
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 tool's complexity (tax calculation with financial implications), no annotations, and 0% schema description coverage, the description is incomplete. It lacks behavioral details and full parameter explanations. However, the presence of an output schema mitigates some gaps by presumably documenting return values, preventing a lower score.
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 description mentions 'net taxable income and household composition,' which partially explains two of the four parameters (net_taxable_income and household_parts). However, with 0% schema description coverage, it doesn't address the 'year' parameter's purpose or the 'ctx' parameter's role, leaving significant gaps in parameter understanding.
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's purpose: calculating French income tax based on specific inputs. It specifies the verb ('calculate'), resource ('French income tax'), and key factors ('net taxable income and household composition'). However, it doesn't explicitly differentiate from sibling tools like 'generate_tax_report' or 'get_tax_brackets', which might also involve tax calculations.
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. It doesn't mention sibling tools like 'get_tax_brackets' (which might provide rate information) or 'generate_tax_report' (which might produce formatted output), nor does it specify prerequisites or exclusions for usage.
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 of behavioral disclosure. It states what the tool does but doesn't describe traits like whether it's read-only, requires authentication, has rate limits, or what the output format is. The description is minimal and fails to compensate for the lack of annotations, leaving key behavioral aspects unspecified.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no redundant or verbose phrasing.
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 tool's low complexity (1 optional parameter) and the presence of an output schema, the description is adequate but minimal. It covers the basic purpose but lacks details on behavior, usage context, and parameter nuances. The output schema likely handles return values, so the description doesn't need to explain those, but it should do more to guide the agent effectively.
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 description mentions 'for a specific year', which aligns with the 'year' parameter in the input schema. However, schema description coverage is 0%, so the schema provides no details about the parameter. The description adds minimal semantics by indicating the parameter's purpose but doesn't explain format, constraints, or the null default. It partially compensates but not fully for the coverage gap.
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 verb 'Get' and the resource 'income tax brackets (tranches d'imposition)' with the scope 'for a specific year'. It distinguishes from siblings like 'calculate_income_tax' (which computes tax amounts) and 'get_tax_info_from_web' (which fetches broader information), but doesn't explicitly differentiate them. The purpose is specific and actionable, though not fully contrasted with alternatives.
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 'get_cached_tax_info' or 'get_tax_info_from_web'. It implies usage for retrieving bracket data by year, but lacks explicit when/when-not instructions or prerequisites. This leaves the agent to infer context without clear direction.
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 of behavioral disclosure. It states 'Get tax deadlines' but doesn't describe what the tool returns (e.g., list of deadlines, dates, formats), whether it requires authentication, rate limits, or if it's a read-only operation. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 extremely concise—a single, clear sentence with no wasted words. It's front-loaded with the core purpose, making it easy to scan and understand quickly. Every word earns its place by specifying the action, resource, and source.
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 that there's an output schema (which handles return values), no annotations, and low schema coverage, the description is incomplete. It doesn't address behavioral aspects like authentication needs or rate limits, and with 0% schema coverage, it fails to explain parameters. However, the output schema mitigates some gaps, making it minimally adequate but with clear deficiencies.
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 0%, so the schema provides no parameter documentation. The description mentions 'tax deadlines' but doesn't explain the 'year' parameter (e.g., optional filtering by year) or the 'ctx' parameter (context object). It adds minimal semantic value beyond the tool name, failing to compensate for the lack of schema descriptions.
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 action ('Get') and resource ('tax deadlines from service-public.fr'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'get_tax_info_from_web' or 'get_cached_tax_info', which might also retrieve tax information, but it's specific about the type of information (deadlines) and source (service-public.fr).
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 guidance is provided on when to use this tool versus alternatives. With siblings like 'get_tax_info_from_web' and 'get_cached_tax_info', the description lacks context on whether this is for official deadlines, cached data, or web-scraped info. It doesn't mention prerequisites, exclusions, or comparisons to other tools.
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 full burden. It mentions the tool is a 'simple health check' which implies a read-only, non-destructive operation, but doesn't explicitly state this. It doesn't describe response format, error conditions, rate limits, or authentication requirements that would be helpful for behavioral understanding.
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, clear sentence that gets straight to the point. It's appropriately sized for a simple health check tool with no wasted words or 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?
For a simple health check tool with an output schema (which presumably documents the response), the description is reasonably complete. However, it lacks information about what 'responsive' means, what constitutes a successful check, or what the tool actually tests. The presence of an output schema helps, but more behavioral context would be beneficial.
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?
With only one optional parameter (ctx) that has 0% schema description coverage, the description doesn't mention parameters at all. However, since this is a health check tool that likely needs no parameters to function, and the single parameter appears to be an optional context injection mechanism, the baseline of 4 is appropriate for a tool that effectively has zero required operational parameters.
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's purpose: 'Simple health check to verify the server is responsive.' It uses specific verbs ('check', 'verify') and identifies the resource ('server'). However, it doesn't distinguish from siblings since this appears to be the only health-related tool among tax-focused siblings.
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. It doesn't mention prerequisites, timing considerations, or relationships to other tools. The agent must infer usage from the purpose alone.
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 of behavioral disclosure. It mentions the tool retrieves 'cached' data as a fallback, which implies read-only behavior and potential staleness, but doesn't detail what 'cached' entails (e.g., freshness, source, update frequency), error handling, or performance traits. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational behavior.
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, efficient sentence that front-loads the core purpose and context without unnecessary words. Every part ('Get cached tax information when web scraping fails') earns its place by clarifying the tool's role and usage scenario.
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 tool has an output schema (which handles return values), no annotations, and low schema coverage, the description is minimally adequate. It explains the tool's purpose and fallback context but lacks details on parameters, caching behavior, and error cases. For a retrieval tool with output schema support, it meets a basic threshold but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about the parameters ('tax_topic' and 'year'), such as what constitutes a valid tax topic, how the year affects retrieval, or examples. With 2 parameters and zero coverage, the description fails to compensate, leaving semantics unclear.
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's purpose: 'Get cached tax information when web scraping fails.' It specifies the verb ('Get'), resource ('cached tax information'), and context ('when web scraping fails'), which distinguishes it from siblings like 'get_tax_info_from_web' that likely fetch live data. However, it doesn't explicitly differentiate from other caching or retrieval tools beyond the context hint.
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 provides clear context for when to use this tool: 'when web scraping fails,' implying it's a fallback mechanism. This distinguishes it from 'get_tax_info_from_web' (for live scraping) and other tax info tools. However, it doesn't specify when NOT to use it (e.g., if cached data is stale) or name explicit alternatives beyond the implied sibling.
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-tax-mcp MCP server](https://glama.ai/mcp/servers/cornelcroi/french-tax-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cornelcroi/french-tax-mcp)

Score Badge

Copy to your README.md:

[![french-tax-mcp MCP server](https://glama.ai/mcp/servers/cornelcroi/french-tax-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cornelcroi/french-tax-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/cornelcroi/french-tax-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server