Skip to main content
Glama
Sign In

Code civil (France)

by io.arxo
OverviewDiscussionsAdmin

law_argue

Read-only

Quelle est la solidité d'une conclusion : la carte du litige selon le profil d'argumentation La réponse tombe en quatre classes : SKEPTICALLY_ACCEPTED — la conclusion est invulnérable (elle survit dans l'extension grounded) ; CREDULOUSLY_ACCEPTED — seulement défendable (il existe une position pour et une contre) ; REJECTED — elle ne survit nulle part ; NO_ARGUMENT — il n'y a aucun argument. Elle construit TOUS les arguments à partir des faits et des règles de l'acte (y compris les chaînes qui n'ont pas tiré dans l'inférence ordinaire), les attaques rebut/undermine/undercut et les défaites par priorité. Les noms de prédicats viennent de law_packages. Sur les grands actes, un refus par plafond est possible — restreignez les faits ou augmentez limits.maxArguments.

Input Schema

NameRequiredDescriptionDefault
argsNoles arguments du prédicat
factsNofaits de l'affaire : [{predicate, args, provenance, negated?}]. provenance est un objet obligatoire ; {} est accepté, ses champs sont facultatifs et evidence n'est pas obligatoire. L'EvidencePolicy du paquet lit confidence, pas l'hôte
limitsNoles plafonds du profil : maxArguments (64), maxExtensions (8), maxUndecided (16)
contextNoContexte temporel explicite : timezone est un nom IANA ; decisionTime et knowledgeTime sont des instants complets avec UTC ou un décalage, conservés sans substitution. legalTime est aussi requis avec context ; le profil peut exiger tous ces champs
packageNorestreindre la question à un paquet de droit
legalTimeNola date du droit (YYYY-MM-DD)
predicateYesla conclusion dont on mesure la solidité

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / context
      Added value: +{
+  "additionalProperties": false,
+  "description": "Contexte temporel explicite : timezone est un nom IANA ; decisionTime et knowledgeTime sont des instants complets avec UTC ou un décalage, conservés sans substitution. legalTime est aussi requis avec context ; le profil peut exiger tous ces champs",
+  "properties": {
+    "decisionTime": {
+      "type": "string"
+    },
+    "knowledgeTime": {
+      "type": "string"
+    },
+    "timezone": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "timezone",
+    "decisionTime",
+    "knowledgeTime"
+  ],
+  "type": "object"
+}
    • changedInput schema / properties / facts / description
      Previous value: -"faits de l'affaire : [{predicate, args, negated?, provenance?}]. provenance est le même objet que pour law_ask : origin, document, citation, extractor. confidence est lu par l'EvidencePolicy du paquet, pas par le moteur"New value: +"faits de l'affaire : [{predicate, args, provenance, negated?}]. provenance est un objet obligatoire ; {} est accepté, ses champs sont facultatifs et evidence n'est pas obligatoire. L'EvidencePolicy du paquet lit confidence, pas l'hôte"
    • addedInput schema / properties / facts / items
      Added value: +{
+  "properties": {
+    "args": {
+      "type": "array"
+    },
+    "predicate": {
+      "type": "string"
+    },
+    "provenance": {
+      "type": "object"
+    }
+  },
+  "required": [
+    "predicate",
+    "args",
+    "provenance"
+  ],
+  "type": "object"
+}
    • changedInput schema / properties / limits / description
      Previous value: -"les plafonds du profil §274 : maxArguments (64), maxExtensions (8), maxUndecided (16)"New value: +"les plafonds du profil : maxArguments (64), maxExtensions (8), maxUndecided (16)"
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description adds real behavioral context: it builds ALL arguments (including chains that didn't fire in ordinary inference), covers rebut/undermine/undercut attacks and priority defeats, and warns of a possible ceiling refusal. These are traits not derivable from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is dense but front-loaded, leading with the purpose and the four result classes before operational detail. Every sentence carries information, though it is on the longer side and could be trimmed slightly.

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?

No output schema exists, so the description must explain return semantics, which it does by defining the four acceptance classes. For a 7-param tool with nested objects it is fairly complete, though it omits how the returned 'dispute map' is structured or whether attacker/defender details are exposed.

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, but the description adds meaning beyond the schema: predicate names come from law_packages, and provenance accepts {} with evidence not required, and the ceiling workaround references limits.maxArguments specifically. This meaningfully extends parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource: it measures the solidity ('solidité') of a conclusion by constructing the dispute map over the argumentation profile, and it enumerates the four outcome classes. This is clearly distinct from an ordinary inference/query tool, though it doesn't explicitly contrast itself with specific siblings like law_explain or law_query.

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?

It implies when to use it (to gauge whether a conclusion is defensible rather than merely querying or explaining), and it gives a concrete operational hint for large acts (restrict facts or raise limits.maxArguments). But it doesn't explicitly say when to prefer this over siblings or state prerequisites for use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Code civil (France) toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources