MCP Server
Connect an AI agent to the Rekamedika SIMRS over the Model Context Protocol.
Rekamedika exposes its SIMRS tools to AI agents over the Model Context Protocol, at a single endpoint backed by the same tRPC API and authorization model as the dashboard:
mcp.rekamedika.com
The remote MCP worker (Streamable HTTP, Durable Object sessions). This is what MCP clients such as Claude should connect to.
Endpoints
| Endpoint | Purpose |
|---|---|
https://mcp.rekamedika.com/mcp | MCP Streamable HTTP endpoint |
https://mcp.rekamedika.com/authorize · /token · /register | OAuth server for MCP clients (dynamic registration, RFC 7591) |
https://mcp.rekamedika.com/.well-known/oauth-authorization-server | OAuth discovery (RFC 8414) |
Transport
The worker (mcp.rekamedika.com/mcp) requires the full Streamable-HTTP
handshake — initialize (returns an Mcp-Session-Id header) →
notifications/initialized → then tools/list / tools/call — and
responds with SSE (data: frames).
Per-tenant scoping
Every MCP session is bound to one operator in one tenant:
- The OAuth grant is created by a signed-in operator (passkey, magic link, or email OTP — see Authentication).
- The resulting token maps to that operator's user row on the server; the tenant is read from the user record — never from the request.
- Every tool call runs through the same
tenantProcedure+ RBAC gates as the dashboard: rows are filtered to the operator's tenant and mutations require the operator's real roles.
A token can therefore never read or write another tenant's data, regardless of what the agent asks for.
Tool visibility
tools/list only advertises what the grant can use: a tool is registered when
the token carries its scope (simrs:read / simrs:write) and the user
holds one of its roles (when the tool declares any). Enforcement always
happens on the API; hiding is a courtesy. See Tools for the
generated registry.
Is this page helpful?