Back to the workshopCase file / 03 of 05
Engineering storyIndependent project · Open-source developer tooling

Toolgrain

Typed tools. Composable servers.

A TypeScript toolkit for building MCP servers from reusable tools. Zod validation, request-scoped context, and stdio or HTTP transports, with optional JWT and Clerk authentication.

TypeScriptMCPZodMIT open source
01 / At a glanceTypeScript + ZodTyped handlers and runtime validation
02 / At a glancestdio + HTTPTransport and handler adapters
03 / At a glanceMITPublic source and npm packages
01 / The challenge

One tool definition. More ways to serve.

A reusable tool should not be tied to one server or transport. Tool authors also need a clear contract for validation, dependencies and authentication without rewriting those concerns for every handler.

What I owned

I created and maintain Toolgrain: a TypeScript toolkit with reusable tool definitions, composable servers, context providers, transport adapters and optional authentication packages. The public repository includes documentation and runnable framework examples.

Interactive system explorer

From a definition to a callable tool

Conceptual map of the public toolkit. Select a step to explore the responsibilities; no remote tool is executed here.

  1. 01Define
  2. 02Compose
  3. 03Serve
  4. 04Execute
Step / 01

Define

Declare a reusable tool with a name, Zod schemas and a typed handler.

Step / 02

Compose

Combine tools with createServer() and attach the context providers and optional authentication needed by that server.

Step / 03

Serve

Expose tool discovery and execution through stdio, a managed Node HTTP listener, or Web and Node handlers.

Step / 04

Execute

Parse inputs, resolve request-cached context, run the handler and validate declared outputs.

02 / Engineering decisions

The choices
behind the work

01

Keep the tool definition independent

What I built

A standalone tool() combines Zod schemas with a typed handler. createServer() composes those definitions into a server, with input and declared output parsing that honors schema defaults and transforms.

Why it matters

The same tool can be reused in different server compositions. Type inference supports authoring, while runtime validation checks the values crossing the tool boundary.

02

Give dependencies a request lifetime

What I built

Lazy, typed context providers resolve dependencies on demand and cache them for the request.

Why it matters

Handlers can share request-scoped services and context without wiring the same dependency into each tool invocation by hand.

03

Separate serving and authentication from tool logic

What I built

The packages provide stdio serving, a managed Node HTTP listener, Web and Node handlers, and optional JWT and Clerk authentication. Framework examples cover Express, Hono, Elysia and Next.js.

Why it matters

Tool definitions stay reusable as the hosting environment changes. Authentication can be added at the server boundary rather than repeated inside each handler.

03 / Evidence & results

Reusable, validated tools that compose into MCP servers over stdio or HTTP.

The context matters

Toolgrain is public under MIT, with published @toolgrain packages, documentation and runnable examples. The current protocol scope is tool discovery and execution over stdio and independent HTTP JSON POST requests. Sessions, SSE, resources and prompts are outside the current scope. No adoption or performance figures are claimed.

View package on npm ↗View source on GitHub (MIT) ↗Read the documentation ↗
There’s more in the workshopUp next / 04
InvestSky

A better feel for finance.