Design Mcp Workflow
Decide whether Zoom (or similar) work belongs in MCP tool calls, REST automation, or a hybrid before you implement the connector.
Overview
Design MCP Workflow is an agent skill most often used in Build (also Validate) that plans whether tasks should use MCP tools, REST APIs, or hybrid Zoom integration before implementation.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill design-mcp-workflowWhat is this skill?
- Five-step workflow: agentic vs deterministic split, routing to zoom-mcp and rest-api skills
- Explicit MCP vs REST responsibility boundaries and hybrid patterns
- Whiteboard-specific MCP routing when visual collaboration is central
- Calls out transport, auth, and client capability assumptions
- Documents common mistakes (MCP for batch jobs, ignoring client support)
- 5-step workflow covering fit assessment, routing, whiteboard, and explicit transport/auth assumptions
Adoption & trust: 886 installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are wiring Zoom into an AI client but cannot tell which flows belong in MCP tool calls versus stable REST jobs.
Who is it for?
Builders designing Zoom or similar MCP connectors who need architecture guardrails before implementing tools.
Skip if: One-off REST scripts with no agent involvement, or teams that already have an approved integration spec and only need codegen.
When should I use this skill?
User wants Claude or another MCP client to use Zoom via tools, needs MCP fit assessment, or asks how to separate MCP from REST API responsibilities.
What do I get? / Deliverables
You get a clear MCP/REST split, routing to zoom-mcp and rest-api skills, with transport and auth assumptions stated before coding.
- MCP vs REST boundary decision
- Pointers to zoom-mcp, rest-api, and whiteboard skill routes
- Listed transport, auth, and client capability assumptions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Agent-tooling is the canonical shelf for designing how LLM clients invoke external products via MCP versus traditional APIs. MCP fit assessment and REST boundaries are architecture decisions made while building agent integrations, not at launch copy time.
Where it fits
Decide if a meeting-summary feature needs MCP tools or a nightly REST job before prototyping.
Route whiteboard collaboration to zoom-mcp/whiteboard while keeping billing webhooks on REST.
Document auth and transport limits before registering Zoom tools in your MCP server.
How it compares
Architecture planning skill for MCP boundaries—not the zoom-mcp implementation skill itself.
Common Questions / FAQ
Who is design-mcp-workflow for?
Developers and indie founders designing agent + SaaS integrations who need a repeatable way to separate MCP tool workflows from REST automation.
When should I use design-mcp-workflow?
In validate when scoping agent features; in build when planning Zoom MCP connectors, hybrid meeting automations, or whiteboard-centric tool routes.
Is design-mcp-workflow safe to install?
It is documentation-only planning with no built-in shell or network calls—still review the Security Audits panel on this page for the parent plugin bundle.
SKILL.md
READMESKILL.md - Design Mcp Workflow
# Design MCP Workflow Use this skill when the user wants Claude or another MCP-capable client to interact with Zoom via tool calls instead of only deterministic API code. ## Covers - MCP fit assessment - REST API vs MCP boundaries - Hybrid architectures - Connector expectations - Whiteboard-specific MCP routing ## Workflow 1. Decide whether the problem is agentic tooling, deterministic automation, or both. 2. Route MCP-only tasks to [zoom-mcp](../zoom-mcp/SKILL.md). 3. Route hybrid tasks to both [zoom-mcp](../zoom-mcp/SKILL.md) and [rest-api](../rest-api/SKILL.md). 4. If Whiteboard is central, route to [zoom-mcp/whiteboard](../zoom-mcp/whiteboard/SKILL.md). 5. Call out transport, auth, and client capability assumptions explicitly. ## Common Mistakes - Using MCP for deterministic backend jobs that should stay in REST - Treating MCP as a replacement for all API design - Ignoring client transport support and auth requirements