mister-parc-mcp

Document du socle

socle_doc

Read-onlyIdempotent

Read a full published socle document — API and stack, secrets and variables, contribution rules, or layering strategy — to check what the shared base already provides before adding new code.

Instructions

Un document du socle, en entier, à la version publiée : README.md (l'API et la stack cible), CONFIG.md (secrets et variables), CONTRIBUTING.md (ce qui entre au socle), STRATEGIE.md (le découpage en trois couches). README.md dépasse 100 Ko : pour une question précise, chercher coûte moins.

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": {
      "fichier": "<fichier>"
    },
    "name": "socle_doc"
  }
}

Input Schema

Name	Required	Description	Default
`fichier`	Yes	Le document du socle à lire.

Output Schema

Name	Required	Description	Default
`url`	Yes
`texte`	Yes
`fichier`	Yes
`version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 31, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld). The description adds real behavioral detail beyond them: the content returned is the published version rather than a working copy, and README.md exceeds 100 KB so cost/latency is high. It stops short of saying whether output is truncated or paginated for that large file, which is the one remaining behavioural unknown.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences, front-loaded with scope and version semantics, then the four documents, then the size caveat and routing advice. Every clause carries information; the size warning is placed exactly where it can prevent a bad call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return formatting need not be explained. The description covers scope, version semantics, the full enum with meanings, and the main failure mode (oversized README) — everything an agent needs to call this correctly.

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% with a single enum parameter, so the baseline is 3; the description earns an extra point because the per-file parentheticals ('l'API et la stack cible', 'secrets et variables', 'ce qui entre au socle', 'le découpage en trois couches') tell the agent what each enum value actually contains, which the schema's generic 'Le document du socle à lire' does not.

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?

States a specific verb and resource ('un document du socle, en entier, à la version publiée') and enumerates the four possible documents with a one-line gloss of each. Combined with the pointer to `chercher` for targeted questions, an agent can distinguish this from socle_chercher without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

Explicitly names the alternative and the condition that selects it: for a precise question, README.md exceeds 100 KB so `chercher` costs less. That is genuine when-to-use guidance. Minor deduction: the sibling is referred to as `chercher`, while the actual sibling names are `socle_chercher` and `parc_chercher`, leaving slight ambiguity about which search tool is meant.

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