A gateway can present tools from selected servers on the same installation through one MCP endpoint. It is useful when one authorised audience needs several services. It is not a reason to combine unrelated customers' access.
Choose the audience and publication scope#
Open the gateway configuration on the intended installation. Prefer an explicit selection of servers for the agreed audience. Check the published tool preview before connecting a client, and review it again whenever server membership changes.
Keep owner-private integrations and unrelated customer servers out of a customer gateway. A gateway aggregates tool exposure; it is not proof of separate tenant permissions for every administrator or client.
Configure gateway authentication#
The gateway has its own client-authentication configuration. Do not assume a credential issued for one individual server is valid at the gateway. Follow the exact endpoint and authentication method supplied in the handoff.
First-party OAuth at the installation and OAuth used to reach an upstream service are different configurations. Verify the actual gateway consent flow with the intended AI client before calling it accepted.
Recognise published tool names#
Published names can be prefixed with their originating server slug to avoid collisions. Check the final tool list rather than assuming that a tool will have the same name as it has on its individual server endpoint.
Verify the boundary#
Confirm expected discovery and a bounded operation from each included service. Also check that excluded private services are not discoverable or callable with that client's credential. Preserve the previous selected list so that a publication change can be reversed.
Direct connections still matter#
Individual server connections can remain useful for narrow scopes or separate environments. Use the assigned route. The platform gateway does not automatically broker arbitrary external MCP servers or copy their OAuth authorisations.