feat(mcp): expose REST APIs as MCP tools from an OpenAPI spec (type: openapi) - #840
Conversation
…openapi) A registered mcp_server can now be backed by a plain REST API instead of a real MCP upstream: 'type: openapi' plus an OpenAPI 3.x document in 'spec' makes the gateway generate one tool per operation and execute tools/call as HTTP requests against 'url', with the gateway-held credential injected (bearer / api_key with an optional api_key_header override / oauth2 client credentials) and never exposed to the calling agent. Generation follows LiteLLM's openapi_to_mcp_generator for familiarity: sanitized operationId tool names (fallback method_path, _2/_3 suffixes on collisions at runtime), path/query parameters as schema properties, a JSON request body as a single 'body' property. Beyond the baseline: bounded local $ref resolution keeps referenced schemas' shape, non-2xx responses and argument mistakes surface as tool-level isError results, operations whose body has no application/json variant are skipped instead of emitting a broken tool, and header/cookie parameters are never exposed to the agent. The Admin API validates strictly at write time (missing/invalid spec, Swagger 2.0, zero generatable operations, duplicate sanitized tool names, api_key_header coupling) via the new aisix_mcp::validate_spec; snapshot loading stays permissive and degrades a broken row like an unreachable upstream. Existing governance — approval flow, per-tool ACLs, per-server rate limits, guardrails — applies unchanged since the openapi bridge sits behind the same McpBridge surface. Ref api7/AISIX-Cloud#1077
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 12 seconds Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (17)
Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
1 participant
What
A registered
mcp_servercan now be backed by a plain REST API instead of a real MCP upstream. Settingtype: openapiplus an OpenAPI 3.x document underspecmakes the gateway generate one MCP tool per operation and executetools/callas an HTTP request against the resource'surl(the REST base URL). The gateway-held credential —bearer,api_key(defaultx-api-keyheader, overridable via the newapi_key_headerfield), oroauth2client credentials through the existing token cache — is injected on every outbound request and never exposed to the calling agent.How
aisix-core:McpServergainstype(mcp|openapi, defaultmcp— existing rows are untouched),spec, andapi_key_header; resource JSON schema regenerated.aisix-mcp: newopenapimodule with anOpenApiBridgeimplementing the existingMcpBridgetrait;McpGateway::from_snapshotpicks the bridge pertype. Because the bridge sits behind the same surface, existing governance — approval gating, per-tool ACLs / MCP policies, per-(key × server) rate limits, guardrails, usage events — applies to generated tools unchanged.openapi_to_mcp_generator(sanitizedoperationIdnames capped at 128 chars, fallbackmethod_path, path/query params as schema properties, JSON request body as onebodyproperty), with deliberate improvements:$refresolution (depth 16, 256 expansions, cycle-safe) so referenced schemas keep their shape;isErrorresults the agent can react to;application/jsonvariant are skipped rather than emitting a tool that cannot succeed;/,\,.,..) and percent-encoded.aisix_mcp::validate_spec: missing/non-object spec, Swagger 2.0 (with a conversion hint), zero generatable operations, duplicate post-sanitization tool names, andapi_key_headercoupling all fail with a message naming the problem. Snapshot loading stays permissive: a broken row degrades like an unreachable upstream (tools absent, warning logged) instead of poisoning the snapshot.Behavior notes
oauth2invalidates the cached token so the next call re-mints (mirrors the MCP connect path).Tests
validate_spec, admin coupling.tests/openapi_tool_roundtrip.rs): real axum REST API + full gateway over Streamable HTTP driven by an rmcp client — list/call, auth injection for both bearer and custom-header api_key, error surfacing, broken-spec degradation next to a healthy server.tests/e2e/src/cases/mcp-openapi-e2e.test.ts): realaisixbinary + etcd + fake ERP REST upstream — generated tool discovery with spec-derived schemas, GET/POST execution with gateway-held auth, non-2xx and missing-param error results, and per-tool ACL enforcement on generated tools.Fixes api7/AISIX-Cloud#1077 (control-plane exposure ships as a paired AISIX-Cloud PR; docs as a paired api7/docs PR)