How to Enhance Your AI Development Workflow with MCP and Zstem

AI can generate a component in seconds. It can create an API handler, write a database query, or scaffold an entire application before you have finished describing the feature.

But speed is not the same as alignment.

Without the system around the task, an AI coding agent does not know which service owns the data, what happens when a dependency fails, which events other parts of the system expect, or why one technology was chosen over another. That context is usually scattered across chat history, tickets, diagrams, documents, and someone’s memory.

An effective AI development workflow needs more than a longer prompt. It needs structured system context that both people and AI can inspect, update, and reuse.

That is where MCP and Zstem fit.

The short answer

The Model Context Protocol, commonly called MCP, lets an AI assistant connect to external tools and resources. An MCP server exposes capabilities that the model can call during a conversation. Instead of only discussing a system, the assistant can create, read, and update it through supported tools. The specification defines MCP as an open-source standard for connecting AI applications to external systems.

MCP is vendor-neutral. Anthropic created and open-sourced it in November 2024, then donated it to the Linux Foundation’s Agentic AI Foundation in December 2025, where it is now governed as a community project. That matters here for a practical reason rather than a political one: Claude, ChatGPT, and Codex are all clients of the same protocol, so a single Zstem MCP server works with whichever one you use.

Zstem uses that connection to give AI a structured system-design workspace. The assistant can create an architecture, sequence diagram, workflow, event flow, API contract, database schema, and technical documentation as connected parts of the same project.

The result is a continuous workflow from idea to design to implementation.

flowchart LR
    IDEA[Product idea] --> CHAT[Plan with AI]
    CHAT --> MCP[Zstem MCP]
    MCP --> DESIGN[Connected system design]
    DESIGN --> CONTEXT[Implementation context]
    CONTEXT --> AGENT[AI coding agent]
    AGENT --> CODE[Working software]
    CODE --> REVIEW[Review and update design]
    REVIEW --> MCP

What is broken in the usual AI coding workflow?

A common workflow looks like this:

1. Describe a product idea in chat.
2. Ask for an architecture.
3. Copy parts of the response into a document.
4. Open a separate diagramming tool.
5. Recreate the architecture manually.
6. Start a new coding session.
7. Explain the product again.
8. Discover that the generated code made different assumptions.
9. Update the code, but forget to update the diagram.

The problem is not that any individual tool is bad. The problem is that the reasoning does not travel with the work.

Fragmented workflow	Connected Zstem workflow
Architecture lives in a chat response	Architecture lives in a structured project
Diagrams are recreated manually	AI creates and updates native diagrams through MCP
API and data decisions drift apart	API, data, events, and behaviour share one project
A new agent needs the full explanation again	The project can be exported as agent-friendly context
Technical decisions disappear	Decisions remain beside the design they affect
Documentation becomes stale silently	The project can be reviewed and updated as the system changes

What MCP changes

MCP changes the assistant from a source of suggestions into a participant in a tool-supported workflow.

An MCP server defines tools with clear inputs and outputs. Claude, ChatGPT, Codex, or another compatible client can decide when to call those tools, pass structured arguments, and use the returned result in the conversation. The same server works across all of them, because the protocol is the contract rather than any one vendor’s integration. See how MCP describes clients and servers.

With Zstem connected, the assistant can do work such as:

• Create a new project from a product brief
• Add AWS or system components and their relationships
• Define REST endpoints and reusable schemas
• Model database tables and relationships
• Describe a request across multiple services
• Define events, channels, producers, and consumers
• Create a business workflow or state machine
• Record architecture decisions and trade-offs
• Export the entire project as implementation context

This means the model is not merely producing a picture. It is working with a system model.

Live demo: from one prompt to a complete system design

For this article, we created a real Zstem project through MCP:

Live Demo: AI-Assisted Customer Support Platform

The starting prompt was:

Create a Zstem project for an AI-assisted customer support platform. Customers create tickets and agents resolve them. Ticket creation must respond immediately, while AI classification happens asynchronously. Include the architecture, REST API, DynamoDB data model, ticket creation sequence, domain events, triage workflow, failure handling, and technical decisions. AI may recommend category and urgency, but a human agent must review the recommendation before it affects the customer.

That prompt created a connected project containing:

• 14 architecture components
• 17 architecture relationships
• 3 REST API paths
• 3 reusable API schemas
• 3 data tables
• 13 sequence messages
• 3 domain-event definitions
• 13 workflow steps
• A product brief
• An architecture decision document

The architecture

The system accepts a customer ticket through API Gateway and Lambda, persists it in DynamoDB, then publishes a lifecycle event through EventBridge. SQS buffers AI classification work so the customer response does not wait for the model. A Lambda worker invokes Amazon Bedrock, stores a structured recommendation, and sends repeated failures to a dead-letter queue.

flowchart LR
    CUSTOMER[Customer portal] --> API[Support API]
    API --> TICKET[Ticket service]
    TICKET --> DB[Ticket store]
    TICKET --> BUS[Event bus]
    BUS --> QUEUE[AI triage queue]
    QUEUE --> WORKER[Triage worker]
    WORKER --> MODEL[Bedrock model]
    WORKER --> DB
    QUEUE --> DLQ[Dead-letter queue]

The important design decision is visible immediately: AI classification is outside the synchronous ticket-creation path.

The customer receives confirmation after the ticket is stored. Model latency or failure does not prevent ticket creation.

The request sequence

sequenceDiagram
    participant U as Customer
    participant A as Support API
    participant T as Ticket Service
    participant D as Ticket Store
    participant E as Event Bus
    participant Q as Triage Queue
    participant W as Triage Worker
    participant M as AI Model
    U->>A: Create support ticket
    A->>T: Validated ticket command
    T->>D: Store OPEN ticket
    D-->>T: Ticket created
    T-->>A: 201 Created
    A-->>U: Ticket accepted
    T-)E: ticket.created
    E-)Q: Route triage job
    Q-)W: Deliver ticket context
    W->>M: Classify category and urgency
    M-->>W: Structured recommendation
    W->>D: Save triage result

The sequence shows something an architecture diagram cannot: the response to the customer happens before AI classification completes.

The API contract

The same project contains a REST contract for:

Method	Path	Purpose
POST	/tickets	Create a support ticket
GET	/tickets	List tickets visible to the caller
GET	/tickets/{ticketId}	Retrieve one ticket
PATCH	/tickets/{ticketId}/status	Update customer-visible status

The API defines reusable Ticket, CreateTicketRequest, and UpdateStatusRequest schemas. This gives an implementation agent more than a vague instruction to “build the API.” It provides named operations, request shapes, response shapes, status values, and expected error cases.

The data model

The project also defines three connected data areas:

Data	Purpose
Tickets	Current customer request and lifecycle status
Ticket messages	Customer and agent conversation history
Triage results	AI recommendation, confidence, model, and human review

Keeping the triage result separate makes the boundary clear. The model output is a recommendation attached to the ticket, not the authoritative ticket state.

The human review workflow

flowchart TD
    START[Customer submits ticket] --> VALIDATE[Validate request]
    VALIDATE --> OK{Valid?}
    OK -->|No| REJECT[Return error]
    OK -->|Yes| CREATE[Create OPEN ticket]
    CREATE --> CLASSIFY[Classify asynchronously]
    CLASSIFY --> CONF{Confidence sufficient?}
    CONF -->|Yes| SUGGEST[Suggest category and queue]
    CONF -->|No| MANUAL[Flag for manual triage]
    SUGGEST --> REVIEW[Agent reviews]
    MANUAL --> REVIEW
    REVIEW --> RESOLVE[Agent responds and resolves]

This makes the product boundary explicit. AI assists the agent, but the agent remains accountable for the outcome.

Demo 1: create a project from a rough idea

Once Zstem MCP is connected, try a deliberately incomplete prompt:

Create a Zstem project for a platform where local tradespeople can quote on repair jobs. Customers upload photos and describe the problem. Include an initial architecture, customer workflow, core API, data model, and a markdown document listing assumptions and unanswered questions. Do not invent certainty where requirements are missing.

The useful part is not only what gets created. It is what becomes reviewable.

You can inspect the assumptions, correct the model, and ask it to update only the affected views.

Follow-up prompt:

Customers must be able to invite a specific tradesperson privately. Update the architecture, API, database schema, and customer workflow. Explain which existing decisions changed and which stayed the same.

Demo 2: challenge the architecture

A design should be discussable, not merely generated.

Try:

Review this Zstem project for coupling, failure handling, security boundaries, and unclear ownership. Do not modify it yet. Give me the three highest-risk decisions and show which diagrams or documents support each finding.

Then:

Apply the approved change to move notification delivery out of the synchronous request path. Update the architecture, sequence, event flow, and architecture decision document. Preserve everything unrelated.

This is where connected views matter. A notification change can affect the component model, timing, event contract, and decision rationale at once.

Demo 3: hand the system to a coding agent

When the design is ready, export it as implementation context.

Example prompt:

Export the complete Zstem project as implementation context. Then create an implementation plan ordered by dependency. Identify which details are confirmed, which are assumptions, and which require a product decision before coding begins.

The exported context can contain the architecture, OpenAPI contract, DBML schema, Mermaid sequence, event definitions, workflow, and markdown documents in one bundle.

Then give the context to a coding agent such as Claude Code or Codex:

Build the first vertical slice from the attached Zstem context: authenticated ticket creation through persistence and the ticket.created event. Follow the API contract and data model. Add tests for validation, idempotency, and event publication. Stop before implementing AI triage.

This creates a bounded implementation task tied to the system design.

Why this produces better AI-assisted development

1. The agent receives relationships, not just requirements

“Build a ticket system” is a requirement. A sequence showing when persistence happens, when the response returns, and when the event is published describes behaviour.

2. Decisions remain visible

The architecture decision document explains why SQS exists, why AI work is asynchronous, and why human review is required. The coding agent can preserve those constraints instead of optimizing them away accidentally.

3. Different views reveal different mistakes

View	What it helps reveal
Architecture	Missing components, ownership, and integration boundaries
Sequence	Incorrect ordering, synchronous dependencies, and latency assumptions
Event flow	Missing consumers, contracts, retries, and coupling
Workflow	Unhandled decisions, waiting states, and failure branches
API contract	Ambiguous requests, responses, errors, and operations
Database schema	Missing relationships, ownership, and persistence requirements
Markdown decisions	Lost rationale, constraints, and trade-offs

4. The context can evolve

A static diagram is useful. A project that an AI assistant can read and update is more useful.

When implementation reveals a better design, the conversation can include both the code and the Zstem project:

The implementation now uses an outbox record to guarantee event publication after ticket persistence. Update the sequence, database schema, event flow, and architecture decision document to reflect the implemented design.

What Zstem does not replace

Zstem does not remove the need for engineering judgment.

You still need to:

• Verify requirements with users and stakeholders
• Challenge security and privacy assumptions
• Validate service limits and costs
• Test failure behaviour
• Review generated API and data contracts
• Decide which trade-offs are acceptable
• Confirm that documentation matches implementation

The aim is not to automate thinking. It is to give thinking a structured place to live and move through the development process.

How to connect Zstem MCP to Claude

Every Claude surface connects to the same endpoint:

https://api.zstem.design/mcp

Sign in to Zstem first, then pick the surface you work in. The Claude icon in the Zstem top bar copies the connector URL for you.

Claude Code

Register the server once, then confirm it from inside a session:

claude mcp add --transport http zstem https://api.zstem.design/mcp
claude mcp list

Open Claude Code in the workspace where you want Zstem, then run /mcp to inspect the server, authenticate when prompted, and see the available tools. Authentication is OAuth by default, so there is no token to paste.

If you would rather authenticate with a personal access token, create one in Zstem under Settings, then register the server with an explicit header:

export ZSTEM_PAT=<token>
claude mcp add --transport http zstem https://api.zstem.design/mcp --header "Authorization: Bearer $ZSTEM_PAT"

Use --scope when you want the configuration to live with the project rather than your user account, so the repository carries it for everyone working in it. See the Claude Code MCP reference.

Claude Desktop

Claude Desktop reaches a remote MCP server through mcp-remote:

npx mcp-remote https://api.zstem.design/mcp --header "Authorization: Bearer <token>"

Claude on the web

On a Pro or Max account, open Settings, Customize, then Connectors, click the plus button, and choose Add custom connector. Paste the Zstem MCP URL and click Connect to complete the OAuth approval. On Team or Enterprise, an Owner adds it once from Organization settings, Connectors, Add, Custom, Web.

Once the connector exists, open a new chat, use the plus button, open Connectors, and enable Zstem for that conversation.

Confirm it works

1. Start a new conversation or coding session.
2. Ask Claude to list your Zstem projects.
3. Create a small test project.
4. Open it in Zstem and review the diagrams and documents.

If the project appears in Zstem with the views populated, the connection is working and the rest of this article applies.

How to connect Zstem MCP to ChatGPT

ChatGPT can connect to MCP-backed apps through developer mode. OpenAI’s current setup flow is available under Settings, Security and login, then Developer mode. Developer-mode apps are managed through Settings, Plugins, where the remote HTTPS MCP endpoint can be added. See OpenAI’s connection guide.

Use the Zstem MCP endpoint:

https://api.zstem.design/mcp

After connecting it:

1. Start a new conversation.
2. Add Zstem from the available tools.
3. Ask Zstem to list your projects to confirm access.
4. Create a small test project.
5. Review the diagrams and documents in Zstem.

A copyable starter prompt

Use this template for your own project:

Create a Zstem project for [product or feature].

Users need to [primary user outcome].

The important constraints are [security, scale, cost, privacy, performance, or operational constraints].

Create the architecture, main user workflow, critical request sequence, API contract, database schema, event flow, and technical decision document. Clearly separate confirmed requirements from assumptions. Include failure behaviour and unanswered questions. Prefer the simplest design that satisfies the stated requirements.

Start with a system, not a blank canvas

AI coding becomes far more useful when the agent can see the system around the code.

MCP gives the assistant a way to work with real tools. Zstem gives the resulting architecture, behaviour, data, contracts, and decisions a connected home.

The outcome is not simply faster diagramming. It is a development workflow where product intent can survive the journey from idea to implementation.

Explore the live AI-assisted customer support project in Zstem.

Connect Zstem MCP and create your first implementation-ready system design.

Connect Zstem MCP

Frequently asked questions

What is MCP in AI development?

MCP is an open standard that allows compatible AI clients to connect to external tools and resources. An MCP server defines capabilities that the model can call with structured inputs and outputs. It is vendor-neutral and governed by the Linux Foundation’s Agentic AI Foundation, so the same server works across Claude, ChatGPT, and Codex.

How do I connect Zstem to Claude?

Run claude mcp add --transport http zstem https://api.zstem.design/mcp for Claude Code, or add the same URL as a custom connector under Settings, Customize, Connectors on claude.ai. Authentication is OAuth by default; personal access tokens are available in Zstem under Settings if you prefer a header. See connecting Zstem MCP to Claude for the full walkthrough.

Is Zstem only an AI diagram generator?

No. Zstem connects architecture, APIs, database schemas, sequences, events, workflows, design notes, and implementation context within a project. Diagram generation is one part of the workflow.

Can Zstem be used without generating code?

Yes. It can support planning, requirements workshops, architecture review, technical documentation, onboarding, reverse engineering, and implementation handoff.

Can I update an existing Zstem project through chat?

Yes. The Zstem MCP exposes tools for reading and updating supported project views. The assistant can preserve unrelated parts while applying an approved change to specific diagrams or documents.

Does more context always improve AI-generated code?

Only when the context is relevant, consistent, and reviewed. Large amounts of contradictory or outdated information can make results worse. Structured context helps because each view has a clear purpose and can be verified independently.

Can I use Zstem while away from my desk?

Yes. You can describe or review a system from a supported device and let the AI assistant structure the result through MCP. Voice transcription can also be used as an optional input when typing is inconvenient.