Claude
Most teams — especially non-technical roles like SDRs — will use Enginy from Claude itself (claude.ai on the
web, desktop, Team, or Enterprise), not from a terminal. This is the recommended starting point.
Before you start
An Enginy admin just needs to enable the MCP integration for the workspace — that’s it to get started. Enginy
grants full access by default and already allowlists the standard redirect URI for Claude.
Restricting policy scopes, pinning trusted client IDs, or customizing allowed redirect URIs are optional,
advanced steps for later — not something you need to set up before the first connection. If you do want to
manage redirect URIs yourself, Claude’s callback is https://claude.ai/api/mcp/auth_callback (Anthropic has
indicated this may migrate to https://claude.com/api/mcp/auth_callback — allowlist both to stay covered
through that change).
Add the connector
- Pro or Max plan: go to Customize → Connectors, click +, choose Add custom connector, paste
https://openapi.enginy.ai/mcp, and click Add.
- Team or Enterprise plan: an Owner must add it first, via Organization Settings → Connectors → Add
→ Custom → Web. Individual members then connect from their own account — a non-admin user won’t see the
option to add a connector themselves.
Turn it on for a conversation
Adding the connector doesn’t turn it on everywhere. In any chat, click the + button (bottom-left of the
message box), select Connectors, and toggle Enginy on for that conversation.
Complete the browser flow
When you approve the connection, Claude validates the same things any Enginy connection does:
- the
redirect_uri against your workspace allowlist
- the requested scopes against your MCP policy ceiling
- the optional
client_id allowlist, if your workspace uses one
Verify the connection
Ask Claude to use the Enginy connector and run:
That confirms the hosted MCP server is reachable, OAuth completed, and the granted scopes match what Enginy approved.
Claude Code
Prefer the terminal? Claude Code is Anthropic’s CLI, and connects to the same hosted Enginy MCP server.
Before you start
Nothing to configure — Enginy already allowlists the standard fixed-port callback Claude Code uses by
default:
A fixed port lets Enginy allowlist one stable redirect URI instead of a random one. If your workspace has
customized the allowed redirect URIs, just make sure this one is still on the list.
Add the hosted server
Run:
Then start Claude Code and open the MCP manager:
Select enginy and start authentication.
Complete the browser flow
Approve the request and return to Claude Code after the browser lands on:
That callback page is usually served by Claude Code’s local receiver, not by Enginy. Seeing a success screen there usually means the code exchange completed.
Verify the connection
After authorization, ask Claude Code to use Enginy MCP and run:
That verifies:
- the hosted MCP server is reachable
- OAuth completed successfully
- Claude Code is sending the correct bearer token
- the granted scopes match what Enginy approved
Advanced: local development
You can ignore this section unless your team is testing a local Enginy environment.
If you are running the local OpenAPI service, the MCP URL defaults to:
A local setup typically needs:
- the OpenAPI service running
- the API OAuth routes running
- an Enginy frontend you can sign into for the browser approval step
- the same callback URI allowlisted in the workspace settings
Example local registration command:
Common Claude Code issues
redirect_uri is not allowed
The callback URI in Claude Code must exactly match one of the workspace allowed redirect URIs. With --callback-port 3118, that means:
OAuth client_id is not allowed
Your workspace is pinning trusted client IDs and Claude Code’s client ID is not on the allowlist. Either add that exact client ID or temporarily remove the allowlist while you establish the first connection.
Requested scopes are not allowed
Claude Code requested a scope set outside the workspace policy ceiling. Reduce the requested scope set or expand the policy in Enginy.
needs authentication or Cannot POST /token
This usually means the client tried a shorthand token path. Enginy supports both the canonical token endpoint and common compatibility aliases, so if you still see this error, you are usually hitting a stale server, a proxy, or the wrong base URL.
No active connection appears in Enginy
Check that:
- MCP is enabled for the workspace
- the policy is active and has at least one scope
- the OAuth flow completed all the way through the browser callback
- the token exchange did not fail after the consent screen
