Skip to main content
Engini exposes your toolsets as Model Context Protocol servers, so MCP clients (Claude, ChatGPT, and any spec-compliant client) can discover and call your Engini tools directly.

The connection URL

Every MCP server you create in Engini has a server token. Point your MCP client at:
The server exposes exactly the tools and connections its toolset permits - the same scoping model as toolsets.

Install in your client

On first use the client opens a browser for the Engini sign-in and consent - no keys to copy. Tokens refresh automatically.

For the agent reading this

Machine-usable facts, no prose required:

Authentication

Engini MCP implements the MCP spec’s OAuth 2.1 authorization:
  1. The client hits the server and receives 401 with a WWW-Authenticate header pointing at https://mcp.engini.io/.well-known/oauth-protected-resource.
  2. That metadata names the authorization server (https://identity.engini.io), whose own discovery document describes the full flow.
  3. The client runs the standard authorize → consent → token flow (PKCE), and retries with Authorization: Bearer <token>.
Spec-compliant clients do all of this automatically - the user just signs in to Engini and approves the connection when the browser opens.
MCP client apps need a registered OAuth client on the Engini side (registration is currently manual - see OAuth apps). The relevant scope is mcp:tools.

What the agent gets

  • tools/list - the toolset’s tools with their JSON Schemas
  • tools/call - execution through the toolset’s bound connections, with the same semantics as the REST execute endpoint (including the isSuccess contract)
The MCP surface, REST API, SDKs, and CLI are all views over the same tools - pick per client, mix freely.