TL;DR: McProxy is an open-standard gateway built on the Model Context Protocol (MCP) that enables AI agents to generate tool integrations on the fly using natural language or OpenAPI specs. By shifting integrations from static code to dynamic assets, it slashes onboarding time from 16 hours to under 30 seconds while centralizing Okta AURM enterprise security.
The integration tax every developer pays (and how to fix it)
You know that feeling when you need to integrate a new API or, worse, create and onboard a new MCP server? What should be straightforward turns into hours of documentation diving, wrestling with authentication flows, and debugging obscure edge cases.
Now multiply that by every tool in your stack—your CI/CD pipeline, project tracker, documentation wiki, and secrets manager. The integration work never stops.
While working on development tooling at Okta, I noticed something that bothered me: Teams would spend entire days building integrations that AI agents would then use for only 10 minutes or so. The math just didn't add up.
So I started wondering: What if we flipped this around? What if AI agents built their own integrations when needed? What if we only set up and configure an MCP server once, and it orchestrated an entire arsenal of tools, workflows, and child MCP servers?
What is McProxy and how does it scale tooling?
McProxy (patent-pending) is a meta-platform I built on top of the MCP. It enables AI agents to create integration tools on the fly using plain English or API specifications, and to orchestrate multiple MCP servers, tools, and workflows under a single, unified umbrella. What used to take hours now takes seconds. Additionally, the gateway architecture presents some interesting possibilities for security and governance that I didn't initially anticipate.
Think of McProxy as a single MCP server that secretly juggles a bunch of other MCP servers behind the curtain. It's both a unified gateway to your developer tools and an integration factory that can spin up new connections on demand.
Quick context: MCP is a relatively new standard for how AI agents talk to tools. It covers the basics—tool discovery, authentication, and result handling. McProxy builds upon that foundation and adds the ability to generate new integrations as needed.
From your AI client's perspective (for example, Copilot CLI, Claude Desktop, or VS Code extensions), McProxy appears as a single server with multiple tools. Under the hood, however, it routes everything to specialized child servers.
Out of the box, it includes enterprise-grade SaaS integrations like Jira for project management, Confluence for documentation, CircleCI for CI/CD pipelines, Calcifer for test analytics and metrics, and even a specialized test fixer for analyzing and fixing flaky tests. And it can spin up entirely new servers in seconds when you ask for something it doesn't have yet.
As your ecosystem grows, McProxy organizes tools into toolsets: Logical groupings that give you finer control when a single server exposes dozens or hundreds of tools. You can enable or disable entire toolsets dynamically, keeping your agent focused on what matters for the current task.
Three methods for generating custom MCP servers on demand
McProxy gives you three different ways to create new MCP servers, and they all share one thing: You get instant results without manual configuration work.
1. Dynamic generation from natural language prompts
This is the coolest part. An AI agent can just say, "Create a weather server with current conditions, forecasts, and severe weather alerts," and McProxy uses an LLM to generate a complete MCP server, including tools, error handling, authentication, and more.
The generated code doesn't cut corners on security either. Credentials are stored in your system keychain, not in environment variables. Behind the scenes, McProxy utilizes sophisticated templates and reference implementations to guide the generation process, ensuring consistent patterns, proper error handling, and adherence to security best practices. It's not just raw LLM output; it's quality-controlled code generation. Give it less than 30 seconds, and the new server is onboarded with all its tools ready to use.
2. Automated conversion of OpenAPI specifications
Many modern APIs publish OpenAPI specifications that describe their endpoints. McProxy can consume these specifications and automatically generate MCP servers.
Point it at GitHub's OpenAPI spec, and you'll have access to more than 200 tools instantly. Each one has proper typing, authentication handling, and documentation. The whole process takes less than 30 seconds, eliminating what would've been weeks of manual work.
3. Multi-server workflow orchestration
Here's where it gets interesting. McProxy can take tools from existing child servers and combine them into new orchestrator servers, essentially creating automated workflows. Just describe a multi-step process like, "Generate a release workflow that handles tagging the repository, creating release notes, updating associated Jira tickets, and sending team notifications."
McProxy generates an orchestrator that chains the calls across multiple servers, handles failures gracefully, and reports progress. Instantly, you've got a single tool that coordinates a complex operation that would normally require a bunch of custom scripting.
How much time does McProxy save developers?
Let's talk numbers. Traditional API and tool onboarding within an MCP architecture is manual and intensive, requiring hours of configuration. Below is a measurable comparison of traditional development vs. automated generation:
Integration Step | Traditional Setup | With McProxy |
Understanding the MCP spec | 30-60 minutes | No need |
Implementing tool schemas | 1-2 hours | No need |
Writing authentication flows | 1-3 hours | No need |
Error handling and edge cases | 2-4 hours | Guided templates |
Testing and debugging | 2-6 hours | Continuous loop |
Total time spent | 6-16 hours | < 30 seconds |
You're looking at 6-16 hours per integration, assuming you don't hit any major snags.
With McProxy? Less than 30 seconds. The AI agent describes what it needs, McProxy automatically generates and onboards the server, and the tools are immediately available. The quality remains consistent, too, because every generated server adheres to the same robust patterns.
Or consider a typical release workflow that involves GitHub, Jira, Confluence, and various notification systems. Manually implementing that with proper error recovery could easily burn a full day. With McProxy, you describe the workflow and get a working orchestrator in seconds.
Decentralized tools, centralized control: The gateway architecture advantage
Here's something I didn't fully appreciate until after building McProxy: Having all requests flow through a single proxy server creates some really powerful opportunities for centralized control.
Since everything goes through one gateway, you can enforce enterprise-grade policies at the top level without reimplementing them in each child server:
- Security policies and access controls
- Personally identifiable information (PII) detection, handling, and redaction
- Rate limiting and quota management
- Comprehensive audit logging
- Compliance enforcement
The gateway also provides runtime management capabilities that keep your ecosystem maintainable. You can list all connected servers, enable or disable them dynamically, or reload configurations—all without restarting anything. Need to temporarily disable a server? One command. Want to see which servers are currently active? Another command. This operational flexibility becomes crucial as the number of integrations grows.
Enterprise governance and top-level security policies
Security isn't an afterthought here—it's baked into the design from day one. Every tool requires authentication through AURM (Okta's secure authentication system), and credentials are stored using the system keychain, never in configuration files or environment variables.
When McProxy generates new servers, it automatically includes proper authentication scaffolding. Generated servers use the same secure patterns as handwritten ones, which prevents the usual suspects, such as hardcoded credentials or insecure token storage.
The bottom line: Even dynamically-generated integrations maintain enterprise-grade security standards. The agent can create tools freely, but it can't create security vulnerabilities.
Chaining complex operations across multiple child servers
Individual tool generation is valuable, sure. But the ability to combine existing tools into workflow servers? That's where things get really transformative.
When you create an orchestrator server, it connects to McProxy as a client and calls tools from other child servers. This enables multi-step workflows with error handling and progress reporting.
A feature development workflow might read requirements from Confluence, create a Jira ticket, transition it to "In Progress," create a branch in GitHub, and update the documentation, all as a single atomic operation.
McProxy includes pre-built workflows for common scenarios, such as feature development, releases, and incident response. But agents can request custom orchestrators tailored to their team’s specific processes. The workflow is generated, onboarded, and immediately usable alongside existing tools.
Traditional workflow automation forces a choice between rigid pre-built integrations or extensive custom code. McProxy's orchestrators strike a balance: They're flexible enough for diverse use cases yet simple enough to be generated from natural language.
Eliminating downtime with dynamic server hot-reloading
A new server is automatically onboarded, regardless of how it is generated—whether from natural language, an OpenAPI specification, or a combination of existing tools—no manual configuration required. No restart. No setup steps. McProxy hot-reloads new servers dynamically, so there's zero downtime.
This transforms the way you think about integration. Instead of treating new integrations as major projects, they become trivial operations. Need a capability? Generate it. Want to automate a workflow? Combine existing tools. Everything happens in seconds and is immediately usable.
The AI-to-engineer feedback loop: Optimizing architectural patterns
We also found an unexpected benefit: Generated code serves as a feedback loop. When reviewing AI-generated servers, engineers sometimes discover better approaches than our hand-written implementations.
This creates a virtuous cycle. Human engineers provide the platform and patterns. The AI generates implementations based on those patterns. Humans learn from the AI's interpretations. Templates and prompts improve over time, leading to better generations.
The ecosystem becomes smarter with each server created.
Why the Model Context Protocol is critical for interoperability
McProxy builds on MCP rather than creating another proprietary format. This matters for longevity and interoperability.
MCP defines standard methods for exposing tools, handling authentication, and communicating results. Servers generated by McProxy work with any MCP-compatible client. As the AI ecosystem evolves, MCP-based integrations remain a relevant choice.
The stdio-based communication model ensures isolation. Each child server runs as a separate process with structured JSON-RPC messages. One server's failure doesn't cascade. Resource control is granular. Debugging is straightforward.
By positioning itself as a single MCP server connecting to many others, McProxy provides a clean abstraction. AI clients don't need to manage multiple connections or comprehend backend complexity. They connect to McProxy and access an ever-growing ecosystem.
It is worth noting, however, that the ultimate developer experience relies heavily on the capabilities of the LLM powering the client. A more capable client LLM will be better at selecting tools, generating arguments, and interpreting results, ultimately leading to a superior, more flexible integration experience with the McProxy tools.
Current McProxy limitations and the future roadmap
Dynamic generation isn't perfect. Generated code requires validation. While LLMs typically produce working code, edge cases and API changes can cause issues. We address this through testing frameworks and gradual rollout.
Future enhancements include:
- Version management for generated servers
- Automatic API change detection and regeneration
- Sophisticated orchestration patterns (parallel execution, conditional logic, and state management)
- Enhanced policy enforcement at the gateway level
- Integration quality scoring and monitoring
The goal is to make generated servers as robust as hand-crafted integrations while maintaining speed and flexibility.
Cross-domain enterprise applications beyond software engineering
While McProxy was built for development workflows, the concept applies to any domain that requires coordination across multiple tools, such as customer support, data analytics, and infrastructure management.
Modern work increasingly involves orchestrating specialized tools rather than using monolithic applications. AI agents excel at orchestration when they can flexibly create and adapt integrations. McProxy demonstrates that this flexibility is achievable through intelligent code generation and robust platform architecture.
The shift from static infrastructure to dynamic AI integrations
McProxy alters the foundational software architecture by treating integrations as dynamic resources created on demand, rather than static infrastructure that requires manual engineering maintenance.
By combining automated tool generation with real-time workflow orchestration, the platform flips traditional integration economics on its head. Operations that previously required careful planning and days of custom development are consolidated into automated, on-demand requests.
Why centralized gateway architecture matters for governance
Deploying a centralized proxy gateway introduces native architectural advantages for enterprise compliance. As an organization’s ecosystem of specialized AI tools expands, this central layer allows engineering teams to universally enforce rate limits, audit logs, and security policies without altering individual servers.
Ultimately, allowing AI agents to dynamically generate their own tools shifts their role within the enterprise: Agents transition from restricted assistants confined to hardcoded capabilities into true, adaptable development partners.
Building the future of secure AI integrations
The integration challenges developers have faced for years may finally have a scalable solution. While McProxy began as an internal project to streamline our own development workflows, the underlying architectural patterns—dynamic tool generation, client-server proxying, and centralized gateway policies—are design principles you can adopt in your own enterprise systems today.
By building a similar framework, you can turn static integrations into on-demand, secure capabilities. To get started, learn more about MCP in AI to explore how the protocol standardizes agent connectivity, and check out how Okta for AI Agents can help you secure and govern your custom agent platforms.
