MCP Architecture: Clients, Servers, Tools, Resources, and Prompts

Understanding how Model Context Protocol works under the hood helps you build better integrations and troubleshoot issues. This guide explains the core architectural concepts of MCP.

The MCP Architecture Overview

MCP follows a client-server architecture where AI assistants (clients) connect to services (servers) that provide tools and data. Here's how it works:

Architecture Diagram (Text Description)

┌─────────────────┐
│  AI Assistant   │
│   (MCP Client)  │
│                 │
│  - Claude       │
│  - Cursor       │
│  - Windsurf     │
└────────┬────────┘
         │
         │ HTTP/SSE Connection
         │ (with Auth Header)
         │
         ▼
┌─────────────────┐
│  MCP Server 1   │  ┌─────────────────┐
│   (Corcava)     │  │  MCP Server 2   │
│                 │  │  (Other Service)│
│  Tools:         │  │                 │
│  - list_tasks   │  │  Tools:         │
│  - create_task  │  │  - read_file    │
│  - start_timer  │  │  - search_code  │
└─────────────────┘  └─────────────────┘
         │                     │
         └─────────┬───────────┘
                   │
         ┌─────────▼─────────┐
         │   Data Sources    │
         │  (Corcava DB,     │
         │   File System)    │
         └───────────────────┘

A single MCP client can connect to multiple MCP servers simultaneously, giving the AI assistant access to tools from different services in one conversation.

MCP Client: The AI Assistant

The MCP client is the AI assistant application that users interact with. It's responsible for:

Connection Management: Establishing and maintaining connections to MCP servers
Tool Discovery: Requesting and caching available tools from each server
Request Routing: Determining which server to call for each tool
Response Handling: Processing tool results and presenting them to users
Error Management: Handling connection failures, timeouts, and errors gracefully

Example: Claude Desktop as MCP Client

When you ask Claude Desktop "What tasks are due this week?", the client:

Identifies that this requires calling a tool from the Corcava MCP server
Sends a request to https://app.corcava.com/mcp with your API key
Calls the list_tasks tool with appropriate filters
Receives the task list and formats it for you

MCP Server: The Service Provider

The MCP server exposes tools, resources, and prompts to clients. Corcava's MCP server provides project management capabilities:

Server Responsibilities

Authenticate requests (API keys)
Authorize operations (team scoping)
Execute tool calls
Return structured responses
Handle errors gracefully

Server Capabilities

Expose tool schemas
Provide resource metadata
Offer prompt templates
Support streaming responses
Log operations for auditing

Tool Discovery: How Clients Find Tools

When an MCP client connects to a server, it first discovers what tools are available through the tools/list endpoint:

Discovery Flow

Client connects to server with authentication
Client requests tools/list to get available tools
Server responds with tool schemas (name, description, parameters)
Client caches tool information for the session
Client can now call tools by name when needed

Each tool has a schema that describes:

Name: Unique identifier (e.g., list_tasks)
Description: What the tool does
Parameters: Required and optional inputs
Returns: Expected output format

How Tool Calls Flow

When you ask your AI assistant to perform an action, here's what happens behind the scenes:

Tool Call Flow Example

1. User: "Create a task to follow up with Acme Corp"

2. AI Assistant (Client):
   - Analyzes the request
   - Identifies this needs create_task tool
   - Determines tool is from Corcava MCP server
   - Extracts parameters: title, description, etc.

3. Client → Server Request:
   POST https://app.corcava.com/mcp
   Headers: Authorization: Bearer API_KEY
   Body: {
     "tool": "create_task",
     "arguments": {
       "title": "Follow up with Acme Corp",
       "description": "...",
       "due_date": "..."
     }
   }

4. Server Processing:
   - Validates API key
   - Checks permissions
   - Creates task in database
   - Returns task object

5. Server → Client Response:
   {
     "task": {
       "id": 123,
       "title": "Follow up with Acme Corp",
       "status": "open",
       ...
     }
   }

6. AI Assistant (Client):
   - Receives response
   - Formats for user
   - Confirms task creation

7. User sees: "I've created task #123: Follow up with Acme Corp"

Corcava MCP Tools in Action

Here's how Corcava's MCP tools map to common project management actions:

Creating a Task

User Request: "Create a task to review the Q4 report"

Tool Called: create_task

Parameters:

title: "Review Q4 report"
description: (generated from context)
project_id: (inferred or specified)

Result: New task created with ID and full details returned

Adding a Comment

User Request: "Add a comment to task #123 that I've completed the API changes"

Tool Called: add_task_comment

Parameters:

task_id: 123
comment: "Completed API changes. Ready for review."

Result: Comment added to task with timestamp

Starting Time Tracking

User Request: "Start tracking time on my current task"

Tool Called: start_time_tracking

Parameters:

task_id: (identified from context or user's active task)

Result: Time tracking started, timer running

Multiple Servers, One Conversation

One of MCP's powerful features is the ability to connect to multiple servers simultaneously. Your AI assistant can use tools from different services in the same conversation:

Example: Multi-Server Workflow

User: "Create a task for reviewing the API documentation, then search our codebase for similar patterns"

AI Assistant:

Calls create_task from Corcava MCP server
Calls search_code from codebase MCP server
Combines results and presents unified response

Transport Layer: HTTP vs STDIO

MCP supports two transport mechanisms:

Remote Servers (HTTP/SSE)

Corcava uses this approach:

Server runs as a web service
Client connects via HTTP/HTTPS
Supports Server-Sent Events (SSE) for streaming
Multi-user, centralized deployment
Better for SaaS applications

Local Servers (STDIO)

Alternative approach:

Server runs as a local process
Client communicates via standard input/output
Single-user, local deployment
Better for personal tools
No network required

Learn more about the tradeoffs in our remote vs local MCP servers guide.

Error Handling and Resilience

MCP includes built-in error handling:

Connection Errors: Clients retry with exponential backoff
Authentication Failures: Clear error messages guide users to fix API keys
Validation Errors: Servers return detailed error messages for invalid parameters
Rate Limiting: Servers can signal rate limits, clients back off appropriately
Timeout Handling: Long-running operations can be cancelled or polled

Ready to Build with MCP?

Connect your AI assistant to Corcava and start automating your workflows

Start Free Trial →Read Quickstart Guide

No credit card required