Skip to main content
Glama
macula-io

Macula MCP

by macula-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

mesh_remember_directory

Recursively ingest local directory files into the mesh's shared memory (mcl-rag) as documents, updating existing entries on re-run. Ideal for corpora, not conversational snippets.

Instructions

Recursively ingest every matching file under a LOCAL directory into the mesh's shared memory (mcl-rag), one mcl-rag/upload_knowledge call per file -- for real documents (a corpus, a set of notes), not conversational snippets (use mesh_remember for those). Each file's content travels in its own mesh call, so this works regardless of where mcl-rag is physically running -- it does NOT ask mcl-rag to read from its own filesystem (mcl-rag's seed_corpus does that, and isn't reachable over the mesh at all). document_id is derived deterministically from each file's relative path, so re-running this on the same directory updates existing documents instead of duplicating them. Binary or undecodable files are skipped, not treated as errors. Processes files sequentially, one mesh call at a time -- a large directory will take a while; the response is a summary (counts + any per-file failures), not a per-file log.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
directoryYesLocal directory to walk, recursively. Must exist and be readable.
exclude_dirsNoDirectory names to skip anywhere in the tree. Defaults to [".git","node_modules","_build","_build_resolved","_checkouts","dist","target",".next","vendor"].
source_prefixNoPrepended to each file's relative path for source_path, e.g. "hecate-corpus".
include_extensionsNoFile extensions to ingest, e.g. [".md", ".ts"]. Defaults to [".md",".mdx",".txt"].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.37.0
    • removedInput schema / properties / host
      Removed value: -{
-  "description": "Station to connect through for both the discovery lookup and every call, \"host[:port]\". Defaults to station-de-frankfurt.macula.io:4433.",
-  "type": "string"
-}
  2. First observedv0.28.7

TDQS

A4.8/5.0
Behavior5/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, and it delivers: deterministic document_id derivation makes reruns idempotent, binary/undecodable files are skipped rather than erroring, and processing is sequential (with an explicit warning that large directories are slow). It also clarifies the response shape is a summary with counts and per-file failures, not a per-file log.

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?

Dense but front-loaded: the verb, target, and per-file call model come first, then the sibling contrast, then behavioral caveats. Length is justified by the amount of non-obvious behavior disclosed, though the parenthetical-heavy single paragraph is slightly harder to scan than it needs to be.

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

Completeness5/5

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

With no annotations and no output schema, the description must cover safety, side effects, failure modes, and returns -- and it does all four: mutation of shared memory, idempotency via derived IDs, skip-not-error on binaries, and a summary-shaped response. Nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all four parameters. The description adds genuine value on top by explaining how file relative paths (modified by source_prefix) become each document's document_id, which is the semantic that makes reruns update rather than duplicate.

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+resource+scope: recursively ingest every matching file under a LOCAL directory into mcl-rag shared memory, one upload_knowledge call per file. It explicitly contrasts itself with mesh_remember and with mcl-rag's own seed_corpus, so an agent can distinguish it from siblings without opening a schema.

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

Usage Guidelines5/5

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

Explicit routing: 'for real documents (a corpus, a set of notes), not conversational snippets (use mesh_remember for those)'. It also rules out the alternative mechanism an agent might wrongly assume (seed_corpus reading mcl-rag's own filesystem, which it notes isn't reachable over the mesh).

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