Skip to main content
Glama
Edsorel75019

Enma Daio

by Edsorel75019
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Enma Daio — moteur de classement et de conseil de destination (MCP)

Enma Daio apprend l'organisation de vos dossiers, mémorise des règles de classement validées, et propose une destination pour chaque contenu. Il s'expose en serveur MCP stdio (n'importe quel harnais compatible MCP : Claude Code, Codex, OpenCode, Cursor…) et en interface web locale.

Mode conseil : Enma propose, le harnais exécute l'écriture. Enma ne crée ni n'écrit aucun fichier de contenu. Ce n'est pas un garde-fou de sécurité : un harnais disposant d'un shell peut écrire sans passer par Enma.

Fonctionnalités

  • Scan + index (Mister Popo) : parcourt l'arborescence, indexe les chemins (borné : 120 000 entrées, profondeur 8, 16 Mio/fichier, budget 600 s).

  • Apprentissage : déduit des règles candidates depuis l'index (dossier à forte concentration d'un type → destination proposée), seuil 50 fichiers, types binaires et dossiers massifs exclus.

  • Résolution : chaîne de priorité instruction ponctuelle > règle projet > gabarit > héritage, avec consultation de l'index en secours.

  • Serveur MCP stdio : 4 outils (resoudre_destination, memoriser_regle, lister_regles, proposer_regle).

  • Interface web locale (enma web) : état, arborescence repliable, règles proposées (tuile compacte), dossiers scannés (ajout/retrait), planification.

  • Planificateur (Karin) : scan périodique en fond (LaunchAgent com.enmadaio.karin), fréquence réglable.

Related MCP server: llm-file-operations-agent

Installation

Aucune dépendance obligatoire (bibliothèque standard Python uniquement). Python ≥ 3.10 requis.

pip install git+https://github.com/Edsorel75019/enma-daio   # ou : pip install .
enma install-opencode                                # pièces OpenCode (plugins, tool, permissions)

Deux points d'entrée : enma (CLI) et enma-serve (serveur MCP). enma uninstall-opencode restaure l'état antérieur.

Configuration

Fichier enma-catalogue.json (chemin via ENMA_CATALOGUE) :

{
  "racines": ["/Volumes/ULYSSE/Atelier"],
  "zones_interdites": ["/Volumes/ULYSSE/Atelier/secrets"],
  "zones_confirmation": ["…/commun/decisions", "…/commun/etat"],
  "exclusions_noms": ["node_modules", "__pycache__", ".git", ".venv", "caches", ".local", "cache"]
}

  • racines : dossiers à observer. zones_interdites : jamais lues/scannées/ cibles. zones_confirmation : proposées avec confirmation. exclusions_noms : dossiers techniques ignorés partout.

Variables d'environnement : ENMA_CATALOGUE, ENMA_STORE (règles), ENMA_INDEX (index), ENMA_REJETS (candidats rejetés).

Branchement MCP

Exemple OpenCode (opencode.json, section mcp) :

{
  "mcp": {
    "enma": {
      "type": "local",
      "command": ["/Users/sorel/Library/Python/3.14/bin/enma-serve"],
      "environment": {
        "ENMA_CATALOGUE": "…/Enma_Daio/enma-catalogue.json",
        "ENMA_STORE": "…/Enma_Daio/enma-regles.json",
        "ENMA_INDEX": "…/Enma_Daio/enma-scan-index.json"
      },
      "enabled": true
    }
  }
}

Claude Code (mcpServers) et Codex ([mcp_servers.enma]) déclarent le même serveur stdio.

Convention de vocabulaire (inscrite dans Atelier/AGENTS.md)

« solliciter Enma Daio », « demander à Enma Daio », « réveiller Enma Daio », « solliciter le portier » = appeler l'outil MCP resoudre_destination.

Utilisation en ligne de commande

enma scan       # observer les racines (Mister Popo)
enma web        # interface web locale (Enma Daio)
enma resoudre --projet atlas --type-contenu compte-rendu
enma memoriser --projet atlas --type-contenu compte-rendu --destination projets/atlas/rapports/
enma lister

Interface web

enma web ouvre http://127.0.0.1:PORT. Le serveur n'écoute que 127.0.0.1, avec un jeton local (mutations refusées sans lui). Sections : présentation (Enma Daio, Mister Popo, Karin), mode d'emploi, état, dossiers scannés (ajout via panneau natif, retrait), règles proposées (tuile compacte + filtre + pagination), arborescence repliable, règles mémorisées.

Tests

python3 tests/run.py    # 42 tests, stdlib uniquement

Limites

  • Mode conseil, pas de confinement OS.

  • Ne connaît pas le contenu des fichiers (seulement l'arborescence et les règles).

  • Pas de publication GitHub (décision Sorel : test local d'abord).

Documentation

Licence

MIT.

Available Tools

4 tools
lister_reglesA

Liste les règles de classement mémorisées.

ParametersJSON Schema
NameRequiredDescriptionDefault
projetNo
type_contenuNo

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. The word 'Liste' strongly implies a read-only operation with no side effects, but the description does not state what the listing returns, whether it reflects persisted rules, or how the optional parameters affect it. Safe but under-specified.

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?

The description is one short, front-loaded sentence with no filler or redundancy. It is sparse, but that affects completeness rather than conciseness or structure.

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?

With no output schema and no annotations, the description should clarify return values and optional-parameter behavior, but it does not. It conveys the core listing operation, yet leaves an agent unsure about what the results will contain or how the two optional parameters modify the request.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain how 'projet' or 'type_contenu' influence the result. The parameter names hint that they are filters, but the description itself adds no meaning beyond the bare property names in the schema.

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?

The description uses the specific verb 'Liste' and names the resource 'règles de classement mémorisées,' making the operation clear: enumerate stored sorting/classification rules. This distinguishes it from sibling tools that resolve, memorize, or propose rules.

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

Usage Guidelines3/5

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

The intended use is implied by the listing verb: call this when you need to see already-memorized classification rules. However, there is no explicit statement of when to choose this over resoudre_destination, memoriser_regle, or proposer_regle, and no exclusions are given.

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

memoriser_regleC

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

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

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.

proposer_regleC

Propose une règle candidate à faire valider, à partir d'une destination observée.

ParametersJSON Schema
NameRequiredDescriptionDefault
contexteNo
sessionIDNo
destinationYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not explain whether proposing a rule persists anything, triggers validation, requires prior setup, or returns a result. This is a meaningful gap for an agent deciding whether invocation is safe or appropriate.

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 short sentence with the core action front-loaded. It is concise and readable, though it achieves conciseness by omitting useful details rather than by packing meaning efficiently.

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 tool with three parameters, no annotations, no output schema, and a set of siblings, a single clause is insufficient. The agent lacks guidance on parameter semantics, side effects, return behavior, and when to use this tool compared to related ones.

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

Parameters2/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 compensate for the undocumented parameters. It adds some meaning for 'destination' (an observed destination), but says nothing about 'contexte' or 'sessionID', leaving two of three parameters entirely unexplained.

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 has a specific verb ('propose'), a specific resource ('règle candidate'), and names the input context ('destination observée'). It distinguishes this tool from siblings like lister_regles and memoriser_regle by indicating it proposes a rule for validation rather than resolving, listing, or storing one, though it does not explicitly name the sibling it is not.

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

Usage Guidelines3/5

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

The phrase 'à partir d'une destination observée' implies the tool should be used when a destination has been observed and a candidate rule needs validation. However, the description gives no explicit guidance on when to choose this over resoudre_destination or memoriser_regle, and no exclusions are stated.

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

resoudre_destinationC

Propose une destination pour un contenu (mode conseil : Enma propose, le harnais écrit).

ParametersJSON Schema
NameRequiredDescriptionDefault
projetNo
fichierNo
reponseNo
sessionIDNo
type_contenuNo
destination_ponctuelleNo

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure, and it does convey the key trait that the tool only proposes while the harness writes ('Enma propose, le harnais écrit'). It does not mention response format, side effects, or any required context, leaving meaningful behavioral ambiguity.

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 one short sentence, front-loaded with the main action and a parenthetical for the mode, with no filler. It is concise, though the parenthetical is slightly cryptic and could be clearer.

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?

Given 6 undocumented parameters, no output schema, and no explicit usage conditions, the description is too thin for an agent to invoke the tool correctly with confidence. It captures the overall purpose and advisory nature but omits parameter roles, expected output, and integration context.

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?

The schema has 0% description coverage across 6 parameters, and the description does not explain projet, fichier, reponse, sessionID, type_contenu, or destination_ponctuelle. It only references 'contenu' and 'destination' generically, so it adds almost no parameter-level meaning.

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 uses a specific verb ('Propose') and a resource ('une destination pour un contenu'), and the parenthetical advisory-mode note helps distinguish it from siblings that manage rules. It is clear at a high level what the tool does, though 'destination' and 'contenu' are not precisely defined.

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

Usage Guidelines3/5

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

The phrase 'mode conseil : Enma propose, le harnais écrit' implies the tool is for advisory proposals rather than direct execution. However, there is no explicit statement of when to use this tool versus the sibling tools, and no exclusions or alternative conditions are given.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.1.0
    • First observedlister_regles
    • First observedmemoriser_regle
    • First observedproposer_regle
    • First observedresoudre_destination
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.3/5.0

Scored across 4 tools

Disambiguation5/5

Each tool serves a distinct function: resolving a destination, memorizing/modifying rules, listing rules, and proposing new rules based on observations. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent pattern of infinitive verb + underscore + noun in French (e.g., resoudre_destination, memoriser_regle). The style is uniform and predictable.

Tool Count5/5

With 4 tools, the set is well-scoped for a rule-based classification system. Each tool addresses a core need (resolution, rule management, listing, and suggestion) without unnecessary bloat.

Completeness3/5

The main workflows are covered (resolve, create/update, list, propose), but there is no delete operation for rules. This is a notable gap that could hinder rule maintenance, though agents might work around it by modifying rules instead.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • MCP Filesystem Server

    midsane
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides file system operations (list, read, write, search) via MCP, enabling an AI agent to manage files through natural language.
    1,734 npm
    MIT

  • Filesystem MCP Server

    kaustubhwarke
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to interact with a sandboxed filesystem via MCP tools for reading, writing, searching, and monitoring files, including batch processing and resource discovery for resume management.
    Academic Free v1.1