MCP Bridge by Appfactor
Connect any API to any AI agent
295 followers
Connect any API to any AI agent
295 followers
Point MCP Bridge at any REST, GraphQL, SOAP, or gRPC API. It auto-generates MCP tool definitions with typed schemas, auth, rate limiting, and response processing. Your LLM agents call enterprise APIs through one standard interface.
Free Options
Launch Team / Built With
Render: Get up to $100K in startup creditsCloud infrastructure for founders who want to move fast and NOT break things
Promoted
Auto-generating typed MCP schemas from SOAP and gRPC alongside REST is the hard part others skip. We've spent cycles manually wrapping customer-side APIs with inconsistent auth patterns just to get an agent to call them reliably. How does schema inference hold up for APIs without an OpenAPI spec, or ones where the response shape varies by query?
@retain_dev Nailed it — that's the part we leaned into. gRPC and GraphQL need no hand-written spec: we pull typed schemas from server reflection / introspection live off the endpoint (gRPC even synthesizes tool descriptions from message fields when proto comments are missing). SOAP uses the WSDL. The one honest gap is REST — we still need an OpenAPI spec, no inference from sample payloads yet.
For varying shapes: GraphQL unions → oneOf, nullables → anyOf, OpenAPI oneOf/anyOf preserved, gRPC treated as dynamic; plus a response-processing layer that rewrites the advertised output schema to match what the agent actually gets back.
Finally, a product to help you create a MCP server, fast and reliable. It's about time! If you don't use @MCP Bridge by Appfactor, you're ngmi.
S/O for the launch, ?makers
@fmerian Thanks so much for the support!
Most "connect any API" tools mean "connect any API that already has an OpenAPI spec and clean auth." What does MCP Bridge actually do when you're dealing with something messier, like a legacy REST endpoint with inconsistent error codes or an API that requires a multi-step auth handshake before you can do anything useful?
Congrats for the launch!
@fberrez1 Honestly, this is the right critique to make — OpenAPI-only tooling falls apart on the second enterprise customer.
How MCP Bridge layers it:
1. OpenAPI / WSDL / GraphQL as a starting point, not the finish line. The Tool Builder imports what you have, but it generates an editable tool definition, not a sealed wrapper.
2. Adapters for response normalization — when an API returns 200 with `{"error": "..."}` in the body, or different error shapes per endpoint, you write a small transform (JavaScript, runs in our sandbox) that maps the mess to a consistent contract. The agent sees a clean tool; the bridge does the dirty work.
3. Multi-step flows as a single tool — auth handshake → token cache → main call → response shaping is one composable tool from the agent's perspective. The LLM never has to reason about flow state.
4. Custom auth handlers — not just OAuth and API keys. We've shipped tools against APIs that want a nonce signed with a private key, exchanged for a session token, then the real request. Three calls and some crypto — one tool to the agent.
5. Failure shaping — inconsistent status codes get classified at the adapter layer into a retry/no-retry decision, so the agent doesn't have to figure out whether a 200 with an error body means "try again" or "give up."
Most "connect any API" tools assume the world looks like Stripe. Enterprise APIs don't. The Tool Builder and the sandbox exist specifically to handle the gap between what's documented and what actually works.
Hi builders!
Keith here, CEO and co-founder of AppFactor. Really excited to ship this one.
The story
We built MCP Bridge for our own need, not an idea.
At AppFactor we've spent years building deterministic tools for an orchestration system of agents that deliver autonomous software maintenance. Infra and software discovery, scanning orchestration, build engines, deployment automation. As we layered our upcoming agentic platform (ForgeCatalyst) on top to harness these tools, we hit the wall every team building production agents eventually hits. Security, governance, cost/token usage, observability...
The AppFactor system requires meaningful validations, in environments where governance, security and controls are paramount when acting on customer code. With large complex API's with many tools, comes the next challenge - context constraints and efficiencies and multiple protocols to support.
The standard fix is to hand-build a dedicated MCP server for every API. This doesn't scale. We know we are not alone with our requirements and given the domain we operate in which is all about software maintenance, legacy transformation and the eternal battle of trying to bridge the past to the future. We recognised that not all systems have clean, well presented OpenAPI spec API's. There are many API protocols, and almost all API's were indeed built before agents and LLM's became an exciting real world proposition. That poses challenges in how these tools are invoked and consumed. So we built MCP Bridge to address all of these challenges.
You know the rest of the story.
What it does
Point it at any REST, GraphQL, SOAP, or gRPC API. It auto-generates fully-typed MCP tools with behavioral annotations and smart response processing. Self-hosted. Open source. Credentials never leave your environment.
What's shipped
4 API types, end-to-end
6 auth methods (Bearer, Basic, API key, OAuth2, Cognito SRP)
Human-in-the-loop approval for destructive ops
Code Mode: 3 meta-tools replace 100+ definitions, ~98% less context
Analytics: latency, token cost, errors per tool
Built in Rust (Dioxus + Axum), PostgreSQL, in a container
We're in the comments all day. What APIs would you connect first? And how should we improve?
Happy building!
Keith
→ MCP Bridge: https://mcp-bridge.ai/
→ Docs: https://docs.mcp-bridge.ai/
Thanks @fmerian for hunting us!
@kjlis Great question. The threat categories we take most seriously with MCP today:
- Prompt injection through tool responses — malicious servers return content that hijacks agent reasoning
- Confused deputy — agents inherit the union of all tool permissions, so a harmless tool becomes dangerous when it sits next to a powerful one
- Credential aggregation — MCP servers concentrate OAuth tokens and become high-value targets
- DNS rebinding / host header attacks on local MCP servers
- Tool description poisoning — descriptions are part of the prompt, so they can be weaponised to bias tool selection
What to monitor:
- Audit log every tool call with full I/O
- Egress traffic from the agent runtime
- Tool description changes over time
- Token usage patterns per integration
In MCP Bridge we lean on per-tool scoping, sandboxed execution for generated code, and full audit trails — the enterprise customers we work with treat agent runtimes the same way they treat any other privileged service, and that's the right instinct.
@kjlis @gabriel_ciuloaica building wrappers for legacy soap and grpc services just to make them talk to cursor or claude code is a huge pain. having a local open source rust engine to handle this via a container setup is an absolute lifesaver for data engineering pipelines. you guys built this exactly how an enterprise developer utility should be executed.
the auto-generated schema approach is smart. biggest pain point with MCP right now is writing tool definitions by hand for every API you want to connect. curious how it handles APIs with inconsistent response formats across endpoints?
@ozandag Thanks — yeah, the hand-written tool definition tax is the largest hidden cost in MCP today, especially when you've got 200+ endpoints to expose.
For inconsistent response shapes across endpoints, the approach is:
1. Auto-gen from the spec, refine from real responses. OpenAPI is often wrong or under-specified, so the Tool Builder lets you feed in actual sample responses and update the schema to match what production really returns. Spec says one thing, reality says another — reality wins.
2. Per-endpoint response transforms. Each tool has its own normalizer slot. Endpoint A returns `{data: [...]}`, endpoint B returns a bare array — a set of declarative rules are predefined. Written once per endpoint, not per call.
3. Canonical field names. When the same concept appears as `user_id`, `userId`, and `uid` across endpoints, the adapter maps them to one canonical form.
Auto-generation gets you ~70% there for clean APIs, maybe ~30% for legacy.
We've run into this problem a few times while connecting different agent workflows. The integration itself is usually easy, but keeping everything reliable once multiple tools start talking to each other is where things get messy.
Are most teams using MCP Bridge as a central layer between agents, or more as a quick way to expose existing APIs to AI tools?
@zaid_mallik1 Thanks Zaid,
It's depending on the goals and pain points they have had to date. Some teams are starting with the second use case: exposing existing APIs (REST, SOAP, gRPC, GraphQL) to their agents without having to build and maintain a dedicated MCP server per system. That's the fast win.
But many teams getting real value treat MCP Bridge as the central connectivity layer. One control plane for auth, governance, observability, and protocol translation across all their agent workflows. Once you have more than two or three agents talking to more than a handful of systems, the "one MCP server per API" approach collapses under its own weight (sprawl, context bloat and then high costs!, inconsistent auth). Exactly the mess you're describing.
@keith_neilson That makes a lot of sense.
The auth and governance layer is actually the part that seems to get overlooked in most MCP discussions. Everyone talks about connecting tools, but once you have multiple agents operating across different systems, consistency becomes a much bigger problem than connectivity.
Have you seen teams run into issues with context isolation between agents, or does the MCP layer end up naturally enforcing those boundaries?