Skip to main content
Using Claude (any surface), Codex, Cursor, VS Code, Gemini CLI, Microsoft 365 Copilot, or ChatGPT? Each has its own dedicated setup page — see the Client support matrix to pick yours. This page covers everything else: bridges and building your own MCP client.

​
Other remote-MCP clients

Add https://openapi.enginy.ai/mcp and follow the client’s remote MCP instructions. If the client only speaks stdio or SSE, place a bridge such as mcp-remote in front of Enginy MCP and let that bridge handle the remote HTTP transport.

​
Advanced setup details

Everything below is mainly for people configuring clients in depth, debugging a connection, or building their own MCP experience.

​
What a client needs in order to work with Enginy

An MCP client can integrate with Enginy if it supports:
  • remote Streamable HTTP MCP
  • OAuth 2.0 Authorization Code + PKCE
  • public-client token exchange with no client secret
  • bearer access tokens and refresh tokens
If your client only supports stdio or SSE, place a bridge in front of Enginy MCP and let that bridge handle the remote HTTP transport. If your client is a server-side platform that cannot run a browser OAuth flow at all (MuleSoft’s MCP Connector, backend agents, schedulers), it can authenticate with a static workspace API key instead — see Server-to-Server (API key).

​
Advanced: discovery model

Start from the hosted MCP URL:
Clients should use discovery instead of hardcoding OAuth endpoints:
  • the MCP host advertises protected-resource metadata
  • the authorization server publishes OAuth authorization-server metadata
  • the client can then follow the discovered authorization, token, revocation, and JWKS endpoints
Enginy also exposes standard authorization-server metadata at:

​
Advanced: OAuth behavior

Enginy uses:
  • Authorization Code grant with PKCE (S256)
  • bearer access tokens
  • rotating refresh tokens
  • no client secret for the hosted remote-client flow
Important runtime behavior:
  • access tokens are short-lived
  • refresh tokens rotate on every successful refresh
  • reusing a refresh token after rotation returns invalid_grant; an already-rotated active token chain is preserved
  • token refresh is checked against the current workspace policy, not only the original grant

​
Advanced: registration options

Enginy supports two useful patterns for public clients:

​
1. Resource-server registration

Post to the hosted MCP server’s /register endpoint with:
That returns a signed dynamic client ID tied to the redirect URIs you supplied. This works well for clients that expect dynamic client registration near the MCP resource server.

​
2. Admin-managed registration

If your workspace pins trusted client IDs, an Enginy admin can pre-register the client from the Enginy side so the client ID is persisted in the workspace allowlist. Use this when you want a tighter production trust model than “any client ID is acceptable.”
If your workspace leaves the allowed client-ID list empty, Enginy accepts any client ID that otherwise passes the redirect-URI and scope checks. If you do pin client IDs, the client must match that allowlist even when using dynamic registration.

​
Advanced: transport expectations

Enginy’s MCP transport is intentionally stateless:
  • no long-lived server-side MCP session is required
  • requests are handled over Streamable HTTP with JSON responses enabled
  • the same bearer token is forwarded into the matching OpenAPI route call
Enginy MCP serves two protocol eras from the same /mcp URL:
  • 2026-07-28 and later: modern clients connect with server/discover and per-request _meta envelopes
  • 2025-era revisions (up to 2025-11-25): legacy clients keep using the initialize handshake, unchanged
Clients that pin a protocol era or probe with server/discover (for example the official TypeScript SDK v2 with versionNegotiation: { mode: 'auto' }) negotiate the modern era automatically; every existing 2025-era client continues to work without changes. For OpenAPI-derived tools, the input contract is normalized into these keys:
  • pathParams
  • query
  • body
Example:

​
Advanced: tool-generation rules

This is important if you are building a client UX around tool discovery. Enginy generates tools from the public OpenAPI schema:
  • summaries become tool names when possible
  • if names would collide, Enginy falls back to method-plus-path names
  • only JSON request bodies are surfaced
  • required scopes come from the OpenAPI route description metadata
This means the OpenAPI docs are the source of truth for the MCP surface area. As Enginy adds public routes, the MCP server can expose more tools without inventing a second contract format.

​
Advanced: compatibility aliases

Some MCP clients assume shorthand OAuth paths. Enginy supports both the canonical and shorthand forms:
  • authorization: canonical /api/v1/mcp/oauth/authorize, alias /authorize
  • token: canonical /api/v1/mcp/oauth/token, alias /token
  • revocation: canonical /api/v1/mcp/oauth/revoke, alias /revoke
You should still prefer discovery and canonical metadata, but these aliases improve client compatibility when a tool makes stricter assumptions.

Client support matrix

Find the dedicated setup page for Claude, Codex, Cursor, VS Code, Gemini CLI, Microsoft 365 Copilot, or ChatGPT.

FAQ / known limitations

See the current constraints before you assume a client or workflow should work.