Skip to main content
Reintersect doesn’t ship its own MCP server framework. Build the server with any library that produces a fetch-style handler, then either mount it on your app with .addMcp, or run it on its own and verify Reintersect’s tokens with verifyReintersectToken.

Mount a server with addMcp

src/mcp.ts
src/app.ts
addMcp(handler, { auth }): The app serves the handler at /mcp and every path under it, next to its delivery path and routes, so routes may not use /mcp. The handler receives the request with the path rewritten to start at /mcp. Calling addMcp twice is a type error. With auth: "reintersect", the SDK verifies the bearer token before calling your handler and passes the caller as extra.authInfo:
agentConversationId is set when the agent makes the call. With "oauth" and "none", your handler receives the request untouched and does its own checks. On the Effect entry, ReintersectApp.layer(app) mounts the MCP handler at /mcp on your HttpLayerRouter the same way. See Services and layers in the Effect guide.

Verify tokens in a standalone server

When your MCP server runs outside the app, for example in an existing Next.js API, verify Reintersect’s tokens with verifyReintersectToken from @reintersect/sdk/mcp:
app/mcp/route.ts
The returned function takes the request and, optionally, a bearer token you already extracted. It resolves to the ReintersectAuthInfo above, or undefined when the token is missing or invalid; the reason (such as Expired, AudienceMismatch or AppMismatch) is logged, never thrown. Keys come from https://api.reintersect.com/.well-known/reintersect/jwks.json and are cached, with a refetch when a token names a key the cache doesn’t have. ReintersectTokenInvalidError and the types McpHandler, McpFetchHandler, McpRequestExtra, ReintersectAuthInfo, ReintersectCaller and VerifyReintersectTokenOptions are exported from the same entry point.