Open-source TypeScript toolkit for MCP servers

Define once.
Deploy everywhere.

Build MCP servers, REST APIs, and CLI tools from a single set of actions. No framework lock-in. No boilerplate. Just composition.

Get Started Read the Docs GitHub

pnpm add @silkweave/core

The Problem

Agents need services. Services need many doors.

The agentic landscape demands that services be reachable via MCP, REST, CLI, and more. Building each transport from scratch is unsustainable.

Fragmented Transports

MCP stdio, HTTP, REST, CLI - each requires a different server setup, different libraries, different patterns.

Boilerplate Overload

Every new endpoint means repeating validation, error handling, and serialization. Your business logic drowns in glue code.

Framework Lock-in

Pick Express? Now you're stuck. Pick Fastify? Same story. Your actions are trapped inside your transport choice.

Quick Start

Up and running in 3 steps.

Install

terminal

pnpm add @silkweave/core @silkweave/mcp zod

Define an action

actions/greet.ts

import { createAction } from '@silkweave/core'
import z from 'zod'

export const GreetAction = createAction({
  name: 'greet',
  description: 'Greet a user by name',
  input: z.object({
    name: z.string().describe('Name to greet')
  }),
  run: async ({ name }) => {
    return { message: `Hello, ${name}!` }
  }
})

Pick an adapter and start

server.ts

import { silkweave } from '@silkweave/core'
import { stdio } from '@silkweave/mcp'
import { GreetAction } from './actions/greet.js'

await silkweave({ name: 'my-server', version: '1.0.0' })
  .adapter(stdio())
  .action(GreetAction)
  .start()

Read the full documentation →

How It Works

One action. Every transport.

Define your business logic once as an Action. Pick an Adapter. Silkweave wires them together.

Action

Zod schema + async handler

→

Adapter

stdio, HTTP, REST, CLI, Vercel

→

Silkweave

Fluent builder wires it up

actions/greet.ts

import { createAction } from '@silkweave/core'
import z from 'zod'

export const GreetAction = createAction({
  name: 'greet',
  description: 'Greet a user by name',
  input: z.object({
    name: z.string().describe('Name of the person to greet')
  }),
  run: async ({ name }) => {
    return { message: `Hello, ${name}!` }
  }
})

Dive deeper into the action model →

Adapters

Same action. Seven adapters.

Swap one line to change how your action is served. The business logic stays identical.

@silkweave/mcp

import { silkweave } from '@silkweave/core'
import { stdio } from '@silkweave/mcp'
import { GreetAction } from './actions/greet.js'

await silkweave({ name: 'my-server', version: '1.0.0' })
  .adapter(stdio())
  .action(GreetAction)
  .start()

@silkweave/mcp

import { silkweave } from '@silkweave/core'
import { http } from '@silkweave/mcp'
import { GreetAction } from './actions/greet.js'

await silkweave({ name: 'my-server', version: '1.0.0' })
  .adapter(http({ port: 8080 }))
  .action(GreetAction)
  .start()

@silkweave/fastify

import { silkweave } from '@silkweave/core'
import { fastify } from '@silkweave/fastify'
import { GreetAction } from './actions/greet.js'

await silkweave({ name: 'my-server', version: '1.0.0' })
  .adapter(fastify({ port: 8080 }))
  .action(GreetAction)
  .start()

@silkweave/trpc

import { silkweave } from '@silkweave/core'
import { trpc, type InferTrpcRouter } from '@silkweave/trpc'
import { GreetAction } from './actions/greet.js'

const server = silkweave({ name: 'my-api', version: '1.0.0' })
  .adapter(trpc({ port: 8080 }))
  .action(GreetAction)

export type AppRouter = InferTrpcRouter<typeof server>

await server.start()

@silkweave/cli

import { silkweave } from '@silkweave/core'
import { cli } from '@silkweave/cli'
import { GreetAction } from './actions/greet.js'

await silkweave({ name: 'my-tool', version: '1.0.0' })
  .adapter(cli())
  .action(GreetAction)
  .start()

@silkweave/edge

import { silkweave } from '@silkweave/core'
import { edge } from '@silkweave/edge'
import { GreetAction } from './actions/greet.js'

const { adapter, handler } = edge()
await silkweave({ name: 'my-server', version: '1.0.0' })
  .adapter(adapter)
  .action(GreetAction)
  .start()

export default { fetch: handler }

@silkweave/typegen

import { silkweave } from '@silkweave/core'
import { typegen } from '@silkweave/typegen'
import { GreetAction } from './actions/greet.js'

await silkweave({ name: 'my-server', version: '1.0.0' })
  .adapter(typegen({ path: 'types/actions.d.ts' }))
  .action(GreetAction)
  .start()
// Generates: export interface GreetInput { name: string }

Compare all the adapters →

Integrations

Drop into your framework of choice.

Adapters are one transport each. Integrations compose them with the conventions of a host framework - decorators, DI, file-based routing - so Silkweave feels native.

Standalone

Stable

Compose the fluent builder yourself. Pick whichever adapters fit; run it as a Node process, container, or serverless function.

Chain unlimited adapters; one action served everywhere
Per-action isEnabled filtering across transports
Drop into Astro / Vercel / Workers via fetch handlers

Read the docs →

NestJS

Stable

Expose your existing NestJS controllers as MCP tools by adding one @Mcp() decorator. Tool input is reflected from the route + @Param/@Query/@Body + swagger/class-validator metadata. Additive - controllers serve HTTP unchanged.

@Mcp() on existing controller routes, DiscoveryService-driven
Input schema reflected from params + swagger/class-validator (+ optional OpenAPI doc)
@UseGuards() fires over MCP, reading inbound tool-call headers

Read the docs →

Next.js

Beta

App Router adapter. defineSilkweave({ actions }) projects one action set onto route handlers - MCP tools for agents and a typed tRPC endpoint for your frontend - from a single source of truth. Additive, App Router only.