DEV Community

Cover image for MCP-USE Explained: Building Full-Stack AI Agents and MCP Apps with TypeScript and Python
Ignacio Gonzalez Bohorquez
Ignacio Gonzalez Bohorquez

Posted on

MCP-USE Explained: Building Full-Stack AI Agents and MCP Apps with TypeScript and Python

#python #ai #agents #typescript

The Model Context Protocol (MCP) has quickly become an important building block for connecting AI applications with external tools, data, APIs, and services.

At its core, MCP provides a standardized protocol through which AI applications can discover and interact with capabilities exposed by MCP servers.

But there is an important distinction between implementing MCP and building an application around MCP.

Writing an MCP server is only one part of the problem.

A production-grade AI application may also need:

  • MCP clients
  • LLM integration
  • Agent orchestration
  • Tool discovery and execution
  • Authentication
  • Multiple MCP servers
  • Structured outputs
  • Observability and debugging
  • Interactive user interfaces
  • Deployment and testing

This is where mcp-use becomes interesting.

mcp-use is an open-source framework designed to make it easier to build applications around MCP, including MCP clients, agents, servers, and, in its TypeScript ecosystem, interactive MCP Apps.

This article explores the architecture, the problems mcp-use solves, and how to use it to build MCP-powered AI applications.

Table of Contents

  1. What Problem Does MCP Solve?
  2. MCP Is Not an Agent Framework
  3. What Is mcp-use?
  4. The Dual Nature of mcp-use
  5. MCP Tools: The Bridge Between LLMs and Real Systems
  6. Type Safety With Schemas
  7. mcp-use and Agents
  8. Connecting Multiple MCP Servers
  9. MCP Resources vs Tools
  10. Interactive MCP Apps
  11. Why UI + MCP Is Interesting
  12. The mcp-use Inspector
  13. Testing MCP Servers From the CLI
  14. Authentication
  15. Structured Output
  16. Integrating With Existing Agent Frameworks
  17. Python vs TypeScript
  18. A Simple End-to-End Architecture
  19. What mcp-use Actually Adds

1. What Problem Does MCP Solve?

Before understanding mcp-use, it is important to understand MCP itself.

An LLM can generate text, but by itself it does not automatically have access to your database, Git repository, internal APIs, filesystem, browser, or business applications.

Traditionally, every AI application had to implement its own integration mechanism.

For example:

LLM
 |
 +-- Custom weather API integration
 |
 +-- Custom database integration
 |
 +-- Custom GitHub integration
 |
 +-- Custom filesystem integration
 |
 +-- Custom browser integration
Enter fullscreen mode Exit fullscreen mode

As the number of integrations grows, this becomes increasingly difficult to maintain.

MCP introduces a standardized interface between AI applications and external capabilities.

Conceptually:

                 MCP
                  |
        +---------+---------+
        |                   |
     Client              Server
        |                   |
       LLM          Tools / Resources
                            |
                    External systems
Enter fullscreen mode Exit fullscreen mode

An MCP server can expose capabilities such as:

Tools
 ├── search_database()
 ├── create_ticket()
 └── deploy_application()

Resources
 ├── database://customers
 └── file://documentation

Prompts
 ├── analyze_customer()
 └── generate_report()
Enter fullscreen mode Exit fullscreen mode

The AI application can then discover and use these capabilities through MCP.

The key idea is that MCP standardizes the communication between AI applications and external capabilities.

2. MCP Is Not an Agent Framework

This distinction is extremely important.

MCP defines how applications communicate with tools and contextual capabilities.

It does not require you to use a particular LLM or agent framework.

Think of MCP as a standardized communication layer:

                  AI Application
                       |
                +------+------+
                |             |
              Agent          LLM
                |
             MCP Client
                |
          Model Context Protocol
                |
             MCP Server
                |
        +-------+-------+
        |       |       |
      API      DB     Files
Enter fullscreen mode Exit fullscreen mode

Each layer has a different responsibility.

LLM

The LLM performs reasoning and generates responses.

Agent

The agent orchestrates the workflow and determines what should happen next.

MCP Client

The MCP client connects the application or agent to MCP servers.

MCP

MCP defines the standardized communication protocol.

MCP Server

The server exposes capabilities such as tools, resources, and prompts.

External Systems

These are the actual systems being accessed:

Databases
APIs
GitHub
Cloud platforms
Files
SaaS applications
Enterprise systems
Enter fullscreen mode Exit fullscreen mode

Therefore:

MCP is a protocol, not an agent framework.

This distinction becomes extremely important when designing AI architectures.

3. What Is mcp-use?

mcp-use provides higher-level tooling for building applications on top of MCP.

The current ecosystem includes both Python and TypeScript implementations.

The TypeScript framework provides a broader full-stack development experience including:

  • MCP servers
  • MCP clients
  • Agents
  • Typed tools
  • Interactive Views
  • MCP Apps
  • Inspector
  • CLI tooling

The Python ecosystem focuses heavily on connecting LLMs and agents to MCP servers.

At a conceptual level:

                 Your AI Application
                         |
              +----------+----------+
              |                     |
             LLM                  Agent
              |                     |
              +----------+----------+
                         |
                      mcp-use
                         |
                 +-------+-------+
                 |               |
             MCP Client      MCP Server
                 |               |
                 +-------+-------+
                         |
                 External systems
Enter fullscreen mode Exit fullscreen mode

The important idea is that mcp-use provides abstractions around the MCP ecosystem, instead of requiring developers to implement every layer manually.

4. The Dual Nature of mcp-use

One of the interesting aspects of mcp-use is that it is not limited to one side of the MCP connection.

It can be understood as supporting two major directions.

Server Side

You can build MCP servers that expose:

  • Tools
  • Data
  • Resources
  • UI capabilities

Client / Agent Side

You can build applications that:

  • Connect to MCP servers
  • Discover tools
  • Invoke tools
  • Read resources
  • Use prompts
  • Give those capabilities to an LLM or agent

Conceptually:

                    mcp-use
                       |
          +------------+------------+
          |                         |
       Server                    Client
          |                         |
      Exposes                   Consumes
          |                         |
     Tools / Data               Tools / Data
          |                         |
          +----------- MCP ---------+
Enter fullscreen mode Exit fullscreen mode

This is an important architectural distinction.

You are not simply building:

"an MCP server."

You can build an entire application ecosystem around MCP.

5. MCP Tools: The Bridge Between LLMs and Real Systems

One of the fundamental MCP concepts is the tool.

A tool gives a model the ability to request an operation.

For example:

def add_numbers(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b
Enter fullscreen mode Exit fullscreen mode

The important concept is not simply the function itself.

The important part is that the function has a machine-readable identity and schema.

A tool can conceptually be represented as:

Tool
 |
 +-- name
 +-- description
 +-- input schema
 +-- execution logic
 +-- output
Enter fullscreen mode Exit fullscreen mode

This allows the model or agent to reason about what capabilities are available.

A simplified workflow looks like:

User
 |
 | "What is the weather in Madrid?"
 v
LLM
 |
 | discovers get_weather
 v
MCP Client
 |
 | tools/call
 v
MCP Server
 |
 | call weather API
 v
Weather API
 |
 v
MCP Server
 |
 v
MCP Client
 |
 v
LLM
 |
 v
User
Enter fullscreen mode Exit fullscreen mode

The important idea is:

Tools give AI applications the ability to interact with real systems.

Instead of simply generating text, an agent can request that an external operation be executed.

6. Type Safety With Schemas

One of the major themes in the mcp-use TypeScript ecosystem is type-safe tool definitions.

For example:

import { MCPServer } from "mcp-use";
import { z } from "zod";

const server = new MCPServer({
  name: "weather-app",
  title: "Weather App",
  version: "1.0.0",
});

const weatherInput = z.object({
  city: z.string().describe("City to look up"),
});

const weatherOutput = z.object({
  city: z.string(),
  temperature: z.number(),
  conditions: z.string(),
});

server.tool(
  {
    name: "get-weather",
    title: "Get weather",
    description: "Get the current weather for a city",
    inputSchema: weatherInput,
    outputSchema: weatherOutput,
  },
  async ({ city }) => {
    const weather = {
      city,
      temperature: 22,
      conditions: "Sunny",
    };

    return {
      content: [
        {
          type: "text",
          text: `Weather in ${city}: ${weather.conditions}, ${weather.temperature}°C`,
        },
      ],
      structuredContent: weather,
    };
  },
);
Enter fullscreen mode Exit fullscreen mode

Here, Zod defines the contract.

                 Zod schema
                     |
                     v
             +---------------+
             | Input contract |
             +---------------+
                     |
                     v
                  Tool
                     |
                     v
             +----------------+
             | Output contract|
             +----------------+
Enter fullscreen mode Exit fullscreen mode

Instead of passing arbitrary JSON around, developers can define explicit contracts.

For example:

Input

city: string
Enter fullscreen mode Exit fullscreen mode

and:

Output

city: string
temperature: number
conditions: string
Enter fullscreen mode Exit fullscreen mode

This becomes increasingly valuable as MCP applications become larger.

Schemas provide:

  • Validation
  • Predictability
  • Type safety
  • Better developer experience
  • More reliable tool integration

The key principle is:

Schemas turn AI/tool communication into a defined contract.

7. mcp-use and Agents

An MCP server becomes considerably more useful when an agent can reason over the available tools.

The architecture becomes:

                    User
                      |
                      v
                    Agent
                      |
              +-------+-------+
              |               |
             LLM          MCP Client
              |               |
              +-------+-------+
                      |
                 MCP Servers
                      |
        +-------------+-------------+
        |             |             |
      GitHub        Database      Browser
Enter fullscreen mode Exit fullscreen mode

The agent can determine which capability is relevant to a particular request.

For example:

"Find the latest customer issues, analyze the data, and create a summary."

The agent might perform:

1. Search database
       ↓
2. Read customer records
       ↓
3. Analyze information
       ↓
4. Generate structured result
       ↓
5. Return summary
Enter fullscreen mode Exit fullscreen mode

This is where MCP becomes particularly powerful for agentic applications.

The agent provides the reasoning and orchestration.

MCP provides the standardized capability layer.

The MCP servers provide the actual tools and data.

So:

Agent
  ↓
Reason
  ↓
Select capability
  ↓
MCP tool
  ↓
External system
  ↓
Result
  ↓
Agent
  ↓
Next step
Enter fullscreen mode Exit fullscreen mode

8. Connecting Multiple MCP Servers

A particularly useful capability is working with multiple MCP servers.

Imagine an enterprise agent with:

                 AI Agent
                    |
               mcp-use Client
                    |
        +-----------+-----------+
        |           |           |
      GitHub      Database    Browser
       MCP          MCP         MCP
        |           |           |
     GitHub        SQL       Playwright
Enter fullscreen mode Exit fullscreen mode

The agent can potentially combine capabilities from multiple systems.

For example:

"Find the open GitHub issues related to customers who experienced payment failures last month."

The agent could conceptually perform:

GitHub MCP
    |
    | Find issues
    v
Issue data

Database MCP
    |
    | Query payment failures
    v
Customer data

          ↓

       Agent
          |
          v
   Correlate information
          |
          v
       Answer
Enter fullscreen mode Exit fullscreen mode

This is one of the compelling use cases for MCP.

Instead of building one giant integration, capabilities can be exposed through separate MCP servers.

This creates a more modular architecture:

             Agent
               |
           MCP Client
               |
      +--------+--------+
      |        |        |
     MCP      MCP      MCP
   Server   Server   Server
      |        |        |
     CRM       DB     GitHub
Enter fullscreen mode Exit fullscreen mode

Each server can specialize in a particular domain.

9. MCP Resources vs Tools

A common MCP architectural distinction is between resources and tools.

A useful mental model is:

Resources → information/context

Tools → actions/operations
Enter fullscreen mode Exit fullscreen mode

For example:

Resource:

database://customers/123
Enter fullscreen mode Exit fullscreen mode

The resource represents information that can be accessed.

Whereas:

Tool:

update_customer(customer_id, data)
Enter fullscreen mode Exit fullscreen mode

represents an operation that can be executed.

The distinction can be summarized as:

RESOURCE
    ↓
"Give me information."

TOOL
    ↓
"Do something."
Enter fullscreen mode Exit fullscreen mode

This is important because not every capability should be modeled as an executable action.

For example:

Customer profile
       ↓
   Resource
Enter fullscreen mode Exit fullscreen mode

while:

Update customer
       ↓
      Tool
Enter fullscreen mode Exit fullscreen mode

A simple memory trick is:

Resource = information. Tool = action.

10. Interactive MCP Apps

One of the areas where the current TypeScript version of mcp-use goes beyond a basic MCP server framework is interactive Views and MCP Apps.

Traditional tool calling might look like:

Tool
 |
 v
Text
Enter fullscreen mode Exit fullscreen mode

An MCP App can instead provide:

Tool
 |
 v
Structured data
 |
 v
React View
 |
 v
Interactive UI
Enter fullscreen mode Exit fullscreen mode

For example, imagine a weather tool.

Instead of returning:

Weather in Madrid:
22°C
Sunny
Enter fullscreen mode Exit fullscreen mode

the application could render:

+--------------------------------+
|         Madrid Weather         |
|                                |
|             ☀️                 |
|                                |
|             22°C               |
|             Sunny              |
|                                |
|        [ Refresh ]             |
+--------------------------------+
Enter fullscreen mode Exit fullscreen mode

This is a significant conceptual shift.

The application is no longer limited to:

AI → Tool → Text
Enter fullscreen mode Exit fullscreen mode

It can become:

AI → Tool → Structured Data → UI
Enter fullscreen mode Exit fullscreen mode

This opens the door to:

  • Interactive dashboards
  • Maps
  • Data visualizations
  • Diagrams
  • Search interfaces
  • Configuration panels
  • Approval workflows
  • Business applications

The key idea is:

MCP can become not only a capability interface, but also part of an interactive application experience.

11. Why UI + MCP Is Interesting

Traditional tool calling looks like:

LLM
 |
 | call tool
 v
Tool
 |
 v
Result
 |
 v
LLM
 |
 v
Text response
Enter fullscreen mode Exit fullscreen mode

With an MCP App:

LLM
 |
 | call tool
 v
MCP Server
 |
 +---- structured result
 |
 +---- UI/View
        |
        v
      User
Enter fullscreen mode Exit fullscreen mode

This creates a different interaction model.

For example, an AI assistant could call a data-analysis tool and return:

Tool
 ↓
Query database
 ↓
Analyze data
 ↓
Generate structured result
 ↓
Render chart
 ↓
User interacts with chart
Enter fullscreen mode Exit fullscreen mode

Possible applications include:

Data analysis 

Database
   ↓
MCP
   ↓
Agent
   ↓
Chart
Enter fullscreen mode Exit fullscreen mode

Maps 

Location data
     ↓
MCP
     ↓
Agent
     ↓
Interactive map
Enter fullscreen mode Exit fullscreen mode

Business workflows 

Agent
  ↓
MCP Tool
  ↓
Approval UI
  ↓
Human decision
  ↓
Action
Enter fullscreen mode Exit fullscreen mode

This is particularly interesting for enterprise applications because the AI does not necessarily have to produce a long textual response for every task.

It can produce an interactive application experience.

12. The mcp-use Inspector

Debugging AI applications can be difficult.

Consider the following chain:

LLM
 ↓
Agent
 ↓
MCP Client
 ↓
MCP Server
 ↓
Database
Enter fullscreen mode Exit fullscreen mode

If something goes wrong, where is the problem?

  • Did the model select the wrong tool?
  • Was the schema incorrect?
  • Did the MCP client send the wrong arguments?
  • Did the server reject the request?
  • Did the database fail?

This is why an MCP Inspector is valuable.

The current TypeScript mcp-use stack includes an Inspector that allows developers to inspect MCP servers and invoke tools during development.

A typical development workflow becomes:

Write tool
    ↓
Run server
    ↓
Open Inspector
    ↓
Inspect schema
    ↓
Invoke tool
    ↓
Inspect result
    ↓
Debug
    ↓
Modify code
    ↓
Repeat
Enter fullscreen mode Exit fullscreen mode

The development server can be started with:

mcp-use dev
Enter fullscreen mode Exit fullscreen mode

The Inspector provides a visual environment for examining and testing MCP capabilities.

This shortens the development feedback loop considerably.

13. Testing MCP Servers From the CLI

Another useful feature is the mcp-use CLI.

For example:

npx mcp-use client connect dev http://localhost:3000/mcp
Enter fullscreen mode Exit fullscreen mode

You can then inspect available tools:

npx mcp-use client dev tools list
Enter fullscreen mode Exit fullscreen mode

And invoke a tool:

npx mcp-use client dev tools call get-weather city=Tokyo
Enter fullscreen mode Exit fullscreen mode

The basic workflow is:

MCP Server
    ↓
CLI
    ↓
Discover tools
    ↓
Inspect schema
    ↓
Call tool
    ↓
Inspect result
Enter fullscreen mode Exit fullscreen mode

This is useful for:

  • Development
  • Debugging
  • Testing
  • Automation
  • CI/CD workflows

It also provides a convenient way to test MCP capabilities without relying exclusively on a graphical AI client.

The important idea is:

MCP capabilities can be developed and tested like other software interfaces.

14. Authentication

Once MCP moves beyond localhost, authentication becomes critical.

An MCP architecture needs to consider:

Authentication
Authorization
Secrets
HTTPS
Token management
Least privilege
Enter fullscreen mode Exit fullscreen mode

A simplified architecture is:

AI Agent
    |
MCP Client
    |
Authentication
    |
MCP Server
    |
External System
Enter fullscreen mode Exit fullscreen mode

For example, an enterprise MCP server might require OAuth or another authentication mechanism before allowing the client to access protected capabilities.

Credentials should never be hardcoded into source code.

Avoid:

API_KEY = "my-secret-key"
Enter fullscreen mode Exit fullscreen mode

Instead use mechanisms such as:

Environment variables
Secret managers
OAuth
Managed identity
Enter fullscreen mode Exit fullscreen mode

depending on the architecture.

Authentication answers:

"Who are you?"

Authorization answers:

"What are you allowed to do?"

These are different security concerns.

For an AI agent, authorization is particularly important because tools can perform real actions.

For example:

Agent
 |
 +-- READ customer data
 |
 +-- READ tickets
 |
 +-- CREATE ticket
 |
 X-- DELETE production database
Enter fullscreen mode Exit fullscreen mode

The principle is:

Give the agent only the capabilities it actually needs.

15. Structured Output

Another important capability for agentic applications is structured output.

Instead of asking an agent to return:

"The temperature is 22 degrees
and it is sunny."
Enter fullscreen mode Exit fullscreen mode

you can define a schema:

from pydantic import BaseModel

class WeatherInfo(BaseModel):
    city: str
    temperature: float
    condition: str
    humidity: int
Enter fullscreen mode Exit fullscreen mode

The result can then be represented as structured data:

{
  "city": "Madrid",
  "temperature": 22,
  "condition": "Sunny",
  "humidity": 45
}
Enter fullscreen mode Exit fullscreen mode

This becomes especially useful when the agent's output is consumed by another system.

For example:

LLM
 |
 v
Agent
 |
 v
Structured Output
 |
 +----> Database
 |
 +----> API
 |
 +----> Dashboard
 |
 +----> Workflow
Enter fullscreen mode Exit fullscreen mode

Compare this with unstructured text:

"The customer is high risk and
the temperature is 22 degrees..."
Enter fullscreen mode Exit fullscreen mode

A machine cannot reliably consume arbitrary text without additional parsing.

With structured output:

risk_level: "high"
temperature: 22
Enter fullscreen mode Exit fullscreen mode

the downstream system knows exactly what each field means.

The key principle is:

AI-generated data becomes much more useful when it has a predictable contract.

16. Integrating With Existing Agent Frameworks

Using mcp-use does not necessarily mean abandoning existing agent frameworks.

The MCP layer can sit underneath an existing orchestration framework.

Conceptually:

             MCP Servers
                  |
                  v
              mcp-use
                  |
             MCP Adapter
                  |
                  v
             Agent Framework
                  |
                  v
                Agent
                  |
                  v
                 LLM
Enter fullscreen mode Exit fullscreen mode

For example, an agent framework can remain responsible for:

  • Planning
  • Reasoning
  • Memory
  • Agent execution
  • Workflow orchestration

while MCP provides standardized access to external capabilities.

This creates a useful separation:

Agent framework
      ↓
"How should I reason and orchestrate?"

MCP
      ↓
"What external capabilities can I use?"
Enter fullscreen mode Exit fullscreen mode

This is an important architectural pattern.

MCP can become the standardized capability layer, while your preferred agent framework remains responsible for orchestration.

17. Python vs TypeScript

The mcp-use ecosystem spans both Python and TypeScript.

The developer experience differs depending on the type of application you are building.

Python

Python is particularly attractive for applications centered around:

AI
Agents
Data
Machine Learning
LLM integrations
Python AI ecosystem
Enter fullscreen mode Exit fullscreen mode

A typical architecture might be:

Python
   |
Agent
   |
LLM
   |
mcp-use
   |
MCP Servers
Enter fullscreen mode Exit fullscreen mode

Python also fits naturally into existing AI and data workflows.

TypeScript

The TypeScript ecosystem becomes particularly interesting for:

MCP Servers
MCP Apps
React
Interactive Views
Full-stack applications
CLI tooling
Inspector
Enter fullscreen mode Exit fullscreen mode

A typical architecture might be:

TypeScript
     |
MCP Server
     |
Tools
     |
Structured Data
     |
React View
     |
Interactive UI
Enter fullscreen mode Exit fullscreen mode

The current TypeScript framework provides native support for Views, MCP Apps, typed contracts, Inspector tooling, and CLI workflows.

Simplified comparison

Area Python TypeScript
MCP clients ✓ ✓
MCP servers ✓ ✓
Agent development ✓ ✓
LLM integrations ✓ ✓
Structured schemas Pydantic Zod
Data/AI workflows ✓ ✓
React MCP Views — ✓
MCP Apps — ✓
Inspector/CLI Ecosystem Native tooling

The choice therefore depends heavily on the application.

If your architecture is primarily:

AI + Data + Python + Agents
Enter fullscreen mode Exit fullscreen mode

Python can be a natural choice.

If your architecture is:

MCP Server + React UI + MCP App + TypeScript
Enter fullscreen mode Exit fullscreen mode

the TypeScript stack becomes particularly interesting.

18. A Simple End-to-End Architecture

Putting everything together, a modern MCP application can look like this:

                         USER
                           |
                           v
                    +-------------+
                    | AI Interface|
                    +-------------+
                           |
                           v
                    +-------------+
                    |    Agent    |
                    +-------------+
                           |
                    +------+------+
                    |     LLM     |
                    +------+------+
                           |
                    +------+------+
                    |  mcp-use    |
                    | MCP Client  |
                    +------+------+
                           |
              +------------+------------+
              |            |            |
              v            v            v
          GitHub MCP   Database MCP  Browser MCP
              |            |            |
              v            v            v
           GitHub         SQL        Web/API
Enter fullscreen mode Exit fullscreen mode

The responsibilities are separated.

User

Defines the goal.

AI Interface

Provides the interaction layer.

Agent

Orchestrates the task.

LLM

Provides reasoning and language generation.

mcp-use

Provides the application infrastructure around MCP.

MCP Client

Connects the application to MCP servers.

MCP Servers

Expose tools and resources.

External Systems

Provide the actual data and perform the actual actions.

This separation creates a modular architecture.

19. What mcp-use Actually Adds

It is useful to think about the entire technology stack in layers.

Layer 1 — LLM

Examples include:

OpenAI
Anthropic
Google
Local models
Enter fullscreen mode Exit fullscreen mode

The model provides reasoning and generation.

Layer 2 — Agent

The agent determines:

What should I do?

Which tool should I call?

What information is missing?

What should happen next?
Enter fullscreen mode Exit fullscreen mode

The agent is responsible for orchestration.

Layer 3 — mcp-use

mcp-use provides developer-oriented abstractions around MCP.

Depending on the ecosystem, this includes:

MCP Clients
MCP Servers
Agents
Tools
Structured contracts
Inspector
CLI
Views
MCP Apps
Enter fullscreen mode Exit fullscreen mode

Layer 4 — MCP

MCP provides the standardized protocol through which AI applications communicate with MCP servers.

Conceptually:

AI Application
      |
   MCP Client
      |
      | MCP
      |
   MCP Server
Enter fullscreen mode Exit fullscreen mode

Layer 5 — MCP Servers

MCP servers expose capabilities such as:

Tools
Resources
Prompts
Enter fullscreen mode Exit fullscreen mode

For example:

GitHub MCP
Database MCP
Browser MCP
CRM MCP
Cloud MCP
Enter fullscreen mode Exit fullscreen mode

Layer 6 — External Systems

These are the systems where the actual data and actions exist:

Databases
APIs
GitHub
Cloud platforms
Filesystem
SaaS applications
Enterprise systems
Enter fullscreen mode Exit fullscreen mode

The complete architecture therefore becomes:

┌─────────────────────────────┐
│            User             │
└──────────────┬──────────────┘
               │
┌──────────────▼──────────────┐
│        AI Application       │
│                             │
│       LLM + Agent + UI      │
└──────────────┬──────────────┘
               │
┌──────────────▼──────────────┐
│          mcp-use            │
│                             │
│ Client / Agent / Server     │
│ Inspector / CLI / Views     │
└──────────────┬──────────────┘
               │
┌──────────────▼──────────────┐
│            MCP              │
│       Protocol Layer         │
└──────────────┬──────────────┘
               │
       ┌───────┼────────┐
       │       │        │
       ▼       ▼        ▼
     APIs   Databases  Tools
Enter fullscreen mode Exit fullscreen mode

The key architectural insight is:

mcp-use is not the protocol itself. It is a development framework built around the MCP ecosystem.

MCP provides the standardized capability layer.

The agent provides orchestration.

The LLM provides reasoning.

The MCP servers expose capabilities.

And the external systems provide the underlying data and actions.

That separation is what makes the architecture powerful and modular.

Top comments (0)