Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@io.github.jbacalso24/mimry what files should I read first to fix the login redirect bug?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MIMRY is a local command-line tool and MCP server that gives AI coding agents a memory of a code repository. It indexes a repo once, keeps the index fresh incrementally, and answers "which files matter for this task?" with a ranked, evidence-backed list and a written context pack.
Who it is for: anyone using an AI coding agent (Claude Code, Codex, Copilot CLI, Gemini CLI, Cursor-style tools, and others) on a real codebase.
The problem it solves: agents start every task cold. They grep blindly, reread the same files, miss the file that actually matters, and burn tokens and time doing it.
What it does instead: one command, mimry preflight "<task>", returns the files to read first, how they connect, what to verify with, and a context pack the agent reads before touching code.
How it works: it parses source files into symbols and a relationship graph (imports, calls, definitions, inheritance, references), combines that with full-text and local semantic search, and learns from feedback about which files agents actually used.
Where it runs: entirely on your machine. No code is uploaded, there are no remote embeddings, and there is no telemetry.
What it is not: it is not a source of truth, a code generator, or an LLM. It narrows where to look; source files, tests, and build output remain the final truth.
Related MCP server: ProjectMind MCP
MIMRY is a Python package on PyPI and needs Python 3.11 or newer. It works on Windows, Linux, and macOS.
uv tool install mimrypipx install mimry and pip install mimry also work.
The install provides two commands: mimry (the CLI) and mimry-mcp (the MCP server for agents).
Check it:
mimry --helpUpgrade later with uv tool upgrade mimry.
Run these inside the project you want an agent to work on:
cd /path/to/your/project
mimry init
mimry index
mimry preflight "fix the login redirect bug"preflight answers like this:
✓ Context ready for "fix the login redirect bug"
Index is up to date (3,105 files, indexed just now)
Context pack: .mimry/mimry-out/context/latest.md
Start with
1 src/auth/session.py
name matches · path matches
2 src/app/login/page.tsx
name matches
3 tests/test_auth.py
path matches
Next: read .mimry/mimry-out/context/latest.md before opening files.preflight also sets MIMRY up and builds the index on first use, so in practice it is the only command an agent needs to start a task.
This section is written for an AI coding agent working in a repository where MIMRY is installed.
Use MIMRY before broad search.
Run it first whenever you need to find where something lives, what a task touches, or how two parts of the code connect.
Fall back to grep, rg, or reading files only to verify MIMRY's answer or when it cannot answer.
Start the task: mimry preflight "<task in plain words>".
Read the context pack: .mimry/mimry-out/context/latest.md.
It lists ranked files with reasons, key symbols, relationships, risky paths, and verification commands.
Navigate with focused queries instead of scanning the tree:
mimry find "<query>", mimry symbol <name>, mimry related "<query>", mimry explain "<task>", mimry path <a> <b>, mimry why <file> --query "<task>".
Verify against the source. MIMRY output is navigation, not proof. Open the files, run the tests, and trust the build output over any ranking.
Record what helped:
mimry feedback --query "<task>" --opened <files> --changed <files> --verification "<command and result>" --outcome passed.
Future searches for similar tasks rank those files higher.
If MIMRY says the index is out of date, run mimry reindex (fast: it only re-reads changed files).
Treat .mimry/, caches, and generated files as support artifacts, never as the place to fix a bug.
Never paste secret values into context or reports; MIMRY skips secret-looking files and redacts feedback.
Output is plain ASCII when piped (OK, !, x marks), and exit codes are meaningful: 0 ok, 1 not set up, 2 stale or an error.
mimry route "<task>" --json returns structured data.
Agents can call MIMRY directly as an MCP server (stdio transport, command mimry-mcp).
Claude Code:
claude mcp add --scope user mimry -- mimry-mcpCodex:
codex mcp add mimry -- mimry-mcpAny other MCP client:
{
"mcpServers": {
"mimry": { "command": "mimry-mcp" }
}
}Without installing anything first, uvx mimry mcp runs the same server straight from PyPI ("command": "uvx", "args": ["mimry", "mcp"]).
MIMRY is listed in the official MCP Registry as io.github.jbacalso24/mimry.
The server works on its current directory by default, and every tool accepts a root argument for another repo.
MCP tool | What it does |
| Set up if needed, then write a context pack and return the top files for a task |
| Rank files for a query |
| Files related to a query through the graph |
| Fuzzy "something like this" search |
| Look up a function, class, or other symbol by name |
| Write a context pack for a task |
| Relevant files, key symbols, and how they connect |
| Shortest relationship path between two files or symbols |
| Why a file ranks for a query |
| Recommend an agent role and write a role-specific brief |
| Index health and maintenance |
| Record which files helped a task |
| Adapters, canonical index digest, read-only plan trees |
MIMRY can install a skill (instruction bundle) that teaches an agent the workflow above:
mimry install --project --platform claude-code --always-on --hooks--project installs into this repo only; omit it to install for every project.
--always-on adds a short rules block to the agent's always-read file, such as AGENTS.md.
--hooks adds a hook that nudges the agent to use MIMRY before broad searches.
Supported platforms: claude-code, codex, opencode, kilo, aider, copilot, claw, droid, trae, trae-cn, hermes, kiro, gemini, agents, amp, devin, antigravity, kimi, pi, codebuddy.
Run mimry install --list-platforms for aliases, mimry install --project --platform <name> --status to check an install, and mimry uninstall --project --platform <name> --always-on --hooks to remove it.
Agents find the right file first. On MIMRY's frozen retrieval benchmark, 94% of the files a task needs appear in its top 5 results (recall@5 0.94, nDCG@5 0.70).
It stays fast on large repos. Like git, it trusts unchanged file metadata, so a reindex with no changes takes about three seconds on a 3,000-file repo, and a real reindex re-parses only what changed.
Answers carry evidence.
Every result says why it ranked, and mimry why and mimry path show the actual relationships behind it.
Unresolvable imports are dropped rather than guessed.
It learns from use. Feedback about files agents opened, changed, missed, or ignored becomes an explainable ranking signal.
It is private by default.
Everything stays local, semantic search uses a deterministic local method (local-hash-v1), and credential files are skipped.
Small outputs save tokens. Results are compact summaries and relative paths, never full source dumps.
Every command answers the same way: one line that says what happened, a few indented details, and a next step only when something needs doing.
Add --verbose (-v) to any command for paths, scores, and raw ranking reasons.
Command | Use it to |
| Start a task: context pack plus the files to read first |
| Rank files for a query ( |
| Find files connected through the graph |
| Fuzzy recall for "I remember something like..." |
| Find where a symbol is defined |
| Write a context pack without the preflight checks |
| Files, key symbols, and how they connect |
| Shortest relationship path between two files or symbols |
| Why a file ranks for a query |
| Recommend an agent role ( |
| Write a role-specific brief |
| Set up a repo and build the index |
| Update the index ( |
| Is the index current? ( |
| Record what helped; |
| List indexed folders on this machine ( |
| Store and render explicit plan trees |
| Run the MCP server (same as |
| List the file-type adapters |
| Manage agent skills |
| Print a canonical digest of the index |
| Delete this repo's cached index |
Use mimry --root /path/to/repo <command> to target another repo.
Keeping an index current:
$ mimry status
! my-app is out of date - 1 file changed, 1 new since the last index
changed src/auth/session.py
new src/auth/magic_link.py
Indexed 5 minutes ago · at commit d7bf046
3,105 files · 6,859 symbols · 10,749 links
Run `mimry reindex` to update it.
$ mimry reindex
✓ Updated the index for my-app in 2.2s
1 file changed, 1 added
changed src/auth/session.py
added src/auth/magic_link.py
3,106 files · 6,871 symbols · 10,762 linksColour is used only on an interactive terminal, and NO_COLOR=1 turns it off.
Piped and captured output always uses plain ASCII marks, so scripts and agents see the same text on every platform.
project-root/
├─ .mimry/ # local settings, gitignored
│ └─ mimry-out/ # generated output for agents and humans
│ ├─ context/latest.md # latest context pack
│ └─ graph/ # relationship graph artifacts
└─ source files...The index itself lives in your user cache directory, outside the repo. It is a generated artifact, not a source of truth.
A context pack contains the query and index freshness, ranked files with reasons, symbol hints, relationships, a suggested reading order, likely edit surfaces versus support files, risk notes for generated or sensitive paths, verification commands from the project's manifests and docs, and a final-report checklist.
It uses relative paths and never includes full source or secret values.
See docs/context-packs.md for the contract.
MIMRY builds its own relationship graph in src/mimry/core/.
Indexing parses each file once and derives these edges from what it read:
relation | shape | from |
| file to symbol | every parsed definition |
| file to file | resolved import/using statements |
| symbol to symbol | call sites resolved to a definition |
| symbol to symbol | base classes and implemented interfaces |
| file to file, file to symbol | markdown links and SQL table mentions |
Languages parsed: Python, JavaScript, JSX, TypeScript, TSX, Go, Rust, and C#.
Markdown, text, .docx, and .xlsx are indexed for content and can carry references edges.
Resolution never guesses.
A target that is ambiguous, or defined outside the repo, produces no edge rather than a plausible one.
inherits additionally resolves a base type by name across the repo when exactly one file defines that name, because C# reaches base types through using <namespace> rather than a path import.
Nodes are grouped into communities by deterministic label propagation, and graph.json is byte-identical across rebuilds of unchanged sources.
Adding a language is a table entry in core/languages.py, since every grammar ships in the pinned tree-sitter-language-pack.
Artifacts land in .mimry/mimry-out/graph/ (graph.json, GRAPH_REPORT.md, manifest.json) during mimry index; there is no separate build step.
Like git, MIMRY treats a file as unchanged while its size, inode, and nanosecond mtime still match the snapshot it was indexed from, so status checks and reindexes do not re-read unchanged files.
A reindex re-parses only new and changed files, and its output is identical to a full rebuild.
Files modified within two seconds of the previous index scan are always re-read, which covers edits that land inside one timestamp tick.
The one edit this cannot see is a rewrite that deliberately keeps size, inode, and mtime.
Run mimry status --verify to re-hash every file, and mimry index --full to re-parse every file.
mimry feedback records which files an agent actually used after a task.
It is stored in the repo's local cache, is not telemetry, and becomes a modest, explainable ranking signal for similar future queries.
mimry feedback --query "fix board card click" \
--context .mimry/mimry-out/context/latest.md \
--opened src/features/boards/api.ts \
--changed src/app/api/bridge/route.ts \
--missed bridge/fastapi_app.py \
--ignored README.md \
--verification "npm run build passed" \
--outcome passedExact filename, symbol, graph, and source evidence stay primary. Feedback breaks ties and recovers previously missed files; it does not override source-truth signals.
mimry plan stores explicit, user-authored plan trees: one root with ordered children, each of which can be split again.
It stores and renders the tree only; it does not generate plans, execute work, or track progress.
mimry plan new "Ship feature" --name ship-feature
mimry plan split <plan-id> <root-node-id> --child "Design" --child "Implement"
mimry plan tree <plan-id> # also --json or --md
mimry plan check <plan-id>
mimry plan listShip feature [node-...]
|-- Design [node-...]
`-- Implement [node-...]split works on leaves only, and repeated --child arguments set sibling order.
Trees are canonical versioned JSON under .mimry/plans/, written atomically.
IDs, projections, and the semantic SHA-256 from mimry plan digest exclude paths, timestamps, locale, and formatting.
MCP exposes read-only parity (mimry_plan_tree, mimry_plan_check, mimry_plan_digest, mimry_plan_list); changing a plan is CLI-only.
MIMRY works best when one root is one meaningful working context: a repo or a project folder.
Good roots: ~/Documents/project-a, C:\Users\you\Documents\project-a, D:\Work\active-product.
Bad roots: /, ~, ~/.config, ~/.cache, C:\, C:\Users\you, AppData, node_modules.
Whole-drive or whole-home indexing is noisy, slow, and likely to include secrets, caches, and unrelated projects.
For a personal "global" memory, make a curated folder such as ~/Workspace and put only useful projects and docs in it.
Source files remain the final truth.
Context packs use relative paths and summaries, not full source.
Semantic search defaults to the deterministic local local-hash-v1; nothing is sent to a remote embedding service.
Feedback is local metadata, not telemetry, and secret-looking values are redacted before they are stored.
Scanner rules skip common credential files.
Tester-owned acceptance_tests/ trees stay out of ordinary index surfaces by default.
This is cooperative isolation, not secrecy: anyone with the repo can still open those files.
Index publication, feedback writes, readers, generation cleanup, and mimry cache wipe --current share one per-root operation lock.
POSIX readers share it; Windows readers take it exclusively because msvcrt.locking has no shared mode.
Lock waits are bounded to 10 seconds by default; set MIMRY_LOCK_TIMEOUT_SECONDS to raise the bound.
Timeout errors include the lock path and holder metadata, so a stuck process can be diagnosed without deleting lock files blindly.
Published indexes are immutable generations.
Startup and successful publication remove abandoned staging trees and keep only the current and last-known-good generations.
Generation manifests checksum immutable sidecars, and SQLite semantic rows carry the same generation identity plus a content checksum.
mimry cache wipe --all is disabled until MIMRY has a proven cache-global writer protocol; use --current instead.
Adapters teach MIMRY about common project surfaces: python-ast, typescript-ast, config-manifest, nextjs-app-router, fastapi, react-native-expo, sql-schema, markdown-docs, and generic-text.
Run mimry adapters --verbose to see what each extracts.
MIMRY targets Windows, Linux, and macOS on Python 3.11 to 3.13, and CI runs the full suite on all nine combinations. Paths are handled POSIX-style internally, and platform-specific system calls are capability-guarded rather than assumed. Handled explicitly, because each was a real bug:
Path.home() resolves from USERPROFILE on Windows, not HOME.
fsync needs a writable descriptor on Windows, and st_ctime there is creation time.
os.utime(follow_symlinks=False) and byte-range lock semantics are capability-guarded.
Human CLI output degrades Unicode safely on strict cp1252 consoles, while JSON, Markdown, and index artifacts stay UTF-8.
Subprocesses never inherit stdin, which under the MCP stdio server is the JSON-RPC channel.
CI runs on every push and pull request: lint, tests, an end-to-end determinism matrix, an unlocked extracted-sdist parser suite, and a clean-wheel smoke test on each platform, plus jobs that compare determinism evidence across platforms and gate the retrieval benchmark.
Releases are cut by pushing a vX.Y.Z tag, which builds reproducible artifacts and publishes them to PyPI and GitHub Releases.
See CHANGELOG.md for release notes and RELEASING.md for the release checks.
git clone https://github.com/jbacalso24/mimry.git
cd mimry
uv sync
uv run ruff format .
uv run ruff check .
uv run pytest -qInstall the CLI from your checkout, so edits take effect immediately:
uv tool install --editable . --forceInstall the Git hooks with uv run pre-commit install.
Run uv run mimry-integration-smoke for a real MCP stdio round trip plus isolated Claude Code and Codex registration checks; it never touches your normal agent configuration.
MIMRY is early but usable for local, per-project agent memory. It is not a whole-computer brain and should not be pointed at entire drives or home directories.
Write a role-aware MIMRY agent brief and return its path plus route payload.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| agent | Yes | ||
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says 'Write' and returns 'path plus route payload', which implies a filesystem mutation, but does not disclose whether this creates or overwrites files, required permissions, what the route payload contains, or whether the operation is idempotent. For a write tool with zero annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that front-loads the action ('Write a role-aware MIMRY agent brief') and mentions the return shape. No wasted words, though it's arguably too terse given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained. But with 4 undocumented parameters, no annotations on a write operation, and no usage guidance among 21 siblings, the description is far too thin. An agent would struggle to call this correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — none of the 4 parameters (root, agent, limit, query) have descriptions in the schema. The tool description adds no parameter meaning either: it doesn't explain that 'query' selects content, 'agent' defines the role perspective, 'limit' caps results, or what 'root' scopes. Complete failure to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and resource ('Write a role-aware MIMRY agent brief') and mentions its output ('return its path plus route payload'). However, 'MIMRY agent brief' is domain-specific jargon that doesn't clarify its distinction from the many sibling mimry_* tools (mimry_route, mimry_plan_digest, mimry_context). It's somewhat clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like mimry_plan_digest (also a digest-like tool) or mimry_context. There are no exclusions, no prerequisites, and no routing hints despite 21 sibling tools. Implied usage only from the name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a MIMRY context pack and return its path plus selected files.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| query | Yes | ||
| semantic | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral burden. It says a pack is generated and returned, but doesn't state whether it writes files to disk, where it writes them, whether it requires an initialized index (mimry_init), or whether the operation is idempotent. For a tool that presumably materializes state, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single tight sentence with the core action and return front-loaded. No wasted words, though the terseness comes at the cost of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, but the description still leaves the agent without prerequisites, parameter meaning, or sibling differentiation for a 3-parameter generation tool in a crowded namespace.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 3 parameters. The description doesn't even name them. 'query' is presumably the search/topic input but its grammar is unexplained; 'root' and 'semantic' are entirely undocumented by either the schema or the description. Description must compensate and doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb and resource ('Generate a MIMRY context pack') and mentions the return, but 'MIMRY context pack' is undefined jargon and the description gives no hint of what a context pack contains or how it differs from siblings like mimry_brief, mimry_digest, or mimry_related. An agent cannot confidently distinguish this from its many siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no alternatives named, no exclusions. With 21 sibling tools competing for similar-sounding tasks, the absence of any routing hint is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical semantic digest and state metadata for an index generation.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. "Return" weakly implies a read, but it never confirms read-only safety, describes side effects, or explains what the digest/state metadata actually represents. For a sole-sentence definition with zero annotation coverage this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of filler, so there is no waste. It is under-specified rather than bloated, and a one-line tool description leaves the reader without actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. But with no annotations, an undocumented parameter at 0% coverage, and no usage guidance, the description is not complete enough for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single "root" parameter has 0% schema description coverage and is not mentioned in the description at all. The phrase "for an index generation" hints at a scoping argument but never explains what root selects or what its default (null) means, leaving the only parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It supplies a verb ("Return") and a resource ("canonical semantic digest and state metadata for an index generation"), which is more than a tautology. However, "canonical semantic digest" and "index generation" are undefined jargon, so an agent cannot confidently distinguish this from siblings like mimry_plan_digest or mimry_status without guessing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this tool, no prerequisites, and no reference to any alternative such as mimry_status or mimry_plan_digest. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain top files, symbols, graph evidence, and verification hints for a task.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says what is explained but does not disclose read-only status, side effects, permissions, rate limits, or other behavioral traits an agent needs before invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values are partly covered. However, with no annotations, 0% parameter description coverage, and many sibling tools, the description is insufficient for choosing the tool or using its parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 mention any of the three parameters (query, root, limit). 'For a task' loosely suggests the query parameter, but root and limit are completely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a clear verb and resource set: explain top files, symbols, graph evidence, and verification hints for a task. It is specific enough to understand the tool's function, but it does not differentiate itself from siblings such as mimry_why, mimry_context, or mimry_brief.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any stated exclusions or prerequisites. Usage is only implied by the phrase 'for a task'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record local agent usage feedback for future ranking.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| notes | No | ||
| query | Yes | ||
| missed | No | ||
| opened | No | ||
| changed | No | ||
| context | No | ||
| ignored | No | ||
| outcome | No | unknown | |
| suggested | No | ||
| verification | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 doesn't say whether this is a write operation, whether it's idempotent, what permissions are needed, whether it has side effects, or how the feedback is stored or used. 'For future ranking' is the only hint, and it's too vague to be actionable. With 11 parameters and no annotations, this is woefully insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, so it's concise and front-loaded. However, its brevity is due to under-specification rather than efficient communication. It doesn't waste words, but it also doesn't provide enough information, so conciseness is somewhat moot.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (11 parameters, no annotations, 0% schema coverage, and an output schema that isn't described), the description is completely inadequate. It doesn't explain what the tool does, how to use it, what feedback to provide, or what happens as a result. An agent would be guessing at every step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the 11 parameters. Critical fields like 'query' (required), 'outcome', and arrays like 'missed', 'opened', 'changed', 'ignored', 'suggested' are completely undocumented. The description doesn't even mention what kind of data should be provided. This is a severe gap that would likely lead to incorrect usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Record local agent usage feedback.' This communicates the basic purpose, but it doesn't distinguish this tool from any sibling (none of the listed siblings appear to be feedback tools, but there's no explicit differentiation). The word 'local' is vague, and 'for future ranking' hints at a downstream effect without explaining it. It's adequate but not specific enough to be strong.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, when not to use it, or how it relates to alternatives. An agent would have to guess that this should be called after using other mimry tools, and there's no mention of prerequisites or timing. This is a significant omission for a feedback tool that likely has a specific place in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search indexed files with ranking reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| limit | No | ||
| query | Yes | ||
| semantic | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and fails to. It doesn't state read-only behavior, whether it hits an index vs. live filesystem, whether it requires prior init/reindex, or what 'ranking reasons' means concretely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence – not bloated, but under-specified rather than genuinely concise. It is front-loaded but so sparse it conveys little.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be explained, but for a 4-param search tool with no annotations and 0% param coverage the description is far too thin to call correctly against a dense sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 4 parameters, so the description must compensate and does not. It never mentions 'query', 'root', 'limit', or 'semantic', leaving the semantic-vs-keyword toggle and root scoping semantics entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb (search) and resource (indexed files) plus a distinctive output trait (ranking reasons). But it is thin: it does not differentiate from siblings like mimry_semantic or mimry_related, and the exact difference between 'search' here vs. semantic variants is left unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance at all. With 20+ sibling tools including mimry_semantic, mimry_related, and mimry_route, an agent gets zero help choosing this over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize MIMRY metadata for a root.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| root_type | No | repo | |
| skip_graph | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not state whether initialization is destructive, idempotent, requires specific permissions, or what happens if metadata already exists. This is a significant gap for an initialization operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no waste. It is front-loaded with the main action, though it may be too terse given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters (0% documented), no annotations, and an output schema, the description is insufficient. It fails to explain parameter usage, behavioral characteristics, or when to use this tool over siblings, leaving critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 any of the three parameters—root, root_type, or skip_graph. The description adds no meaning beyond the parameter names themselves, leaving the agent to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Initialize) and resource (MIMRY metadata for a root), which is clearer than a tautology. However, 'MIMRY' is undefined and no sibling differentiation is provided, leaving the purpose vague to an agent unfamiliar with the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no when-to-use context, no prerequisites, and no comparison to sibling tools like mimry_status or mimry_reindex. An agent has no guidance on when initialization is required versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active and planned MIMRY adapter plugins for coding-agent routing.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' reasonably conveys a read-only, non-mutating operation, and mentioning both active and planned adapters gives useful scope context, but nothing is said about permissions, ordering, or whether the list is scoped to the current workspace.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the scope qualifier and purpose are packed efficiently. Nothing could be trimmed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and this is a simple one-parameter list tool. However, with zero annotations and an undocumented parameter, the definition leaves an agent without enough to know the effect of active_only or the intended call context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter 'active_only', so the description must compensate and does not. It says the tool lists active and planned adapters but never explains that the boolean toggles between those two result sets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('MIMRY adapter plugins'), and adds scope ('active and planned') plus purpose ('for coding-agent routing'). No sibling tool lists adapters, so differentiation is achieved by the resource itself despite the crowded mimry_* namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this versus alternatives, nor any stated prerequisites or exclusions. The one implicit decision point (narrowing to active-only) is neither named nor connected to the parameter that controls it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a graph relationship path between two files/symbols/queries.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| source | Yes | ||
| target | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 does not state whether the operation is read-only or mutating, whether it requires an index or prior initialization, what happens if no path exists, or any rate limits. It merely restates the core action without additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a brief tool description, though it could benefit from additional structure to convey more information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, three parameters with zero schema coverage, and an output schema exists, the description is incomplete. It does not explain the parameters, does not mention the output, and provides no behavioral details. While the output schema may cover return values, the description leaves major gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 any of the three parameters. It does not clarify what 'source' and 'target' represent beyond the vague 'files/symbols/queries' phrase, and it completely omits the optional 'root' parameter. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Find a graph relationship path between two files/symbols/queries.' This clearly describes the operation. However, it doesn't distinguish itself from siblings like mimry_related or mimry_route, leaving ambiguity about when to prefer this tool over those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as mimry_related or mimry_route, which also likely deal with graph relationships. The description provides context but no exclusions or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a stored plan tree without changing it.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| plan_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose the single most important behavioral trait — validation is non-mutating — but says nothing about permissions, what happens on an invalid tree, or whether it reports warnings vs errors. That is one genuine disclosed trait against many undisclosed ones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or redundancy. It is efficient, though the terseness edges toward under-specification rather than tight writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. However, for a 2-parameter tool with 0% schema coverage, no annotations, and no usage guidance, an agent still lacks what validation means, how 'root' scopes the check, and when to invoke this rather than its plan_* siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions either parameter. 'plan_id' is at least inferable from 'stored plan tree', but 'root' — an anyOf string/null with a null default — is left completely unexplained, which is exactly the kind of ambiguity the description needs to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('validate') and resource ('stored plan tree'), which is enough to distinguish it from write-oriented siblings like mimry_plan_tree and mimry_plan_digest. It stops short of naming a sibling or saying what 'validate' actually checks (structure? schema? cycles?), so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to reach for this tool versus mimry_plan_tree, mimry_plan_digest, or mimry_plan_list, and no prerequisites or exclusions. The only implicit guidance is the phrase 'without changing it', which hints at a read-only audit use case but does not route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical semantic SHA-256 for a stored plan tree.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| plan_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden. 'Return' implies a non-mutating operation and 'canonical semantic' signals that equivalent plan trees hash identically regardless of formatting, which is useful behavioral context. However, it says nothing about error behavior for unknown plan_ids, permissions, or determinism guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with zero filler; the key term (canonical semantic SHA-256) leads immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-format explanation is not required, and the tool is simple with two parameters. Still, the unexplained 'root' parameter and absent usage guidance leave gaps for an agent deciding when and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 and does not. It never explains plan_id or the optional 'root' parameter (string|null, default null), leaving the agent to guess what 'root' scopes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returning the canonical semantic SHA-256 of a stored plan tree. That is enough to separate it from mimry_plan_tree and mimry_plan_check, though it never names a sibling or clarifies how it differs from the non-plan mimry_digest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites (must the plan already exist?), and no mention of alternatives such as mimry_digest or mimry_plan_tree. The agent must infer the context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the deterministic local plan inventory for a root.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. 'Deterministic' and 'local' hint at caching/reproducibility, but it doesn't state permissions needed, whether anything mutates, what happens when no plans exist, or how the root default is interpreted. Output schema exists, so return format is excused, but mutation/safety context is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-param tool in a dense sibling family with no annotations, the description is under-specified: no root semantics, no behavior on empty/missing plans, no routing to plan_tree/plan_digest. Output schema covers the return type, but everything else is left to the schema's sparse fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter (root) with 0% schema description coverage and default null. The description mentions 'for a root' but never explains what a root is, what the default (null) means, or the expected format. With low coverage, the description should compensate and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Return ... plan inventory') with a qualifier ('deterministic local') and a scoping input ('for a root'). Clear purpose, though it does not distinguish itself from sibling plan tools like mimry_plan_tree or mimry_plan_digest, which likely overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no exclusions. Given four sibling plan tools (plan_tree, plan_check, plan_digest, plan_list), an agent has no basis to pick this one over the others. The description should route between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return canonical JSON plus deterministic terminal and Markdown projections for a plan tree.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| plan_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the output formats (canonical JSON, terminal, Markdown), which is useful, but it doesn't disclose whether the operation is read-only, whether it requires specific parameters like root to be set, or any rate limits or side effects. For a tool with no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary output (canonical JSON) and then lists additional projections. It is concise and wastes no words, though it could be slightly more specific about the resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, no schema descriptions, and no output schema details (though an output schema exists, the description doesn't explain its structure or how it relates to the projections), the description is incomplete. It should at least clarify the parameter semantics and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description doesn't explain the parameters plan_id or root. It mentions 'plan tree' but doesn't clarify the role of root or the required plan_id. The schema itself has no descriptions, so the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (return) and resource (plan tree), and it specifies the output format (canonical JSON plus terminal and Markdown projections). But it doesn't differentiate from siblings like mimry_plan_list or mimry_plan_check, leaving the agent to infer the scope. A 3 reflects vague purpose relative to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus mimry_plan_list, mimry_plan_check, or mimry_plan_digest. The description only states what it does, not the context or conditions for selection. This is a significant gap for a tool with several plan-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fast readiness check and task context generation, matching CLI preflight.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| query | Yes | ||
| force_refresh | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 doesn't state whether this is a read-only operation, what side effects (if any) it has, what permissions are needed, or what the output contains. 'Fast' implies performance but no concrete details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is front-loaded. However, it is under-specified rather than concise – it wastes the opportunity to provide useful detail and remains vague.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three undocumented parameters, no annotations, and no output schema, the description is completely inadequate. It fails to explain the tool's purpose, usage, behavior, or parameters sufficiently for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – none of the three parameters (root, query, force_refresh) are documented in the schema. The description adds no meaning for any parameter. For 'query', it doesn't specify the query format or expected content. 'force_refresh' and 'root' are entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fast readiness check and task context generation, matching CLI preflight' restates the name in vague terms. 'Readiness check' and 'task context generation' are abstract without specifying what resource is being checked or how it differs from siblings like mimry_status or mimry_context. A user cannot tell what this tool actually does from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as mimry_status or mimry_context. The description doesn't explain prerequisites, exclusions, or typical invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run MIMRY index, semantic index, then status.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says it re-runs indexes but not whether this is destructive to existing state, how expensive/long it takes, whether it can run while other queries are active, or whether it requires a root to be initialized. An output schema exists, so return values are covered, but the operational traits are not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence, front-loaded with the verb and the ordered sequence, so there is no waste. However it is terse to the point of under-specification for a multi-step operation, which is a different failure than verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation-style composite with no annotations and a completely undocumented parameter, the description leaves too much open. The output schema covers results, but the agent still lacks the when/why and the meaning of root needed to invoke this confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter 'root' is undocumented in both schema and description. An agent cannot tell whether root is a path, a project identifier, or what the default (null) resolves to, even though the default hints it is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific composite operation and enumerates its three phases ('index, semantic index, then status'), which lets an agent distinguish it from the single-purpose siblings mimry_reindex and mimry_status. The only weakness is that 'MIMRY index' is internal jargon that isn't defined, but the verb+sequence is otherwise concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this composite over calling mimry_reindex / mimry_semantic / mimry_status individually, nor any note about prerequisites (e.g. whether mimry_init must run first). Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rebuild the local MIMRY index for a root; full re-parses unchanged files too.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries full burden. It discloses that full=true re-parses unchanged files (a meaningful behavioral distinction), and that it rebuilds an index for a specified root (implying write/local effects). However, it doesn't say whether this is destructive, whether the index is unavailable during rebuild, or how it behaves when root is null (defaults to something?). Partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the action and appends the parameter nuance. No waste. Could be slightly more informative without losing concision, but it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained. But for a write-ish index-rebuild tool with no annotations, the description doesn't cover safety, root scoping, or when to prefer it over refresh/init. Given 21 siblings, more routing context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains 'full' ('re-parses unchanged files too'), which is good, but says nothing about 'root' despite it being the scoping parameter with a null default. With 2 undocumented parameters and only half addressed, more is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb+resource: 'Rebuild the local MIMRY index for a root.' An agent knows exactly what this does. It distinguishes itself from siblings like mimry_refresh or mimry_init by being the index rebuild operation. Not a 5 because it doesn't explicitly contrast with refresh/init to help selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of alternatives like mimry_refresh (which is a very close sibling by name), no prerequisites or conditions. The agent must infer from sibling names alone whether to reindex or refresh. This is a notable gap given there are 21 siblings with overlapping index-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend an agent/role, context packs, files, risk gates, and verification for a task.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states only that it recommends items, without indicating whether the operation is read-only, what permissions are needed, whether it mutates state, or any rate limits. The behavioral burden is largely unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It lists the outputs compactly, though the density of nouns makes it feel slightly like a label rather than a complete instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values need not be explained. However, with 3 parameters at 0% schema coverage, no annotations, and no usage guidance, the definition leaves significant gaps for correct invocation (e.g., what query should contain, what root and limit do).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 mention any of the three parameters (query, root, limit). The only clue is 'for a task,' which loosely implies the query parameter, but no parameter meaning, format, or default behavior is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Recommend') and enumerates the resources it produces: agent/role, context packs, files, risk gates, and verification. It does not distinguish itself from sibling tools like mimry_context or mimry_plan_tree, but the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternatives are provided. The phrase 'for a task' implies the tool is invoked when a task needs routing recommendations, but there are no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local-only semantic search over bounded MIMRY chunks.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does disclose that search is local-only and operates over 'bounded' chunks, which is useful context. But it says nothing about whether the index must be built first, permission requirements, or ranking behavior – notable gaps for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the key qualifier ('local-only') front-loaded. No wasted words, though it is arguably too terse given the documentation gaps elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be explained, but the 0% parameter coverage and the absence of any annotation or usage guidance leave the definition under-specified for a search tool in a crowded sibling namespace.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all three parameters (query, root, limit). The description adds no meaning to any of them – it doesn't clarify that 'query' is the semantic text, what 'root' scopes, or what 'limit' caps. For a 0%-coverage schema the description is expected to compensate and does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('semantic search over bounded MIMRY chunks') and adds the 'local-only' qualifier, which distinguishes it from a hypothetical remote search. However, with siblings like mimry_find, mimry_related and mimry_symbol in the namespace, the description never explains how this search differs from those, leaving the agent to guess.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative routing is provided. The agent cannot tell from this text whether mimry_find or mimry_related is the better choice for a given lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return MIMRY initialization and index freshness for a root.
Freshness trusts unchanged file metadata, like git; verify re-hashes every file.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| verify | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses a genuinely useful behavioral trait: default freshness trusts unchanged file metadata 'like git' while `verify` re-hashes every file, implying a cost/latency difference. It stops short of confirming read-only safety or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler; the core purpose is front-loaded and the mode distinction follows immediately. Efficient for the amount of information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-format details are correctly omitted. However, with two undocumented parameters (0% schema coverage) and no annotations, the definition leaves the `root` argument and the read-only nature of the operation unstated, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It adds real meaning for `verify` (re-hashes every file vs trusting metadata), which is more than the schema gives, but the `root` parameter — including its null default — is never explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return') and resource (MIMRY initialization and index freshness for a root), which clearly separates it from mutation siblings like mimry_refresh and mimry_reindex. It doesn't explicitly name which sibling to prefer, but the read/status framing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied — the agent infers this is the tool to check init state and index freshness. The description does give conditional guidance on the `verify` mode (re-hash every file) versus trusting metadata, but offers no when/when-not framing relative to siblings such as mimry_preflight or mimry_validate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search indexed symbols by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| root | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It doesn't state whether search is exact/prefix/fuzzy, whether it respects the optional root scope, whether results are ranked or paginated, or any limits. The 'indexed' qualifier hints at index dependency but nothing is explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single terse sentence with no filler. However, brevity here borders on under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be described. But with 0% param coverage, no annotations, and numerous ambiguous siblings, the description is far too thin to let an agent invoke it confidently or choose it over alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so both parameters ('name', 'root') are undocumented in the schema. The description mentions searching 'by name' but adds nothing about matching semantics, and does not mention the 'root' parameter at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Search indexed symbols by name') but is bare-bones. With siblings like mimry_find, mimry_semantic, mimry_related, and mimry_context, it's unclear how 'search by name' differs from 'find' or other search tools – no differentiation is offered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative guidance is provided. Given many overlapping-looking siblings (mimry_find, mimry_semantic, mimry_related), an agent gets no help choosing this tool over the others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain why a file or symbol ranked for a task query.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| limit | No | ||
| query | Yes | ||
| surface | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not state that this is a read-only inspection, whether it requires a prior index/reindex, whether results are deterministic, or what the explanation contains. 'Explain' implies a read, but nothing is confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no waste, but it is under-specified rather than concise — the brevity costs needed detail instead of trimming filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return-value explanation is not required, but with zero annotation coverage, 0% parameter documentation, and an undefined required 'surface' argument, the definition is not sufficient for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 4 parameters, including the required 'surface' and 'query'. The description loosely maps 'file or symbol' and 'task query' onto two of them, but 'surface', 'root', and 'limit' are left entirely undefined and their formats are unguessable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb ('Explain') and a resource ('why a file or symbol ranked for a task query'), which is more than a tautology, but it never distinguishes itself from close siblings like mimry_explain, mimry_find, or mimry_route. An agent cannot tell from this text alone which of those to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no preconditions, and no mention of alternatives, despite the tool sitting in a cluster of overlapping read/explain siblings. The agent must infer the triggering context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1mimry_briefmimry_contextmimry_digestmimry_explainmimry_feedbackmimry_findmimry_initmimry_list_adaptersmimry_pathmimry_plan_checkmimry_plan_digestmimry_plan_listmimry_plan_treemimry_preflightmimry_refreshmimry_reindexmimry_relatedmimry_routemimry_semanticmimry_statusmimry_symbolmimry_whyScored across 22 tools
Several tools occupy overlapping search/context/ranking territory, including find, semantic, related, symbol, path, why, explain, context, route, brief, and preflight. The descriptions clarify some boundaries, but the set still leaves meaningful ambiguity about which retrieval/explanation tool to choose.
All tools use a consistent mimry_ prefix with lower_snake_case naming. The main variation is noun vs. verb forms such as mimry_status, mimry_find, and mimry_plan_tree, but the convention is still readable and predictable.
The server exposes 22 tools, which is heavy for an MCP surface even considering the indexing, routing, and planning scope. It sits in the borderline-heavy range where consolidation or stronger grouping would improve usability.
The toolset covers index lifecycle, search, semantic retrieval, routing, context generation, explanations, feedback, digests, and plan tree operations. Minor gaps may exist around explicit reset/delete or plan mutation, but core workflows appear well represented.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Project memory, semantic code search, and grounded agent context.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
Search indexed code, trace dependencies, assess change impact, and recall repository memory.