mcp-facture-electronique-fr

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.8.2
Disambiguation4/5
Most tools have distinct purposes: lookup/search for companies, establishments, routing codes, directory lines; submission and validation for flows; CRUD for webhooks. Potential overlaps exist between submit_flow and the specific submit_transaction_report/payment_report, but descriptions clarify their scopes. The by-ID vs by-code variants are clearly differentiated.
Naming Consistency4/5
Snake_case verb_noun pattern dominates (get_company_by_siren, search_establishment, create_routing_code). Minor inconsistencies: healthcheck_flow vs check_ppf_annuaire_health, and validate_facturx vs validate_ereporting_xml use different structures, but the overall pattern is predictable.
Tool Count2/5
With 34 tools, this exceeds the 25-tool threshold for 'too many'. Many tools are CRUD variations for similar resources (routing codes, directory lines, webhooks), making the surface heavy for an MCP server. While the domain is complex, consolidation or grouping could streamline the set.
Completeness4/5
The tool surface covers comprehensive lifecycle operations: search/get for lookup, create/update/delete for directory lines and routing codes, flow submission and retrieval, validation, webhooks, and health checks. Minor gaps exist (e.g., no direct update for flows), but core workflows are well covered.
Average 4/5 across 32 of 34 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 27 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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?
With no annotations, the description must disclose behavioral traits. It only provides the endpoint and action, but does not state that the tool is read-only, whether it requires authentication, or any side effects. The input schema provides parameter details but no behavioral context.
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 immediately conveys the core action and endpoint. It is concise, front-loaded, and contains no extraneous information.
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?
Despite having an output schema and complete parameter descriptions in the schema, the description is too sparse for a search tool with six optional parameters and pagination. It does not summarize filtering capabilities or expected results, and lacks behavioral context due to absent 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?
Schema coverage is 100%, meaning all parameters have descriptions in the schema. The tool description adds no additional parameter information beyond what the schema already provides. 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 the verb 'Search' and the resource 'routing codes', and includes the specific HTTP endpoint, distinguishing it from sibling tools like create or get routing codes. However, it lacks elaboration on what routing codes are, which would enhance clarity.
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 such as get_routing_code_by_siret_and_code or search_directory_line. The description does not mention use cases, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 HTTP method and endpoint but does not disclose behavioral traits such as pagination details, rate limits, what happens on empty results, or any side effects. The description repeats the endpoint name but adds little behavioral insight.
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?
Extremely concise at one sentence. No redundancy. However, it sacrifices necessary context for brevity.
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?
With 6 parameters and no annotations, the description is too brief. It does not explain the purpose of common filters (e.g., siren vs siret), pagination, or the output schema (though output schema exists). Lacks completeness 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 description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what is in 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 clearly states the action ('Search establishments (SIRETs)') and the resource ('PPF Annuaire') with a specific endpoint ('POST /siret/recherche'). It distinguishes from sibling tools like 'search_company' which search for companies, not establishments.
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 (e.g., 'search_company'), no prerequisites, and no scenarios where another tool would be preferred. It simply states the endpoint.
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?
The description mentions building an FRR XML payload and submitting to an Approved Platform, and notes no payload validation. But it lacks details on side effects, authentication requirements, rate limits, or what happens on failure. Without annotations, more behavioral context 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 concise and well-structured with sections for scope and use cases. It uses bullet points effectively. Referencing a README is acceptable but slightly reduces standalone 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 19 parameters (16 required) and an existing output schema, the description covers high-level behavior and use cases. However, it lacks details on prerequisites, error handling, and full process flow, which are important for a complex submission 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 the baseline is 3. The description does not add significant meaning beyond the schema for parameters; it mostly provides high-level context. The reference to README is external.
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 submits a DGFiF Flux 10.2/10.4 payment e-reporting flow and lists specific use cases. However, it does not explicitly differentiate from sibling tools like submit_flow or submit_transaction_report.
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 lists three specific use cases with processing_rule and flow_type combinations, implying when to use. However, it does not provide exclusions or direct comparisons to alternatives like submit_flow or submit_transaction_report.
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 fully disclose behavior. It mentions it's a GET request (read-only), but fails to specify authentication requirements, rate limits, or what happens if the ID is not found. The existence of an output schema is not leveraged.
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 front-loads the verb and resource. It is concise with no unnecessary words.
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 lookup with one parameter and an output schema, the description is minimally adequate. However, it lacks guidance on error cases (e.g., missing establishment) and does not differentiate from sibling lookup tools.
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% and the schema already provides a clear description of id_instance (from a previous search). The main description adds the HTTP path indicating the parameter is used in the URL, but this adds marginal value 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 action 'Look up an establishment' and specifies the key 'by directory instance ID', including the HTTP GET path pattern. This distinguishes it from siblings like get_establishment_by_siret and get_company_by_id_instance.
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 alternatives like get_establishment_by_siret or search_establishment. It only implies usage when an id_instance is available, but lacks explicit 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 should disclose behavioral traits. It only mentions the HTTP method (GET), implying read-only, but fails to describe authentication, error handling, or any side effects. With no annotations, more detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with the URL pattern, no redundant information. Every word adds value.
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?
An output schema exists, so return value details are covered. However, given the complexity of sibling tools and lack of usage context, the description feels minimal. It provides basic purpose but not enough for an agent to confidently select it over similar lookup tools.
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 description for id_instance. The description adds the URL pattern showing how the parameter is used, but does not significantly enhance understanding beyond the schema. Baseline 3 applies.
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 'Look up a routing code by directory instance ID', specifying the action and resource. The tool name already implies the lookup, and the description reinforces it with the URL pattern, distinguishing it from siblings that use different identifiers.
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 on when to use this tool versus alternatives like get_routing_code_by_siret_and_code or search_routing_code. The description does not mention exclusions or 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 are provided, so the description bears full responsibility for behavioral traits. It only mentions a GET request, implying read-only, but does not disclose authentication needs, rate limits, or other behaviors. This is insufficient for safe invocation.
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, which is concise. However, including the full HTTP endpoint ('GET /siret/code-insee:{siret}') is somewhat redundant and could be omitted for brevity.
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 lookup tool with one parameter and an output schema, the description covers the core purpose. However, it lacks usage guidance and behavioral details, making it adequate but not 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% and the schema provides clear parameter description (exact SIRET, 14 digits, no spaces). The description adds the HTTP endpoint but no semantic value beyond the schema. The baseline 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 states the verb 'Look up' and the resource 'establishment by SIRET', which is specific and distinct. The sibling tools such as get_company_by_siren and search_establishment use different identifiers or broader scope, so this tool's purpose is 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 does not explicitly state when to use this tool versus alternatives like get_company_by_siren or search_establishment. It implies usage when a SIRET is available, but lacks explicit guidance or exclusions.
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 describes a 'look up' operation, implying read-only behavior, but does not disclose any other traits such as authentication requirements, rate limits, or error handling. The existence of an output schema helps, but the description itself lacks behavioral detail.
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 front-loaded sentence that clearly states the verb, resource, and filtering criterion. It includes the HTTP endpoint for extra context. No unnecessary 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?
Given the existence of an output schema, the description need not cover return values. The tool is simple with one parameter, and the description is sufficient for basic usage. Minor missing elements like error cases are acceptable for this level of simplicity.
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 baseline is 3. The description mentions 'addressing code' but adds little beyond the parameter's schema description. No additional semantic value is provided for the single parameter.
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 uses a specific verb 'look up' and resource 'directory line' with a clear filtering criterion 'by addressing code'. It also provides the HTTP endpoint, distinguishing it from siblings like 'get_directory_line' or 'search_directory_line'.
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 looking up a directory line by a specific code, but does not explicitly state when to use it versus alternatives, nor does it provide exclusions or when-not-to-use guidance.
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?
The description only states 'Look up' which implies a read-only operation, but no explicit behavioral traits are disclosed (e.g., authentication needs, rate limits, side effects). With no annotations, the description carries the full burden and provides minimal transparency beyond the HTTP method hint.
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 is front-loaded with the purpose. It includes the HTTP path for context. No redundant words, making it efficient and easy to parse.
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 presence of an output schema (which explains return values) and the simple nature of a two-key lookup, the description is largely complete. It covers the input parameters and the action. Minor missing details like error conditions or uniqueness are acceptable for this complexity.
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 descriptions for both 'siret' and 'identifiant_routage'. The description does not add additional semantics beyond what the schema provides (e.g., examples, constraints). 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 states the action ('Look up') and the resource ('routing code') with specific identifiers (SIRET and code). It includes the HTTP method and path, adding specificity. While it doesn't explicitly differentiate from siblings, the name and description together uniquely identify the tool's purpose.
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 versus alternatives like search_routing_code or get_routing_code_by_id_instance. However, the description implies it is for a direct lookup by two specific keys, which provides some context. A score of 3 reflects the lack of exclusions or alternative suggestions.
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 only states 'look up', which implies read-only, but no details on prerequisites, failure modes, or other behavioral traits. Minimal but sufficient for a simple lookup.
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?
Single sentence with exactly 12 words. No fluff, front-loaded with purpose, and includes the endpoint for developer reference. Efficient and well-structured.
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 (one parameter, output schema present), the description is complete enough. It specifies the identifier type and action. Minor improvement could mention its use after a search, 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?
Schema description coverage is 100%, so the parameter is already described in the schema. The description adds no additional meaning beyond restating the parameter's purpose, meeting the baseline.
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 action 'Look up a legal unit' and specifies the unique identifier type 'directory instance ID'. It includes the exact GET endpoint, making the purpose unambiguous. It distinguishes from siblings that use different identifiers (SIREN, SIRET).
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 versus alternatives like get_company_by_siren or get_establishment_by_id_instance. The parameter description hints at 'from a previous search', but the main description lacks 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 are provided, so the description carries the full burden. It only mentions it is a GET request, implying idempotent read, but does not disclose authentication needs, error handling, rate limits, or other behavioral traits beyond the 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?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and endpoint.
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?
With an output schema present, return format is handled. The tool is simple (1 required param) and the description provides enough to invoke it correctly. Minor gap: no mention of potential 404 or error responses.
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?
The schema covers the single parameter with 100% description, and the description adds format constraints ('Exact SIREN (9 digits, no spaces)') that go beyond the basic string type, reducing ambiguity.
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 action (look up) and resource (legal unit by SIREN), and the use of 'SIREN' distinguishes it from siblings like get_establishment_by_siret which uses SIRET.
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 you have a SIREN, but it does not explicitly state when to use this tool vs alternatives like search_company or get_establishment_by_siret, nor does it include any 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 carries full burden. It discloses the confirmation requirement and that it is a full replacement. However, it lacks details on side effects (e.g., overwrites all fields?, permissions needed) and doesn't describe return values.
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?
Extremely concise: two sentences. First sentence communicates purpose, second gives usage guidance. No wasted words, front-loaded.
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 presence of an output schema and full parameter coverage, the description is fairly complete. It covers the core behavior and the confirmation flow. However, it does not explain what 'fully replace' entails in terms of field behavior (e.g., null handling).
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 well-documented in schema. The description adds no further parameter-specific meaning beyond the schema, meeting the baseline for high coverage.
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 ('replace') and resource ('directory line'), and the endpoint method. It distinguishes from siblings like update_directory_line, though 'replace' vs 'update' could be explicitly contrasted.
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?
Explicitly describes the two-step human-in-the-loop process: call first without confirmation_token, show summary to user, then call again with token. This is strong usage guidance, though it doesn't specify when not to use this tool or alternatives.
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 describes the operation as a search, implying it is read-only and safe, but does not explicitly disclose behavioral traits such as authentication requirements, rate limits, or the fact that it uses a POST method. More detail would be needed for full transparency.
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 concise with two sentences and a parenthetical endpoint. It front-loads the purpose and then provides usage context. Every sentence adds value, and there is no wasted text.
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 7 optional parameters and the presence of an output schema, the description provides sufficient context for the primary use case. It lacks detail on default behavior when no parameters are supplied, but overall is adequate 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 description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter. It mentions the overall purpose but does not clarify which parameters are most relevant for the stated use case.
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 searches directory lines (electronic invoice receiving addresses) and explicitly mentions the use case: verifying a recipient's registered line and Approved Platform before sending an invoice. This distinguishes it from sibling tools like create, get, or delete directory lines.
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 explicitly says 'Call before sending an invoice to verify the recipient has a registered line and to identify their Approved Platform,' providing clear when-to-use guidance. However, it does not explicitly state when not to use or suggest alternative tools, though the context implies usage for verification.
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 discloses partial update behavior ('Only provided fields are modified') but omits details like authorization, side effects, error handling, or HTTP method (though implied by PATCH in endpoint). Adequate but could be richer.
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 redundancy. First sentence provides endpoint and method, second sentence clarifies behavior. Every word earns its place.
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?
Output schema exists, so return values are covered. Description covers the core behavioral trait (partial update). However, lacks prerequisites (e.g., routing code must exist) or potential error conditions. Moderate completeness for a simple update.
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. Description adds minimal extra meaning beyond 'Omit to leave unchanged' already in schema. No new insights about parameter formats or constraints.
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 verb 'update' and resource 'routing code', and specifies it is a partial update (PATCH). It distinguishes from sibling 'replace_routing_code' which would be a full replacement.
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?
Implicitly clarifies when to use (partial update) but does not explicitly state when not to use or suggest alternatives like 'replace_routing_code'. Sibling context helps but description lacks direct guidance.
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 the burden of behavioral disclosure. It clearly explains the human-in-the-loop requirement, the two-step process (call without token, then with token), and implies it is a creation operation. This is comprehensive for a mutation 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?
The description is extremely concise—three lines including the endpoint and critical human-in-the-loop note. Every sentence serves a purpose with no redundancy.
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 has 8 parameters (3 required), an output schema, and a human-in-the-loop pattern, the description covers the essential workflow adequately. It does not explain error handling or output details, but the output schema exists. The description is sufficiently complete for an agent to invoke correctly.
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 the schema already documents all parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline. No extra constraints or clarifications are provided.
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: 'Create a directory line (electronic invoice receiving address)' and includes the specific HTTP method and endpoint. This distinguishes it from sibling tools like search_directory_line, get_directory_line, etc.
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 does not explicitly state when to use this tool vs alternatives. It mentions the human-in-the-loop workflow but lacks guidance on when to prefer create_directory_line over replace_directory_line or update_directory_line. Implicit from context, but not 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 must carry the burden. It implies a read-only, non-destructive operation via 'Look up' and the HTTP GET method in the endpoint. However, it does not disclose potential errors, rate limits, or required permissions explicitly.
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, front-loads the core purpose, and includes the endpoint. Every word is necessary and contributes to clarity.
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 tool has a simple signature with one parameter and an output schema. The description covers the essential lookup action. It omits error handling or edge cases, but given the output schema exists, the description is sufficiently complete for this straightforward 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?
The parameter id_instance is fully described in the input schema (100% coverage). The description adds no additional semantic details beyond restating the purpose, so the baseline of 3 applies.
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 'Look up' and the resource 'directory line' with the specific identifier 'directory instance ID'. It distinguishes from siblings like get_directory_line_by_code by specifying the lookup key. Including the HTTP endpoint adds precision.
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 clearly indicates when to use this tool: to retrieve a directory line by its instance ID. While it does not explicitly state when not to use it or mention alternatives, the context from the tool name and sibling names implies the distinction (e.g., use get_directory_line_by_code for code-based lookup).
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 exist, so the description carries full burden. It mentions pagination behavior and the nextUpdatedAfter field, but does not disclose whether the operation is read-only, required permissions, or potential side effects. Adequate but not thorough.
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, front-loaded with purpose and criteria, followed by pagination instruction. Every sentence adds value with no redundancy.
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 complexity (6 optional parameters, pagination, output schema), the description covers purpose, main filters, and pagination. It could mention default limit or that it returns a list, but overall 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?
Schema description coverage is 100% (all parameters have descriptions). The tool description adds value by explaining pagination (using nextUpdatedAfter), but otherwise summarizes what's already in the schema. Baseline 3 with marginal improvement.
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 searches flows (invoices, statuses, e-reportings) by specific criteria. It uses the verb 'search' matching the name and distinguishes from sibling tools like get_flow (single flow) and submit_flow.
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 explains when to use: to search flows by criteria. It provides pagination guidance but does not explicitly exclude alternatives or state when not to use. Still, the context is clear for a search tool.
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 the full burden. It discloses that the tool triggers webhook notifications (a side effect) and crucially explains the two-step human-in-the-loop confirmation process, which is significant behavioral information. However, it does not mention authentication requirements for the tool itself or potential side effects like overwriting existing subscriptions, but for a creation tool, the confirmation flow is the key behavior and is well covered.
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 concise, well-structured, and front-loaded. The first sentence states the core purpose, the second explains the event triggering, and the final paragraph clearly outlines the confirmation flow. No redundant words or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 parameters, 100% schema coverage, and an output schema), the description provides sufficient context for an agent to use the tool correctly. It explains the behavioral trigger, the confirmation requirement, and the purpose of the callback URL. The absence of return-value details is acceptable because the output schema exists. The description is complete for a subscription-creation tool with these structures in place.
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 the baseline is 3. The description adds some conceptual context by mentioning the filter criteria (flow type, direction, processing rule, ack status) but does not explain any parameter in greater depth than the schema already does. It repeats the callback URL's purpose but adds no new syntactic or semantic information.
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 action ('Subscribe to webhook notifications') and the resource (the Approved Platform), and specifies that the AP will POST event payloads to the callback URL on flow creation/update. This distinguishes it from sibling tools like list_webhooks, update_webhook, and delete_webhook.
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 explains what the tool does and the trigger conditions (flow matches filters), but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., update_webhook for modifying an existing subscription, or list_webhooks to enumerate). No exclusions or comparisons are mentioned, so the usage context remains implied rather than 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?
The description implies a read-only operation ('Retrieve') but provides no explicit assurance of non-destructiveness or details on error conditions, permissions, or rate limits. Without annotations, the description carries the burden but is adequate for a simple get.
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 front-loads the action and lists the key returned items, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately explains what will be returned. The tool has only one required parameter and no nested objects, making the description sufficient for an agent to invoke it correctly.
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%, and the parameter 'webhook_uid' is well-defined in the schema. The tool description adds no additional semantics to the parameter beyond what the schema 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 'Retrieve' and the resource 'webhook subscription', and lists specific details returned (callback URL, authentication mode, etc.), distinguishing it from sibling tools like 'list_webhooks' which likely return a summary list.
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 purpose is clear and the tool's name indicates retrieving a single webhook, but the description does not explicitly state when to use this tool versus alternatives (e.g., list_webhooks for a collection).
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 are provided, so the description must disclose behavioral traits. It correctly identifies this as a user-confirmation-required action and explains the two-step process. The permanent nature of deletion is noted in the schema for id_instance, but the description itself could mention it. Overall, it adds significant behavioral context.
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: two sentences covering the action and the user-confirmation workflow. No unnecessary words, and the critical guidance is front-loaded.
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 complexity (delete with confirmation) and the presence of an output schema (context signal), the description is largely complete. It explains the required workflow. It could add a note about what the summary contains, but the output schema likely covers return values.
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 the baseline is 3. The description does not add extra information about parameters beyond what the schema already provides. The schema itself includes descriptions and warnings, so the tool definition is adequate without redundance.
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: 'Delete a directory line'. It also specifies the HTTP DELETE endpoint, making the action unambiguous. The name and description together distinguish it from sibling tools like update_directory_line and create_directory_line.
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 explicit usage instructions: requires user confirmation, call without confirmation_token first, then call again with the token. It does not explicitly contrast with alternatives, but the context of deletion is clear 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 identifies the tool as a SEARCH operation (POST /siren/recherche) and adds prerequisire context, but does not disclose auth needs, rate limits, or response behavior. With an output schema available, some transparency gaps remain, but the prerequisite info is valuable.
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?
Three sentences, each adding distinct value (purpose, prerequisite, sibling alternative). No wasted words; front-loaded with the main 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 6 optional parameters and available output schema, the description is fairly complete. It covers purpose, prerequisite, and sibling alternative. It could mention pagination behavior, but the schema already covers limit and ignorer, so the description is sufficient.
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 detailed parameter descriptions. The description adds no additional parameter semantics beyond what the schema already provides, so 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 states the tool searches legal units (SIRENs) via a POST endpoint. It distinguishes from the sibling get_company_by_siren by noting the preferred use case when the exact SIREN is known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use get_company_by_siren when the exact SIREN is known, and provides prerequisite context that a company must appear here before its establishments can be resolved. This helps the agent choose correctly.
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?
Without annotations, the description bears full behavioral burden. It discloses that the tool returns JSON metadata by default and explains the return format (base64 for other docTypes). It does not mention error handling or auth, but the read-only nature is clear and well-explained.
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 convey all necessary information, front-loading the core action. Every word serves a purpose—no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description sufficiently covers what the agent needs: retrieval by ID, parameter meanings, and return format variations. No gaps for a single-resource read 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%, baseline 3. The description adds value by explaining docType options, default behavior, and clarifying flow_id origin ('assigned by Approved Platform'), improving understanding 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 a flow by identifier, specifying the action and resource. It also explains the docType parameter, making the purpose unambiguous and distinct from siblings like search_flows or submit_flow.
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 you have a flow identifier and need to retrieve its metadata or document, but does not explicitly contrast with alternatives (e.g., search_flows for listing). No when-not-to-use guidance is provided.
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?
Given no annotations, the description effectively discloses key behavioral traits: it performs a full replacement (overwrites existing object), requires a two-step confirmation process, and mandates all fields. While it doesn't cover auth or rate limits, the workflow and destructive nature are well communicated.
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 covering purpose and contrast, followed by a clear workflow explanation. It is front-loaded and efficient, though some minor structural improvements could be made, such as separating the workflow into bullet points.
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 tool has 5 parameters (4 required), an output schema exists, and the description covers the operation type, workflow, and distinguishes from a sibling. It is complete enough for an agent to understand how to invoke it correctly, though additional details about response or error handling are not needed due to the output schema.
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 additional meaning to the parameters beyond what the schema already provides, except for clarifying the confirmation_token workflow (first call omit, second call include). This is acceptable but doesn't elevate the 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 clearly states the tool's purpose: 'Fully replace a routing code' with HTTP method PUT, and explicitly distinguishes it from the sibling 'update_routing_code' by noting that all fields are required and replace the existing object entirely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions on when and how to use the tool: call without confirmation_token first to get a summary, then call again with the token for user confirmation. It also contrasts with update_routing_code, guiding the agent to use this for full replacement instead of partial update.
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?
Discloses the key behavioral trait (human-in-the-loop requirement) and the two-step invocation pattern. However, does not mention side effects, permissions, or the fact that the first call returns a confirmation token (though implied).
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?
Extremely concise: two sentences plus a procedural note. Purpose is front-loaded, and every sentence adds value. No fluff.
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?
Covers the critical human-in-the-loop workflow. The output schema exists, so return values need not be in the description. Could mention that creation is immediate or provide error handling hints, but overall sufficient for a tool with 8 parameters and a two-step process.
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 schema fully documents parameters. The description adds value only for the confirmation_token parameter in terms of usage, not semantics. 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?
Clearly states 'Create a routing code' with the HTTP method, distinguishing it from sibling tools like update_routing_code and replace_routing_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes the two-step human-in-the-loop process: call without confirmation_token, show summary, then call with token. This provides clear, actionable usage instructions.
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 the full burden. It discloses that Refused and Cashed are mandatory to PPF, reason mandatory for certain statuses, and the two-call confirmation pattern. It omits error handling but covers key behavioral traits.
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 well-structured, front-loaded with core action, lists statuses clearly, and provides a concise two-call procedure. No redundant sentences.
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 complexity (23 parameters, enums, workflow), the description covers core logic, mandatory fields, and references standards. It could mention error handling but is fairly complete, and output schema exists so return values are covered.
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%, so baseline is 3. The description adds value by explaining which statuses require reason and the confirmation flow, going beyond 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 the tool emits a processing status on an invoice, lists all allowed statuses, and notes mandatory transmissions to PPF. It distinguishes from sibling tools like submit_flow which handle initial invoice submission.
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 context for when to use (after receiving an invoice) and includes a two-call human-in-the-loop procedure. However, it does not explicitly state when not to use or compare to alternatives like submit_flow.
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 the burden of behavioral disclosure. It declares the PATCH method and the partial update behavior ('Only provided fields are modified'). This is adequate for a simple update tool, though it omits details like idempotency or error conditions.
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 action and key behavior. It is front-loaded with the verb and resource, containing no extraneous information.
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 low complexity, presence of an output schema, and adequate parameter descriptions, the description covers the essential aspects. It could be slightly more explicit about the use of id_instance, but overall it is complete enough for an agent to correctly invoke the 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 descriptive names and descriptions for each parameter. The description adds meaning beyond the schema by clarifying that provided fields are updated, which is essential semantic context for using the optional 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 clearly states the tool's action: 'Partially update a directory line', including the HTTP method and path. It distinguishes from sibling tools like replace_directory_line by specifying that only provided fields are modified, making the purpose specific and unambiguous.
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 when to use this tool (for partial updates) versus a full replace, but does not explicitly mention sibling tools or provide when-not-to-use guidance. It gives clear context but lacks exclusionary instructions.
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 are provided, so the description carries the burden. It discloses PATCH semantics and the constraint on metadata filters. However, it does not mention potential side effects (e.g., whether updates affect active callbacks) or required permissions. Still, it is transparent about the update 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 two sentences, efficiently conveying scope, constraints, and update semantics without unnecessary words. It is well-structured and front-loaded.
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 has 9 parameters (1 required) and an output schema, the description is adequate. It covers what can be updated, what cannot, and the update semantics. It does not need to explain return values as the output schema exists. Could mention that the webhook must exist, but that is implied.
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% (all parameters have descriptions). The description groups parameters into categories (authentication, signature, custom headers) but does not add significant detail beyond the schema. The mention of 'custom headers' may be slightly misleading as no such parameter exists in the schema. Baseline 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 states the tool updates technical parameters of a webhook subscription, specifies which parameters (authentication, signature, custom headers), and explicitly notes what cannot be changed (metadata filters), with a directive to delete and recreate instead. This distinguishes it from sibling tools like create_webhook and delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs. alternatives: it clarifies that metadata filters cannot be changed and directs users to delete and recreate the webhook for such changes. It also specifies PATCH semantics, so only provided fields are modified.
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 are provided, so the description carries full burden. It discloses the HTTP method (GET) and the endpoint (/healthcheck), and clarifies that the tool is non-destructive (checking availability). This is transparent enough for a simple health check.
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 sentences, no filler. The first sentence states the purpose, the second provides usage guidance. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (covering return format), the description is complete. It tells the agent when to use the tool (before directory-management sessions) and what it does (check availability).
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?
There are no parameters (0), so the baseline is 4. The description does not add parameter information, but none is needed. The schema coverage is 100% trivially.
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 specifies the verb 'Check the availability' and the resource 'PPF Annuaire service (GET /healthcheck)'. It distinguishes the tool from siblings, which are CRUD operations, by positioning this as a health check for the directory service.
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 states to use it 'before a directory-management session to ensure the service is reachable', providing clear context. It does not explicitly mention when not to use it or alternatives, but the sibling list includes a similar 'healthcheck_flow' tool, so some differentiation would be beneficial.
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 are provided, so the description carries full burden. It states the tool returns operational status (ok/degraded/unavailable), which is transparent about the output and non-destructive nature. It does not cover error behavior or rate limits, but the core behavior is clear.
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 states purpose, second states return value and usage context. No redundant information, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check with zero parameters and an output schema (implied by context signals), the description provides all needed information: what it does, what it returns, and when to use it.
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?
The input schema has zero parameters, so the description does not need to add parameter info. Schema coverage is 100% vacuously, and baseline for 0 parameters is 4.
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 checks availability of the Flow Service, using a specific verb and resource. No sibling tool has a health-check function, so it is clearly 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 says 'Use before an invoice submission session to ensure the AP is reachable,' providing a clear use case. It does not mention when not to use, but the context is sufficient.
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 adds value by specifying the authentication owner and that it returns UUIDs. It implies a read-only operation (list). No side effects are mentioned, but none expected for a list 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?
The description is two sentences with no waste. Purpose is stated first, followed by additional details. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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, the description needn't detail return values; it mentions UUIDs. It also provides next-step guidance. No critical gaps for a simple list 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?
The tool has 0 parameters, and the description does not need to elaborate on them. Per guidelines, 0 params baseline is 4. The description adds no parameter info because none exist.
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 lists webhook subscription IDs, scoped to the current OAuth2 token holder. It distinguishes from sibling tools like get_webhook (which retrieves details) and create_webhook (which creates).
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 explains when to use (to get list of IDs) and suggests following up with get_webhook for details. It doesn't explicitly mention when not to use or compare with other sibling tools, but the guidance is clear.
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, so description carries full burden. It discloses validation behavior, returns validation result with errors, and describes three validation levels (xsd, wellformedness, none). Does not mention side effects, but as a validation tool, it's clearly read-only.
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?
Description is concisely structured with multiple sentences, front-loading the purpose and scope, then providing details on validation levels. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple validation tool with one parameter and an output schema (implied), the description covers all necessary aspects: what it validates, against what specification, return type, and validation levels. No critical gaps.
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?
Single parameter 'xml_content' is fully described in schema (100% coverage) and tool description adds context about XML format and validation scope. Description also details validation levels, enhancing understanding of parameter usage.
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 validates a DGFiP e-reporting XML payload against XSD schema, specifying scope (XSD only, no business rules) and version (v3.2). It distinguishes from sibling tools like validate_facturx by targeting a specific XML format.
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?
Explicitly advises use 'before submitting to catch structural problems early' and mentions validation levels. Implies alternatives for business rule checks but doesn't explicitly list when not to use; references README for scope details.
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 are provided, so the description carries the full behavioral disclosure burden. It mentions building an XML payload conforming to spec, submission via POST to Approved Platform, and that no payload validation is performed. However, it does not cover error handling, authentication requirements, or rate limits, which would be beneficial.
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 relatively long but front-loaded with the purpose. It uses clear sections and bullet points. Some redundancy exists (e.g., repeating 'B2C' and 'B2B' cases) but overall it remains well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (19 parameters, 16 required, nested invoices_json structure), the description is thorough. It covers the XML spec, use cases, parameter details, and refers to external documentation. The existence of an output schema means return values are assumed documented, so no gap there.
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 100% schema description coverage, the description still adds value by explaining the required fields for invoices_json and clarifying the processing_rule and flow_type enums. This goes beyond the schema's structured data.
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 submits a DGFiP Flux 10.1/10.3 transaction e-reporting flow, specifies scope (CS mode, no payload validation), and lists four specific use cases. It distinguishes itself from sibling tools like submit_payment_report and submit_lifecycle_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-to-use conditions (international B2B outbound, inbound, B2C individual/aggregated) and implies exclusions via sibling tool names. It references a README for scope details, giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the fallback behavior when the optional saxonche extra is missing: returns level='unavailable' with is_valid=None instead of raising. Also states the return structure (is_valid, errors, warnings) which is not in annotations.
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 detailed but each sentence adds meaningful information. It could be condensed slightly, but the structure flows logically from purpose to usage to dependency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Includes scope, return fields, usage guidance, and dependency installation. Complete for a validation tool given the rich parameter descriptions and assumed output schema.
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 covers both parameters fully (100%), but the description adds nuance: xml_content is the embedded XML (not the PDF) and the profile parameter clarifies the limitation of EXTENDED-CTC-FR. This exceeds baseline 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?
Clearly states it validates Factur-X CII XML against Schematron rules, with explicit scope (no XSD). Distinguishes from sibling validate_ereporting_xml by format and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use before embedding into PDF/A-3 or submitting via submit_flow. Also clarifies it's only Schematron, implying when not to use (e.g., for structural checks).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the two-step confirmation requirement, that deletion stops notifications, and the need for user confirmation. This is thorough and accurate.
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 paragraphs: purpose first, then procedure. Every sentence adds value. No redundancy or fluff. Well-structured for quick reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description fully explains the two-step process and the effect (stop notifications). Output schema exists but is not needed. The description is complete for agent use.
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% and describes both parameters. The description adds meaning by explaining the two-step flow for confirmation_token, which enhances understanding beyond the schema. Baseline 3 with added context warrants a 4.
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 deletes (unsubscribes from) a webhook, distinguishing it from sibling tools like create_webhook or update_webhook. The verb 'Delete' and resource 'webhook' are specific, and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and how-to-use guidance: the two-step human-in-the-loop process. It instructs the agent to first call without confirmation_token, show summary, then call with token. This is a model example of usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, but description covers async submission, error cases (base64, AP rejection), B2B recipient requirements, success response fields, and confirmation token flow.
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?
Well-structured with clear sections (HUMAN-IN-THE-LOOP, BEHAVIOR, RESPONSE, USAGE GUIDELINES). Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 params, 100% schema coverage, and presence of output schema, description covers all necessary context: prerequisites, async behavior, error handling, alternative tools, and human-in-the-loop process.
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?
Input schema has 100% coverage, but description adds usage context (e.g., confirmation_token flow, tracking_id recommendation) beyond schema explanations.
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 it submits invoices, e-reportings, or lifecycle statuses, specifies scope (CS, no validation), and distinguishes from sibling tools like submit_lifecycle_status and healthcheck_flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (B2B pre-check with get_directory_line, setting tracking_id, human-in-the-loop flow) and when not to (prefer submit_lifecycle_status for lifecycle statuses, call healthcheck_flow before batch).
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:

[![mcp-facture-electronique-fr MCP server](https://glama.ai/mcp/servers/cmendezs/mcp-facture-electronique-fr/badges/card.svg)](https://glama.ai/mcp/servers/cmendezs/mcp-facture-electronique-fr)

Score Badge

Copy to your README.md:

[![mcp-facture-electronique-fr MCP server](https://glama.ai/mcp/servers/cmendezs/mcp-facture-electronique-fr/badges/score.svg)](https://glama.ai/mcp/servers/cmendezs/mcp-facture-electronique-fr)

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/cmendezs/mcp-facture-electronique-fr'

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