Skip to main content
Glama
Sign In

Marcel

by fr.marcel-retraite
OverviewDiscussionsAdmin

Vérifier la cohérence de résultats Marcel

validate_results
Read-onlyIdempotent

Contrôle la cohérence de plusieurs résultats Marcel. Entrée : liste de résultats (moteur, identifiant de trace, statut, version de règles, résultat). Sortie : statut blocked en cas de conflit temporel (TEMPORAL_CONFLICT) ou de moteur blocked, et un avertissement de règle obsolète lorsqu'un résultat cite une règle déjà remplacée, dont CGI.200-A.PFU_30PCT depuis le 1er janvier 2026. Les identifiants de trace ne sont pas vérifiés : un traceId inconnu n'est pas détecté. La réponse le dit dans portee et identifiantsVerifies.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "results": "<results>"
    },
    "name": "validate_results"
  }
}

Input Schema

NameRequiredDescriptionDefault
resultsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare read-only, idempotent, closed-world, non-destructive; the description goes well beyond them by enumerating the conditions that produce a blocked status (TEMPORAL_CONFLICT, a blocked engine) and an obsolete-rule warning. Crucially it discloses a known blind spot — unknown traceIds pass undetected — and says the response reports this in portee and identifiantsVerifies, which is exactly the kind of limitation an agent needs before trusting the output.

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?

Purpose is front-loaded, then input, output, and caveat in that order. The dated rule example (CGI.200-A.PFU_30PCT since 1 January 2026) is concrete enough to earn its place, though the description runs slightly long for a single-parameter tool.

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 no output schema, the description correctly takes on return-value semantics, naming the blocked status, the obsolete-rule warning, and the portee/identifiantsVerifies fields. What is missing is the happy-path result shape when no conflict or staleness is found.

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 description coverage is 0%, so the description has to carry the load, and it does: it enumerates the per-result fields (moteur, identifiant de trace, statut, version de règles, résultat), covering all five nested properties. It stops short of stating types or whether rulesVersion/result are optional, so a small gap remains.

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 opens with a specific verb and resource (checking the consistency of a batch of Marcel results) and immediately distinguishes itself from the sibling compare_* tools, which compare values rather than validate a set of result records. An agent can tell what it produces (blocked status, obsolete-rule warnings) 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.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The input contract ('Entrée : liste de résultats...') implies the tool is fed previously produced Marcel results, which is enough to infer usage, but there is no explicit 'use this when' and no named alternative such as compare_results. The one exclusion it does give is a data caveat (traceIds are not verified), not a routing rule.

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

All Marcel 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