This article is published in English.
Practical notes: 5 MCP Connections That Turn Claude Code Into a Chief of Staff
Operable walkthrough of Practical notes: 5 MCP Connections That Turn Claude Code Into a Chief of Staff: contracts, checks, and drop-in code slots for teams shipping this pattern.
The following notes reconstruct a practical path around “5 MCP Connections That Turn Claude Code Into a Chief of Staff”. Emphasis stays on contracts, checks, and drop-in code placeholders rather than motivational framing.
Part 1 covered workflows on your files. This one plugs the agent into your calendar, Slack, and email, so it works on live data.
When working through the Part 1 covered workflows stage, write down the contract first: required inputs, success signal, and what happens on partial failure. That checklist keeps later code changes honest. Record timings and token or query cost next to functional results. Cost visibility early prevents surprise bills when the path moves from demo to shared environments. Log tool name, args hash, latency, and outcome for every call. Debugging agent loops without that trail wastes hours.
claude mcp add <name> <command or URL>
1. The morning briefing that knows your calendar
When working through the 1 The morning briefing stage, write down the contract first: required inputs, success signal, and what happens on partial failure. That checklist keeps later code changes honest. Keep configuration outside application code. Environment files, secret stores, and feature flags belong in one place operators can audit without reading the whole graph. Log tool name, args hash, latency, and outcome for every call. Debugging agent loops without that trail wastes hours.
---
description: Morning briefing from calendar plus notes
---
Read today's and tomorrow's calendar events.
Read my notes from the past 7 days in notes/.
Read projects/ for anything with a deadline this week.
Produce a briefing:
- Today's schedule, with a one-line "what you need for this" per meeting,
pulled from my notes where relevant
- Conflicts, back-to-backs, or meetings with no clear purpose
- The one thing that deserves my best two hours today, and why
Under 300 words. Do not create, move, or edit any events.
2. Catch up on your chat apps without scrolling
When working through the 2 Catch up on stage, write down the contract first: required inputs, success signal, and what happens on partial failure. That checklist keeps later code changes honest. Document the happy path and the recovery path together. Retries, human gates, and dead-letter handling are part of the product, not later polish. Log tool name, args hash, latency, and outcome for every call. Debugging agent loops without that trail wastes hours.
Read the past 2 days of messages in #team, #project-atlas, and
any thread I was mentioned in.
Summarise:
- Decisions made (with who made them)
- Questions directed at me that I haven't answered
- Anything that changed a deadline, scope, or owner
- Threads still on fire
Link each item to the message so I can jump in. Do not post,
react, or reply to anything.
3. Automating your Email inbox
When working through the 3 Automating your Email stage, write down the contract first: required inputs, success signal, and what happens on partial failure. That checklist keeps later code changes honest. Prefer small, testable units over sprawling scripts. When a step fails, the failure should point at a single responsibility rather than a tangled pipeline. Log tool name, args hash, latency, and outcome for every call. Debugging agent loops without that trail wastes hours.
Read unread email from the past 3 days.
Sort into:
- Needs a reply from me (draft one, save to drafts/, do NOT send)
- Needs an action but not a reply (list the action)
- FYI only (one-line summary each)
- Ignorable (just count them)
Never send, delete, archive, or mark anything. Drafts stay drafts.
4. The self-updating Task Board
When working through the 4 The self-updating Task stage, write down the contract first: required inputs, success signal, and what happens on partial failure. That checklist keeps later code changes honest. Treat this stage as a contract between inputs and validated outputs. Name the artifacts, define success checks, and refuse silent partial completion. Log tool name, args hash, latency, and outcome for every call. Debugging agent loops without that trail wastes hours. When working through the 4 The self-updating Task stage, write down the contract first: required inputs, success signal, and what happens on partial failure. That checklist keeps later code changes honest. Keep configuration outside application code. Environment files, secret stores, and feature flags belong in one place operators can audit without reading the whole graph.
---
description: Reconcile the project board with reality
---
Read the project board.
Read my notes and logs from the past 7 days.
Find the drift:
- Tasks marked in-progress that my notes say are done
- Work my notes describe that has no ticket at all
- Tickets untouched for 14+ days
Propose the updates as a list. On my approval, apply them.
5. Search everything!
The 5 Search everything stage works best when treated as a measurable surface. Capture one golden transcript, one failure case, and the rollback note before expanding scope. Document the happy path and the recovery path together. Retries, human gates, and dead-letter handling are part of the product, not later polish. Expose tools with narrow schemas and explicit side-effect labels. Hosts need to know which calls mutate state before they auto-approve.
---
description: Weekly review across every connected source
---
Read: this week's calendar, my notes/, the project board,
Slack decisions in #team, and my sent email from the past 7 days.
Produce the week:
- What shipped, versus what the week was supposed to be about
- Decisions made anywhere (notes, Slack, email) that never made it
to the board or my notes
- Commitments I made in email or Slack that have no task attached
- Next week's real priorities, based on all of the above
Write to reviews/YYYY-WW.md. Flag anything you inferred rather
than found.
The pattern (again)
The The pattern again stage works best when treated as a measurable surface. Capture one golden transcript, one failure case, and the rollback note before expanding scope. Prefer small, testable units over sprawling scripts. When a step fails, the failure should point at a single responsibility rather than a tangled pipeline. Expose tools with narrow schemas and explicit side-effect labels. Hosts need to know which calls mutate state before they auto-approve.
Operational checklist
For the Operational checklist stage, define the inputs, the owner of the step, and the exit criteria before changing code. Operators should be able to re-run the step from a known checkpoint without guessing hidden state.
Record timings and token or query cost next to functional results. Cost visibility early prevents surprise bills when the path moves from demo to shared environments.
Authenticate at the gateway and re-authorize at the data plane. A bearer token alone is not a tenancy boundary.
Write a short runbook: how to rotate keys, how to drain the queue, how to roll back the last ingest.
Keep configuration outside application code. Environment files, secret stores, and feature flags belong in one place operators can audit without reading the whole graph.
Authenticate at the gateway and re-authorize at the data plane. A bearer token alone is not a tenancy boundary.
Before promoting the stack, freeze versions, capture a golden transcript for the critical path, and confirm rollback steps. Shared environments need rate limits, tenancy checks, and a clear owner for secret rotation. Prefer boring reliability over clever one-off demos.
Batch note for a0d364d17aa1: keep provider keys out of the repo, set a per-session token ceiling, and store transcripts next to the eval fixtures so later model swaps stay comparable.