Launched this week
MCP Bridge by Appfactor
Connect any API to any AI agent
279 followers
Connect any API to any AI agent
279 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.
MCP Bridge by Appfactor
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!
Using MCP as the standard transport is a smart call. Agents get structured tool definitions without any custom adapter code. We've hit the N+1 connector problem repeatedly building AI agents that need to talk to CRMs and ticketing systems. How do you handle auth token lifecycle when agents discover and invoke new endpoints dynamically?
MCP Bridge by Appfactor
@anand_thakkar1 Quick reframe — MCP Bridge actually eliminates the N+1 situation by construction: it's a single MCP server that fronts every integration. Your agent connects once and discovers tools across all your CRMs, ticketing systems, and whatever else through that one endpoint. No per-system connector glue on the agent side.
The real question then is how we handle token lifecycle inside that single server when an agent is invoking tools dynamically across many backends:
1. Refresh happens at the bridge, invisible to the agent. We hold refresh tokens server-side, track expiry, and refresh proactively (or on a 401 retry). The agent's tool call either succeeds or gets a clean error — it never has to reason about token state.
2. Tokens are bound to integration, not to the agent. When a tool is invoked, the bridge looks up credentials keyed by the authenticated end user on whose behalf the agent is running, not anything the agent provides.
3. Scope mismatches trigger re-consent at the human layer. If an agent reaches for an endpoint whose required scopes aren't covered by the existing grant, the bridge returns a structured "needs consent" response and the OAuth flow runs with the human user. The agent doesn't get to escalate on its own.
4. Revocation propagates. When an upstream system revokes a token, or a user revokes consent in our UI, the cached binding is invalidated and subsequent tool calls fail with a clear signal rather than a 401 storm.
5. Audit per tool call. Every invocation logs which credential was used, when it was last refreshed, and which user it was bound to. SOC2 table stakes, but also what lets you actually debug "why did the agent suddenly start failing on Salesforce."
Tool selection is fully dynamic when the underlying integrations are pre-authorized. A brand-new system the user has never connected still needs a human-in-the-loop first consent — no auth model gets around that. The trick is making that the only manual step.
How does auth work when the target API needs OAuth? that's the part that always kills these tools for me
MCP Bridge by Appfactor
@trekh Totally fair — auth is where a lot of these break. We support OAuth2 client-credentials (and password grant) for target APIs: MCP Bridge fetches, caches, and auto-refreshes the token server-side so the agent never touches it. Plus Bearer/Basic/API-key, Cognito SRP, and WS-Security. Credentials are encrypted at rest.
The "connect any API to any AI agent" pitch is compelling. I wonder how it handles auth flows that require OAuth callbacks vs simple API keys. That is usually the painful part.
MCP Bridge by Appfactor
@xiaosong001 For target APIs we support OAuth2 client-credentials and password grant, with MCP Bridge fetching, caching, and auto-refreshing the token server-side so the agent never touches it. We also handle Bearer/Basic/API-key, Cognito SRP, and WS-Security, and all credentials are encrypted at rest.
One thing worth flagging if you're planning to run MCP Bridge in Azure with Entra ID as the IdP: the MCP authorization spec requires Authorization Servers to support Dynamic Client Registration (RFC 7591), and Entra ID doesn't. Without a workaround, every MCP user would need their own Entra app registration — unworkable at any real scale. So we provide a DCR Shim: it presents a DCR-compliant AS interface to clients while delegating the actual OAuth flow to a single pre-registered confidential app in your tenant.
Congrats on your launch @keith_neilson @ehw_appfactor @knarik !
You provide any way to test the MCP tool definitions created as well?
MCP Bridge by Appfactor
@aiswarya_s thank you! 😊
MCP Bridge by Appfactor
@aiswarya_s Yes — there's an inline test runner in the Test Console. You can invoke a tool directly against the real endpoint, inspect the response, and verify the schema and adapter produce what you expect. Tightens the build-test loop a lot.
Another way is to use the MCP Inspector connected to MCP Bridge.
mailX by mailwarm
How do you handle user permissions without leaking secrets to the agent?
MCP Bridge by Appfactor
@thamibenjelloun Agent never sees any permissions nor credentials. Credentials used to access an API, are stored encrypted by the Bridge itself. The Agent interacts only with tools/prompts/resources.
On top of that, optional input/output guardrails to protect tool execution.
Input guardrails detect prompt injection patterns in tool arguments (3 sensitivity levels: Low, Medium, High — covering role-play jailbreaks, XSS, SQL injection, role tag injection).
Output guardrails detect sensitive data in API responses across 8 categories (SSN, credit cards, AWS keys, GitHub tokens, JWTs, API keys, emails, phone numbers) with per-category detect-and-log or detect-and-redact modes. Per-tool overrides. Violations logged to MCP clients in real time. Off by default — configurable via Settings UI
the security breakdown in the comments is the most honest thing I've read on a PH launch. most tools in this space skip the 'what happens when your agent gets prompt injected' conversation entirely. the 3-level sensitivity guardrails and credential encryption is how this should be built
MCP Bridge by Appfactor
@tina_chhabra Hi Tina,
That is very kind of you. Thank you for the feedback and your support.