
from obsidian-mcp-server541
Deploy an MCP server to Cloudflare Workers using createWorkerHandler; covers bindings, runtime compatibility guards, and wrangler.toml requirements.
This skill documents how to deploy an MCP-style server into Cloudflare Workers using the package @cyanheads/mcp-ts-core/worker and its exported helper createWorkerHandler. It explains the per-request McpServer factory pattern, how to register tools/resources/prompts, and how to safely map environment and object bindings into the Worker runtime. Concrete guidance covers lazy env parsing, handling object bindings on globalThis, runtime capability checks (isWorkerLike, isNode), and recommended wrangler.toml settings. The material is aimed at developers who want to run an MCP server in Cloudflare's constrained environment and need practical patterns to avoid common runtime and configuration pitfalls.
Use this skill when you are packaging an MCP server for deployment to Cloudflare Workers — for example, when you need a compact, edge-deployed API that registers tools, prompts, and resources per request. It's appropriate when you must support Cloudflare-specific bindings (KV, R2, D1) or when you want safe fallbacks for node-only utilities. If your project requires persistent storage beyond in-memory, follow the storage whitelist guidance in this skill.
Best for TypeScript/Node-oriented agents and human developers: Copilot/Code assistants, Codex-like tooling, and manual deploy workflows.
A well-structured reference skill for deploying MCP servers to Cloudflare Workers using createWorkerHandler from @cyanheads/mcp-ts-core. Covers binding types, runtime compatibility, wrangler.toml config, and Workers-specific gotchas like lazy env parsing and volatile in-memory storage. No scripts included — pure documentation/reference. Clear, detailed, and technically accurate but serves a narrow audience of developers already using the cyanheads MCP framework.
Pure reference/documentation skill with no executable code. Security is strong — no credentials, no network calls, no destructive commands, no exfiltration risks. Only minor deduction for referencing process.env patterns that could be misused if not lazily parsed. Code quality is good — clear structure, comprehensive coverage, well-organized tables. Architecture follows skill spec well with proper frontmatter and progressive disclosure. Usefulness is moderate: valuable for cyanheads framework users but niche overall.