Integrations

Native to the framework you already use.

Adapters are one transport each. Integrations compose them with the conventions of a host framework - decorators, dependency injection, file-based routing - so Silkweave feels native rather than bolted on.

Four ways to integrate

Whatever your stack, Silkweave meets it - reflecting an existing app into MCP, or projecting one action set onto a framework's routes.

NestJS - reflect controllers into MCP tools

The NestJS integration is additive controller reflection. Add @Mcp() to a route a controller already has, and it becomes an MCP tool - nothing is re-declared. The tool's name, description, and input schema are reflected from metadata the method already carries: the route and @Param / @Query / @Body decorators, plus @nestjs/swagger and class-validator annotations (and an optional OpenAPI document). 

@Controller('users')
export class UsersController {
  @Get(':id')
  @Mcp({ description: 'Fetch a user by id' })
  findOne(@Param('id') id: string) {
    return this.users.find(id)
  }
}
🔐

On a tool call, guards run first and a header-reading @UseGuards() sees the inbound tool-call headers - so the same auth that protects your REST route protects it over MCP. Your controllers keep serving HTTP unchanged.

Next.js - one action set, MCP and tRPC

The Next.js integration goes the other way: action-first projection. Define your actions once and project them onto App Router route handlers. defineSilkweave({ actions }) returns app.mcp() (MCP tools for agents) and app.trpc() (a typed tRPC endpoint for your frontend) - a single source of truth serving both audiences. 

// app/api/mcp/[[...slug]]/route.ts
export const { GET, POST, DELETE, OPTIONS } = app.mcp()

// app/api/trpc/[trpc]/route.ts
export const { GET, POST, OPTIONS } = app.trpc()

typeof app.Router carries the fully typed AppRouter for createTRPCClient, so your frontend gets end-to-end types with no manual plumbing. It is App Router only and has no next or react dependency - the handlers are Web-Standard Request / Response.

Standalone - compose it yourself

You do not need a host framework. Compose the fluent builder directly, pick whichever adapters fit, and run it as a Node process, a container, or a serverless function. Chain unlimited adapters, gate actions per transport with isEnabled, and drop into Astro, Vercel, or Cloudflare Workers via the fetch handlers. See standalone usage.

Vercel AI SDK - useChat over tRPC

@silkweave/ai bridges the Vercel AI SDK's useChat to a Silkweave streaming action over a tRPC subscription, skipping the Data Stream Protocol entirely. createChatAction() wraps streamText into a streaming action; silkweaveTransport() adapts the subscription into the ReadableStream that useChat consumes - typed chunks, no /api/chat route.

Keep exploring