{
  "id": 16722465,
  "title": "Why Toolgrain keeps MCP tools separate from servers",
  "url": "https://urgent.news/2026/10/27/why-toolgrain-keeps-mcp-tools-separate-from-servers",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-27T07:32:10.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/keshav_katwe/why-toolgrain-keeps-mcp-tools-separate-from-servers-2o39"
  },
  "original_language": "en",
  "account": "Toolgrain is a toolkit designed to separate tool definitions from server execution and transport mechanisms. This separation allows for greater flexibility and reuse of tool definitions across different MCP servers. The core idea is to define a tool as a standalone, self-contained entity that includes its description, Zod schemas, and handler function.\n\nA server registers these tool definitions under specific names, which are then discoverable by MCP clients. The transport layer is responsible for handling how requests are received, such as through stdio or HTTP POST requests.\n\nFor example, a TypeScript tool can be defined in a file like `server.mts`, where the tool's schema and behavior are specified using Zod for input validation and output structuring. The server is then created using the `createServer` function, specifying the tool names and their corresponding handler functions. The server can be started, listening for requests on stdin/stdout using a transport such as `stdio()`.\n\nWhen a tool is invoked via the MCP Inspector CLI, the tool's TypeScript definition is separate from the actual server implementation. The server acts merely as a mediator, validating the input against the tool's schema and returning the result according to the specified output schema. This separation enables the same tool to be used across multiple servers, each potentially using a different transport mechanism or server-side implementation.\n\nBy keeping tool definitions, server execution, and transport mechanisms separate, Toolgrain provides a modular and flexible approach to building MCP-based applications. This design enables developers to define reusable tool logic, register them under desired names, and manage how they are accessed and executed across various environments.",
  "summary": "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…",
  "key_points": [
    "Toolgrain separates tool definitions from server execution.",
    "Tools defined as standalone entities with schemas and handlers.",
    "Enables reuse across different MCP servers and transport mechanisms."
  ],
  "editors_take": "Decoupling tool definitions from execution and transport layers allows developers to build modular applications where logic remains reusable across different server implementations and communication protocols.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}