Bring enterprise APIs to MCP without losing control.
Frege gives enterprise API teams a concrete way to expose tools and docs to AI clients while preserving isolation, access boundaries, auditability, and change control.
What enterprise reviews actually ask
Enterprise adoption does not stall because the API is missing. It stalls because buyers need confidence in how access is governed, how credentials are handled, how changes are rolled out, and how incidents can be investigated later.
- How is tenant data isolated?
- Who can see and call which tools?
- Can credentials be stored safely and applied per organization?
- Can we roll back a bad spec publish without breaking every client?
- Can we explain exactly what happened during an incident or review?
Frege is designed for those questions
Frege is not just a generator that turns API operations into tool definitions. It wraps the MCP surface in a runtime model that is easier to reason about in production.
Isolation at the data and process layers
Tenant-scoped data access runs behind PostgreSQL row-level security. Project MCP runtimes are supervised as separate processes. That means a misbehaving project is contained both in storage and in execution.
Relationship-based authorization
Frege uses Ory Keto to govern which tools and documents each API key can see. Unauthorized tools do not just fail when called—they can be hidden from listings entirely, reducing discovery risk.
Encrypted credentials per organization
Enterprise rollouts often require organization-specific backend credentials. Frege stores those encrypted, resolves them by organization and project, and applies them through pluggable auth adapters at proxy time.
Versioning that matches enterprise rollout
Every publish creates an immutable version. Teams can diff versions, detect breaking changes, roll back quickly, and pin clients to explicit versioned routes during migrations. That is much closer to how enterprise API change control actually works.
Identity and onboarding paths
Frege already includes identity and OAuth building blocks for cases where downstream users or customer organizations need to authenticate, consent, and receive scoped access. That makes it suitable for both internal enterprise tooling and external partner-facing integration flows.
Where it fits best
- Internal platform teams exposing existing service APIs to AI clients under central governance.
- Regulated product teams that need docs, versions, and access rules to move together.
- Partner ecosystems where downstream organizations need their own credentials and controlled onboarding.
- Security-conscious evaluations where technical buyers want to inspect the runtime model, not just marketing claims.
Ship MCP your platform and security teams can reason about.
Start with the API assets you already have, then add the access control, versioning, encryption, and auditability needed for a serious rollout.