Browser, MCP and SDK request paths
The browser, MCP client and Python SDK reach the same fixed operation authority through different transport and authentication paths. The following paths are for the packaged HTTPS deployment.
| Entry | Internal path | Authority |
|---|---|---|
| Browser on the application host | Proxy → browser gateway → web API on 5195. /api/platform/browser/ has higher routing priority and the gateway forwards it to /browser/ on platform port 5193. | Same-origin web requests use the opaque __Host-openepm_session cookie. The gateway uses its server-side session and supplies the upstream access token. It discards a caller-supplied Authorization value on this path. |
| MCP client | The proxy strips /api/platform, /api/workspace or /api/application and forwards to platform 5193, the optional workspace listener 5192, or router 5194. | Send a bearer access token with the configured MCP audience. The exact listener catalog determines available tools and whether workspace and application IDs are required in the arguments. |
| Python SDK | The SDK uses the MCP transport and the published typed function contract. | Use the same endpoint and authorization scope as an MCP client. Function wrappers prepare typed requests for the fixed server to validate. |
Follow the scope through a request
Discover the exact endpoint, list its tools, resolve the stable IDs, then retrieve the typed catalog before constructing a program. The router checks the requested scope and the application service validates the operation and grant before reaching PostgreSQL. The MCP guide shows this sequence through HTTPS discovery, a read and a receipt-backed write. Use Endpoint scopes and Tools for individual contracts.