Atlas-brief-mcp is a local/offline MCP server that indexes project documentation and code so agents can locate context efficiently and verify work before marking it done.
Find docs fast: atlas_where returns a section pointer by topic; atlas_search runs BM25 full-text search.
Read selectively: atlas_read fetches one section by anchor with pagination; atlas_outline lists the documentation table of contents.
Inspect relationships: atlas_links shows section tags, cross-references, sibling sections, and linked code files.
Manage tasks and status: atlas_tasks lists Markdown checkboxes; atlas_status lists Work Orders and index freshness.
Build agent briefs: atlas_brief assembles a self-contained task brief with relevant sections, files, tasks, and guardrails.
Find code symbols: atlas_code_find locates definitions/signatures and optional call/reference counts across 9 languages.
Write with verification: atlas_publish and atlas_set_status update Work Order status only after read-back and, for done status, a wiring gate that refuses dead/unwired symbols.
Work with spreadsheets: atlas_sheets lists bound spreadsheets/tabs; atlas_sheet_update updates rows by row_key + column name; atlas_sheet_append adds rows by column mapping.
Lint documentation: atlas_lint checks anchors, headings, oversized sections, Work Order status markers, and broken implements: paths.
Indexes and searches Google Docs through the Docs API, including multiple document tabs. Supports verified append-only writes and tab-scoped status updates, plus spreadsheet read/write tools for Google Sheets.
Project documentation as an index and a wiring gate — not as context fuel.
Why atlas · Measured Benchmarks · 30s Quickstart · Bootstrap (atlas init) · MCP Client Setup · The 15 Tools · Google Docs & Sheets
atlas is a local MCP server for coding agents. Ask "where is the damage model described?" and get back a file, a line, and a section anchor (~60 tokens) — instead of dumping 20,000+ tokens of raw Markdown into the context window.
When the agent finishes a task and tries to mark a work order ✅ DONE, atlas checks the codebase first: if the target function or class is defined with zero callers/references, the checkoff is refused.
┌──────────────┐ ~60 tok ┌──────────────┐ section only ┌─────────────────┐
│ atlas_where │ ─────────────► │ atlas_read │ ───────────────► │ atlas_code_find │
│ (BM25 / FTS5)│ │ (by anchor) │ │ (9 languages) │
└──────────────┘ └──────────────┘ └────────┬────────┘
│
┌───────────────────────────────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ atlas_publish / atlas_set_status (Wiring Gate) │
│ ├─ callers > 0 ──► Write ✅ DONE + verify read-back │
│ └─ callers == 0 ──► REFUSE write ("defined, 0 callers") │
└──────────────────────────────────────────────────────────┘Works 100% offline with any folder of Markdown (docs/, specs/, adr/, gdd/) — plus optional live sync for multi-tab Google Docs and Google Sheets.
atlas Exists)atlas exists because of a specific production failure. An agent implemented 1,070 lines, forgot the single dispatcher call that made them reachable, and reported "done". The next cleanup run saw an unused-function warning and deleted all of it — the lines were never committed, so nothing could be recovered. Nobody had asked the question atlas now asks before every checkoff: is this actually wired up?
That failure has a shape, and atlas answers it with a hard refusal instead of a warning nobody reads:
{
"written": false,
"refused": true,
"refusal": "Acceptance refused — wiring check failed:\n ✗ '_dispatch_unit_class_skill' is defined in scripts/turn_manager.gd:3774 but never called or bound (0 calls, 0 references)\n\nA ✅ without a caller documents an intention, not a result."
}That check runs before any network or filesystem write, so it costs nothing when it blocks. It has caught this exact class of mistake twice in real use.
Related MCP server: docs-mcp
All numbers below were measured with atlas measure on a real production project (5-tab specification document, 124 sections, 218 source files) — no synthetic estimates:
Task | Naive File Read ( | With | Token Reduction |
Answer one doc question ( | 20,364 tokens | 875 tokens | −96% |
Locate 8 code symbols & callers ( | 291,447 tokens | 3,106 tokens | −99% |
Inspect one symbol in a monolith file | 74,522 tokens | 388 tokens | −99% |
8-question benchmark run ( | 224,088 tokens | 5,945 tokens | −97% |
atlas compares to other approachesCapability | Raw File Reads ( | Read-Only Doc Indexers |
|
Granularity | Full files (10k–70k tokens) | Section snippets (~300–1,000 tokens) | ~60-token pointers ( |
Search Engine | Linear grep | Embeddings or basic FTS | Local SQLite FTS5 (BM25) + EN/DE compound & umlaut folding |
Code Symbol & Caller Lookup | Manual grep across repo | ❌ None | ✅ |
Dead-Code Wiring Gate | ❌ Trusts agent self-report | ❌ Read-only | ✅ Refuses |
Task & Work-Order State | Lost when chat ends | ❌ None | ✅ |
Cloud & Privacy | Local | Varies (often cloud embeddings) | 100% local & offline (optional Google Docs/Sheets OAuth) |
Every new agent session starts blind. It re-reads the repository, re-discovers where things live, re-derives what the current state is — and when the context window fills up, the next session starts over. The map lives in the conversation, and conversations are disposable.
atlas moves the map next to the code:
atlas_where answers "where is this documented?" in one call — for any fresh chat.
atlas_status says which work orders are done, so the checklist survives the session.
atlas init writes the architecture down once instead of re-deriving it every week.
atlas_set_status records the outcome in the document, not in the transcript.
You can close a chat mid-task and open a new one. The next session asks three questions and is up to speed in three tool calls, without reading a single file end to end.
What it does not know is what you discussed. A decision that was never written down is gone — which is the same rule as before, just applied to conversations: if it matters, it belongs in the document.
Requires Python 3.10+ and uv (or pipx). No Google account, no API key, and no network access required.
# Recommended (installs `atlas` globally in an isolated environment)
uv tool install atlas-brief-mcp
# Or with pipx / pip
pipx install atlas-brief-mcp
pip install atlas-brief-mcp
# Or run directly without installing via uvx
uvx --from atlas-brief-mcp atlas --helpPATH note: If
atlasis not found afteruv tool install, runuv tool update-shellonce (or add~/.local/bin/%USERPROFILE%\.local\binto yourPATH).
atlas --root examples/demo doctor
atlas --root examples/demo where "Where is the damage model?"
atlas --root examples/demo brief "damage calculation"Any folder of .md files works — docs/, specs/, atlas/, gdd/. The index lives in <root>/.atlas/index.sqlite, can be regenerated at any time, and your Markdown stays the source of truth.
cd your-project
atlas initScans the repository — no LLM, no network, under 0.3 seconds for 50 files — and generates docs/ARCHITECTURE.md containing:
Domains: every source folder with files, line counts, token estimates, and the largest functions per domain (not the first ones — those are getters).
Context hotspots: files over 10,000 tokens that should never be read whole.
Unwired symbols: functions over 15 lines whose name appears nowhere else — candidates for "implemented but never connected".
It also writes AGENTS.md, .antigravityrules, .mcp.json, and adds .atlas/ to .gitignore — but only if they don't already exist. atlas init never overwrites your rules.
atlas init --dry-run # Preview what would be created, write nothing
atlas init --out docs/ARCH.md # Custom output path
atlas init --force # Regenerate deliberatelyinit records what it created in .atlas/managed.json. atlas lint uses that to separate managed documents (must be clean, exit code 1) from discovered legacy docs (reported as hints, exit code 0).
GDScript & Godot Scenes (.gd, .tscn)
Python (.py)
TypeScript / JavaScript (.ts, .tsx, .js, .jsx — including React.memo(...) and forwardRef<...>(...) wrappers)
Rust (.rs)
C# (.cs)
Go (.go)
Java & Kotlin (.java, .kt)
Swift (.swift)
Test functions (test_*, Test*, *_test) and framework-bound functions (@decorator, @mcp.tool()) are automatically excluded from unwired warnings.
atlas init creates docs/ARCHITECTURE.md with Work Order 1 — ⬜ OPEN. If no Google document is bound to the project, atlas writes straight into that local Markdown file — with the same contract, read-back verification, and .atlas/mutations.log audit trail:
atlas set-status --wo 1 --status done --verify-symbols my_func # ⬜ OPEN -> ✅ DONE + records symbol
atlas set-status --task "Balance damage" --status done # - [ ] -> - [x] in Markdown
atlas status # Reads the verified state
atlas check # CI / pre-commit regression guardThe server speaks standard MCP over stdio. Because ATLAS_ROOT=. resolves relative to the client's working directory, one installation serves every project.
uvx (Claude Code / Cursor / Windsurf / Antigravity)Runs directly from PyPI without pre-installing:
{
"mcpServers": {
"atlas": {
"command": "uvx",
"args": ["--from", "atlas-brief-mcp", "atlas", "serve"],
"env": { "ATLAS_ROOT": "." }
}
}
}.mcp.json / ~/.gemini/config/mcp_config.json)If you installed atlas via uv tool install atlas-brief-mcp (or let atlas init create .mcp.json):
{
"mcpServers": {
"atlas": {
"command": "atlas",
"args": ["serve"],
"env": { "ATLAS_ROOT": "." }
}
}
}claude_desktop_config.json)Same block as above. On Windows, use "command": "atlas.exe" if the bare command name is not resolved.
Built-in Agent Guardrails: On connect,
atlasdelivers its own MCPinstructionstelling the agent to route documentation lookups throughatlas_where→atlas_readinstead ofRead/Grep, and to callatlas_set_status/atlas_publishonly after tests pass.
Category | Tool | Purpose |
Read & Search |
| Fast topic → file, line, heading & section anchor (~60 tokens) |
Read & Search |
| Full-text BM25 search across all sections (EN + DE stop words & umlaut folding) |
Read & Search |
| Read a single section by anchor ( |
Read & Search |
| Full table of contents across all indexed documents (or one |
Read & Search |
| Section cross-references, tags, sibling sections, and linked |
Workflow & Briefs |
| Build a self-contained subagent task brief (sections + affected files + guardrails) |
Workflow & Briefs |
| List open/done Markdown checkbox tasks ( |
Workflow & Briefs |
| List all Work Orders ( |
Code & Wiring |
| Locate symbol definitions, signatures, and call/reference counts across 9 languages |
Verified Writes |
| Append a verified Work Order status block — blocks on |
Verified Writes |
| Flip an existing Work Order status marker in-place — with the same wiring gate |
Spreadsheets |
| List indexed spreadsheet tabs, headers, and row keys |
Spreadsheets |
| Update balancing cells by |
Spreadsheets |
| Append new rows by column name mapping |
Diagnostics |
| Check docs for duplicate anchors, oversized sections, and broken |
If your team's living documentation or balancing tables live in Google Docs and Sheets, atlas indexes and updates them through the official Google APIs — including multi-tab documents:
atlas auth # One-time OAuth consent in the browser
atlas sync --query MYPROJECT # Pull documents & sheets into the local cache
atlas status
atlas publish --wo 7 --title "Mission 1" --desc "Rooms 1-9"Three engineering details that prevent common agent accidents:
Export to read, query directly to judge: The search index is built from Drive exports, but post-write verification queries documents.get directly — because the Docs API is consistent immediately after batchUpdate while Drive export caches lag by 0.5–2 seconds.
Append-only with revision lock: requiredRevisionId prevents a write from landing on a stale document revision, and an idempotency guard prevents duplicate status headers when a work order already exists in the live doc.
Tab-scoped status updates: replaceAllText uses tabsCriteria so status changes only affect the active tab, never archive tabs.
You don't have to take our benchmark numbers on faith — run the exact same measurement on your own repository:
cd your-project
atlas init # Or point at existing docs
atlas measure # Compares naive full-doc read vs. atlas index per questionDocuments: 4 · naive baseline: 28,011 tokens per question
Question naive atlas saved
------------------------------------------------------------------------
Where is 7.6 Built engine features described? 28,011 885 97%
Where is 01_Units_Stats described? 28,011 689 98%
...
------------------------------------------------------------------------
Total 224,088 5,945 97%By default, questions are derived from your section headings (which is optimistic because the question shares words with the heading — atlas measure explicitly notes this). For an independent benchmark, pass your own question list:
atlas measure --questions my-questions.txt # One question per lineatlas Is NotNot a prose editor: It writes verified status markers and spreadsheet rows/cells, not design prose.
Not a web crawler: It indexes the documentation folders in your repository (and optional bound Google Docs).
Not a test replacement: The wiring gate verifies that a symbol is defined and referenced/called — not that its logic is bug-free.
uv run pytest -q # 209 unit & integration tests (offline)
uv run python scripts/smoke_mcp.py --root examples/demo # End-to-end JSON-RPC MCP smoke testAll 209 tests run completely offline. Every Google Docs & Sheets interaction is tested against deterministic fakes — including edge cases where the API swallows a write or lags on export.
MIT — see LICENSE.
Assemble a self-contained Markdown task brief for a coding agent or subagent.
Use this tool before starting or delegating a feature task. It bundles the top matching spec
sections (with stable anchors), linked source file paths, open tasks, project guardrails, and
the verified checkoff command so the subagent does not need to search from scratch.
Behavior & Output:
- Read-only aggregation of indexed documentation sections and code metadata.
- Returns a formatted Markdown brief string ready to paste into a subagent prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | One-sentence description of the task to prepare a brief for (e.g. 'wire the dwarf vault-charger perk into turn_manager'). | |
| files | No | Optional list of relative source file paths to include alongside auto-detected `implements` files (e.g. ['scripts/unit.gd', 'src/combat.py']). | |
| work_order | No | Optional Work Order number (e.g. 7). When provided, the brief includes the exact `atlas_publish` / `atlas_set_status` closing command for that Work Order. | |
| max_sections | No | Maximum number of relevant documentation sections to embed in the brief (1-20, default 5). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, it explains that the tool performs read-only aggregation of indexed documentation and code metadata and returns a formatted Markdown string ready to paste into a prompt. That adds useful behavioral context, though it does not discuss limitations or edge cases.
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 front-loaded with the core purpose, followed by usage and behavior/output sections. Every sentence adds useful context without unnecessary repetition.
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 the tool has an output schema and full schema coverage, the description provides enough context: what gets bundled, when to use it, and what the output is. Nothing essential for correct invocation appears missing.
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 100%, so the schema already documents all four parameters thoroughly. The description does not add parameter-specific meaning beyond what the schema provides, which is the expected baseline.
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: 'Assemble a self-contained Markdown task brief for a coding agent or subagent.' It also clarifies the aggregation scope (spec sections, source paths, open tasks, guardrails, checkoff command), making it distinct from search/read 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?
It gives clear timing guidance: 'Use this tool before starting or delegating a feature task,' and implies the alternative is searching from scratch. It stops short of explicit when-not-to-use conditions or naming sibling tools directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate function or class definitions across the codebase (file, line, signature) and optionally inspect call sites.
Use this tool BEFORE reading source files to find where a symbol lives (~30 tokens per signature vs.
thousands of tokens for a full file) or set `usage=True` to check if a symbol is actually called before
marking a task done. Supports GDScript (`.gd`/`.tscn`), Python, TypeScript/JavaScript, Rust, C#, Go,
Java, Kotlin, and Swift.
Behavior & Output:
- Read-only static scan of project source files; ignores build directories and `.atlas/`.
- Returns a formatted summary of matching definitions (`path:line — signature`) and, when `usage=True`,
the caller/reference count and file:line call sites for each symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of matching symbol definitions to return (1-100, default 10). | |
| usage | No | If true, also scan the repository for call sites and references to each matched symbol (including Godot `.tscn` signal bindings) to verify whether the symbol is wired up (default false). | |
| symbol | Yes | Function, method, or class name (or substring) to search for across the codebase (e.g. 'apply_damage' or 'TurnManager'). Does not match local variables. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real value on top: static scan scope, exclusion of build directories and .atlas/, supported languages, and the shape of returned results. It stops short of noting limits on accuracy or behavior for unresolved/dynamic symbols.
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?
Front-loaded with purpose in the first line, then usage rationale, then a labelled 'Behavior & Output' block. Slightly verbose in the token-cost aside, but every section carries information an agent needs.
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?
Covers purpose, when to use, language support, scan exclusions, and output format, and an output schema exists for return details. Nothing material is missing for a read-only lookup tool with three well-documented parameters.
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 coverage is 100%, so the baseline is 3; the description earns above that by explaining what usage=True actually does (call-site/reference scanning, including Godot .tscn signal bindings) and by justifying its purpose in the workflow. The limit parameter is left entirely to the schema.
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 ('Locate function or class definitions across the codebase') plus the returned fields (file, line, signature) and an optional mode. This clearly separates it from siblings like atlas_read (file contents) and atlas_search (text search).
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?
Gives explicit when-to-use guidance: call it BEFORE reading source files, with a token-cost rationale, and set usage=True to verify call sites before marking a task done. It never names a specific sibling tool as the alternative (e.g. atlas_search or atlas_read), so routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a documentation section's relationships: linked source files (implements), tags, cross-references, and sibling sections.
Use this tool to answer 'which code files implement this spec section?' or 'what other sections
reference or belong to the same document as this anchor?'.
Behavior & Output:
- Read-only lookup against the local section graph and frontmatter metadata (`implements`, `tags`).
- Returns a JSON string `{anchor, heading, path, implements: [...], tags: [...], outgoing_links: [...], incoming_links: [...], siblings: [...]}`
or `{error}` if the anchor is unknown.
| Name | Required | Description | Default |
|---|---|---|---|
| anchor | Yes | Section anchor identifier in `<doc_id>#<section-slug>` or `<doc_id>` format (e.g. 'combat#damage-model'), as returned by `atlas_where`, `atlas_search`, or `atlas_outline`. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description goes further by naming the data sources (local section graph plus frontmatter metadata) and the failure mode (`{error}` when the anchor is unknown). The listed return shape is partly redundant with the existing output schema, which caps it below 5.
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?
Purpose is front-loaded in one sentence, then a labelled 'Behavior & Output' block. Every line carries information — sources, return fields, error case — with no filler or restatement of the name.
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 single-parameter read-only lookup with a rich annotation set and a declared output schema, nothing an agent needs is missing: purpose, invocation guidance, data provenance, return shape, and error behavior are all covered.
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 coverage is 100%, so the anchor format and its provenance (atlas_where/atlas_search/atlas_outline) are already documented. The description still adds meaning by disclosing what happens with an invalid anchor — a `{error}` payload — which tells the agent how to interpret results and recover from a bad identifier.
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 ('Inspect') and resource ('a documentation section's relationships'), then enumerates exactly which relations are covered: `implements`, tags, cross-references, siblings. An agent can distinguish this from atlas_read (content) or atlas_search (discovery) without opening any schema.
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?
Frames two concrete question patterns the tool answers ('which code files implement this spec section?', 'what other sections reference or belong to the same document?'), which is a strong usage signal. It does not explicitly name alternatives such as atlas_read or atlas_code_find, so the boundary is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit indexed documentation for structural and formatting problems that degrade retrieval quality.
Takes no parameters. Checks managed documentation for duplicate section anchors, empty headings,
oversized sections (>8,000 chars), Work Orders missing a status marker (`⬜`/`🚧`/`✅`), and broken
`implements:` code file paths. Use this tool after editing documentation or running `atlas init`.
Behavior & Output:
- Read-only structural check; respects `.atlas/managed.json` (separating managed docs from legacy discovered docs).
- Returns a JSON string `{managed_issues: [...], discovered_hints: [...], clean: bool}` detailing each issue by file and line.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, closed-world, and non-destructive, so the description is not the sole carrier of safety information. It still adds real behavior beyond them: it clarifies that the check respects `.atlas/managed.json`, distinguishes managed docs from legacy discovered docs, and that legacy findings surface only as hints. The explicit thresholds (e.g. >8,000 chars) and required status markers are useful operational detail.
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?
Front-loaded purpose sentence, then a compact checklist of checks, then a labeled 'Behavior & Output' block — an easy scan for an agent. The return-shape line partially restates the output schema, which is a small redundancy rather than a structural flaw.
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 zero-parameter, read-only audit tool, everything needed to invoke and interpret it is present: trigger conditions, the exact defect categories, the managed-vs-discovered distinction, and the response keys. No required behavior or interpretation guidance is missing.
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 tool takes zero parameters, which is the baseline-4 case; 'Takes no parameters' merely confirms the empty schema. There is no parameter meaning left to add, so no deficiency exists here.
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?
Names a specific verb ('Audit') and resource ('indexed documentation'), and enumerates the concrete defect classes it detects (duplicate anchors, empty headings, oversized sections, missing status markers, broken `implements:` paths). That specificity separates it cleanly from siblings like atlas_read, atlas_outline, and atlas_links, which inspect content rather than structural health.
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?
Gives an explicit trigger: 'Use this tool after editing documentation or running `atlas init`.' That is a clear when-to-use signal. It stops short of naming a discriminating alternative or stating when-not to run it (e.g. that atlas_links covers link inspection more deeply), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the hierarchical table of contents (headings and section anchors) across indexed documentation.
Use this tool when exploring an unfamiliar project structure, browsing available documents,
or when keyword searches (`atlas_where` / `atlas_search`) did not match your query terms.
Behavior & Output:
- Read-only, side-effect-free query of indexed document headings.
- Returns a JSON string `{doc, outline, truncated}` where `outline` lists each heading level,
title, and `anchor` ready for `atlas_read`.
| Name | Required | Description | Default |
|---|---|---|---|
| doc | No | Optional document ID (e.g. '02-combat' or 'architecture') to list headings for a single document. Omit or pass null to list the table of contents for all documents. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, but the description still adds value by describing the return envelope {doc, outline, truncated} and that anchors are directly usable with atlas_read. It stops short of explaining when 'truncated' becomes true or how to handle it, which is the main remaining 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?
Front-loaded purpose followed by usage and output sections; the structure is easy to scan. The 'Read-only, side-effect-free' bullet partially restates annotations and could be trimmed, but overall wording earns its place.
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?
Covers what the tool returns, how to use anchors downstream, and when to prefer it, which is more than sufficient for a single-optional-param read tool with an output schema. The unexplained truncation semantics are the only notable omission.
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 coverage is 100% with a thorough 'doc' description including example IDs and the null/omit behavior, so the schema does the heavy lifting. The description adds nothing about the single parameter, making the baseline 3 correct.
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 the hierarchical table of contents (headings and section anchors) across indexed documentation') and scopes it to indexed docs, which separates it from retrieval siblings like atlas_read and atlas_search.
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?
Explicitly names three situations (unfamiliar project structure, browsing available docs, keyword searches via atlas_where/atlas_search that failed) and names the alternative tools, so an agent can decide between outline and search without opening schemas.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a new Work Order status entry to the documentation — gated by a code-wiring check and verified by read-back.
Use this tool as the FINAL step after tests pass to record a new Work Order in the bound Google Doc
or local managed Markdown file (`docs/ARCHITECTURE.md`). If the Work Order heading already exists and
you only need to flip `⬜ OPEN` to `✅ DONE`, use `atlas_set_status` instead.
Behavior & Output:
- Pre-write wiring gate: when `status='done'`, verifies that every symbol in `verify_symbols` (and
`.atlas/wo-symbols.yml`) is both defined and referenced/called (`calls + references > 0`). If any
symbol is dead code, returns `{written: false, refused: true, refusal: "..."}` without touching disk/network.
- Atomic verified write: appends the formatted status line, reads the document back to confirm presence,
logs to `.atlas/mutations.log`, and returns `{written: true, verified: true, wo, line}`.
| Name | Required | Description | Default |
|---|---|---|---|
| wo | Yes | Work Order number (positive integer, e.g. 7 for 'Work Order 7'). | |
| title | Yes | Short title of the Work Order (e.g. 'Critical Hit Calculation'). | |
| status | No | Target Work Order status: 'done' (writes `✅ DONE`, default) or 'open' (writes `⬜ OPEN`). | done |
| description | No | Optional summary of what was implemented and which files were touched. | |
| verify_symbols | No | List of function or class names built in this Work Order (e.g. ['apply_crit_bonus']). When `status='done'`, each symbol is checked before writing: if any symbol is undefined or has 0 callers/references across the codebase, the write is refused. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/openWorld/idempotent/destructive hints; the description goes well beyond them by disclosing the pre-write wiring gate, the dead-code refusal condition with its exact return shape, the read-back verification, and the `.atlas/mutations.log` side effect. The refusal is described as happening 'without touching disk/network', which materially informs error handling.
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?
Front-loaded with the purpose and alternative, then cleanly sectioned into 'Behavior & Output' with bulleted return contracts. Slightly verbose, but each sentence carries operational information rather than restating the name or schema.
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?
Despite an output schema existing, the description still documents both success and refusal return shapes, and covers the mutation side effects an agent needs. For a write tool with a pre-flight gate, nothing material is missing.
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 coverage is 100%, so the baseline is 3, but the description adds real meaning: `verify_symbols` is checked only when `status='done'`, is augmented by `.atlas/wo-symbols.yml`, and requires both definition and at least one call/reference. That conditional gating semantics is not derivable from the schema alone.
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 ('Append a new Work Order status entry to the documentation') plus the gating and verification that define it. It explicitly names the sibling `atlas_set_status` and the condition that separates the two, so an agent can route correctly without opening either schema.
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?
Gives an explicit lifecycle position ('FINAL step after tests pass') and an explicit exclusion with the alternative ('if the heading already exists and you only need to flip ⬜ OPEN to ✅ DONE, use atlas_set_status instead'). Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the Markdown content of a single documentation section by its anchor with character-budget pagination.
Use this tool after obtaining an `anchor` from `atlas_where`, `atlas_search`, or `atlas_outline`.
Never read raw documentation files from disk when `atlas_read` can fetch the exact section.
Behavior & Output:
- Read-only lookup from the local documentation index.
- Returns a JSON string `{anchor, heading, path, lines, content, truncated, next_offset}`.
If the anchor does not exist, returns `{error, suggestions}` with the closest valid anchors.
| Name | Required | Description | Default |
|---|---|---|---|
| anchor | Yes | Section anchor identifier in `<doc_id>#<section-slug>` format (or `<doc_id>` for the document root), as returned by `atlas_where`, `atlas_search`, or `atlas_outline` (e.g. 'combat#damage-model'). | |
| offset | No | Character offset to start reading from (default 0). When a previous call returned `truncated: true`, pass its `next_offset` value here to read the next page. | |
| max_chars | No | Maximum number of characters to return in one call (default 3000). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered structurally. The description adds genuinely useful behavior the annotations cannot express: the read is from a local index, the success payload carries `truncated`/`next_offset` for pagination chaining, and a missing anchor yields `{error, suggestions}` rather than a bare failure. Minor redundancy is recounting the return keys, which the output schema already supplies.
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?
It is front-loaded with the core action, follows with a routing rule, then a short labeled behavior block. Every line carries information an agent needs: there are no filler adjectives or repetition of the title.
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 fully explained, yet the description still covers the error path and pagination continuation, the two cases an agent must handle. For a three-parameter read tool, nothing material is left unspecified.
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 coverage is 100%, so the schema already defines anchor, offset and max_chars in detail, which sets the baseline at 3. The description adds meaning beyond it by framing max_chars as a character budget and describing the offset/next_offset handoff across calls, though it does not restate the anchor's `<doc_id>#<section-slug>` format, which only the schema carries.
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 opens with a specific verb+resource: 'Read the Markdown content of a single documentation section by its anchor', and immediately scopes it with 'single' and 'character-budget pagination'. That distinguishes it cleanly from atlas_search (discovery), atlas_outline (structure), and atlas_where (locating anchors) without requiring the agent to open any other schema.
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?
It states the precondition explicitly ('Use this tool after obtaining an anchor from atlas_where, atlas_search, or atlas_outline') and adds a negative guideline ('Never read raw documentation files from disk when atlas_read can fetch the exact section'). Both the when and the when-not are present, which is rare and directly actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a BM25 full-text search across documentation sections and return ranked snippets with anchors.
Use this tool for broad or multi-section topics ('where all is armor mentioned?') or when
`atlas_where` returns no single match. Pass a returned `anchor` to `atlas_read` to inspect the full section.
Behavior & Output:
- Read-only lexical search via SQLite FTS5 (no embeddings; project synonyms come from `.atlas/aliases.yml`).
- Returns a JSON string `{query, count, hits: [{anchor, title, path, line, snippet, score}]}`.
Returns `count: 0` and an empty `hits` list if nothing matches.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Maximum number of ranked section hits to return (1-50, default 5). | |
| doc | No | Optional document ID (e.g. 'combat' or '02-combat') to restrict the search to a single document. Omit or pass null to search all documents. | |
| query | Yes | Keywords or phrase to search across all indexed documentation sections (e.g. 'cover reduction', 'turn order'). Uses lexical FTS5 matching with umlaut folding ('Hoehe' matches 'Höhe') and German compound splitting. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds real substance beyond them: the search is lexical FTS5 with no embeddings, synonyms come from `.atlas/aliases.yml`, and the zero-result case returns `count: 0` with an empty hits list. That tells an agent both the retrieval model and how to interpret an empty response.
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?
Front-loaded with the action, then usage, then a labeled 'Behavior & Output' block — easy to scan with no filler. The output-shape sentence is somewhat redundant given an output schema exists, which keeps it from a perfect score.
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?
Covers mechanism, selection criteria, sibling routing, alias configuration, and empty-result semantics for a three-parameter read tool. Nothing an agent needs before calling it or after receiving hits is missing.
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 coverage is 100%, so `k`, `doc`, and `query` are already fully documented including ranges, defaults, and the umlaut-folding/compound-splitting note. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.
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 mechanism and resource: a BM25 full-text search across documentation sections returning ranked snippets with anchors. The example query and the boundary against `atlas_where` make it instantly distinguishable from 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?
Explicit when-to-use ('broad or multi-section topics'), an explicit fallback condition ('when `atlas_where` returns no single match'), and an explicit next step ('pass a returned anchor to `atlas_read`'). The routing to two sibling tools is fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flip the status marker of an existing Work Order (⬜ OPEN <-> ✅ DONE) or Markdown checkbox task (- [ ] <-> - [x]).
Use this tool as the final step when completing an existing open Work Order (`wo=N`) or a checkbox
task from `atlas_tasks` (`task='...'`). To append a brand-new Work Order entry that is not yet in the
document, use `atlas_publish` instead.
Behavior & Output:
- Pre-write wiring gate: when `status='done'`, checks that all symbols in `verify_symbols` (and
`.atlas/wo-symbols.yml`) are defined and have at least one caller/reference. Refuses with
`{changed: false, refused: true, refusal: "..."}` if any symbol is unwired.
- Verified in-place update: updates the status marker or checkbox in the local Markdown file (or active
Google Doc tab for Work Orders), verifies by reading back, and returns JSON `{changed, verified, status}`.
| Name | Required | Description | Default |
|---|---|---|---|
| wo | No | Existing Work Order number to update (positive integer, e.g. 8 for 'Work Order 8'). Provide either `wo` or `task`. | |
| task | No | Substring identifying a Markdown checkbox item (`- [ ] ...`) to toggle between `- [ ]` ('open') and `- [x]` ('done') when `wo` is omitted (e.g. 'Balance damage formula'). | |
| status | No | New status: 'done' (`✅ DONE` / `- [x]`, default) or 'open' (`⬜ OPEN` / `- [ ]`). | done |
| verify_symbols | No | Optional list of function or class names that must be defined and called/referenced in the codebase before `status='done'` is allowed. Merged with `.atlas/wo-symbols.yml`. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic profile (not read-only, idempotent, non-destructive), while the description adds non-obvious behavior: a pre-write wiring gate triggered on `status='done'`, the exact refusal payload `{changed: false, refused: true, refusal: "..."}`, and a read-back verification step. It also discloses the `verify_symbols` merge with `.atlas/wo-symbols.yml`, which no structured field conveys.
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?
Front-loaded purpose sentence followed by clearly labeled usage and behavior blocks; no filler. Minor redundancy in restating the return shape `{changed, verified, status}` when a separate output schema already exists.
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 four-parameter tool with full schema coverage and an output schema, the description covers the remaining unknowns: gating preconditions, failure mode, verification, and file/tab targeting. An agent has everything needed to call it correctly or recognize a refusal.
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 coverage is 100%, so baseline is 3, but the description adds real meaning: that `verify_symbols` is only enforced when `status='done'` and is merged with `.atlas/wo-symbols.yml`, and that `wo` and `task` are alternative selectors. It stops short of explaining matching semantics for `task` substring ambiguity (what happens on multiple matches).
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 concrete verb and resource: flipping the status marker of an existing Work Order (`⬜ OPEN` <-> `✅ DONE`) or a Markdown checkbox task, with the literal markers shown. It also explicitly distinguishes itself from `atlas_publish`, so an agent can separate it from the closest sibling without opening either schema.
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?
Gives an explicit when-to-use rule ("final step when completing an existing open Work Order (`wo=N`) or a checkbox task from `atlas_tasks`") plus an explicit when-not rule routing new entries to `atlas_publish`. The `wo` vs `task` selector is also spelled out, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a new row to a spreadsheet tab by mapping column header names to values.
Use this tool when adding a new entry (e.g. a new unit, item, or parameter row) to a bound spreadsheet.
To modify cells of an existing row, use `atlas_sheet_update` instead.
Behavior & Output:
- Not idempotent: each non-dry-run call appends a new row at the bottom of the table and verifies it by read-back.
- Validates all keys in `values` against the tab's header row before writing.
- Returns JSON `{ok, sheet, tab, values, range, verified, resynced, dry_run}` and updates the local search index.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | Yes | Exact worksheet/tab name inside the spreadsheet (e.g. 'Units'). Use `atlas_sheets` to discover valid tab names. | |
| sheet | No | Optional spreadsheet name or ID when multiple spreadsheets are bound to the project. | |
| values | Yes | Mapping of `{column_header_name: value}` for the new row (e.g. `{"ID": "monster_goblin", "Name": "Goblin", "HP": 100}`). Omitted columns are left empty. | |
| dry_run | No | If true, validate column headers and preview the row without writing to the spreadsheet (default false). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes beyond the annotations by disclosing that keys are validated against the tab's header row before writing, that each append is verified by read-back, and that the local search index is updated — none of which the annotations convey. The non-idempotency claim duplicates `idempotentHint: false`, though it usefully explains the consequence (a new row at the bottom per call).
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?
Front-loaded purpose sentence, then a usage sentence with the alternative, then a compact labeled behavior section — easy to scan and every line is substantive. The explicit return-key list is mildly redundant given that an output schema exists, but it earns partial credit by naming the meaningful flags (`verified`, `resynced`).
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 4-parameter mutation tool with full schema coverage, rich annotations, and an output schema, the description covers purpose, selection criteria, validation constraints, side effects (index update), and safety via dry-run. No gap remains that would cause a misinvocation.
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 coverage is already 100%, so the 3 baseline is met; the description adds a real constraint not stated in the schema — that `values` keys are validated against the tab's header row before writing, which tells the agent keys must be exact header names. It also reinforces the header-name mapping model with a concrete conceptual example.
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 (append a new row to a spreadsheet tab) plus the mechanism (mapping column header names to values). It explicitly contrasts with the sibling `atlas_sheet_update`, so an agent can distinguish the two without opening either schema.
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?
Gives an explicit when-to-use condition (adding a new entry such as a unit, item, or parameter row to a bound spreadsheet) and an explicit when-not with a named alternative (`atlas_sheet_update` for modifying existing rows). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all spreadsheets bound to the project along with their worksheet tab names.
Takes no parameters. Call this tool before `atlas_sheet_update` or `atlas_sheet_append`
whenever you need to discover the exact `sheet` name/ID or valid `tab` names.
Behavior & Output:
- Read-only metadata lookup; returns spreadsheet and tab names without dumping cell contents.
- Returns JSON `{spreadsheets: [{name, id, tabs: [...]}]}` or `{spreadsheets: [], hint: "..."}`
when no spreadsheet has been synced yet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value beyond them by clarifying it is a metadata-only lookup that does not dump cell contents, and by describing the empty-state response with a hint string. It does not discuss scoping (which project) or sync freshness beyond the 'not yet synced' case.
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?
Front-loaded purpose sentence, then a routing instruction, then a labeled 'Behavior & Output' block. Every line carries information; nothing is padding.
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 zero-parameter read tool with rich annotations and an output schema, the description covers purpose, preconditions, read-only semantics and the empty-state case. An agent has everything needed to call it correctly and interpret the result.
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?
Zero parameters, so the schema baseline of 4 applies. The description reinforces this with 'Takes no parameters', leaving no room for the agent to invent arguments.
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 concrete verb and resource: lists spreadsheets bound to the project plus their worksheet tab names. Combined with the pre-call routing to atlas_sheet_update/atlas_sheet_append, an agent can distinguish it from sibling lookup tools like atlas_where or atlas_outline without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this before atlas_sheet_update or atlas_sheet_append whenever the exact sheet name/ID or valid tab names are unknown, naming both alternatives and the selecting condition. Also states it takes no parameters, removing any setup ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update specific cells of an existing spreadsheet row by row_key and column header name (never by cell coordinate).
Use this tool to modify balancing values, implementation markers, or metadata in an existing row.
To add a brand-new row to a tab, use `atlas_sheet_append`. If unsure of tab names, call `atlas_sheets` first.
Behavior & Output:
- Resolves the exact cell range from `row_key` + header names, preventing off-by-one row overwrites.
- If a column name is unknown, aborts without writing and returns the list of valid column headers.
- Returns JSON `{ok, sheet, tab, row, key, changes, verified, resynced, dry_run}` and refreshes the local search index.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | Yes | Exact worksheet/tab name inside the spreadsheet (e.g. 'Units' or 'Weapons'). Use `atlas_sheets` to list valid tabs. | |
| sheet | No | Optional spreadsheet name or ID when multiple spreadsheets are registered. Omit if only one spreadsheet exists. | |
| dry_run | No | If true, compute and return the cell diff without writing changes to the spreadsheet (default false). | |
| row_key | Yes | Primary key value identifying the target row in the key column (e.g. 'monster_goblin'). | |
| updates | Yes | Mapping of `{column_header_name: new_value}` for the cells to update in that row (e.g. `{"HP": 45, "Status": "✅"}`). Never pass raw cell coordinates like 'C14'. | |
| key_column | No | Optional header name of the key column used to match `row_key`. Defaults to the first column of the tab. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: it resolves the cell range from key + header, aborts without writing and returns the valid header list when a column name is unknown, and refreshes the local search index. The annotations only declare non-readonly, non-destructive, idempotent; the description supplies the actual failure mode and side effects an agent needs.
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?
Front-loaded with the core action and address model, then a scannable "Behavior & Output" block; every line carries information. The literal return-JSON enumeration is mildly redundant given an output schema exists, which keeps it off a 5.
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 six-parameter nested-object mutation tool with full schema coverage and a declared output schema, the description covers intent, addressing model, failure behavior, side effects, and routing to siblings. Nothing an agent needs to invoke it correctly is missing.
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 100%, so all six parameters are already documented in the schema, including the header-name mapping and the `dry_run` diff behavior. The description reinforces the key-vs-coordinate addressing constraint but adds no syntax or format detail the schema lacks; baseline 3 applies.
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 ("Update specific cells of an existing spreadsheet row") plus the exact addressing model (by `row_key` and column header name, never by cell coordinate). This is enough to distinguish it from `atlas_sheet_append` without opening either schema.
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?
Gives concrete when-to-use cases (balancing values, implementation markers, metadata), names the sibling to use for a different intent (`atlas_sheet_append` for brand-new rows), and prescribes a prerequisite call (`atlas_sheets`) when tab names are unknown. No alternative is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the complete list of documented Work Orders (⬜ OPEN, 🚧 IN PROGRESS, ✅ DONE) and index freshness.
Takes no parameters. Use this tool first when asked about project progress, completed milestones,
or which Work Order is next — one call returns the authoritative list without reading documentation files.
For granular Markdown checkboxes (`- [ ]`), use `atlas_tasks` instead.
Behavior & Output:
- Read-only query over all Work Order headings/entries in the index (up to 60 orders).
- Returns a human- and agent-readable summary starting with the index freshness timestamp,
total counts (`done` / `open`), and one line per Work Order (`WO # — status — title (anchor)`).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the description doesn't need to re-litigate safety. It adds real context beyond them: the operation is a read-only index query capped at up to 60 orders, and the output begins with an index freshness timestamp that signals possible staleness.
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?
Front-loaded with the core purpose, then when-to-use, then a labeled 'Behavior & Output' block — a clean structure. Slightly long for a zero-parameter tool, and the status emoji list is mildly redundant with the status names, but every section carries usable 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?
Complete enough to call correctly: it covers trigger conditions, the sibling boundary, the 60-order cap, and the return shape. The one gap is that the description explains the output format even though a formal output schema exists, which is mild duplication rather than a missing piece.
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 tool takes zero parameters, so the baseline is 4; the description confirms 'Takes no parameters', which prevents an agent from searching for filters. Nothing further is needed since there is no schema surface to explain.
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 the complete list of documented Work Orders') and enumerates the status values it reports, plus index freshness. It also explicitly distinguishes itself from the sibling atlas_tasks, which handles granular Markdown checkboxes.
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?
Gives an explicit when-to-use rule ('Use this tool first when asked about project progress, completed milestones, or which Work Order is next') and an explicit alternative for the adjacent case ('For granular Markdown checkboxes, use atlas_tasks instead'). The no-parameter constraint is also stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List design and development action items (- [ ] / - [x] checkboxes) extracted from all documentation sections.
Use this tool to inspect granular checklist items embedded in specs. To inspect numbered
high-level Work Orders (`Work Order N — ⬜ OPEN / ✅ DONE`), use `atlas_status` instead.
Behavior & Output:
- Read-only query over indexed Markdown checkboxes.
- Returns a JSON string `{status, owner, count, tasks: [{text, done, owner, tags, anchor, path, line}]}`.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | No | Optional owner handle to filter tasks assigned via `@name` tags in Markdown (e.g. '@design' or 'design'). Omit or pass null for all owners. | |
| status | No | Filter tasks by completion state: 'open' for unchecked `- [ ]` items (default), 'done' for checked `- [x]` items, or 'all' for both. | open |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description need not prove safety. It goes beyond them by naming the underlying data source (indexed Markdown checkboxes) and sketching the return payload shape, which annotations cannot convey. It does not cover pagination or handling of unindexed/stale docs, keeping it just short of a 5.
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?
Purpose, sibling routing, and behavior are front-loaded in that order, with the alternative named before details an agent doesn't need yet. The 'Read-only query' line partly restates the annotations, which is a minor redundancy in an otherwise tight definition.
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?
Two optional, fully documented parameters and an existing output schema mean the agent needs little more than routing guidance. The description supplies the sibling disambiguation and data source that structured fields cannot, so nothing needed to call it correctly is missing.
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 100% with per-parameter text and an enum on `status`, so the schema already carries the semantics. The description's `- [ ]` / `- [x]` notation loosely reinforces the open/done distinction already spelled out in the schema, adding little new meaning. Baseline 3 is appropriate.
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 ('List design and development action items') and pins down the data source ('checkboxes extracted from all documentation sections'). It explicitly contrasts itself with the sibling `atlas_status`, so an agent can pick between granular checklist items and numbered Work Orders without opening either schema.
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?
Gives an explicit when-to-use ('inspect granular checklist items embedded in specs') and an explicit alternative with its own defining syntax ('numbered high-level Work Orders ... use `atlas_status` instead'). The selection rule is fully determined, not inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate the best-matching documentation section for a topic and return its pointer (~60 tokens) without full text.
Use this tool FIRST for 'where is X documented?', 'which file covers Y?', or 'which section defines Z?'.
Follow up with `atlas_read(anchor)` only if you need the section body, or fall back to `atlas_search`
if you need multiple ranked snippets across documents.
Behavior & Output:
- Read-only, deterministic BM25 lookup against the local SQLite FTS5 index (auto-refreshed before query).
- Returns a JSON string with `{found: true, anchor, heading, path, line, alternatives}` when matched,
or `{found: false, hint}` when no section matches.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Natural-language question or topic keywords to locate in the project documentation (e.g. 'damage model', 'Where is dialogue branching described?'). Supports English and German terms with automatic stop-word removal and umlaut folding. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that: deterministic BM25 ranking against a local SQLite FTS5 index that auto-refreshes before the query, which explains freshness and ranking behavior. It also restates the return payload (found/anchor/heading/path/line/alternatives, or found/hint), but an output schema already exists, so that portion is duplication rather than added 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?
Well front-loaded: purpose in sentence one, routing in the next two, behavior in a labeled block. The 'Behavior & Output' return-shape lines partly duplicate the output schema and could be trimmed, but nothing else is wasteful.
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 single-parameter lookup tool, the definition covers purpose, selection criteria, alternatives, index/ranking behavior, freshness, and no-match handling. With an output schema present, return values need no further explanation, so there is no meaningful gap for an agent to call 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 100% and the single `topic` param is documented there with examples, language support, stop-word removal, and umlaut folding. The description adds nothing about the parameter beyond the schema, so the baseline 3 applies.
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 first sentence names a specific verb (locate) and resource (documentation section) and states the output shape and cost (~60 tokens, pointer only, no full text). It explicitly distinguishes itself from siblings atlas_read and atlas_search by role, so an agent can select it without opening any schema.
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?
Provides explicit routing: use FIRST for 'where is X documented?', 'which file covers Y?', 'which section defines Z?'. It then names both alternatives with the exact conditions that select them — atlas_read(anchor) for the body, atlas_search for multiple ranked snippets.
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.3atlas_set_status8 fields changedInput schema / properties / status / descriptionPrevious value: -"New status for the Work Order: 'done' (`✅ DONE`, default) or 'open' (`⬜ OPEN`)."New value: +"New status: 'done' (`✅ DONE` / `- [x]`, default) or 'open' (`⬜ OPEN` / `- [ ]`)."Input schema / properties / taskAdded value: +{
+ "anyOf": [
+ {
+ "minLength": 1,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Substring identifying a Markdown checkbox item (`- [ ] ...`) to toggle between `- [ ]` ('open') and `- [x]` ('done') when `wo` is omitted (e.g. 'Balance damage formula').",
+ "title": "Task"
+}Input schema / properties / wo / anyOfAdded value: +[
+ {
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / wo / defaultAdded value: +nullInput schema / properties / wo / descriptionPrevious value: -"Existing Work Order number to update (positive integer, e.g. 8 for 'Work Order 8')."New value: +"Existing Work Order number to update (positive integer, e.g. 8 for 'Work Order 8'). Provide either `wo` or `task`."Input schema / properties / wo / minimumRemoved value: -1Input schema / properties / wo / typeRemoved value: -"integer"Input schema / requiredRemoved value: -[
- "wo"
-]v0.1.1atlas_brief8 fields changedInput schema / properties / files / descriptionAdded value: +"Optional list of relative source file paths to include alongside auto-detected `implements` files (e.g. ['scripts/unit.gd', 'src/combat.py'])."Input schema / properties / goal / descriptionAdded value: +"One-sentence description of the task to prepare a brief for (e.g. 'wire the dwarf vault-charger perk into turn_manager')."Input schema / properties / goal / minLengthAdded value: +1Input schema / properties / max_sections / descriptionAdded value: +"Maximum number of relevant documentation sections to embed in the brief (1-20, default 5)."Input schema / properties / max_sections / maximumAdded value: +20Input schema / properties / max_sections / minimumAdded value: +1Input schema / properties / work_order / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "minimum": 1,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / work_order / descriptionAdded value: +"Optional Work Order number (e.g. 7). When provided, the brief includes the exact `atlas_publish` / `atlas_set_status` closing command for that Work Order."atlas_code_find6 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of matching symbol definitions to return (1-100, default 10)."Input schema / properties / limit / maximumAdded value: +100Input schema / properties / limit / minimumAdded value: +1Input schema / properties / symbol / descriptionAdded value: +"Function, method, or class name (or substring) to search for across the codebase (e.g. 'apply_damage' or 'TurnManager'). Does not match local variables."Input schema / properties / symbol / minLengthAdded value: +1Input schema / properties / usage / descriptionAdded value: +"If true, also scan the repository for call sites and references to each matched symbol (including Godot `.tscn` signal bindings) to verify whether the symbol is wired up (default false)."atlas_links2 fields changedInput schema / properties / anchor / descriptionAdded value: +"Section anchor identifier in `<doc_id>#<section-slug>` or `<doc_id>` format (e.g. 'combat#damage-model'), as returned by `atlas_where`, `atlas_search`, or `atlas_outline`."Input schema / properties / anchor / minLengthAdded value: +1atlas_outline1 field changedInput schema / properties / doc / descriptionAdded value: +"Optional document ID (e.g. '02-combat' or 'architecture') to list headings for a single document. Omit or pass null to list the table of contents for all documents."atlas_publish8 fields changedInput schema / properties / description / descriptionAdded value: +"Optional summary of what was implemented and which files were touched."Input schema / properties / status / descriptionAdded value: +"Target Work Order status: 'done' (writes `✅ DONE`, default) or 'open' (writes `⬜ OPEN`)."Input schema / properties / status / enumAdded value: +[
+ "done",
+ "open"
+]Input schema / properties / title / descriptionAdded value: +"Short title of the Work Order (e.g. 'Critical Hit Calculation')."Input schema / properties / title / minLengthAdded value: +1Input schema / properties / verify_symbols / descriptionAdded value: +"List of function or class names built in this Work Order (e.g. ['apply_crit_bonus']). When `status='done'`, each symbol is checked before writing: if any symbol is undefined or has 0 callers/references across the codebase, the write is refused."Input schema / properties / wo / descriptionAdded value: +"Work Order number (positive integer, e.g. 7 for 'Work Order 7')."Input schema / properties / wo / minimumAdded value: +1atlas_read7 fields changedInput schema / properties / anchor / descriptionAdded value: +"Section anchor identifier in `<doc_id>#<section-slug>` format (or `<doc_id>` for the document root), as returned by `atlas_where`, `atlas_search`, or `atlas_outline` (e.g. 'combat#damage-model')."Input schema / properties / anchor / minLengthAdded value: +1Input schema / properties / max_chars / descriptionAdded value: +"Maximum number of characters to return in one call (default 3000)."Input schema / properties / max_chars / maximumAdded value: +50000Input schema / properties / max_chars / minimumAdded value: +100Input schema / properties / offset / descriptionAdded value: +"Character offset to start reading from (default 0). When a previous call returned `truncated: true`, pass its `next_offset` value here to read the next page."Input schema / properties / offset / minimumAdded value: +0atlas_search6 fields changedInput schema / properties / doc / descriptionAdded value: +"Optional document ID (e.g. 'combat' or '02-combat') to restrict the search to a single document. Omit or pass null to search all documents."Input schema / properties / k / descriptionAdded value: +"Maximum number of ranked section hits to return (1-50, default 5)."Input schema / properties / k / maximumAdded value: +50Input schema / properties / k / minimumAdded value: +1Input schema / properties / query / descriptionAdded value: +"Keywords or phrase to search across all indexed documentation sections (e.g. 'cover reduction', 'turn order'). Uses lexical FTS5 matching with umlaut folding ('Hoehe' matches 'Höhe') and German compound splitting."Input schema / properties / query / minLengthAdded value: +1atlas_set_status5 fields changedInput schema / properties / status / descriptionAdded value: +"New status for the Work Order: 'done' (`✅ DONE`, default) or 'open' (`⬜ OPEN`)."Input schema / properties / status / enumAdded value: +[
+ "done",
+ "open"
+]Input schema / properties / verify_symbols / descriptionAdded value: +"Optional list of function or class names that must be defined and called/referenced in the codebase before `status='done'` is allowed. Merged with `.atlas/wo-symbols.yml`."Input schema / properties / wo / descriptionAdded value: +"Existing Work Order number to update (positive integer, e.g. 8 for 'Work Order 8')."Input schema / properties / wo / minimumAdded value: +1atlas_sheet_append6 fields changedInput schema / properties / dry_run / descriptionAdded value: +"If true, validate column headers and preview the row without writing to the spreadsheet (default false)."Input schema / properties / sheet / descriptionAdded value: +"Optional spreadsheet name or ID when multiple spreadsheets are bound to the project."Input schema / properties / tab / descriptionAdded value: +"Exact worksheet/tab name inside the spreadsheet (e.g. 'Units'). Use `atlas_sheets` to discover valid tab names."Input schema / properties / tab / minLengthAdded value: +1Input schema / properties / values / additionalPropertiesPrevious value: -trueNew value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Input schema / properties / values / descriptionAdded value: +"Mapping of `{column_header_name: value}` for the new row (e.g. `{\"ID\": \"monster_goblin\", \"Name\": \"Goblin\", \"HP\": 100}`). Omitted columns are left empty."atlas_sheet_update9 fields changedInput schema / properties / dry_run / descriptionAdded value: +"If true, compute and return the cell diff without writing changes to the spreadsheet (default false)."Input schema / properties / key_column / descriptionAdded value: +"Optional header name of the key column used to match `row_key`. Defaults to the first column of the tab."Input schema / properties / row_key / descriptionAdded value: +"Primary key value identifying the target row in the key column (e.g. 'monster_goblin')."Input schema / properties / row_key / minLengthAdded value: +1Input schema / properties / sheet / descriptionAdded value: +"Optional spreadsheet name or ID when multiple spreadsheets are registered. Omit if only one spreadsheet exists."Input schema / properties / tab / descriptionAdded value: +"Exact worksheet/tab name inside the spreadsheet (e.g. 'Units' or 'Weapons'). Use `atlas_sheets` to list valid tabs."Input schema / properties / tab / minLengthAdded value: +1Input schema / properties / updates / additionalPropertiesPrevious value: -trueNew value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "integer"
+ },
+ {
+ "type": "number"
+ },
+ {
+ "type": "boolean"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Input schema / properties / updates / descriptionAdded value: +"Mapping of `{column_header_name: new_value}` for the cells to update in that row (e.g. `{\"HP\": 45, \"Status\": \"✅\"}`). Never pass raw cell coordinates like 'C14'."atlas_tasks3 fields changedInput schema / properties / owner / descriptionAdded value: +"Optional owner handle to filter tasks assigned via `@name` tags in Markdown (e.g. '@design' or 'design'). Omit or pass null for all owners."Input schema / properties / status / descriptionAdded value: +"Filter tasks by completion state: 'open' for unchecked `- [ ]` items (default), 'done' for checked `- [x]` items, or 'all' for both."Input schema / properties / status / enumAdded value: +[
+ "open",
+ "done",
+ "all"
+]atlas_where2 fields changedInput schema / properties / topic / descriptionAdded value: +"Natural-language question or topic keywords to locate in the project documentation (e.g. 'damage model', 'Where is dialogue branching described?'). Supports English and German terms with automatic stop-word removal and umlaut folding."Input schema / properties / topic / minLengthAdded value: +1v0.1.0atlas_briefatlas_code_findatlas_linksatlas_lintatlas_outlineatlas_publishatlas_readatlas_searchatlas_set_statusatlas_sheet_appendatlas_sheet_updateatlas_sheetsatlas_statusatlas_tasksatlas_whereScored across 15 tools
Most tools target a clearly distinct resource+action (read vs outline, status vs tasks, set_status vs publish, sheet_update vs sheet_append), and descriptions explicitly cross-reference when to use each alternative. The only genuine overlaps are atlas_where vs atlas_search (both BM25 lookups over the same index) and atlas_status vs atlas_tasks, but the descriptions disambiguate those well enough that misselection is unlikely.
All names use a consistent snake_case with the atlas_ prefix, which is the strongest consistency signal here. There is minor variation in convention—some are verb-first (atlas_read, atlas_publish, atlas_set_status), others noun-first (atlas_status, atlas_tasks, atlas_sheets), and subresource ordering differs (atlas_code_find vs atlas_sheet_update)—but the pattern stays readable.
Fifteen tools is well within a healthy scope for a documentation/project-memory server and each maps to a distinct capability (search, read, outline, links, tasks, status, brief, publish, status flip, lint, code find, and three sheet operations). Nothing feels redundant or padded.
The documentation lifecycle is thoroughly covered: discover (where/search/outline), inspect (read/links/tasks/status), act (brief/publish/set_status), plus code lookup and lint. Minor gaps remain—there is no spreadsheet cell/row read tool (only list/update/append) and no delete operations for Work Orders or rows—but these are workaroundable and do not block core workflows.
Sub-millisecond FTS5 search across 17,671 Google Cloud APIs, SDKs, Billing SKUs, and MCPs.
Ask a codebase what calls what: search, blast radius, paths between symbols, and diffs.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…