MCPClaude CodeAI Integration

How to Use an MCP Server for Product Design

A practical guide to the Model Context Protocol and how Intent's MCP server gives Claude Code direct access to your product specs.

Intent Team9 min read

You've written a detailed product spec. Your data models are defined. Your API contracts are documented. Your user stories have acceptance criteria. But when you open Claude Code and start building, the AI has no idea any of this exists.

This is the disconnect that the Model Context Protocol (MCP) solves. MCP lets AI tools like Claude Code connect directly to external systems, including your product specs, so that the AI has access to your design decisions as persistent context while it writes code.

This article explains what MCP is, how MCP servers work, and how to set up Intent's MCP server so Claude Code can read your specs while you build.

What Is MCP and Why Does It Matter

The Model Context Protocol is an open standard created by Anthropic that defines how AI applications communicate with external data sources and tools. Think of it as a USB-C port for AI: a standardized interface that lets any AI client connect to any compatible server.

Before MCP, giving an AI tool access to external data required custom integrations. Each tool had its own plugin system, its own API format, its own authentication flow. If you wanted Claude Code to access your project management tool, your documentation system, and your spec tool, you'd need three separate integrations.

MCP standardizes this. An MCP server exposes data and functionality through a defined protocol. Any MCP client (like Claude Code, Cursor, or other AI tools that support the standard) can connect to any MCP server and immediately use its capabilities.

The protocol defines three types of capabilities a server can expose:

  • Resources: Read-only data the AI can access, like documents, specs, or configuration files.
  • Tools: Actions the AI can execute, like creating a ticket, running a query, or checking implementation status.
  • Prompts: Pre-defined prompt templates that help the AI use the server's capabilities effectively.

The Problem of Disconnected Product Knowledge

Most teams keep their product knowledge in scattered locations: specs in Google Docs, user stories in Jira, data models on a whiteboard photo, API contracts in a Confluence page, architecture decisions in an ADR folder that nobody remembers exists.

When a developer sits down to implement a feature, they have to manually gather context from all these sources. When they use an AI coding tool, the context problem is even worse, because the AI can only work with what it's explicitly given.

The typical workflow looks like this:

  1. Developer reads the spec in Google Docs.
  2. Developer opens Claude Code.
  3. Developer manually copies relevant parts of the spec into the prompt.
  4. Claude Code generates code based on the pasted context.
  5. Developer realizes they forgot to include the error response format.
  6. Developer goes back to the spec, copies more context, re-prompts.

This manual context-shuttling is slow, error-prone, and defeats the purpose of having a structured spec in the first place. The spec exists, but the AI tool can't see it.

MCP eliminates this gap. When your specs live in a system with an MCP server, Claude Code can read them directly. No copying. No pasting. No context lost in translation.

How MCP Servers Work

An MCP server is a lightweight process that communicates with AI clients using the MCP protocol. The most common transport is stdio (standard input/output), where the server runs as a subprocess of the AI client and they communicate through stdin/stdout using JSON-RPC messages.

Here's the basic architecture:

Claude Code (MCP Client)
    |
    | stdin/stdout (JSON-RPC)
    |
MCP Server Process
    |
    | HTTP/API calls
    |
External System (Intent, database, etc.)

When Claude Code starts and an MCP server is configured, it launches the server process and queries it for available tools and resources. The server responds with a list of capabilities. From that point forward, Claude Code can call those tools and read those resources as part of its normal workflow.

A simplified MCP tool definition looks like this:

{
  "name": "get_project_spec",
  "description": "Retrieve the complete specification for a project, including features, user stories, data models, and API contracts",
  "inputSchema": {
    "type": "object",
    "properties": {
      "project_id": {
        "type": "string",
        "description": "The ID of the project to retrieve the spec for"
      }
    },
    "required": ["project_id"]
  }
}

When Claude Code decides it needs the project spec (either because you asked for it or because it determines the context would be helpful), it calls this tool. The MCP server handles the request, fetches the data from the external system, and returns it to Claude Code as structured content.

Intent's MCP Server Capabilities

Intent's MCP server exposes your product specs and project metadata to Claude Code through several tools:

Reading Project Specifications

The primary tool retrieves the full specification for a project. This includes features, user stories, data models, API endpoints, and architecture decisions, everything defined in your Intent project.

// Claude Code can call this tool to get the full spec
{
  tool: "get_project_spec",
  arguments: {
    project_id: "proj_abc123"
  }
}

// Returns structured spec data:
{
  project: {
    name: "Acme Platform",
    features: [...],
    user_stories: [...],
    data_models: [...],
    api_endpoints: [...],
    architecture: [...]
  }
}

When Claude Code has this context, it can generate code that matches your spec exactly: correct field names, correct validation rules, correct API response formats, correct error handling.

Listing Projects and Features

The server provides tools to list available projects and their features, so Claude Code can discover what specs are available and navigate to the right context.

// List all projects in the organization
{ tool: "list_projects" }

// List features within a project
{
  tool: "list_features",
  arguments: { project_id: "proj_abc123" }
}

Checking Implementation Status

One of the more powerful capabilities is checking whether a spec has been implemented. The server can compare your specification against your actual codebase to identify gaps.

// Check implementation status for a feature
{
  tool: "check_implementation_status",
  arguments: {
    project_id: "proj_abc123",
    feature_id: "feat_xyz789"
  }
}

// Returns:
{
  feature: "User Authentication",
  status: "partial",
  implemented: [
    "POST /api/v1/auth/login",
    "POST /api/v1/auth/register"
  ],
  missing: [
    "POST /api/v1/auth/forgot-password",
    "POST /api/v1/auth/reset-password"
  ]
}

This lets you ask Claude Code things like "what parts of the spec haven't been implemented yet?" and get an accurate, up-to-date answer.

Setting Up Intent's MCP Server

Setting up the MCP server takes a few minutes. Here's the step-by-step process.

Step 1: Get Your API Key

In Intent, navigate to your organization settings and generate an API key. This key authenticates the MCP server with your Intent account.

Step 2: Configure Claude Code

Claude Code reads MCP server configuration from its settings file. Add Intent's MCP server to your project-level configuration by creating or editing .mcp.json in your project root:

{
  "mcpServers": {
    "intent": {
      "command": "npx",
      "args": ["-y", "@anthropic/intent-mcp-server"],
      "env": {
        "INTENT_API_KEY": "your-api-key-here"
      }
    }
  }
}

Alternatively, you can add it to your global Claude Code configuration so it's available in all projects.

Step 3: Verify the Connection

Restart Claude Code (or reload the window if using an IDE integration). Claude Code will automatically start the MCP server and discover its tools. You can verify by asking Claude Code:

What MCP tools are available?

You should see the Intent tools listed, including get_project_spec, list_projects, and check_implementation_status.

Step 4: Link Your Project

If your Intent project isn't automatically detected, you can tell Claude Code which project to use:

Use the Intent project "Acme Platform" for spec context.

Claude Code will use the MCP server to fetch the project details and keep them as context for the rest of the session.

Example Workflow: Building a Feature With MCP

Here's what a realistic development session looks like when Claude Code has access to your specs through MCP.

Starting the Feature

You open Claude Code and say:

I need to implement the "Team Invitations" feature.
Pull the spec from Intent first.

Claude Code calls the MCP server, retrieves the spec for the Team Invitations feature, and now has full context: the data model for invitations, the API endpoints, the user flows, the error states, and the acceptance criteria.

Generating the Backend

You continue:

Generate the API endpoint for creating an invitation based on the spec.

Claude Code doesn't need you to explain the fields, validation rules, or response format. It already has them from the spec. It generates:

@router.post("/api/v1/teams/{team_id}/invitations", status_code=201)
async def create_invitation(
    team_id: UUID,
    request: CreateInvitationRequest,
    current_user: User = Depends(get_current_user),
    db: AsyncSession = Depends(get_db),
):
    # Verify user is team owner or admin
    team_member = await team_repo.get_member(db, team_id, current_user.id)
    if not team_member or team_member.role not in ["owner", "admin"]:
        raise HTTPException(status_code=403, detail="Not authorized to invite members")

    # Check if user is already a member
    existing = await team_repo.get_member_by_email(db, team_id, request.email)
    if existing:
        raise HTTPException(status_code=409, detail="User is already a team member")

    # Check for pending invitation
    pending = await invitation_repo.get_pending_by_email(db, team_id, request.email)
    if pending:
        raise HTTPException(status_code=409, detail="An invitation has already been sent to this email")

    invitation = await invitation_repo.create(
        db,
        team_id=team_id,
        email=request.email,
        role=request.role or "member",
        invited_by=current_user.id,
    )

    await send_invitation_email(invitation)

    return InvitationResponse.model_validate(invitation)

The field names, error messages, status codes, and business logic all match the spec, because Claude Code read the spec through MCP before generating the code.

Checking Progress

Midway through implementation, you ask:

What parts of the Team Invitations feature still need to be implemented?

Claude Code calls check_implementation_status through the MCP server and reports:

Based on the spec, the following are still missing:
- DELETE /api/v1/teams/{team_id}/invitations/{id} (cancel invitation)
- POST /api/v1/invitations/{token}/accept (accept invitation)
- Frontend: Invitation management page
- Frontend: Accept invitation flow

This keeps you aligned with the spec without manually tracking progress.

When MCP Makes the Biggest Difference

MCP provides value in any project, but the impact is most significant in specific situations:

Multi-developer teams. When multiple developers are implementing different parts of the same feature, MCP ensures they all work from the same spec. The API developer and the frontend developer get identical context.

Long-running features. For features that take days or weeks to implement, the spec serves as persistent memory across Claude Code sessions. You don't have to re-explain the context every time you start a new session.

Onboarding. New team members can ask Claude Code to explain any part of the system, and the AI can pull the spec to give accurate, up-to-date answers rather than hallucinating based on partial code analysis.

Verification. After implementation, you can ask Claude Code to compare what was built against what was specified, catching drift before it becomes a problem.

Beyond Reading: The Future of Spec-Connected AI

Today, MCP servers primarily provide read access to specs. But the protocol supports bidirectional communication. Future capabilities could include AI tools that update specs based on implementation discoveries, flag spec-code divergence automatically, or suggest spec modifications when new requirements emerge.

The core idea remains the same: your product specifications shouldn't be passive documents that developers read once and forget. They should be living, connected artifacts that your AI tools can access, reference, and act on throughout the entire development lifecycle.

MCP is the protocol that makes this connection possible. Intent provides the structured specs worth connecting to. Together, they close the gap between what you intend to build and what you actually build.

Related articles

Cursor

How to Get Better Output from Cursor and Claude Code

Practical tips for getting AI coding tools to produce better, more consistent code — starting with how you give them context.

Spec-Driven Development

The Complete Guide to Spec-Driven Development

Learn what spec-driven development is, why it matters in the age of AI code generation, and how to implement it step by step.

AI Tools

Stop Re-Prompting: Why Your AI Coding Tool Needs a Spec

If you're constantly re-prompting Cursor, Claude, or Copilot, the problem isn't the AI — it's the missing spec. Here's how to fix it.

Ready to write specs that actually work?

Intent helps you structure product ideas, generate visual previews, and export specs your dev team and AI tools can use immediately.

Start free trial

7-day trial · Full access · Cancel anytime