Skip to main content
Glama
Sign In
mcp-pilotage

mcp-pilotage

by fmenguy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

lire_cerveau

Reads a project's context files (CLAUDE.md, AGENTS.md, README, ARCHITECTURE.md) to learn its conventions, tech stack and rules, or lists available docs without reading them.

Instructions

Lit le contenu des documents de contexte d'un projet : son CLAUDE.md, son .claude/CLAUDE.md, son AGENTS.md, son README, son ARCHITECTURE.md, et sur demande n'importe quel autre markdown de ses dossiers docs, notes, références ou .claude. C'est ainsi que tu apprends comment François pense un projet donné : ses conventions, sa pile, ses règles d'écriture, ses pièges connus, sans qu'il ait à te les redire. Par défaut, seuls les documents prioritaires sont retournés, tronqués pour ne pas saturer ton contexte. Pour un document précis, passe son chemin relatif dans « fichier ». Pour connaître les documents disponibles sans les lire, mets « lister_seulement » à true. Lecture seule : cet outil n'écrit jamais dans les dépôts.

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": {
      "projet": "<projet>"
    },
    "name": "lire_cerveau"
  }
}

Input Schema

NameRequiredDescriptionDefault
projetYesNom du dossier du projet (par exemple « mon-site ») ou son chemin absolu. Utilise lister_projets si tu ne connais pas les noms.
fichierNoChemin relatif d'un document précis à lire, par exemple « CLAUDE.md », « docs/architecture.md » ou « références/personnages.md ». Si absent, les documents prioritaires du projet sont lus.
max_caracteresNoBudget de caractères par document. Au delà, le document est tronqué et signalé comme tel. Augmente cette valeur si un document important a été coupé.
lister_seulementNoNe renvoyer que la liste des documents de contexte disponibles avec leur taille, sans leur contenu. Utile pour choisir quoi lire avant de consommer du contexte.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does well: it declares read-only behavior explicitly ('cet outil n'écrit jamais dans les dépôts'), discloses the default truncation designed to protect context budget, and notes that truncated documents are flagged as such. What it lacks is any statement about ordering or size of the default priority set.

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?

Front-loaded with what is read and why, then the two mode switches, then the read-only guarantee. Some editorial flourish ('comment François pense un projet donné', 'sans qu'il ait à te les redire') could be trimmed, but nothing is genuinely redundant.

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 4-parameter read tool with no annotations and no output schema, the description covers defaults, truncation, mode switching, and safety. The main residual gap is that it never says what the returned content looks like structurally (per-document headers, ordering), which matters given no output schema.

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 all four parameters are already self-documenting; the description mostly restates what the schema says for 'fichier' and 'lister_seulement'. Its only genuine addition is the workflow hint to list before reading in order to save context, which the schema does not frame that way.

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 ('Lit le contenu') and resource, then enumerates the exact documents concerned (CLAUDE.md, .claude/CLAUDE.md, AGENTS.md, README, ARCHITECTURE.md, plus any markdown in docs/notes/références). An agent can tell immediately that this is the project-context ingestion tool rather than a file search or project listing tool.

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?

Gives a clear when-to-use rationale ('c'est ainsi que tu apprends comment François pense un projet donné') and explains the two alternate modes — targeted read via 'fichier' and inventory via 'lister_seulement'. No explicit when-not guidance or named sibling routing (e.g., versus trouver_fichiers or lister_projets), which keeps it below a 5.

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

Deploy Server

Other Tools