Skip to main content
Glama

mesh_remember_directory

Recursively ingest local files into the mesh's shared memory, one upload per document. Re-runs update existing entries via relative paths, skipping unreadable files and summarizing results.

Instructions

Recursively ingest every matching file under a LOCAL directory into the mesh's shared memory (hecate-rag), one hecate-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 hecate-rag is physically running -- it does NOT ask hecate-rag to read from its own filesystem (hecate-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
hostNoStation to connect through for both the discovery lookup and every call, "host[:port]". Defaults to station-de-frankfurt.macula.io:4433.
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. First observedv0.28.7

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and succeeds. It discloses that each file is sent in its own mesh call, that document_id is deterministically derived from the relative path so reruns update rather than duplicate, that binary/undecodable files are skipped, that processing is sequential and may be slow, and that the response is only a summary, not a full 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?

The description is long and packs many details into one dense paragraph, which slightly hurts scannability. However, every sentence contributes meaningful information: purpose, alternative routing, execution model, idempotency, error handling, and performance expectations. It is front-loaded with the core purpose and then adds progressively deeper behavioral detail, so it earns a high but not perfect score.

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?

Given the tool's moderate complexity (five documented parameters, no output schema, no annotations), the description is remarkably complete. It explains the execution model, the return shape, the update semantics, the handling of binary files, and the expected performance characteristics. An agent has enough information to select and invoke this tool correctly without guessing.

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?

The input schema has 100% description coverage, so the schema already fully documents all five parameters including defaults and examples. The description adds behavioral context around document_id and source_path, but it does not need to repeat parameter meanings. Baseline 3 is appropriate because the description adds some useful conceptual color but does not carry the semantic load.

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 clearly identifies the action ('Recursively ingest every matching file under a LOCAL directory into the mesh's shared memory') and names the specific mechanism (hecate-rag.upload_knowledge per file). It also distinguishes itself from mesh_remember, stating this is for real documents/corpora, not conversational snippets, so an agent can easily disambiguate it among many similar mesh tools.

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?

The description gives explicit usage context: use it for real documents such as a corpus or set of notes, and explicitly says to use mesh_remember for conversational snippets. It also clarifies a key non-trivial condition: it does not rely on hecate-rag reading its own filesystem, which prevents an agent from assuming a different execution model.

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