MCP Gateways
Connect MCP endpoints as governed Resources and expose only the capabilities an Agent needs.
An MCP Gateway is a governed connection from Constal to a remote MCP server. It is an ordinary Resource: the Resource pins the server endpoint, Credential bindings, egress boundary, reviewed tool schemas, effects, recovery behavior, and Policies used for every call.
MCP Gateways do not replace Tools or Credentials. The Gateway translates MCP tools into Resource operations, a Credential authenticates the connection, and an Agent package projects only the operations it needs as model-facing Tools. Credential rotation and scoped binding selection remain independent of Agent code.
Constal is not an MCP portal. It does not publish a second integration registry, proxy arbitrary public traffic, or let a remote server silently expand an Agent's authority. MCP uses the same Resource, Policy, Credential, invocation, ledger, and analytics paths as every other capability.
What the Console shows
Open Resources → MCP Gateways to inspect registered connections. Each row shows the Gateway identity, pinned capabilities, authentication relationship, current consumers, and status. Open a Gateway to review its exact CRN, operation catalog, Credential references, and Policy attachments.
Choose Add MCP Gateway, select the Remote MCP package, and enter the exact Streamable HTTP endpoint. Choose bearer, API-key-header, or no authentication. For authenticated modes, select a stored Credential; secret material is injected only inside an admitted invocation.
Constal connects to the server and runs MCP initialization followed by paginated tools/list. Review the result before installation:
- Deselect tools the Agent estate should never use.
- Mark reads as Reads only.
- Mark mutations the server explicitly declares idempotent as Repeatable change.
- Leave all other mutations as One-time change.
Installation pins this reviewed snapshot into the Resource revision. A later change in the remote server does not silently add, remove, or redefine an operation. Run discovery again and install a new revision when you intend to accept a changed catalog.
Bind capabilities, not transports
An Agent manifest binds the MCP Resource by stable CRN. Agent code then invokes an accepted capability or projects it as a Tool, exactly as it would for another Resource kind:
import { opTool } from "@constal/sdk";
export const findTickets = opTool("linear", "issues.search");The model never chooses the MCP endpoint URL, Credential, tenant, customer, or principal. Those are resolved by the accepted Resource binding and Policy. Use a scoped binding when different customers or principals should resolve different MCP Resources or Credentials.
At runtime the Gateway initializes an MCP session and calls only the remote tool pinned to the selected operation. Protocol errors, HTTP errors, and rate limits remain visible. The Gateway does not perform hidden retries. The Resource operation's reviewed effect and recovery declaration controls what the durable invocation engine may safely repeat after uncertain delivery.
Review checklist
- Select only the remote tools your Agents require.
- Keep schemas bounded and descriptions outcome-oriented.
- Verify every external mutation has accurate effect and recovery behavior.
- Store authentication in Credentials, never in the Agent package or Tool arguments.
- Keep the endpoint exact; setup compiles it into the Resource's egress boundary.
- Attach the narrowest practical Policy for
resource:invoke,tool:invoke, andcredential:use. - Pin the adapter and capability contract during Agent deployment.
Continue with Use Resources from Agents and Build and use Tools.