Universal LLM plugin system - simplifying tool integration and increasing flexibility in AI by 2025

The Hook:

The Hook:

You're building an AI agent. It's smart, it can chat. But... it's stuck .

It can't browse the web. It can't access files. It can't call APIs. It's stuck in its own sandbox - like giving a genius a blank notebook and locking the door.

Now imagine this: you write six lines of code and equip your agent with tools like browser control, file system access, and real-time API queries — and it works instantly .

Welcome to  MCP-Use : a deceptively simple Python library that connects any LLM with any external tool via the open Model Context Protocol (MCP)  — built by *** Pietro Zullo ***

Why This Matters (and Why I Wrote This Article)

For months, developers like me have been cobbling together fragile toolchains just to make ChatGPT able to search the web and call custom APIs. We tried LangChain agents, wrote wrappers, and tinkered with plugins. But all of them were tied to specific models, closed applications, or complex hacks .

MCP-Use solves these problems - clean, open and powerful.

This guide will cover everything from how MCP-Use works, the problems it solves, to how to build agents that think and act - using real-world examples like controlling a browser, searching Airbnb, driving Blender 3D, and even operating IoT devices.

If you've ever wanted to give your LLM  real-world capabilities , this is the most flexible way to do it.

Let’s analyze it in depth together ?

What is MCP-Use (and why it’s a game changer)

To understand  MCP-Use , first you need to understand the pain points it solves:

All major LLM APIs - OpenAI, Anthropic, Cohere - can provide excellent text generation. But based on this action?  It is still very limited.

Want GPT-4 to run a web search? Claude to read a file or query a database? Llama3 to control an app like Blender 3D?

You often have to build custom integrations , connect to APIs, or rely on vendor-specific platforms such as ChatGPT plugins, Cursor IDE, Claude Desktop, etc.

That’s where the Model Context Protocol (MCP)  comes in—and  MCP-Use  makes it truly usable .

MCP's core philosophy

MCP is a new open protocol - it can be understood as an enhanced version of function call .

It borrows the Language Server Protocol (LSP) from the code world, allowing LLM to discover and call external tools in a standardized, stateful way. Tools are exposed through servers, and each server declares its own capabilities (functions, parameters, return types).

It’s open, model-agnostic, and extensible —the Rosetta Stone of AI tools.

But MCP is just a protocol. To use it, you need a way to connect your models to the tool server.

This is exactly  what MCP-Use  does - launching a tool-laden smart agent with 6 lines of Python code.

So what is MCP-Use?

MCP-Use is a Python library with MCP client functionality. It connects any LLM to any MCP server (browser, file system, API, 3D renderer, etc.) through LangChain, allowing your agent  to use tools dynamically and intelligently .

It can:

• • Discover public tools on the server side
• • Convert tools into functions that can be called by LLM
• • Handles all JSON-RPC messages, supports HTTP or local I/O
• • Manage sessions, tool calls, responses, and memory

And it has a clear abstraction layer - so you don't have to worry about the protocol details and focus on building a better agent.

Brief summary

MCP-Use = Agent + Tools + Any LLM is a lightweight open source way to build a tool-type agent that is not locked into a single platform or plug-in ecosystem.

A brief analysis of the MCP-Use architecture

The MCP-Use core architecture revolves around two key components:MCPClient and MCPAgentOne is responsible for connecting tools , and the other is responsible for agent intelligence . Together, they allow your LLM-driven agent  to discover, call, and coordinate tools - through the open Model Context Protocol.

The details are as follows:

1. MCPClient: a bridge to connect external tools

Responsible for connecting with the outside world .

You define tools (such as browsers, file servers, API wrappers) in JSON configuration.MCPClient meeting:

• • Start the MCP server (locally using the CLI such as npx, or remotely using HTTP/SSE)
• • Read tool definitions exposed by the server (e.g. "search_web", "read_file", "render_scene")
• • Maintaining active sessions
• • Handle messaging (JSON-RPC 2.0), exceptions, retries, timeouts

In simple terms,MCPClient Make sure all tools are readily available, clear, and accessible —no matter where they are.

2. MCPAgent: The brain layer

Where the magic happens.

MCPAgent It sits between the LLM and the tools. It:

• • Map each tool to a function visible and callable by LLM (similar to OpenAI’s function calls or Claude’s tool support)
• • Maintain session memory (optional) to keep track of what the LLM said and did
• • Management decision cycle:

1. 1. LLM receives the request
2. 2. It thinks: Should I call the tool?
3. 3. Call tools (such as search_web(query="MCP-Use Python")）
4. 4. MCPAgent calls MCPClient to run the tool
5. 5. Tool results are returned to LLM
6. 6. The cycle continues until the answer is complete

No extra coding is required - MCP-Use does it all. Pass in the model and configuration, and call agent.run("query content") That's it.

Overview of the whole process

[Your question] ─▶ MCPAgent
                   ├── Memory and Prompt Design
                   ├── Function call interface
                   ▼
               [LLM Thinking...]
                   ├── Select Tool
                   ▼
            Call MCPClient.run_tool()
                   ├── Send JSON-RPC request
                   ▼
             MCP server execution tool (such as browser)
                   └── Return the result to MCPClient
                            ↓
               MCPAgent feeds the results back to LLM
                            ↓
             LLM Completed the task → Return to the final answer

Key points

MCPClient  is responsible for connection and capability discovery. MCPAgent  is responsible for LLM intelligence and tool call orchestration.

Advantages? You can connect to  multiple MCP servers at the same time - the agent will manage them intelligently.

Quick start with MCP-Use — 6 lines of code to build your first tool call Agent

Want to quickly build an LLM assistant that can browse the web or operate local files? No need for a lot of boilerplate or a huge framework.

With  MCP-Use , only  6 lines of Python  code are needed.

Let’s take a look at the specific operations.

Step 1: Install dependencies

Ensure Python 3.11+.

Install MCP-Use and your LLM provider (OpenAI in this case):

pip install mcp-use langchain-openai

To run tools like browser automation, you also need  Node.js (for npx Start as @playwright/mcp tools).

Step 2: Create a tool configuration file

Save As mcp-config.json:

{
  "mcpServers": {
    "browser": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Define an MCP server: Playwright-based browser tool. MCP-Use will pass npx Launch it.

Step 3: Add API Key

Create in the same directory .env:

OPENAI_API_KEY=your_openai_key_here

Use in Python dotenv load:

pip install python-dotenv

Step 4: Write the Agent (6 lines of code!)

from dotenv import load_dotenv
from mcp_use import MCPAgent, MCPClient
from langchain_openai import ChatOpenAI
load_dotenv()
client = MCPClient.from_config_file("mcp-config.json")
agent = MCPAgent(llm=ChatOpenAI(model="gpt-4"), client=client)
print(await agent.run("Search for best sushi places in Tokyo"))

Finish.

When running the script:

1. 1. The browser MCP server will be started
2. 2. LLM will choose to call search_web or click_link Tools
3. 3. The tool is executed and the results are returned
4. 4. You get a final answer

Sample Output

"Based on recent search results, the top sushi restaurants in Tokyo include Sushi Saito, Sushi Yoshitake, and Sukiyabashi Jiro..."

✨ LLM dynamically decides what tool to call and completes the task.

Any Model, Any Tool - MCP-Use Ecosystem

You wouldn’t build a smartphone that only runs one app. So why build an AI agent that only supports a single model or tool?

This is  where MCP-Use  is really powerful.

The core is not a clever wrapper around some model or framework - it is an open interface between LLM and external tools via the MCP protocol , allowing you to build freely.

Detailed disassembly.

Compatible Models MCP-Use supports any chat-based LLM that can use function calling - this includes most modern leading-edge models.

The following is a non-exhaustive list:

What do they have in common? They all function-call — when they want to call a tool, they output structured JSON instead of plain text.

That's all you need for MCP-Use.

? It uses LangChain’s chat models to access each model, making it easy to switch providers without rewriting logic.

Plug and play tools

MCP-Use, on the other hand, can connect to any tool that exposes itself as an MCP server - the community has already built some really great tools.

Popular MCP Servers

All of these are open source and are primarily hosted on NPM or GitHub. They follow the MCP specification and expose tools using a schema similar to the following:

{
  "name" : "search_listings" ,
"description" : "Search Airbnb for listings" ,
"parameters" : {
    "location" : "string" ,
    "max_price" : "number" ,
    "amenities" : "list"
}
}

MCP-Use will read it, present it to the model, and then let the agent call it like a native function. No special code required.

Mix and Match: Your Model, Your Tools

This is where the magic lies.

Because the two sides are decoupled - the model and the tool - you can combine them however you want.

Scenario: Using Claude 3 with Headless Browser and local file access

{
  "mcpServers" : {
    "web" : {
      "command" :  "npx" ,
      "args" : [ "@playwright/mcp" ]
    },
    "fs" : {
      "command" :  "npx" ,
      "args" : [ "@modelcontextprotocol/server-filesystem" ,  "/sandbox" ]
    }
  }
}
from  langchain.chat_models  import  ChatAnthropic
client =  await  MCPClient.from_config_file( "tools.json" )
agent = MCPAgent(llm=ChatAnthropic(), client=client)
await  agent.run( "Search for news about AI startups and save the headlines" )

Done. Your Claude powered agent now has a browser and a file system.

Scenario: Using the local LLaMA model with a custom API Wrapper

Let’s say you have a local LLaMA 3 running through Ollama, and an MCP server implemented in Python that wraps your internal CRM API. You can run both locally — no cloud, no internet — and the same agent logic will still work.

With MCP-Use, tools don't depend on models . They depend on protocols . This is a huge architectural advantage.

Remote Tools, WebSockets, and Cloud Agents

Not all MCP servers have to be local.

You can also connect to remote MCP servers based on HTTP or WebSocket , which means:

• • You can deploy your tools to the cloud (e.g. a crawler server running 24/7)
• • Ability to split computation: run models locally, run tools remotely, or vice versa
• • Can build multi-user Agents to share centralized tool access

Just replace the configuration:

{
  "mcpServers" : { 
    "scraper" : { 
      "url" : "https://tools.example.com/mcp/sse" 
    }
  }
}

MCP-Use will handle the connection type behind the scenes. As long as the MCP protocol is followed, the Agent can use it.

Don't trust your model? No problem.

You can disable any tool at runtime or in configuration to prevent accidental use.

For example:

• • Disable shell commands
• • Disable write_file, but allow read_file
• • Create a read-only secure sandbox

Just pass in a list of disallowed tool names when creating the agent:

agent = MCPAgent(..., disallowed_tools=["shell", "delete_file"])

Your model may be smart, but you are smarter.

"Any LLM, Any Tool" - Overview of the Core Architecture

To summarize:

  +----------------+ +----------------+ +------------------+
  | Any LLM | <--> | MCP-Agent | <--> | MCP Servers |
  | (Claude, GPT) | | (MCP-Use lib) | | (Browser, APIs) |
  +----------------+ +----------------+ +------------------+

MCP-Use is in the middle, parsing the tool schema and forwarding calls, allowing the model to use the tool like calling native functions.

MCP-Use vs. Other Solutions - Why It Matters

Let’s be honest: AI tools are everywhere these days.

LangChain, OpenAI Plugins, Hugging Face Agents, ReAct, AutoGPT, CrewAI, OpenAgents… It’s a jungle. They all try to push the boundaries, but they all have a fundamental problem:

? Tool usage is fragmented.  Each model has its own way of using tools, and each framework is reinventing the wheel. Most are tightly coupled to a specific cloud model or platform. 

Let's compare MCP-Use philosophically   — not just on a functional level.

LangChain Agents

LangChain is widely used to build complex LLM applications. Its agents can use tools through function calling and support multiple providers.

but……

• • Tools are often tightly coupled with LangChain logic
• • You need to define tools in Python , usually using a wrapper
• • Multi-tool choreography tends to be brittle (ReAct loop debugging is the way to go)

MCP-Use Advantages:

• • Tools are externalized and do not bind your code
• • Changing models does not require rewriting tools
• • LLM gets the schema  and tool name , not the custom wrapper

✅ LangChain is responsible for orchestration logic ✅ MCP-Use is responsible for decoupled and reusable tool interfaces

The two combined? The power is endless - you can even use MCP-Use agent in the LangChain chain.

OpenAI Plugins/Assistants API

OpenAI's plugin ecosystem (now mostly Assistants API) allows GPT-4 to use tools through the OpenAPI spec. Yes, but only within OpenAI.

but……

• • Only use their platform
• • The plugin only supports GPT series models
• • Tools must conform to the publicly hosted OpenAPI 3 specification
• • Cannot be reused across Claude, LLaMA, etc.

MCP-Use Advantages:

• • Compatible with any  LLM (Claude, GPT, LLaMA, native, etc.)
• • Tools are not required to be public and can be customized locally
• • Use MCP , a simpler, more general protocol, not OpenAPI
• • Tools can maintain state - something most REST APIs cannot

The OpenAI plug-in is an experimental product, while MCP-Use is an open standard with no barriers to entry.

AutoGPT / Agent Framework

Agent frameworks such as AutoGPT, CrewAI, and BabyAGI focus on planning: breaking down tasks and executing with memory.

but……

• • Tools are often pre-installed Python code or custom scripts
• • Changing models or tools requires changing core logic
• • Many agents use eval+print to pretend to use tools

MCP-Use Advantages:

• • Real-time structured tool calling, implemented through function calling
• • You can use the same tool for 10 agents without duplicating code
• • Tools are automatically discovered and agents  see what they can do

You can use MCP-Use as the tool backend of these frameworks and let the agent delegate MCP execution.

Custom Integration

You might be thinking: “Why don’t I just write my own tool using requests, Selenium, or Puppeteer?”

Of course. But you will encounter:

• • You need to write and maintain a bunch of wrappers yourself
• • Handle edge cases, retries, timeouts, formatting, etc.
• • Tightly couple model logic with tools

MCP-Use Advantages:

• • Tools are self-contained microservices that adhere to MCP
• • AI says “call search()”, ignoring internal implementation
• • Tools can be launched locally, remotely, containerized, or on demand

You are not tied to how the tool is built, you just need to ensure the MCP protocol.

Visual comparison chart

Philosophical Change: From "Plugins" to "Protocols"

Understand it this way:

OpenAI Plugins are like browser extensions. MCP is the entire Web itself .

Plugins are useful, but limited. Protocols are infinitely combinable. MCP-Use is not just "another tool framework".  It is a decentralized, standardized ecosystem where any model can use any tool securely and intelligently.

This is a huge unlock for the future of AI.

Why MCP May Define the Next Decade of AI

Every technological revolution has an overlooked critical moment that lays the foundation for the future.

• • The URL is one of the key moments of the Internet
• • The USB protocol is one of the key moments in hardware
• • HTTP requests are the invisible glue of the Web

Now, in the field of AI, MCP  is playing such a role—low-key, efficient, almost invisible, but with far-reaching impact.

Why protocols are more important than models

Now everyone is obsessed with models.

GPT-5 rumors. Claude 3 performance. Gemini multimodal demo.

But the truth is:

The model is not the AI ​​entity. The agent is.

The definition of an agent is not "what it knows", but "what it can do". To act in the real world, an agent needs tools. To use tools intelligently, it needs structure. And to extend this structure across models, teams, devices, and domains - it needs a protocol.

This is MCP.

Agent operating system

MCP is more than just a wrapper around function calls. It is an interface contract between cognition and capabilities .

It contains:

• • The tool declares itself
• • The model will automatically discover them
• • Function calls are standardized
• • Sessions carry state
• • The agent is in control

This is strikingly similar to the development path of operating systems:

• • CPU ↔ Driver ↔ Hardware
• • OS ↔ APIs ↔ Applications
• • Now: LLM ↔ MCP ↔ Tools

In this sense, MCP is quietly becoming the core of the AI ​​operating system —the key to turning thinking into action.

How this changes the way we build

Imagine a future like this:

• • You start a new agent within 30 seconds
• • You get the tools from a public MCP server registry like GitHub
• • You switch models like you would a middleware — Claude today, GPT-5 tomorrow
• • You deploy agents that drive business, scientific papers, 3D pipelines—all with secure and composable tooling

This is not far away.

MCP-Use is one of the first libraries to open this reality to developers . It does not lock platforms, models, or ecosystems. It simply gives your LLM the ability to use things.

That makes it more than just a tool. It's the foundation .

The future of MCP-Use

The roadmap is already exciting:

• • Support WebSocket for low latency tools
• • Add more tool servers (PDF, vector database, IDE, API)
• • Support for agents with memory functions
• • GUI tools use visualization
• • Plug-and-play UI front end

But more importantly:

It's open. It's standard. It's yours.

You can build tools today and plug into any agent tomorrow. You can run agents locally, remotely, on edge devices, or in a secure lab. You ask LLMs  to do things—not by writing prompts, but by giving them capabilities.

And no one’s permission is required .

Conclusion: The arrival of the LLM action era

For the past few years, we’ve been living in the era of “LLMs can talk .”

They are clever, surprising and sometimes poetic.

But the next era—the era we are entering—is completely different.

This is the era of “LLMs will act .”

When future developers look back and ask:

“When do AI agents really start to be useful?”

Most likely the answer will be:

"Probably around the time someone released a Python library called MCP-Use."