McpServer is the server instance a Skybridge app hands to its handler, once per request. Its registration methods return the server itself, so you chain them and return the chain: that return value is what carries your tool types into typeof app.
Example
The handler registers two tools and a middleware, and returns the chain.src/server.ts
oauth verifier produces into extra.http.authInfo.extra, and the tool registry into typeof app. Splitting the tool definitions across files is still easy, since each registerTool callback is an ordinary function you can import.
Methods
Every method returns the server, so calls chain.registerTool
registerResource, registerPrompt
Inherited from the MCP SDK’s McpServer, with the same signatures. Views register their own resources, so you only need registerResource for data you expose directly.
mcpMiddleware
(request, extra, next), can inspect or short-circuit the call, and invokes next() to continue. Middleware runs in registration order, outermost first. An optional filter scopes which methods it runs for.
getToolError
isError tool result, so await next() resolves normally and the middleware never sees the failure. getToolError returns the error the tool handler threw during the current request, with its stack and cause intact. It lives on extra, which is never serialized to the client.
useOnError never runs for it: report tool errors from mcpMiddleware, and keep useOnError for transport-level failures. Errors raised by the SDK itself (unknown tool, input or output schema validation) never reach your handler and are not reported here.
Skybridge
Configure and run the app that builds this server
registerTool
Define the tools and views the server exposes
generateHelpers
Turn
AppType into typed client hooks