atlas-brief-mcp

Overview Schema Source Related Servers Discussions Admin

atlas_set_status

Idempotent

Toggle a Work Order or Markdown checkbox task between open and done, refusing completion when referenced functions are undefined or have no callers.

Instructions

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

Input Schema

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

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.2.3Nov 6, 2026

changedInput schema / properties / status / description

Previous value: -"New status for the Work Order: 'done' (`✅ DONE`, default) or 'open' (`⬜ OPEN`)."New value: +"New status: 'done' (`✅ DONE` / `- [x]`, default) or 'open' (`⬜ OPEN` / `- [ ]`)."

addedInput schema / properties / task

Added 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"
+}

addedInput schema / properties / wo / anyOf

Added value: +[
+  {
+    "minimum": 1,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / wo / default
```
Added value: +null
```

changedInput schema / properties / wo / description

Previous 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`."

removedInput schema / properties / wo / minimum
```
Removed value: -1
```
removedInput schema / properties / wo / type
```
Removed value: -"integer"
```
removedInput schema / required
```
Removed value: -[
-  "wo"
-]
```

Changed5 schema fields changedv0.1.1Nov 6, 2026

addedInput schema / properties / status / description

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

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

addedInput schema / properties / verify_symbols / description

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

addedInput schema / properties / wo / description

Added value: +"Existing Work Order number to update (positive integer, e.g. 8 for 'Work Order 8')."

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

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server