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.
"Any API" is the key claim does it handle APIs that require OAuth or custom auth flows, or mostly simple API key setups? That's usually where these tools hit a wall.
MCP Bridge by Appfactor
@imad_elkhafi Totally fair — auth is where a lot of these break. 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.
@gabriel_ciuloaica Token caching and auto-refresh server-side is the right architecture the agent shouldn't be touching credentials at all. The DCR Shim for Azure/Entra is a clever workaround for a real limitation. Thorough answer, appreciate it.
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.
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.
This could save developers a lot of integration time.
MCP Bridge by Appfactor
@nithin_raju1 Thanks Nithin, Yes!!!! It's also of course about trying to reduce the maintenance surface area of many MCP servers, that often lack standardization or guardrails. Observability then becomes a major issue too.