Cursor & custom MCP clients

Anything that speaks Model Context Protocol revision 2025-03-26 over Streamable HTTP can connect, including Cursor, in-house agents and your own scripts. OAuth is auto-discovered; for clients that only handle static tokens, a bearer key works.

Endpoints

MCP server URLhttps://mcp.msharti.dev/mcp
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
TransportStreamable HTTP
Session headerMcp-Session-Id

OAuth clients

Point the client at the server URL and let it read the discovery document. Dynamic client registration is supported at the registration endpoint, so there is no application to create by hand and no client secret to distribute. PKCE with S256 is required.

Static-token clients

Generate a key in the console under Settings → API Keys, choose Custom, and copy the msh_cus_… value. It is displayed once. Send it as a normal bearer token on every request.

mcp client configuration
{
  "mcpServers": {
    "msharti": {
      "transport": "http",
      "url": "https://mcp.msharti.dev/mcp",
      "headers": {
        "Authorization": "Bearer msh_cus_xxxxxxxxxxxxxxxx"
      }
    }
  }
}
⚠️

Treat the key like a production credential. It carries a role and can invoke every tool on that role's allowlist, including write tools if you granted them. Keep it out of source control, give each integration its own key, and rotate on the schedule in tenants and API keys.

Cursor

  1. Open MCP settings. Cursor exposes MCP servers in its settings panel under Model Context Protocol.
  2. Add an HTTP server. Use https://mcp.msharti.dev/mcp as the URL. Where Cursor supports OAuth, let it discover the flow; otherwise supply the bearer header above.
  3. Confirm tool discovery. Msharti's tools should appear in the tool list. If the list is empty, your role's allowlist is empty or no connectors are configured yet.

Building your own agent against the endpoint

This endpoint is also how in-house agents connect. The pattern is the same as for any assistant: give the agent its own API key, bind that key to a role whose allowlist contains exactly the tools the agent needs, and read the audit log by key prefix to see what it did. That whole process is written up in build an agent.

Behaviour worth knowing

BehaviourDetail
Tool list is filteredDiscovery returns tools the credential's role permits. An empty list usually means an empty allowlist, not a broken connection.
Tools appear without redeployingThe gateway re-discovers connector tools periodically. New tools reach your client on their own.
Databases are read-onlySQL connectors accept SELECT only, capped at 500 rows and a 30 second timeout, enforced at the gateway.
Rate limits are per tenantA retry loop in one agent consumes the shared daily quota. See limits and plans.
Responses are redactedKeys, passwords and sensitive identifiers are stripped before the response leaves the gateway.