# Why Toolgrain keeps MCP tools separate from servers

> Source: <https://dev.to/keshav_katwe/why-toolgrain-keeps-mcp-tools-separate-from-servers-2o39>
> Published: 2026-10-27 07:32:10+00:00

I started Toolgrain while building Pushwing and experimenting with Elysia for an MCP integration.

I wanted a TypeScript workflow where I could define a tool independently, get useful types from its input and output schemas, and reuse that definition across servers.

The approach I was using wasn’t giving me that combination, and the documentation I found didn’t give me a clear path to the structure I wanted. I thought a toolkit built around those needs could be useful.

The central design decision in Toolgrain is to make a tool a standalone definition. It bundles its description, Zod schemas, and handler. A server registers those definitions under the names exposed to MCP clients, and a transport handles how requests arrive.

Here’s a small inventory example using the published packages. It runs on Node.js 24.20.0 or later within 24.x, with TypeScript strict mode.

In a new directory:

```
npm init -y
npm install @toolgrain/mcp@0.1.2 @toolgrain/node@0.1.2 zod@^4.6.6
npm install --save-dev typescript @types/node@^24.10.0
```

Save this as `server.mts`:

``` js
import { createServer, tool } from "@toolgrain/mcp";
import { stdio } from "@toolgrain/node";
import { z } from "zod";

const inventory = { notebook: 12, pencil: 48 };

const getStock = tool({
  description: "Look up the stock available for a product",
  annotations: { readOnlyHint: true },
  input: z.object({ sku: z.enum(["notebook", "pencil"]) }),
  output: z.object({
    sku: z.string(),
    quantity: z.number().int().nonnegative(),
  }),
  execute: ({ sku }) => ({ sku, quantity: inventory[sku] }),
});

const server = createServer({
  name: "inventory-demo",
  version: "1.0.0",
  tools: { get_stock: getStock },
});

await server.listen(stdio());
```

Compile it:

```
npx tsc server.mts --strict --module NodeNext --target ES2022 --types node
```

Then call the tool with MCP Inspector’s CLI:

```
npx --yes @modelcontextprotocol/inspector@2.11.0 --cli \
  --protocol-era modern --format json \
  --method tools/call --tool-name get_stock \
  --tool-args-json '{"sku":"pencil"}' \
  node server.mjs
```

Inspector starts the server, calls the tool, and exits. The response’s `result.structuredContent` contains:

```
{ "sku": "pencil", "quantity": 48 }
```

A few details explain the separation:

`getStock` is the TypeScript value; `get_stock` is the registered name that MCP clients discover and call.`sku` type. Server execution validates both input and the declared output.`execute()` calls are raw handler calls. They bypass server validation.
In an application, the handler can call an existing service instead of reading the in-memory inventory. Toolgrain also has context providers for application dependencies.

The current implementation focuses on tool discovery and execution over stdio and independent HTTP POST requests with JSON responses. Sessions, SSE, resources, and prompts are outside its current scope.

The separation between tool definitions, server execution, and transports came directly from the workflow I wanted while building Pushwing.

The [Toolgrain source](https://github.com/keshavkatwe/toolgrain) is MIT-licensed. Its [tool authoring guide](https://toolgrain.mintlify.site/tools/overview) documents the validation and execution behavior in more detail.

How do you organize tool definitions when the same application operation needs to be exposed through more than one MCP server?

*This article was drafted with AI assistance from my description of the project. The example was verified against Toolgrain 0.1.2.*