# MCP Tools Inventory

Atlas's hands. Skills are the brain; MCP tools (and CLI commands) are how the brain reaches the world.

| Tool | Status | Spec |
|------|--------|------|
| **email-fetch** | V0 | (in `email-extractor.md` Stage 1) |
| **email-extractor** | V0 — critical | [`email-extractor.md`](./email-extractor.md) |
| **state-io** | V0 | TBD — read/write `state/*.json` with optimistic locking |
| **report-render** | V0 | TBD — Markdown → PDF / HTML / WeChat-card |
| **email-send** | V0 (boss only) | TBD — sends Brief to boss only; refuses any other recipient in V0 |
| **rule-audit** | V0 | TBD — append-only audit log of which rules fired on which judgments |
| **wechat-fetch** | V0.5 | TBD |
| **feishu-fetch** | V1 | TBD |

## Why MCP and not just plain CLI

For V0, plain Python CLI tools are fine. We move to MCP-server style when:

1. The same tool needs to be callable by multiple Claws (e.g., Atlas + Zero both want to read state)
2. We want fine-grained per-tool permission gates
3. We deploy Atlas as a hosted multi-client SaaS

For now: **CLI commands callable from skill prompts via Bash** is the V0 model. MCP wrapping is a V0.5 refactor.

## Tool Authorization Matrix

| Tool | Can Atlas call autonomously? | Requires boss approval? |
|------|-----------------------------|--------------------------|
| email-fetch | ✅ | No (configured at install) |
| email-extractor | ✅ | No |
| state-io read | ✅ | No |
| state-io write | ✅ | No (state is Atlas's working memory) |
| report-render | ✅ | No |
| email-send (Brief to boss) | ✅ | No (auth granted at install) |
| email-send (anything else) | ❌ in V0 | Always |
| boss_skill.md write | ❌ in V0 | Always — boss audits diff |