Deterministic French legal computation & B2B contract dispute resolver (Légifrance, Judilibre)
Scored across 6 tools
Each tool targets a distinct legal operation (clause validity, cure notice, termination risk, prescription periods, article status, jurisprudence search). Minor overlap exists between french_b2b_clause_validator and french_commercial_termination_risk since both invoke Art. L. 442-1 imbalance concepts, but their outputs (clause assessment vs. rupture exposure) are distinguishable.
Four tools share the french_ prefix while resolve_article_status and search_jurisprudence_precedent do not, and the noun/verb style is mixed (validator, notice, risk vs. resolve, search). Readable but not a predictable single convention.
Six tools is a tight, well-scoped set for a specialization in French contract and commercial law analysis. Nothing feels redundant or filler, though the surface is narrow by design rather than expansive.
Covers clause validity, breach remedy, termination risk, prescription, statutory status, and precedent search — the core lifecycle of a French commercial dispute analysis. Gaps remain (e.g., procedural/appeal steps, damages quantification, contract drafting), but agents can work around them.
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_category | Yes | Clause category: liability_cap_derisory, unilateral_termination_asymmetric, unilateral_price_modification, excessive_penalty_clause, disproportionate_audit_rights | |
| clause_text_excerpt | No | Excerpt of the analyzed clause text | |
| is_adhesion_contract | No | True if non-negotiable adhesion contract under Art. 1110 C. civ. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this is a safe read-only assessment (readOnlyHint=true, destructiveHint=false), so the description need not re-state safety. It usefully discloses the legal standards applied (Arts. 1170/1171 C. civ., L. 442-1 C. com.), but says nothing about what the assessment yields — a verdict, a risk rating, or a rationale — which is the key behavioral question for a judge-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the resource and the governing articles front-loaded and no filler. 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?
Inputs are fully documented by the schema and read-only nature is covered by annotations, but with no output schema the description should say what the assessment returns and how the adhesion-contract flag alters the analysis. As written the agent knows what it feeds in but not what it gets back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents clause_category (with its five enumerated values), clause_text_excerpt and is_adhesion_contract. The description adds no parameter-level guidance beyond the citations, so 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 ('Assesses') and a well-bounded resource (statutory validity / unenforceability risk of abusive B2B clauses), pinned to concrete French articles. An agent can distinguish it from french_breach_remedy_notice and french_commercial_termination_risk, though the description never explicitly contrasts with those siblings.
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 legal framing — this is the tool to run when a clause looks abusive — but there is no explicit when-to-use, when-not-to-use, or routing to siblings such as search_jurisprudence_precedent or resolve_article_status. The agent must infer the trigger conditions.
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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, and the description is consistent with that (it generates a document, does not destroy anything). The description adds the statutory basis, which is useful context, but says nothing about whether the notice is persisted, delivered, or returned as a draft requiring legal review.
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 the core purpose and legal grounding front-loaded and no filler. It is efficient, though for a six-parameter legal document generator it is arguably terse rather than optimally scoped.
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 a fully documented schema and annotations covering the safety profile, the definition is minimally complete. However, it omits what the tool actually returns (draft text, filed document, delivered notice) and any workflow context, which matters for a legal-document generator with no output schema.
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 the schema already documents all six parameters including the breach_type categories and the default remedy period. The description adds no parameter-level meaning beyond that, 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 ('Generates') and a specific resource ('formal cure notice (Mise en demeure)'), grounded in named statutory articles (1225, 1226). An agent can distinguish it from siblings like french_b2b_clause_validator or french_commercial_termination_risk, though the description never explicitly contrasts 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 explicit statement of when to use this tool versus the sibling legal tools, no prerequisites (e.g. an established breach, prior informal demand), and no exclusions. Usage is only inferable from the domain terminology.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered and 'evaluates' is consistent with them. The description adds the statutory framing but discloses nothing beyond annotations about method, assumptions, or the risk output it produces, so a baseline 3 is appropriate.
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 that names the evaluation, the scenario, and the legal basis with zero filler. 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?
Inputs are fully specified by the schema and the read-only nature is covered by annotations, but with no output schema the description never indicates what the evaluation returns (a risk score, damages estimate, or exposure summary). For a computation tool this leaves a real gap an agent would care about.
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 inputs (duration, margin, dependency rate, notice months) are already documented in the schema. The description adds no syntax, units, or interpretation guidance beyond what the schema provides, matching the baseline for high-coverage schemas.
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), a concrete resource (financial and legal exposure for abrupt rupture of established B2B relationships), and anchors it to a named statute (Article L. 442-1, II). This is clearly distinguishable from siblings like clause_validator or breach_remedy_notice without opening any 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?
The phrase 'abrupt rupture of established B2B commercial relationships' implies the triggering scenario, giving usable context. However, it names no alternative tool and states no when-not conditions or prerequisites, leaving the agent to infer when to prefer this over related French-law siblings.
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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read-only, non-destructive operation, so the safety profile is covered. The description adds the useful trait 'deterministic' (implying no LLM inference, formula-driven output), but says nothing about what is returned (a duration, an expiry date, citations) or whether suspension/interruption of the period is handled, which is central to French limitation law.
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 zero filler; the domain and legal authority are established immediately and nothing is redundant.
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 no output schema, the description should indicate what comes back (computed period, resulting deadline, statutory citations). It names the legal basis but leaves the return shape and treatment of interruption/suspension unaddressed, so an agent knows the input well but not the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself documents both claim_type (with its category list) and starting_point_date (ISO format), so the baseline of 3 applies. The description adds no further parameter semantics beyond restating the legal domain.
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?
Specific verb ('Computes') plus a precise resource ('statutory limitation and prescription periods under French law'), anchored in named legal bases (Article 2224 Civil Code, L. 110-4 Commercial Code). This clearly separates it from siblings like french_b2b_clause_validator or french_breach_remedy_notice, though no sibling is explicitly named.
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 says what it computes but never says when to reach for it versus the four other French-law siblings, nor any prerequisite (e.g., which claim_type applies to which fact pattern). Usage must be inferred entirely from the name and parameter enum.
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) |
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 usefully names the three things being checked (applicability, VIGUEUR status, consolidated text), but leaves the 'at date T' mechanism unexplained and says nothing about what happens when an article is not in force.
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?
One front-loaded sentence with no filler; the three verification targets are enumerated efficiently. Dense legal jargon (VIGUEUR) is the only minor cost, and it is at least domain-precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with no output schema, the description should indicate what comes back and how the temporal scope is determined; it only hints at consolidated text. The unresolved 'at date T' reference is the main completeness gap.
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 with examples — baseline 3 applies. The description adds no parameter meaning and in fact introduces a tension: it references 'date T' while the schema has no date parameter, leaving the agent unsure whether temporal lookup is controllable.
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 concrete verb ('Verifies') plus the specific resources: statutory article applicability, in-force status (VIGUEUR), and consolidated text. The legal-domain framing clearly separates it from siblings like french_b2b_clause_validator or french_statute_of_limitations, though it never names those alternatives explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus the five sibling legal tools, no prerequisites, and no exclusions. The agent must infer from the resource name alone that this is the lookup for article-level validity rather than clause validation or limitation periods.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds the useful 'ranked FTS5' relevance detail and names the returned fields. It does not disclose ranking semantics, language requirements, or pagination limits beyond what the schema states.
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 zero filler. Every element (ranked, FTS5, jurisdiction, source, returned fields) 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?
For a search tool with an output-less schema and full parameter coverage, the definition is minimally complete. It lacks usage context (when this beats statute lookup) and any note on ranking or language expectations, which would help an agent call it correctly in this toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are fully documented in the input schema. The description adds no syntax, example, or format detail beyond the schema; 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?
The description uses a specific verb ('ranked FTS5 precedent search') and a specific resource ('French Court of Cassation decisions (Judilibre)'), plus names the return artifacts (ECLI, rulings, chamber analysis). No sibling tool overlaps with case-law search, so it is clearly 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?
There is no guidance on when to use this tool versus alternatives, no mention of preconditions, and no exclusions. An agent must infer everything from the purpose sentence. The sibling tools are all statutory or clause-related, but the description does not say so.
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_validator9 fields changedInput schema / properties / annual_contract_value_eurRemoved value: -{
- "description": "Annual contractual value in EUR",
- "type": "number"
-}Input schema / properties / clause_categoryAdded value: +{
+ "description": "Clause category: liability_cap_derisory, unilateral_termination_asymmetric, unilateral_price_modification, excessive_penalty_clause, disproportionate_audit_rights",
+ "type": "string"
+}Input schema / properties / clause_text_excerptAdded value: +{
+ "description": "Excerpt of the analyzed clause text",
+ "type": "string"
+}Input schema / properties / clause_typeRemoved value: -{
- "description": "Clause type: liability_cap, non_compete, unilateral_modification, penalty_clause",
- "type": "string"
-}Input schema / properties / is_adhesion_contractAdded value: +{
+ "description": "True if non-negotiable adhesion contract under Art. 1110 C. civ.",
+ "type": "boolean"
+}Input schema / properties / liability_cap_eurRemoved value: -{
- "description": "Proposed liability cap in EUR (if applicable)",
- "type": "number"
-}Input schema / properties / standard_terms_adhésionRemoved value: -{
- "description": "True if non-negotiable adhesion contract under Art. 1110 C. civ.",
- "type": "boolean"
-}Input schema / requiredPrevious value: -[
- "clause_type"
-]New value: +[
+ "clause_category"
+]Output schema / (root)Previous value: -{
- "properties": {
- "audit_seal": {
- "type": "object"
- },
- "clause_type": {
- "type": "string"
- },
- "doctrinal_analysis": {
- "type": "string"
- },
- "risk_level": {
- "type": "string"
- },
- "validity_status": {
- "type": "string"
- }
- },
- "required": [
- "clause_type",
- "validity_status",
- "risk_level",
- "audit_seal"
- ],
- "type": "object"
-}New value: +nullfrench_breach_remedy_notice1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "audit_seal": {
- "type": "object"
- },
- "formal_notice_body": {
- "type": "string"
- },
- "statutory_references": {
- "type": "array"
- },
- "subject": {
- "type": "string"
- }
- },
- "required": [
- "formal_notice_body",
- "statutory_references",
- "audit_seal"
- ],
- "type": "object"
-}New value: +nullfrench_commercial_termination_risk1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "audit_seal": {
- "type": "object"
- },
- "estimated_gross_margin_exposure_eur": {
- "type": "number"
- },
- "legal_ceiling_applied": {
- "type": "boolean"
- },
- "notice_shortfall_months": {
- "type": "number"
- },
- "reasonable_notice_months": {
- "type": "number"
- },
- "statutory_reference": {
- "type": "string"
- }
- },
- "required": [
- "reasonable_notice_months",
- "estimated_gross_margin_exposure_eur",
- "audit_seal"
- ],
- "type": "object"
-}New value: +nullfrench_statute_of_limitations1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "audit_seal": {
- "type": "object"
- },
- "claim_type": {
- "type": "string"
- },
- "duration_years": {
- "type": "integer"
- },
- "expiry_date": {
- "type": "string"
- },
- "statutory_basis": {
- "type": "string"
- }
- },
- "required": [
- "claim_type",
- "expiry_date",
- "statutory_basis",
- "audit_seal"
- ],
- "type": "object"
-}New value: +nullresolve_article_status1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "article": {
- "type": "string"
- },
- "audit_seal": {
- "type": "object"
- },
- "code": {
- "type": "string"
- },
- "date_debut": {
- "type": "string"
- },
- "date_fin": {
- "type": "string"
- },
- "etat": {
- "type": "string"
- },
- "texte": {
- "type": "string"
- }
- },
- "required": [
- "article",
- "code",
- "etat",
- "texte",
- "audit_seal"
- ],
- "type": "object"
-}New value: +nullsearch_jurisprudence_precedent1 field changedOutput schema / (root)Previous value: -{
- "properties": {
- "audit_seal": {
- "type": "object"
- },
- "query": {
- "type": "string"
- },
- "results": {
- "type": "array"
- },
- "total_found": {
- "type": "integer"
- }
- },
- "required": [
- "query",
- "results",
- "audit_seal"
- ],
- "type": "object"
-}New value: +nullfrench_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.