atlas-brief-mcp

Overview Schema Source Related Servers Discussions Admin

atlas_publish

Idempotent

Append and verify a Work Order status entry in project docs after tests pass; refuses writes when code-wiring checks fail.

Instructions

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}`.

Input Schema

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.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.1.1Nov 6, 2026

addedInput schema / properties / description / description

Added value: +"Optional summary of what was implemented and which files were touched."

addedInput schema / properties / status / description

Added value: +"Target Work Order status: 'done' (writes `✅ DONE`, default) or 'open' (writes `⬜ OPEN`)."

addedInput schema / properties / status / enum
```
Added value: +[
+  "done",
+  "open"
+]
```

addedInput schema / properties / title / description

Added value: +"Short title of the Work Order (e.g. 'Critical Hit Calculation')."

addedInput schema / properties / title / minLength
```
Added value: +1
```

addedInput schema / properties / verify_symbols / description

Added 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."

addedInput schema / properties / wo / description

Added value: +"Work Order number (positive integer, e.g. 7 for 'Work Order 7')."

addedInput schema / properties / wo / minimum
```
Added value: +1
```

First observedv0.1.0Nov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server