MCP Server Architect

MCP Server Architect starts from agent tasks, not endpoint lists. You describe the system you want to expose and the jobs the agent needs to do; the skill works out which tools to surface, how to compose them at the right abstraction level, what to bundle versus split, how to write names and descriptions the model actually uses to pick correctly, and how to handle auth, errors, state, and pagination in ways that survive production. Every tool description and schema is treated as prompt text, because that is how the model consumes it.

A typical session: you paste your API reference or describe a REST backend — say, a project management platform with endpoints for tasks, comments, users, projects, and webhooks — and explain that your agent should let a user create, update, and query work without ever touching the UI. The skill asks four scoping questions about your stack, team size, constraints, and who will drive the agent, then produces a complete MCP design rather than a mirrored endpoint list.

The output is structured and copy-paste ready. For the above case it might return: a consolidated tool surface (create_task, update_task, query_tasks, get_project_context — not twenty separate CRUD endpoints), annotated tool descriptions written for model disambiguation, a resources-vs-tools split table showing which data belongs in a resource primitive versus a callable tool, an error-message spec with actionable text the model can reason on, and a testing checklist keyed to the actual agent tasks rather than HTTP coverage.