Skip to main content
The OpenAPI Adapter automatically converts OpenAPI 3.x specifications into fully-functional MCP tools. Each API operation becomes a callable tool with built-in validation, authentication, and type safety.

Why use it

  • Zero boilerplate — Turn REST APIs into MCP tools without writing glue code
  • Type-safe — Automatic Zod schema generation from OpenAPI specs
  • Multi-auth support — Built-in support for multiple authentication providers
  • Production-ready — Comprehensive security validation and error handling
  • Flexible — Filter operations, customize schemas, and inject custom logic

Installation

Quick start

Configuration

Required Options

string
required
Unique identifier for this adapter instance. Used to prefix tool names when multiple adapters are present.
string
required
Base URL for API requests (e.g., https://api.example.com/v1).
OpenAPIV3.Document | OpenAPIV3_1.Document | object
In-memory OpenAPI specification object. Accepts typed documents or plain objects from JSON imports. Use either spec or url, not both.
string
URL or file path to the OpenAPI specification. Can be a local file path or remote URL. Use either spec or url, not both.

Optional Configuration

Record<string, string>
Static headers applied to every request. Useful for API keys or static authentication tokens.
(ctx: FrontMcpContext, headers: Headers) => Headers
Function to dynamically set headers based on request context. Access ctx.authInfo, ctx.sessionId, ctx.traceContext, etc. Headers set here are hidden from MCP clients.
(ctx: FrontMcpContext, body: any) => any
Function to transform or augment the request body before sending. Access ctx.authInfo, ctx.sessionId, etc. Useful for adding tenant IDs or user-specific data.
LoadOptions
Options for loading the OpenAPI specification (headers, timeout, etc.). See mcp-from-openapi for details.
GenerateOptions
Options for tool generation. See Advanced Features for details.
InputTransformOptions
Hide inputs from the schema and inject values at request time. Supports global, per-tool, and generator-based transforms. See Input Schema Transforms.
ToolTransformOptions
Customize generated tools with annotations, tags, descriptions, and more. Supports global, per-tool, and generator-based transforms. See Tool Transforms.
'summaryOnly' | 'descriptionOnly' | 'combined' | 'full'
How to generate tool descriptions from OpenAPI operations. Default: 'summaryOnly'.
FrontMcpLogger
Logger instance for adapter diagnostics. When using OpenapiAdapter.init() within a FrontMCP app, the SDK automatically provides the logger via setLogger(). For standalone usage, you can optionally provide a logger implementing the FrontMcpLogger interface; if omitted, a console-based logger is created automatically.

Authentication

The OpenAPI adapter provides multiple authentication strategies with different security risk levels. Choose the approach that best fits your use case.

Strategy 1: Static Headers (Medium Risk)

Best for: Server-to-server APIs with static credentials.
Store credentials in environment variables or secrets manager, never hardcode them.
Best for: Multi-provider authentication (GitHub, Slack, Google, etc.). This approach maps OpenAPI security scheme names to authentication extractors. Each security scheme can use a different auth provider from the authenticated user context.
How it works:
  1. Extracts security scheme names from OpenAPI spec (e.g., GitHubAuth, SlackAuth)
  2. For each tool, looks up the required security scheme
  3. Calls the corresponding extractor function to get the token from ctx.authInfo
  4. Applies the token to the request
Security Risk: LOW — Authentication is resolved from the request context, not exposed to MCP clients.
The ctx parameter in authProviderMapper, headersMapper, bodyMapper, and securityResolver callbacks is the FrontMcpContext containing authInfo, sessionId, traceContext, and more. By the time your tool executes, authentication has been verified and auth fields are populated.

Strategy 3: Custom Security Resolver (Low Risk)

Best for: Complex authentication logic or custom security requirements.
Security Risk: LOW — Full control over authentication resolution from request context.

Strategy 4: Static Auth (Medium Risk)

Best for: Server-to-server APIs where credentials don’t change per user.
Security Risk: MEDIUM — Store credentials securely in environment variables or secrets manager.

Strategy 5: Dynamic Headers & Body Mapping (Low Risk)

Best for: Adding user-specific data (tenant IDs, user IDs) to requests.
Security Risk: LOW — User-specific data is injected server-side, hidden from MCP clients.

Default Behavior (Medium Risk)

If no authentication configuration is provided, the adapter uses authInfo.token for all Bearer auth schemes.
Security Risk: MEDIUM — Only works for single Bearer auth. For multiple auth providers, use authProviderMapper or securityResolver.

Advanced Features

Filtering Operations

Control which API operations become MCP tools.

Input Schema Transformation

Customize the input schema for generated tools.

Input Schema Transforms

Hide inputs from AI/users and inject values server-side at request time. This is more powerful than inputSchemaMapper as it provides access to the authentication context.
Security Benefit: Sensitive inputs like tenant IDs and user IDs are injected server-side, never exposed to MCP clients.

Tool Transforms

Customize generated tools with annotations, tags, descriptions, and more.
Available transform properties:

x-frontmcp OpenAPI Extension

Configure tool behavior directly in your OpenAPI spec using the x-frontmcp extension:
openapi.yaml
Extension properties:
Use x-frontmcp in your OpenAPI spec for declarative configuration. Use toolTransforms in adapter config to override spec values.

Description Mode

Control how tool descriptions are generated from OpenAPI operations:

Load Options

Configure how the OpenAPI spec is loaded.

How It Works

Request Processing

  1. Path Parameters — Interpolated into URL template (e.g., /users/{id}/users/123)
  2. Query Parameters — Validated and appended to URL
  3. Headers — Merged from additionalHeaders, headersMapper, and security config
  4. Request Body — Validated and transformed by bodyMapper (for POST/PUT/PATCH)
  5. Authentication — Applied via selected strategy (auth provider mapper, security resolver, etc.)

Response Processing

  • JSON responses — Automatically parsed to objects
  • Text responses — Returned as plain text
  • Error responses — Thrown as errors with status code and message

Complete Examples

Multi-Provider OAuth Application

Multi-Tenant SaaS Application

Expense Management (From Demo)

Security Best Practices

Use Auth Provider Mapper

For multi-provider authentication, use authProviderMapper to map each security scheme to the correct auth provider. This provides LOW security risk.

Never Hardcode Credentials

Always store credentials in environment variables or secrets manager. Never commit credentials to source control.

Avoid includeSecurityInInput

Setting generateOptions.includeSecurityInInput: true exposes auth fields to MCP clients (HIGH risk). Only use for development/testing.

Validate User Context

Always validate that authInfo.user contains the expected fields before extracting tokens. Handle missing tokens gracefully.

Security Risk Levels

The adapter automatically validates your security configuration and assigns a risk score:

Built-in Security Protections

Beyond authentication, the adapter includes defense-in-depth protections: Auth Type Routing: Tokens are automatically routed to the correct context field based on security scheme type (Bearer → jwt, API Key → apiKey, Basic → basic, OAuth2 → oauth2Token).
These protections are automatic—no configuration required. See the README for implementation details.

Troubleshooting

Cause: Your OpenAPI spec defines security schemes that aren’t mapped in authProviderMapper.Solution: Add all required security schemes to authProviderMapper:
Cause: The tool requires authentication but no auth configuration was provided.Solution: Choose one of the authentication strategies:
  1. Add authProviderMapper (recommended for multi-provider)
  2. Add securityResolver (for custom logic)
  3. Add staticAuth (for server-to-server)
  4. Add additionalHeaders (for static API keys)
Cause: Tools may be filtered out by filterFn or excludeOperationIds.Solution: Check your filter configuration or remove filters to include all operations.
Cause: Authentication token is missing or invalid.Solution:
  1. Verify authInfo.user contains the expected token fields
  2. Check that token extraction returns a valid value
  3. Verify the token is not expired
  4. Check API logs for specific auth errors
Cause: OpenAPI spec may not be typed correctly.Solution: Cast the spec to OpenAPIV3.Document:

API Reference

OpenapiAdapter.init(options)

Creates a new OpenAPI adapter instance. Parameters:
  • options: OpenApiAdapterOptions — Adapter configuration
Returns: Adapter instance ready for use in @App({ adapters: [...] })

Security Types

Performance Tips

The adapter uses lazy loading — the OpenAPI spec is only loaded and tools are only generated on first use, not during initialization.
Combine with app-level plugins (caching, logging, metrics) to enhance all generated tools automatically.
Use filterFn to generate only the tools you need, reducing initialization time and memory usage.

Demo Application

See the expense management demo app using the OpenAPI adapter

Example OpenAPI Spec

OpenAPI spec used in the demo application

Generator Library

Underlying library for OpenAPI to MCP conversion

Source Code

View the adapter source code