What this page covers Alpha
This page is for product-level expectations, not error-by-error debugging.
Use it when you want to know:
- what Enginy MCP supports today
- what is still intentionally limited in alpha
- which assumptions are unsafe to build into an integration
Current limitations Alpha
| Limitation | What it means | What to do |
|---|---|---|
| Remote MCP only | Enginy MCP is served over Streamable HTTP. It is not a local stdio server. | Use a client that supports remote MCP directly, or put a bridge in front of Enginy MCP. |
| Alpha tool surface | The MCP surface is derived from the public OpenAPI spec and can still change. | Treat tool names and coverage as current behavior, not a contract for long-term stability. |
| Scope ceilings apply | A client can only use the scopes allowed by the workspace policy and the user approval. | Start with narrow scopes and expand only when a workflow needs more access. |
| OAuth, not API keys | The hosted flow is user-granted OAuth 2.0 Authorization Code + PKCE. | Do not expect a static API key to work for MCP access. |
| Stateless transport | Enginy does not rely on a sticky server-side MCP session. | Do not design around a long-lived session identifier. |
| Rotating refresh tokens | Refresh tokens change on every successful refresh. | Always store the newest refresh token and reconnect after stale-token failures. |
| Client behavior varies | Each client exposes MCP setup differently. | Follow the client-specific page for Claude, Codex, Cursor, or VS Code-based flows. |
FAQ Alpha
Which clients work best?
Start with the clients covered in Clients & Interfaces and Connect Claude Code. Claude Code, Codex, Cursor, VS Code-based agent UIs, and ChatGPT developer mode are the main patterns we document today.Can I use Enginy MCP with any MCP client?
Only if the client supports:- remote Streamable HTTP MCP
- OAuth 2.0 Authorization Code + PKCE
- bearer tokens and refresh tokens
- the ability to follow discovery instead of hardcoding endpoints
Will the tool names stay the same?
Not guaranteed in alpha. Enginy generates MCP tools from the public OpenAPI schema, so tool naming can change if the underlying route summaries or supported operations change.Why do I see no tools, or only a tiny subset?
Usually one of these:- the workspace policy is too narrow for the workflow
- the client approved only a small subset of scopes
- the client cached stale auth state
- the client is pointed at the wrong MCP URL
Is Enginy MCP a replacement for the REST API?
No. Use MCP when you want a tool-driven client experience with discovery and scoped OAuth. Use direct HTTP when you want a fixed integration against specific REST endpoints.Can I rely on a local callback port or a fixed browser flow?
For Claude Code we documenthttp://localhost:3118/callback, but the exact callback behavior is client-specific.
Do not assume every MCP client uses the same browser approval UX or the same redirect handling.
Does Enginy support everything in the public API immediately?
No. The MCP surface is generated from the OpenAPI document, but alpha support still depends on the current tool generation rules and on which public routes are surfaced for MCP. If you need a guaranteed integration point, use the REST API documentation instead.When this is a bug
Treat it as a bug when:- a documented client flow no longer works with the current hosted MCP URL
- a scope that should work according to Scopes is being rejected
- a working auth flow suddenly fails without a policy or client change
- a client-specific setup step changes
- a tool family is added, renamed, or temporarily unavailable
- a client assumes stdio, a fixed token path, or a non-OAuth flow
Clients & interfaces (Alpha)
See the per-client setup patterns for Claude, Codex, Cursor, VS Code, ChatGPT developer mode, and other
MCP clients.
Security and troubleshooting (Alpha)
Debug auth, scope, token, and transport issues after a client successfully connects.