05. Assignment 5 — MCP-Powered Briefing Workflow¶
Week 10. Build one MCP server and one multi-agent workflow that actually justify each other.
Goal¶
Create a briefing assistant that does four things: 1. researches a topic 2. drafts a brief 3. reviews the draft 4. publishes only approved output
The key requirement is architectural clarity. Do not build “many agents” for drama. Build the minimum multi-agent structure that improves reliability over one giant agent.
What you are building¶
Part A — MCP server¶
Expose at least these capabilities:
1. search_reports(query, top_k=5)
2. save_note(title, body, tags)
3. get_editorial_policy()
4. publish_brief(title, summary, body_markdown, review_status)
Requirements:
- Use clean tool descriptions
- Use explicit schemas or typed inputs
- Make publish_brief safe by requiring approved status
Part B — Multi-agent workflow¶
Build at least three agents: 1. Research agent — gathers claims and sources 2. Writer agent — drafts the brief from validated material 3. Reviewer agent — checks grounding, clarity, and publish readiness
Optional fourth agent: - Publisher agent — formats and invokes the publish tool after approval
Suggested topology¶
Start with pipeline or orchestrator-worker. Do not start hierarchical unless you can justify it. Do not add debate unless you can measure the gain.
Required deliverables¶
mcp_server.pyor equivalent MCP server entrypointagents.pyor equivalent workflow implementationschemas.pyor equivalent structured handoff definitionsREADME.mdwith architecture diagrameval_notes.mdwith failures, fixes, and final verdict on whether multi-agent was worth it
Handoff contract requirement¶
At minimum, the handoff between agents must include: - task - inputs - constraints - evidence or citations - open risks - done definition
Evaluation requirement¶
Run at least 10 task scenarios. Track: - end-to-end success rate - one failure example per agent - total latency - total model cost or token estimate
Also compare against a simple single-agent baseline. That comparison is the heart of the hands_on_lab.
What success looks like¶
- MCP server works end-to-end
- Agents use structured handoffs
- Reviewer catches at least some errors the writer missed
- You can explain why your chosen topology fits
- You have a clear answer to: “Did multi-agent actually help?”
Common pitfalls¶
- Overstuffed handoffs that recreate one giant context window
- Vague agent roles
- Tool definitions that allow invalid actions
- No baseline comparison
- Fancy topology with no measurable benefit
Stretch goals¶
- Cheap router model before generation
- Human approval gate before publish
- Parallel evidence gathering in research
- Trace visualization or structured logs
Write-up prompts¶
Answer these in your README or eval_notes.md:
1. Why did you choose this topology?
2. Where did MCP help reuse or clarity?
3. What was the first failing handoff?
4. What did your single-agent baseline do better?
5. Would you keep this design in production?
Cross-reference¶
Use 02_explainer.md for the mental model. Use 03_study_material.md as the compact checklist. Use 06_revision.md after shipping.