Streamline Agentic AI Engineering with MCP OpenAPI Proxy and MCPO

Agentic AI systems are transforming how we build intelligent workflows by allowing AI agents to dynamically invoke tools and APIs in order to accomplish complex tasks. Two emerging technologies – MCP OpenAPI Proxy and MCPO – have been developed to make such tool integrations easier and more powerful. These tools leverage Anthropic’s Model Context Protocol (MCP) to bridge AI agents with external services in both directions: MCP OpenAPI Proxy exposes existing REST APIs to AI agents as usable tools, while MCPO exposes AI agent tools as standard HTTP APIs. In this article, we will explore the core functionality of each, their technical workings (with a focus on Marvin AI 3.0 integration), and how they enhance dynamic tool usage in data-centric workflows.

Background: Agentic AI and the Model Context Protocol (MCP)

Agentic AI refers to AI systems (often driven by large language models) that can make decisions and call external tools autonomously to achieve goals. Traditionally, connecting an AI agent to multiple tools or data sources meant writing custom integration code for each API or using complex orchestration frameworks. This led to an M×N integration problem: each AI application needed to handle each tool’s unique interface. The Model Context Protocol (MCP) was introduced to simplify this landscape . MCP defines a standardized client-server interface for tools, so an AI agent can connect to any number of tool “servers” through a single unified protocol. Each MCP server provides a set of capabilities (called tools, essentially functions the agent can call) and standardized metadata (like a list of available tools, their parameters, and documentation) . The agent, using an MCP-compatible client, can handshake with each server to discover its tools and then invoke those tools when needed, with the MCP framework handling execution and returning results .

In practice, MCP decouples tool implementations from the agent. Tool providers (e.g. developers of a Slack API integration, database interface, etc.) implement an MCP server exposing their service’s functionality, and AI application developers incorporate an MCP client (such as in Marvin 3.0) to utilize those tools. This reduces integration complexity and encourages a plug-and-play ecosystem for AI agent tools . However, to fully leverage this in real-world projects, we need ways to connect existing services into MCP and also to interface MCP-based tools with other systems. This is where MCP OpenAPI Proxy and MCPO come into play.

MCP OpenAPI Proxy: Exposing REST APIs as Agent Tools

MCP OpenAPI Proxy is a Python-based MCP server designed to dynamically expose any RESTful API (defined by an OpenAPI specification) as a collection of tools for an AI agent . In simpler terms, if you have a web service with an OpenAPI/Swagger spec, this proxy will turn each API endpoint into a callable tool that an AI agent can invoke. This greatly simplifies integrating existing data services or SaaS APIs into agent workflows, without writing custom tool code. The proxy “reads” the API’s spec and automatically generates MCP tool definitions for endpoints, including their parameters and expected responses, so that the agent can call them as if they were native functions.

Key Features and Operation: MCP OpenAPI Proxy supports two modes of operation :

• Low-Level Mode (Default): The proxy registers an MCP tool for every valid endpoint defined in the OpenAPI spec. For example, an endpoint POST /chat/completions would become a tool named chat_completions() that the agent can call . Tool names are derived from normalized endpoint paths and HTTP methods, and their descriptions are populated from the API’s documentation. This mode maximizes coverage, exposing the full range of the API’s functionality to the agent.
• FastMCP Mode (Simple Mode): In this optional mode (OPENAPI_SIMPLE_MODE=true), the proxy exposes a fixed, generic set of tools instead of one per endpoint . Typically, this means tools like list_functions() (to list available API operations) and call_function() (to invoke an API operation by name) are provided, rather than dozens of granular endpoint tools. This approach can simplify the agent’s reasoning about which tool to use by consolidating access, at the cost of an extra step (the agent must choose and call an operation via a generic function). FastMCP mode is useful when the API spec is large and you prefer the agent to reason at a higher level about API calls.

Regardless of mode, dynamic tool generation is a core benefit: the proxy reads the OpenAPI spec and creates tool interfaces on the fly . It supports OpenAPI v3 specs (v2 might be supported as well) and allows filtering which endpoints become tools via a whitelist if desired . You can also configure a prefix for tool names (to avoid collisions or to group tools by service) and strip out certain parameters globally (for example, removing an auth token field from all tool inputs) . The proxy automatically handles authentication headers: you can provide an API key or token as an environment variable, and it will be included in outgoing requests (using a default Bearer <API_KEY> header, customizable via settings) . This means the agent doesn’t need to worry about auth details – it just calls the tool, and the proxy inserts credentials and queries the REST API.

Using MCP OpenAPI Proxy: This proxy is distributed as a Python package for easy installation (pip install mcp-openapi-proxy). At runtime, it can be launched as a standalone MCP server process. A minimal invocation might look like:

# Install and run the MCP OpenAPI Proxy with an example API
pip install mcp-openapi-proxy
OPENAPI_SPEC_URL="https://api.example.com/openapi.json" API_KEY="your_api_key" uvx mcp-openapi-proxy

Here, OPENAPI_SPEC_URL points to the OpenAPI spec (it could also be a local file path), and API_KEY is passed to authorize API calls . The uvx command above is a launcher for MCP servers (part of the uv toolchain commonly used in MCP ecosystem); you could similarly run mcp-openapi-proxy directly after installing. Once running, the proxy will register tools corresponding to the API. For instance, if the spec defines an endpoint GET /users/{id}, the agent might gain a tool like users_get(id: str) (actual naming normalized) to retrieve a user by ID.

Configuration can also be done in a JSON file that the MCP client (or orchestrator) reads. For example, to integrate a Slack API via its OpenAPI spec, one would configure an MCP server entry:

{
  "mcpServers": {
    "slack": {
      "command": "uvx",
      "args": ["mcp-openapi-proxy"],
      "env": {
        "OPENAPI_SPEC_URL": "https://raw.githubusercontent.com/slackapi/slack-api-specs/master/web-api/slack_web_openapi_v2.json",
        "TOOL_WHITELIST": "/chat,/bots,/conversations,/users",
        "API_KEY": "xoxb-<your_slack_bot_token>",
        "STRIP_PARAM": "token",
        "TOOL_NAME_PREFIX": "slack_"
      }
    }
  }
}

This configuration (based on the Slack example from the project) launches mcp-openapi-proxy for Slack’s API, but limits the exposed tools to certain endpoint groups like chats, conversations, users, etc., and strips the token parameter from payloads since the API token is injected in the header . All generated tool names will be prefixed with slack_ (e.g. slack_postMessage()), to clearly associate them with Slack . Such selective exposure is useful in data workflows to avoid overwhelming the agent with too many tools and to enforce focus on relevant operations.

Value for Dynamic Agent Tools: MCP OpenAPI Proxy essentially unlocks any service with a documented API as a potential tool for your AI agent. This is a game-changer for dynamic tool usage. Instead of hard-coding functions or relying on limited built-in tools, an agent can be given access to a new API at runtime by simply pointing the proxy to a spec. From that point, the agent’s reasoning engine can decide to call those tools when appropriate. For example, in a data analysis workflow, if the agent needs to fetch the latest sales figures from a CRM system, the CRM’s OpenAPI spec can be plugged into the proxy – the agent will then have tools like crm_getSalesData(...) available and can call them to retrieve data as JSON, which it can then analyze or transform. The beauty is that no custom code was required to teach the agent how to call the CRM; the formal API description was enough. This accelerates integrating new data sources and services into AI-driven workflows .

Moreover, because the proxy leverages the API’s formal specification, it inherently provides structured input/output schemas for each tool. In Marvin AI 3.0 (and similarly capable frameworks), those schemas can be translated into function signatures with typed arguments and well-defined response models (often using Pydantic for data validation under the hood). This means the agent is less likely to make mistakes in calling the tool (it knows what parameters are expected and what the response format is) and can even validate or format its outputs more reliably.

MCPO: Bridging MCP Tools to Standard OpenAPI Services

While the MCP OpenAPI Proxy brings external APIs into the MCP agent ecosystem, MCPO does the reverse: it exposes MCP-based tools outward as standard HTTP APIs. The name “MCPO” literally stands for MCP-to-OpenAPI. It is a lightweight proxy server that wraps any MCP server behind a RESTful interface, complete with an automatically generated OpenAPI schema and interactive documentation . In effect, MCPO allows you to take a tool that was designed for AI agent use and make it accessible to other software (or even other AI agents that prefer HTTP) as if it were a regular web service.

Core Functionality: Normally, MCP servers communicate with clients over pipes, sockets, or other IPC/RPC mechanisms (e.g. JSON-RPC over stdio for local tools, or server-sent events for remote streaming). This raw protocol is not something you’d directly call from a web app or a curl command. MCPO addresses this by acting as an adapter: it runs an HTTP server that accepts normal REST requests and translates them into MCP requests to the underlying tool, then returns the tool’s output as an HTTP response. Crucially, MCPO also advertises an OpenAPI spec for these endpoints, so any OpenAPI-compatible client or SDK can discover and invoke the MCP-backed functions easily .

Why is this useful? Consider that many AI agent tools might be very powerful (e.g. a tool that can run complex database queries, or a specialized ML model for data classification) but only accessible through MCP within an agent framework. With MCPO, one could expose such a tool to a broader environment. For example, a data engineering team could deploy an MCP-based data transformation tool (perhaps an agent that uses Python to manipulate dataframes) and then wrap it with MCPO, instantly making it an API service that other systems can call via HTTP. This creates a bridge between agentic AI capabilities and traditional microservice architectures.

From a security and compatibility standpoint, MCPO also brings advantages. “MCP servers usually speak over raw stdio, which is inherently insecure and incompatible with most tools, and lacks standard features like documentation, authentication, and error handling,” as the MCPO developers note . By putting an MCP tool behind a proper HTTP server, you can leverage battle-tested web security practices (think API keys or OAuth, TLS, etc.), standardize error responses, and auto-generate documentation UIs. MCPO essentially makes an AI tool look like a well-behaved web service with minimal effort. As the README succinctly states, it adds security, stability, and scalability using trusted web standards and provides interactive docs for every tool without extra coding . In other words, what might have been a niche AI helper function can become a robust, shareable API.

Usage and Technical Workflow: Using MCPO is straightforward. After installing (e.g. pip install mcpo), you run the mcpo command with the MCP server to expose. For instance:

# Expose a local MCP server (e.g., a Time service) on port 8000 with an API key
mcpo --port 8000 --api-key "top-secret" -- uvx mcp-server-time --local-timezone=America/New_York

In this example, mcp-server-time is a hypothetical MCP server that returns the current time (one of the example tools often used in MCP demos). By running it with mcpo, the time service will be accessible at http://localhost:8000 via REST. MCPO will have automatically generated an OpenAPI definition for it, so if you navigate to http://localhost:8000/docs you’ll see a Swagger UI with the endpoints (perhaps a GET /now or GET /time endpoint, etc.) . The --api-key "top-secret" flag in the command added a simple API key requirement; all requests must include this key for authorization. This is an example of how MCPO can easily layer on auth – a crucial feature if you intend to expose the AI tool within a larger organization or publicly.

MCPO can also host multiple tools simultaneously behind different URL routes. By using a JSON/YAML configuration, you can specify multiple MCP servers to run, each given a name. For example:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-memory"]
    },
    "time": {
      "command": "uvx",
      "args": ["mcp-server-time", "--local-timezone=America/New_York"]
    }
  }
}

Running mcpo --config config.json --port 8000 --api-key "top-secret" with the above config would launch two tools: one accessible at /memory and another at /time on the same server . Each tool gets its own sub-path and its own OpenAPI schema. For instance, /memory/docs would show docs for the memory tool, and /time/docs for the time tool . This approach is very powerful for composing a suite of AI-driven utilities and exposing them through a unified API gateway.

Enabling Agentic Workflows with MCPO: By turning agent tools into standard APIs, MCPO enables integration of AI capabilities into traditional data workflows and applications. A data engineer could call the above memory or time endpoints from a script or an ETL job just like calling any other microservice. This means that even if one is not using an AI orchestrator in a particular part of a system, they can still leverage the “intelligence” or functionality of an agent tool. For example, imagine an MCP server that provides a sophisticated data cleaning function (perhaps it uses an LLM to fix inconsistencies in records). Using MCPO, this could be served as POST /clean_data (with the schema derived from the tool’s MCP interface). Downstream systems could send raw data to this endpoint and get cleaned data back – essentially calling an AI-powered function over HTTP. The interoperability that MCPO provides ensures that the innovations in the agentic AI space can be accessed by a wide array of platforms and languages (anything that can make an HTTP request and read a JSON response can use the tool). Additionally, it serves as a convenient debugging and development aid: developers can hit the tool’s endpoint manually to test its behavior, thanks to the live documentation and standard web protocols, which is much easier than, say, driving it via an AI agent for every test.

Marvin AI 3.0 Integration and Technical Details

Marvin 3.0, a Python framework for building AI workflows, is particularly relevant because it’s designed from the ground up to work with structured AI outputs and tools, using Pydantic for modeling. In fact, Marvin 3.0 was “re-platformed on Pydantic AI” – moving away from earlier reliance on other toolkits – to natively support a broad range of models and standardized function-call interfaces . Marvin treats tools in a very Pythonic way: each tool is like a function (with inputs and outputs defined, often via Pydantic models for validation) that an agent can call when reasoning through a task.

Marvin 3.0 has first-class support for MCP servers, which means both the MCP OpenAPI Proxy and any tools you expose via MCPO can be leveraged within Marvin’s agents. When you create a Marvin agent, you can simply attach one or more MCPServer instances to it. Under the hood, Marvin will spawn those MCP servers (as subprocesses or connect to them) and automatically discover all the tools they provide . The discovered tools are then presented to the language model as available actions it can take (Marvin converts them into the model’s function-call format, including docstrings and parameter schemas). From the agent’s perspective, using an MCP-provided tool is no different than using a built-in Python tool function – Marvin handles the routing. If the model decides to call a tool, Marvin sends the request to the corresponding MCP server, waits for the result, and then feeds the result back to the model .

Let’s illustrate how we might integrate the MCP OpenAPI Proxy into a Marvin 3.0 agent for a data workflow:

from marvin.agents import Agent
from pydantic_ai.mcp import MCPServerStdio

# Suppose we have an OpenAPI spec for a data service (e.g., a data catalog API)
openapi_spec_url = "https://example.com/data_service/openapi.json"

# Configure the MCP OpenAPI Proxy server with the spec and any required auth
data_api_server = MCPServerStdio(
    command="uvx", 
    args=["mcp-openapi-proxy"], 
    env={
        "OPENAPI_SPEC_URL": openapi_spec_url,
        "API_KEY": "MY_API_TOKEN"  # e.g., for Bearer auth
    }
)

# Create a Marvin agent and attach the MCP server
agent = Agent(
    name="DataAssistant",
    description="An AI agent that can fetch and analyze data from the company data service.",
    mcp_servers=[data_api_server]
)

# Now the agent has tools corresponding to the data service's API.
# For example, if the API had an endpoint GET /reports/{id}, 
# the agent might now have a tool like get_report(id: str).

# We can ask the agent to perform a data task that involves calling the API:
query = "Retrieve the latest sales report and calculate the year-over-year growth."
result = agent.run(query)
print(result)

In this example, once the agent is run on the given query, Marvin will allow the underlying LLM to decide which actions to take. The agent knows (from the MCP handshake) that it has tools related to the data service – perhaps get_report(report_id) and other endpoints – so it might decide to call get_report with the latest report’s ID. The MCP OpenAPI Proxy will receive that call, translate it into an HTTP request to the actual GET /reports/{id} endpoint, and return the JSON result. Marvin will pass that data back to the LLM, which can then proceed to calculate the growth (perhaps using built-in Python tools or just by reasoning if it’s a straightforward calculation), and finally provide the answer. All of these steps are orchestrated seamlessly: the agent dynamically used a new external API tool and combined it with its own reasoning to fulfill a complex task, without any custom code for that specific API.

The above also demonstrates how Pydantic models come into play. The OpenAPI spec defines the schema of inputs and outputs (for example, the structure of a “Report” object). When Marvin imports those tools, each tool’s parameters and return schema can be mapped to Pydantic models, giving the agent’s developer (and the LLM) a clear contract for what data is expected. Marvin’s use of Pydantic means that if the API returns data, it can be automatically validated and parsed into a Python object, enabling the agent to work with it in a structured way. For instance, if get_report returns a JSON with fields like {"id": 123, "sales": 10000, "year": 2025}, Marvin could load that into a Report Pydantic model for easier downstream use. This tight integration of schema ensures robustness in data-oriented workflows – the agent won’t mistakenly treat a number as a string or miss a required field, because the schemas are enforced.

On the flip side, consider using MCPO with Marvin. While Marvin itself would typically consume MCP servers directly (it doesn’t need MCPO for its internal operation), MCPO can be a companion in a larger Marvin-based system. Suppose you have a Marvin agent with a custom tool (maybe a proprietary algorithm running as an MCP server) that your workflow heavily relies on. By wrapping that tool with MCPO and exposing it at an HTTP endpoint, you make it possible for non-Mavin processes to trigger the same functionality. For example, if your Marvin agent can produce a complex data visualization via an MCP tool, MCPO can expose that as an API endpoint /generate-visualization. This way, even external schedulers or services can call into your AI tool when needed, using standard web requests. Essentially, Marvin + MCP + MCPO together allow you to mix and match AI agent tools with conventional software components. The Marvin agent can focus on orchestration and reasoning, using MCP OpenAPI Proxy to pull in data or interact with third-party APIs, and you can use MCPO to expose some of Marvin’s own capabilities to the rest of your architecture.

Enhancing Data Workflows with Dynamic Tools

In data workflows – such as ETL pipelines, analytical reporting, or automated research – the ability of an AI agent to flexibly fetch, transform, and output data is paramount. MCP OpenAPI Proxy and MCPO significantly enhance these capabilities:

• Seamless Data Retrieval: With MCP OpenAPI Proxy, an agent can tap into any data source that has an API. Whether it’s pulling records from a database-as-a-service, querying a third-party analytics API, or just fetching documents from a CMS, the agent can do so by activating the appropriate tool (no bespoke integration code needed). This opens the door for AI-driven ETL, where the agent decides what data it needs and when, rather than following a rigid pre-defined pipeline.
• Dynamic Data Transformation: Agents can also use MCP servers that provide computational tools – for example, a Python execution sandbox (as demonstrated with mcp-run-python) or data manipulation libraries. Marvin 3.0 already includes patterns for tasks like classification, extraction, and transformation of data using AI . By adding MCP servers, these transformations can become more powerful. Imagine an agent that, after retrieving data via an API proxy, uses a Python interpreter MCP tool to run Pandas for cleanup and analysis, and perhaps another tool for generating a plot. This multi-step process can be orchestrated by the agent in real-time, effectively acting as a autonomous data analyst.
• Integration and Deployment: MCPO ensures that the outputs of these AI-driven data processes can be integrated into broader systems. For example, after an agent computes a result, you might want to expose that result or provide a way for other services to trigger the same process. By hosting the agent’s tool (or even the agent itself, if it’s encapsulated as an MCP server) via MCPO, you turn your AI data pipeline into a microservice. A downstream application could invoke it to get on-demand insights. Additionally, having a standardized OpenAPI interface means you can plug it into monitoring tools, apply rate limiting, or wrap governance around it just like any other data service in your enterprise.

To make this concrete, consider a workflow scenario: a marketing analytics agent that monitors campaigns. It might use an OpenAPI Proxy tool for the marketing platform’s API (to fetch campaign data), a database MCP tool to store or query internal data, and a Python execution tool for calculations. The agent’s instructions could be: “Find any campaign whose conversion rate dropped by more than 20% compared to last week, and prepare a summary report.” Upon receiving this task, the agent will call the marketing API (via the proxy) to get recent campaign stats, possibly call a database tool to get historical stats, then calculate differences. If a significant drop is found, it could even use an email-sending MCP tool to dispatch a notification. All these actions (API calls, database queries, sending email) are decided at runtime by the agent. The dynamic tool availability provided by MCP means the agent can fluidly combine these data operations. From the outside, you could expose this entire workflow via MCPO as a single endpoint like GET /critical_campaign_alerts – any time it’s hit, the agent runs the multi-step process and returns the result as JSON. This illustrates an agentic data service: a live intelligence that fetches and processes data on-demand, made accessible through standard web protocols.

Conclusion

MCP OpenAPI Proxy and MCPO represent two sides of the same coin in advancing agentic AI engineering. The MCP OpenAPI Proxy lowers the barrier to give AI agents access to a world of existing data and services by instantly converting OpenAPI-described endpoints into agent tools . This empowers agents (like those built with Marvin 3.0) to perform complex data tasks – from data retrieval to transformation – with minimal setup. On the other hand, MCPO extends the reach of those AI-driven tools beyond the agent’s own environment, packaging them as secure, documented APIs that can slot into traditional IT workflows . By using web-friendly standards, MCPO ensures that the innovations in the MCP tool ecosystem can be tapped by any system or team without deep AI expertise.

In technical terms, both tools contribute to a more modular and interoperable AI architecture. AI agents can be thought of as orchestration engines that assemble tool usage to accomplish goals. MCP OpenAPI Proxy fills those engines with a rich palette of external actions (any API in the organization can become an action for the agent), while MCPO turns the agent’s own actions into services others can rely on. The synergy with frameworks like Marvin 3.0 – which embraces structured outputs and tool use via Pydantic models – means these components can be integrated with just a few lines of configuration or code. Marvin’s agent can load an MCP OpenAPI Proxy tool and call it as naturally as a Python function, and an MCPO-wrapped service can be invoked as easily as calling an HTTP endpoint from a requests client.

In summary, MCP OpenAPI Proxy and MCPO greatly enhance dynamic tool usage in agentic AI, especially for data-centric workflows. They let us engineer AI agents that are both empowered and empowering: empowered to use any tool or service they need, and empowering other software to leverage the agents’ capabilities. As the ecosystem matures, we can expect to see an increasing separation of concerns where AI agents focus on decision-making and reasoning, while tools (exposed via MCP) provide the heavy lifting for data access and actions – all made frictionless by proxies like these. It’s an exciting development in AI engineering that pushes us closer to truly intelligent, autonomous data workflows, backed by the reliability of standardized protocols and schemas.

Sources:

1. Anthropic & Community, Model Context Protocol (MCP) Specification
2. Matthew Hand, MCP OpenAPI Proxy – GitHub README
3. Playbooks.com, OpenAPI MCP Server (Overview)
4. Open WebUI, MCPO – MCP to OpenAPI Proxy README
5. BusyBrain (N. N.), MCP vs OpenAI’s OpenAPI Tools (Publication)
6. Marvin AI 3.0 Documentation – Using MCP Servers