MCP Flow

MCP Flow turns an existing REST API into a governed, agent-callable MCP (Model Context Protocol) server. Point it at an OpenAPI schema and it discovers every operation, scores the risk of exposing each one to an AI agent, drafts the resulting tool definitions, and gates every change behind automated evals before it ever reaches production traffic.

What it's for

Teams that want an LLM agent to call their API can't just hand it the raw OpenAPI spec — every endpoint becomes a callable "tool," and some of those tools (deleting a customer, issuing a refund, changing billing) are far riskier to expose than others. MCP Flow is the control plane for that process: it analyzes the API, recommends what should and shouldn't be exposed, generates the agent-facing tool contracts, tests them with simulated agent calls, and only promotes a new version once it passes a quality gate.

Related MCP server: OpenAPI MCP Server

Main features

• API Analysis — Every operation discovered in the OpenAPI schema, annotated with a risk level (low/medium/high/critical) and an exposure recommendation (recommended, optional, review required, exclude), with full request/response schema detail per operation.

• Capabilities — The generated agent-facing contract for each exposed tool: its intent, when to use it (and when not to), argument schemas, side effects, and exposure policy (allow, deny, or require client confirmation).

• Agent Tests — Automated evals that score tool selection accuracy, argument accuracy, negative selection, tool confusion, risk behavior, and schema compatibility, run against both the published and candidate release so regressions are visible before they ship.

• Release — The promotion gate. A candidate release can only be published once its eval run passes; blocking failures, score deltas, and a full diff against the currently published version are shown before you publish. Previous releases stay in history and can be rolled back to individually.

• Overview — At-a-glance sync status, tool inventory, gate status, and recent traffic for the active project.

End-to-end workflow

MCP Flow is organized around three phases: discover and draft the tool surface, test and gate every change, then publish and operate the resulting MCP server.

1. Discover and draft

• Detect changes to the connected OpenAPI specification, either on a polling interval (URL source) or on re-upload (file source).

• Classify every operation's risk and generate a candidate MCP release whenever the spec changes.

• Draft MCP capabilities from the recommended operations, then let a reviewer include, exclude, rename, or edit each one on the Capabilities screen before it ships — the risk classification is a starting recommendation, not a final decision.

• Generate an Agent Contract for each included capability: its intent, usage guidance (when to call it and when not to), argument schema, side effects, and exposure policy.

2. Test and gate

• Generate behavioral eval cases directly from each Agent Contract, covering correct tool selection, negative selection (not calling a tool when it shouldn't), argument accuracy, tool confusion, risk behavior, and schema compatibility.

• Run those evals against a supported LLM provider and model (the eval run records which provider/model produced each score) to produce a per-dimension and overall Agent Readiness Score.

• When the spec changes, the resulting candidate release is scored the same way, and the Release screen shows the schema, tool, contract, and risk diff against the currently published release — added/removed/modified tools, regressed scores per tool, and any new risk classifications.

• Releases pass or are blocked using configurable thresholds: a release with blocking failures (e.g. a capability scoring below the minimum, or an unresolved critical-risk exposure) cannot be published until it's fixed and re-evaluated.

3. Publish and operate

• Publishing a passed candidate makes it the live release; every prior published version stays in history and can be rolled back to individually if a regression is caught after the fact.

• The published release is served as a hosted remote MCP endpoint that agent clients connect to.

• MCP clients calling that endpoint are authenticated, and MCP Flow in turn authenticates its own requests to the customer's upstream API using the credentials configured for the project.

• Every call is captured in a traffic log — tool name, policy result (allowed / denied / confirmation required), success or error status, latency, and the client and release version involved — which feeds the recent-activity view on Overview.

Note on this build: API Analysis, Capabilities, Agent Tests, and Release are fully implemented end-to-end. Capability include/exclude/rename/edit, hosted endpoint publishing, MCP client authentication, and upstream API authentication are modeled in the data layer and described above as the intended workflow, but don't yet have dedicated UI in this version — a dedicated Traffic log view and a Settings screen for connection/auth management are linked from the sidebar but not yet built.

Creating a project

1. From the project switcher, choose New project.

2. Basics — Name the project, add a short description, and choose the environment (development or production).

3. Connect your API — Provide the OpenAPI 3.x schema either as a URL (polled on an interval you set) or as an uploaded file (.json/.yaml). Optionally override the base URL if it differs from the schema's declared server, and choose the authentication method the agent will use (API key, bearer token, or OAuth 2.0). Credentials themselves are configured afterward in Settings.

4. Review — Confirm the details, then select Create & analyze.

What happens during analysis

Creating a project (and every subsequent schema poll) triggers the same pipeline:

1. Fetch the OpenAPI schema from the configured URL or uploaded file.

2. Parse operations — every path/method combination becomes a candidate API operation.

3. Classify risk per operation — each operation is scored by risk level and assigned an exposure recommendation based on its HTTP method, side effects, and data sensitivity.

4. Draft agent capabilities — recommended operations are turned into MCP tool definitions (name, description, argument schema, usage guidance) ready for review on the Capabilities screen.

The result lands as a candidate release, which then needs to pass its automated evals on the Agent Tests screen before it can be promoted on the Release screen.

Getting started locally

npm install
npm run dev

Then open http://localhost:3000. The app runs entirely on in-memory mock data — no environment variables or external services are required.

Adding components

This project uses shadcn/ui. To add a component:

npx shadcn@latest add button

Components are placed in components/ui and can be imported as:

import { Button } from "@/components/ui/button";