Skip to main content
Glama

memoriser_regle

Memorize or modify a filing rule for projects or templates, specifying destination and content type. File exceptions are never persisted.

Instructions

Mémorise ou modifie une règle de classement (projet/gabarit). Une exception fichier n'est jamais persistée.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
porteeNo
projetYes
valideurNo
demandeurNo
sessionIDNo
destinationYes
type_contenuYes
auteur_harnaisNo
champ_d_applicationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden. It discloses one behavioral trait ('Une exception fichier n'est jamais persistée') but omits other important behaviors: whether the rule is overwritten, whether mutation is destructive, permissions required, or any side effects. For a mutation tool, this is insufficient.

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 purpose and a key caveat. No fluff or redundancy. Efficient and well-structured.

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

Completeness1/5

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

Given 9 parameters (3 required) and no output schema, the description is far too thin. It does not explain what each parameter means, what the tool returns, or any edge cases. An agent cannot safely invoke this tool correctly based on the description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters, but it does not. It only mentions 'projet/gabarit' which loosely relates to the 'portee' enum, but the other six parameters (valideur, demandeur, sessionID, destination, type_contenu, auteur_harnais, champ_d_application) are left undefined. The description adds almost no semantic value over the bare schema.

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?

States a specific verb ('Mémorise ou modifie') and resource ('règle de classement') with scope ('projet/gabarit'). Adds a clarifying caveat about file exceptions. However, it does not differentiate from siblings like 'proposer_regle' or 'lister_regles', so purpose is clear but not explicitly set apart.

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?

No guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or exclusions relative to sibling tools. The agent is left to infer usage context.

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