FAQ / Known Limitations

​

What this page covers

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
• which assumptions are unsafe to build into an integration

If you are already debugging auth or scope errors, use Security & Troubleshooting instead.

​

Current limitations

​

FAQ

​

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

If your client only supports stdio or SSE, you need a bridge in front of Enginy MCP.

​

Will the tool names stay the same?

Not guaranteed. 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

If this happens after a successful login, check Scopes and then retry the authorization flow.

​

A tool I used before disappeared (for example start_an_actions_run)

Enginy keeps serving every tool — when a previously-working tool vanishes from your client while mcp_whoami still shows the right role and scopes, the client is showing you a stale cached tool list, and large tool definitions are the most likely ones to go missing. Reconnecting or re-authorizing does not refresh that cache. Force a tool-list refresh instead:

• Claude (claude.ai): Settings → Connectors → open the Enginy connector → ⋮ menu → Refresh tools list. The full tool list (including start_an_actions_run) reappears immediately, both in the settings page and for the model.
• Other clients: remove the connector and add it back once, which forces a fresh tools/list fetch.

You can verify what the server actually exposes at any time: every tool Enginy serves is listed in the generated API reference, and mcp_get_usage_guide (topic actions) documents the enrichment/verification actions workflow.

​

I authorized successfully, but the client keeps asking me to reconnect and won’t run tools

This is the most common “looks like a permissions problem but isn’t” report. The symptom: the client writes the tool call, you click connect, approve every scope, see “connected and authorized” — then back in the client it still won’t run the tool and shows connect again, in a loop. In almost every case Enginy authorized you correctly and the client is re-running the whole login flow instead of reusing the token it just received. Repeatedly disconnecting/reconnecting or re-granting permissions keeps the loop alive, because each cycle registers a brand-new client. Fix it by fully removing the connector, re-adding it once, and confirming the session with mcp_whoami before doing anything else — without re-clicking connect in a loop. Full steps are in Security & Troubleshooting.

​

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 document http://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 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

Treat it as expected behavior when:

• 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