ent1-mcp

carnet_signer

Idempotent

Sign a child's liaison book note to acknowledge receipt and confirm you have read the school message.

Instructions

Signe un mot du carnet de liaison (accusé de lecture) pour un enfant.

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": {
      "mot_id": "<mot_id>",
      "enfant_id": "<enfant_id>"
    },
    "name": "carnet_signer"
  }
}

Input Schema

Name	Required	Description	Default
`mot_id`	Yes
`enfant_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 20, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the mutation/idempotency profile is covered. The description adds no behavioral context beyond the act itself: it doesn't say whether signing notifies a teacher, whether it can be undone, or what permissions are required.

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?

A single, front-loaded sentence with no filler. It is efficient, though the parenthetical could have been used for behavioral or parameter detail instead of restating the resource.

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

Completeness2/5

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

For a two-required-param mutation tool with no output schema and no permission or side-effect disclosure in annotations or description, the definition is thin. An agent knows what to call but not under what authority, with what side effects, or how failure modes behave.

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?

Although measured schema coverage is 0%, the $defs entries for MotId and UtilisateurId do define both referenced parameters. The description maps loosely onto them ('un mot', 'un enfant') but adds no id format, ownership, or validation detail beyond what the schema refs already convey.

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 gives a specific verb+resource ('Signe un mot du carnet de liaison') and clarifies what signing means via '(accusé de lecture)', so the action is unambiguous. It does not, however, differentiate from the nearby sibling carnet_repondre, which an agent could plausibly confuse with it.

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?

There is no when-to-use guidance, no prerequisites (e.g. that it requires an authenticated ENT session or a parent role), and no mention of the alternative carnet_repondre. The usage context must be inferred entirely from the tool name.

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

Deploy Server