Skip to main content
Glama
Sign In

Code civil (France)

by io.arxo
OverviewDiscussionsAdmin

law_process_run

Read-only

Comment une affaire particulière se déroulera, étape par étape : un journal {date, attempt?, facts?} est exécuté cadre par cadre, et le droit de chaque cadre est le droit de SA date. La réponse dit : quelles étapes ont été atteintes ; quelle transition tentée n'a produit AUCUN effet juridique ; quelles obligations sont violées et quels délais courent ; ce qui est disponible ensuite et CE QUI MANQUE EXACTEMENT pour le reste. Les noms des transitions viennent de law_process. Étapes atteintes signifie « a-t-on déjà entré », non « où l'on est maintenant » : le noyau 0.1 ne calcule pas les points de l'état courant.

Input Schema

NameRequiredDescriptionDefault
stepsYesle journal de l'affaire : [{date, attempt?, time?, decisionTime?, knowledgeTime?, facts: [{predicate, args, provenance}]}] ; chaque fait exige un objet provenance ({} est accepté), ses champs sont facultatifs et evidence n'est pas obligatoire. Sur une transition tentée, `time` est l'instant de l'événement (ISO 8601 avec un décalage), et par lui le porteur prend sa place dans l'historique ; les axes de décision et de connaissance d'un cadre viennent de l'entrée, sinon de l'affaire, sinon de minuit UTC de la date ; chaque cadre nomme les axes qu'il a utilisés et d'où ils viennent
packageYesl'acte
instanceYesce qui traverse la procédure : le numéro du lot, de la demande, de l'affaire
legalTimeNola date de base (YYYY-MM-DD) ; la date d'un cadre est fixée par l'étape elle-même
probeTimeNol'instant d'une tentative hypothétique, pour déterminer les étapes disponibles sur le dernier cadre ; sans lui les étapes disponibles ne sont pas calculées — l'outil n'invente pas l'heure
procedureNola procédure, s'il y en a plus d'une

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / steps / description
      Previous value: -"le journal de l'affaire : [{date, attempt?, time?, decisionTime?, knowledgeTime?, facts: [{predicate, args}]}] ; sur une transition tentée, `time` est l'instant de l'événement (ISO 8601 avec un décalage), et par lui le porteur prend sa place dans l'historique §161.1 (DECISION-0156) ; les axes de décision et de connaissance d'un cadre viennent de l'entrée, sinon de l'affaire, sinon de minuit UTC de la date ; chaque cadre nomme les axes qu'il a utilisés et d'où ils viennent"New value: +"le journal de l'affaire : [{date, attempt?, time?, decisionTime?, knowledgeTime?, facts: [{predicate, args, provenance}]}] ; chaque fait exige un objet provenance ({} est accepté), ses champs sont facultatifs et evidence n'est pas obligatoire. Sur une transition tentée, `time` est l'instant de l'événement (ISO 8601 avec un décalage), et par lui le porteur prend sa place dans l'historique ; les axes de décision et de connaissance d'un cadre viennent de l'entrée, sinon de l'affaire, sinon de minuit UTC de la date ; chaque cadre nomme les axes qu'il a utilisés et d'où ils viennent"
    • addedInput schema / properties / steps / items
      Added value: +{
+  "properties": {
+    "facts": {
+      "items": {
+        "properties": {
+          "args": {
+            "type": "array"
+          },
+          "predicate": {
+            "type": "string"
+          },
+          "provenance": {
+            "type": "object"
+          }
+        },
+        "required": [
+          "predicate",
+          "args",
+          "provenance"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/no-destructive behavior, but the description adds substantive output semantics and a key caveat that 'steps reached' means entered, not current position, and that kernel 0.1 does not compute current state points. It also explains that each frame uses the law of its own date, which is useful behavioral context beyond 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?

The description is front-loaded around what the run produces, then adds output details and a precise caveat about 'steps reached'. It is dense but appropriately sized for a complex legal-process tool, with little 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?

For a complex tool with no output schema and nested step objects, the description explains the response contents well enough to know what will be returned. Parameter details are largely delegated to the rich schema, though the description does not explicitly tie probeTime to calculating available steps.

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 six parameters in detail. The description adds only a brief journal shape and the law_process dependency, but does not materially extend parameter semantics beyond what the schema provides.

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 states a specific function: running a particular case journal frame by frame and reporting reached steps, ineffective transitions, violated obligations, deadlines, and what is missing. It distinguishes itself from law_process by noting that transition names come from that sibling, though it never states a direct verb like 'run' or 'simulate'.

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?

Usage is implied: this tool handles a particular case journal, while law_process supplies transition names. However, the description gives no explicit when-to-use guidance, no when-not conditions, and no direct comparison to siblings beyond the transition-name dependency.

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