MCP Server

Most file and storage access work still happens through a UI a human drives. MCP MCP server moves it into the conversation instead. A production-grade TypeScript template for scalable MCP servers with built-in observability.

The short version

@cyanheads/mcp-ts-core is the infrastructure layer for TypeScript MCP servers. Install it as a dependency — don't fork it. Your agent collaborates with you to design and build the tools, resources, and prompts for your server.

• Declarative definitions — — tool(), resource(), prompt() builders with Zod schemas; appTool()/appResource() add interactive HTML UIs
• Server-level orientation — — instructions on createApp/createWorkerHandler rides every initialize for the model. Cross-tool composition hints, regional notes, scope guidance — without leaking text into every tool description
• Server identity — — optional title, websiteUrl, description, icons (SEP-973) on createApp/createWorkerHandler flow to initialize serverInfo, the /.well-known/mcp.json server card, and the landing page
• Unified Context — — one ctx for logging, tenant-scoped storage, elicitation, cancellation, and task progress
• Auth — — auth: ['scope'] on definitions, checked before dispatch (no wrapper code). Modes: none, jwt, or oauth (local secret or JWKS)
• Task tools — — task: true for long-running ops; framework manages create/poll/progress/complete/cancel

The tools it exposes

The server publishes 2 tools. What each one is for:

• Builders — The Builders tool exposed by this server
• Context — The Context tool exposed by this server

What it needs from you

Configuration is passed through the environment: MCP_HTTP_HOST, MCP_AUTH_SECRET_KEY, OPENROUTER_API_KEY. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.

Getting it running

Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client.

How it compares

Plenty of file and storage access servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. MCP's toolset — Builders, Context — is a fair guide to whether it matches your workflow. It is maintained by cyanheads; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.

Things to watch

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• Keep per-call confirmation enabled while you learn its behaviour; it is the cheapest safeguard you have.