Deterministic French legal computation & B2B contract dispute resolver (Légifrance, Judilibre)
Scored across 6 tools
Each tool addresses a distinct legal task: clause validation, breach notice generation, termination risk assessment, limitation periods, article status verification, and jurisprudence search. The boundaries are clear from the descriptions, with no tool duplicating another's function.
The names mix conventions: four tools use a noun-phrase style with a 'french_' prefix, while two use a verb_noun pattern without the prefix. All are in snake_case, which aids readability, but the inconsistent structure prevents a higher score.
Six tools is well-suited to the specialized domain of French legal resolution, covering key operations without unnecessary bloat. Each tool has a clear purpose and the count is within the optimal range.
The surface covers major aspects: B2B contract validity, breach remedies, termination risk, limitation periods, article status, and case law search. Minor gaps exist, such as a tool for general statutory keyword search or broader contract compliance checks, but core workflows are supported.
Assesses statutory validity and unenforceability risk for abusive B2B contract terms, derisory caps (Art. 1170 C. civ.) and significant imbalance (Art. 1171 C. civ. & L. 442-1 C. com.).
| Name | Required | Description | Default |
|---|---|---|---|
| clause_type | Yes | Clause type: liability_cap, non_compete, unilateral_modification, penalty_clause | |
| liability_cap_eur | No | Proposed liability cap in EUR (if applicable) | |
| standard_terms_adhésion | No | True if non-negotiable adhesion contract under Art. 1110 C. civ. | |
| annual_contract_value_eur | No | Annual contractual value in EUR |
| Name | Required | Description |
|---|---|---|
| audit_seal | Yes | |
| risk_level | Yes | |
| clause_type | Yes | |
| validity_status | Yes | |
| doctrinal_analysis | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds domain context that this is a risk assessment rather than a mutation, but it does not disclose how risk is reported or whether results are advisory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the verb and purpose, with no filler. The heavy legal parentheticals slightly reduce readability but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations carry the safety profile. The description adequately frames the analytical scope for a four-parameter tool, though it omits any note on the type of clauses it does not cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all four parameters are documented in the schema itself. The description adds no per-parameter meaning (e.g. how liability_cap_eur interacts with annual_contract_value_eur to trigger Art. 1170), so it only meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (assesses) and a precise resource (statutory validity and unenforceability risk for abusive B2B contract terms), anchoring it with the exact legal grounds (Art. 1170, 1171 C. civ., L. 442-1 C. com.). It does not explicitly contrast itself with the sibling tools (breach notice, termination risk, limitations), but the domain is narrow enough to be distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never states when to invoke this validator versus alternatives, nor any preconditions (e.g. that it is for B2B adhesion contracts). Usage must be inferred from the legal citations in the text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates compliant formal cure notice (Mise en demeure) enforcing statutory resolutory clauses under Articles 1225 and 1226 of the French Civil Code.
| Name | Required | Description | Default |
|---|---|---|---|
| breach_type | Yes | Breach category: payment_default, service_failure, delivery_delay, confidentiality | |
| debtor_name | Yes | Legal entity name of defaulting party | |
| creditor_name | Yes | Legal entity name of creditor issuing notice | |
| amount_due_eur | No | Outstanding claim amount in EUR (optional) | |
| contract_reference | Yes | Contract ID, date, or agreement reference | |
| remedy_period_days | No | Cure period granted (default: 15 days) |
| Name | Required | Description |
|---|---|---|
| subject | No | |
| audit_seal | Yes | |
| formal_notice_body | Yes | |
| statutory_references | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is already covered. "Generates" usefully signals a document is produced rather than a state change being applied, and the statutory framing adds domain context, but nothing is said about permissions, whether the notice is dispatched, or side effects. The description neither contradicts nor richly extends the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence leading with the verb and the deliverable, with zero filler. Every clause earns its place by adding scope or legal grounding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists and schema coverage is complete, so return values need no explanation. However, for a six-parameter legal-generation tool the description supplies no procedural context (preconditions, what the notice contains, relationship to deadline or termination tools), leaving a real gap in workflow guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six fields (breach_type enum values, amount_due_eur, remedy_period_days default) are already documented in the schema. The description adds no parameter-level meaning beyond the statutory reference, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and artifact ("Generates ... formal cure notice (Mise en demeure)") and anchors it in Articles 1225 and 1226 of the French Civil Code. An agent can tell this is a document generator rather than a validator or risk analyzer as the sibling tools are, though it never explicitly differentiates itself from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no alternatives named. The agent gets no signal about when a Mise en demeure is the appropriate instrument versus the sibling tools (e.g. french_commercial_termination_risk or french_b2b_clause_validator).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluates financial and legal exposure for abrupt rupture of established B2B commercial relationships under Article L. 442-1, II of French Commercial Code.
| Name | Required | Description | Default |
|---|---|---|---|
| annual_gross_margin_eur | Yes | Average annual gross margin generated from partner in EUR | |
| dependency_rate_percent | Yes | Percentage of revenue represented by this partner | |
| contractual_notice_months | Yes | Notice period given or provided by contract | |
| relationship_duration_years | Yes | Continuous duration of commercial relations in years |
| Name | Required | Description |
|---|---|---|
| audit_seal | Yes | |
| statutory_reference | No | |
| legal_ceiling_applied | No | |
| notice_shortfall_months | No | |
| reasonable_notice_months | Yes | |
| estimated_gross_margin_exposure_eur | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered and there is no contradiction. The description adds the governing legal framework as context, but says nothing about output shape, jurisdiction caveats, or assumptions made when inputs are ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the legal basis is attached efficiently rather than padded into separate sentences. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and annotations cover the read-only nature. However, for a legal risk-evaluation tool the description omits applicability conditions, jurisdictional assumptions, and routing guidance relative to the five sibling tools, leaving real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema (margin in EUR, dependency percentage, notice months, duration years). The description adds no additional meaning such as units, thresholds, or how these inputs interact in the assessment, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Evaluates') and a specific resource ('financial and legal exposure for abrupt rupture of established B2B commercial relationships') anchored to a precise legal provision (Article L. 442-1, II). An agent can tell this is a risk-assessment tool, though it does not explicitly contrast itself with siblings like french_b2b_clause_validator or french_breach_remedy_notice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the scenario it covers but gives no explicit when-to-use instruction, no prerequisites, and no mention of alternative sibling tools for adjacent questions (clause validity, breach remedies, limitation periods). The agent must infer applicability from the legal citation alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Computes deterministic statutory limitation and prescription periods under French law (Articles 2224 Civil Code, L. 110-4 Commercial Code, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| claim_type | Yes | Claim category: commercial, civil_contract, consumer, employment, tort | |
| starting_point_date | Yes | Trigger date (ISO 8601 YYYY-MM-DD) |
| Name | Required | Description |
|---|---|---|
| audit_seal | Yes | |
| claim_type | Yes | |
| expiry_date | Yes | |
| duration_years | No | |
| statutory_basis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the computation is 'deterministic' and identifies the legal basis, but it does not disclose permissions, calculation caveats, or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the operation, resource, jurisdiction, and legal authority.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, both parameters are fully described in the schema, and annotations cover the safety profile. The description identifies the tool's scope and legal basis, though it omits usage routing among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both required parameters are documented in the schema. The description adds no parameter-level detail beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Computes') and resource ('statutory limitation and prescription periods'), names the jurisdiction (French law), and cites governing articles. It clearly differentiates this limitation-calculation task from the sibling legal tools, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, prerequisites, or conditions for choosing this tool over siblings such as french_commercial_termination_risk or resolve_article_status. The agent can infer a general use case from the purpose, but no explicit routing or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verifies statutory article applicability, active status (VIGUEUR), and exact consolidated legal text at date T.
| Name | Required | Description | Default |
|---|---|---|---|
| num | Yes | Statutory article number (e.g. 1104, L442-1) | |
| code | Yes | Target French legal code (e.g. civil, commerce, travail, consommation) |
| Name | Required | Description |
|---|---|---|
| code | Yes | |
| etat | Yes | |
| texte | Yes | |
| article | Yes | |
| date_fin | No | |
| audit_seal | Yes | |
| date_debut | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine domain context beyond that by naming the specific verifications performed (applicability, VIGUEUR status, consolidated text), though it omits behavior for edge cases such as an unknown or abrogated article.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with no filler, and the core action and verified facets are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description covers the verification facets adequately for a read-only tool. Minor gaps around failure cases remain but are not required for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'num' and 'code' are fully documented in the schema with examples. The description adds no additional parameter meaning, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Verifies) and resource (statutory article) with the exact facets checked: applicability, active status (VIGUEUR), and consolidated text at date T. It is clearly distinguishable in substance from the sibling tools, though it never names them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description's mention of checking status 'at date T', which signals a point-in-time validity check, but there is no explicit when-to-use guidance or routing against alternatives like search_jurisprudence_precedent or french_statute_of_limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs ranked FTS5 precedent search over French Court of Cassation decisions (Judilibre) returning official ECLI identifiers, rulings, and chamber analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default: 3, max: 10) | |
| query | Yes | Legal keywords, doctrinal principles or statutory references |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| results | Yes | |
| audit_seal | Yes | |
| total_found | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context that results are ranked and include ECLI identifiers and chamber analysis, but it says nothing about rate limits, source coverage, or freshness of the Jurilibre index beyond what the output schema would show.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the mechanism, scope, and outputs come first. It is dense but readable, with only mild redundancy in enumerating return values that the output schema already carries.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value detail need not be repeated, and annotations cover safety, so the definition is nearly complete for a 2-parameter search tool. The only gap is any guidance on query construction or result interpretation, which is minor here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'query' and 'limit' are already documented with types, defaults, and max values. The description adds no syntax or query-construction guidance (e.g., how to phrase statutory references), so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and mechanism ('ranked FTS5 precedent search'), the exact resource and jurisdiction ('French Court of Cassation decisions (Judilibre)'), and the returned artifacts ('ECLI identifiers, rulings, chamber analysis'). This scope is plainly distinct from siblings like french_b2b_clause_validator or french_statute_of_limitations, so an agent can route to it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, no mention of the alternative sibling tools for related French legal questions, and no prerequisites. The agent must infer the appropriate context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
french_b2b_clause_validatorfrench_breach_remedy_noticefrench_commercial_termination_riskfrench_statute_of_limitationsresolve_article_statussearch_jurisprudence_precedent
Add one secure layer between your agents and this server.