mister-parc-mcp

Ce qu'un dépôt prend au socle

socle_usage

Read-onlyIdempotent

Reports what a repository consumes from the shared socle based on its code: locked version, imported modules, script and CI tools, plus reusable workflows and their inputs.

Instructions

Ce qu'un dépôt prend au socle, mesuré dans son code par le relevé : la version qu'il verrouille, les modules qu'il importe, les outils de ses scripts et ceux que la CI partagée lance pour lui, les workflows réutilisables qu'il appelle et avec quelles entrées.

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": {
      "depot": "<depot>"
    },
    "name": "socle_usage"
  }
}

Input Schema

Name	Required	Description	Default
`depot`	Yes	Nom du dépôt, par exemple mister-cim10.

Output Schema

Name	Required	Description
`depot`	Yes
`socle`	Yes	Version du socle que le dépôt verrouille.
`appels`	Yes
`genere`	Yes	Date du relevé qui fonde la réponse (ISO 8601).
`outils`	Yes	Outils appelés par ses scripts.
`modules`	Yes	Modules importés directement.
`outils_ci`	Yes	Outils que la CI partagée lance pour lui.
`workflows`	Yes
`mesure_incomplete`	Yes	Le relevé n'a pas pu lire tout le code du dépôt.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 31, 2026

TDQS

B3.2/5.0

Behavior3/5

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

The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds useful provenance by saying the data is measured from the repository's code via a relevé, which is beyond the annotations. It does not add caveats about permissions, freshness, or rate limits, so it remains a moderate enhancement.

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 a single front-loaded sentence that states the purpose first and then enumerates the measured elements. It is efficient and free of filler, though the list is somewhat long. No sentence is wasted.

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?

Given one fully documented parameter, existing annotations, and an output schema, the description supplies enough conceptual context to understand what the tool reports. It explains the measurement basis and the categories of usage. It does not explain sibling distinctions, but that is more a usage-guideline gap than a completeness gap.

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?

There is only one parameter, depot, and schema description coverage is 100%, so the schema already explains it with an example. The description implies the tool operates per repository but adds no syntax or constraints beyond the schema. The baseline of 3 is appropriate when the schema carries the parameter documentation.

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 clearly identifies the resource: what a repository consumes from the socle, measured from its code. It enumerates the specific data returned, including locked version, imported modules, script tools, shared CI tools, and called reusable workflows with inputs. It is clear, though it does not explicitly contrast itself with sibling tools such as socle_offre or socle_workflow.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives. It neither names alternatives nor states exclusions or typical scenarios. The only implied use is auditing a repository's socle usage.

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