The MCP gateway

The gateway is the one address every assistant in your organisation points at. It is the place identity is established, policy is enforced, secrets are removed and the audit record is written. There is no second door: a connector is not reachable except through it.

One endpoint, every assistant

You register a single URL. Claude, ChatGPT, Copilot, Cursor and anything else built on the open MCP specification all use the same one. Adding a connector later does not mean touching client configuration, because the endpoint has not changed.

MCP server URLhttps://mcp.msharti.dev/mcp
ProtocolModel Context Protocol, revision 2025-03-26
TransportStreamable HTTP
Session headerMcp-Session-Id
AuthOAuth 2.1 with PKCE (S256), or a static bearer key
ℹ️

Streamable HTTP, not SSE. The gateway was upgraded from Server-Sent Events to the Streamable HTTP transport in the 2025-03-26 revision of the spec. Clients pinned to the older SSE transport should be updated; every assistant documented in Connect your AI already speaks the current one.

How the gateway establishes who is asking

There are two ways a request proves its identity, and the difference matters for governance.

OAuth 2.1, the default

The assistant discovers the authorisation flow itself from the server's /.well-known/ metadata, redirects the person to Msharti, and they sign in as themselves. Nothing is pasted anywhere. The resulting tool calls run as that person, which is what makes role-based access and the audit trail meaningful: the log records a human, not a shared robot account.

Discovery document/.well-known/oauth-authorization-server
Authorization endpointhttps://mcp.msharti.dev/oauth/authorize
Token endpointhttps://mcp.msharti.dev/oauth/token
Registration endpointhttps://mcp.msharti.dev/oauth/register
PKCE methodS256

Static bearer key, the fallback

Some clients cannot run an interactive OAuth flow, and some corporate DLP policies block it. Those use an API key generated in the console, sent as a normal bearer token. The key carries a role, so it is still scoped, still logged and still revocable, but it identifies a machine rather than a person.

request header 
Authorization: Bearer msh_cop_xxxxxxxxxxxxxxxx

Key formats and rotation are covered in tenants and API keys.

What happens inside a call

Six stages, in fixed order, on every request. There is no trusted-client fast path.

1
Authenticate

The bearer token or OAuth access token is validated. Expired, revoked and malformed credentials are rejected here, before the tenant is even resolved.

2
Resolve tenant

Each credential belongs to exactly one tenant. The gateway loads that tenant's connector configuration, its encrypted credentials and its role definitions. One tenant's credential can never address another tenant's data.

3
Authorise the tool

The role attached to the credential carries a tool allowlist. If the requested tool is not on it, the call stops here and is logged as denied. The assistant cannot talk its way past this: the check is on the name of the tool, not on the wording of the prompt.

4
Scan for prompt injection

The payload is inspected for injection patterns. The threat here is not a hostile user, it is content already sitting in your own systems: an email body or a CRM note written to hijack an assistant that reads it. Flagged requests are blocked and recorded.

5
Route to the connector

The call is forwarded to the connector server for that system, one isolated container per connector. The container decrypts the credential for that system only, calls the real API, and returns the result. A compromised connector cannot read another connector's credentials.

6
Strip secrets, write audit, return

API keys, passwords and sensitive identifiers are redacted from the response before the assistant ever sees them. The call is written to an immutable audit record. The clean response is returned.

Dynamic tool discovery

The gateway asks each connector server what tools it offers, at startup and periodically after that. Two consequences follow, and both are the point:

  • When Msharti adds a connector or extends an existing one, the new tools appear in your assistant on their own. No configuration change, no redeploy, no re-registering the endpoint.
  • The tool list an assistant can see is the tool list after your role filter has been applied. A viewer does not see write tools greyed out. They do not see them at all.

Read-only enforcement for databases

SQL connectors (PostgreSQL, MySQL and MSSQL) are read-only, and the enforcement lives at the gateway rather than only at the database user. Even if a prompt were manipulated into producing an INSERT, UPDATE or DELETE, the statement is rejected before it reaches the connector.

Permitted statementsSELECT only
Row limit500 per query
Query timeout30 seconds
⚠️

Read-only is a database guarantee, not a platform-wide one. Other connectors genuinely write. M-Pesa can initiate a B2C payment and remit tax. Outlook and Gmail can send mail. CRM connectors can create records. That is deliberate, and it is exactly why roles exist. Decide which write tools belong in which role before you invite anyone.

Rate limiting

Every tenant has a daily call quota set by its plan, enforced at the gateway. It protects your backend systems as much as ours: an assistant in a retry loop cannot turn into thousands of calls against your production database. Exact quotas per tier are in limits and plans.