TypeMCP - Declaring MCP Servers With Classes and Decorators

I was writing the same code for the third time

After a few MCP servers, the work was identical each time. Write the tool name and description, write the input schema again in zod, register the handler, then eyeball whether the types match the schema. Past about ten tools those three drift apart. The schema gets fixed and one of the types doesn't, and you find out at runtime.

TypeMCP puts the declaration next to the class.

@McpServer({ name: "weather", version: "1.0.0" })
class WeatherServer {
  @Tool({ description: "Get the current weather for a city" })
  getWeather(@Input(z.string()) city: string) {
    return fetchWeather(city);
  }
}

With the declaration in one place, there are fewer seams for the schema and the types to split along.

The boundary is explicit

Once a library takes over application policy, removing it later is painful. What TypeMCP does is record declarations, validate them, and compile them into the shape the MCP SDK expects.

Everything after that belongs to the consumer: where to host, who to authorize, how to set retries and timeouts, what to log. Having the library handle authorization looks convenient right up until that decision is pinned to a library version.

getMcpServerDefinition() exists for the same reason. You should be able to inspect what a server exposes without starting it.

Added in 0.4.0

• MCP SDK v2 protocol serving
• Structured outputs (outputSchema)
• Prompt arguments, resource templates and completion
• Invocation context and protocol-backed testing
• Component visibility control

stdio, Streamable HTTP, the LangChain adapter and the legacy-decorator entrypoint stay behind separate boundaries. Take only what you host.

Using it

Node.js 20 or later, with standard (Stage 3) decorators.

npm install @theorvane/type-mcp zod

Agents using this package sometimes assume APIs exist that don't, so the docs include a separate guide that pushes them to check the evidence first.

• npm
• Docs
• GitHub