setup — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited setup (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill assumes bunx @cyanheads/mcp-ts-core init [name] has already run. The CLI created the project's CLAUDE.md and AGENTS.md for different agents, copied external skills to skills/, and scaffolded the directory structure with echo definitions as starting points. This skill covers what was created and what to do next.
The init CLI generates both CLAUDE.md and AGENTS.md with identical content — CLAUDE.md is read by Claude Code, AGENTS.md by Codex, Cursor, Windsurf, and other agents. Keep both. Shipping both keeps the project agent-agnostic, and they're cheap to hold in sync: edit one, then cp CLAUDE.md AGENTS.md (the framework keeps its own pair byte-identical the same way, enforced by check-docs-sync). Only delete one if you're certain the project will never be opened by the other family of agents.
For the full framework docs, read node_modules/@cyanheads/mcp-ts-core/CLAUDE.md (or its identical twin AGENTS.md) once per session. It contains the exports catalog, tool/resource/prompt contracts, error codes, context API, and common import patterns.
What init actually creates:
CLAUDE.md # Agent protocol — Claude Code
AGENTS.md # Agent protocol — other agents (Codex, Cursor, etc.)
package.json # Starter deps + scripts (placeholders substituted on init)
tsconfig.json # TypeScript config
tsconfig.build.json # Build-only TS config
vitest.config.ts # Test runner config
biome.json # Lint + format config
devcheck.config.json # Which devcheck steps to run
Dockerfile # Starter multi-stage image
.dockerignore
.env.example # Copy to .env and fill in
.gitignore
.github/ISSUE_TEMPLATE/ # Bug / feature-request issue forms
.vscode/ # Recommended extensions + editor settings
server.json # MCP Registry publishing metadata
changelog/template.md # Format reference for per-version changelog files
scripts/ # build, clean, devcheck, lint-mcp, list-skills, build-changelog, tree, check-docs-sync
skills/ # External skills copied from the package (source of truth)
src/
index.ts # createApp() entry point
mcp-server/
tools/definitions/
echo.tool.ts # Standard tool starter
echo-app.app-tool.ts # UI-enabled app tool starter (pairs with echo-app-ui resource)
resources/definitions/
echo.resource.ts # Standard resource starter
echo-app-ui.app-resource.ts # UI resource paired with echo-app app tool
prompts/definitions/
echo.prompt.ts # Prompt starter
tests/
tools/echo.tool.test.ts # Starter tests (one per echo definition)
resources/echo.resource.test.ts
prompts/echo.prompt.test.tsAdd these as needed:
src/
worker.ts # createWorkerHandler() — only for Cloudflare Workers
config/
server-config.ts # Server-specific env vars (own Zod schema)
services/
[domain]/
[domain]-service.ts # Init/accessor pattern
types.tsThe init creates five echo definitions plus matching starter tests:
| File | Demonstrates |
|---|---|
echo.tool.ts | Standard MCP tool: input/output Zod schemas, handler, format |
echo-app.app-tool.ts | MCP App tool — same as a tool, but emits a UI (ui_app:// link) for clients that render MCP Apps |
echo.resource.ts | Standard MCP resource with a parameterised URI template |
echo-app-ui.app-resource.ts | UI resource served to MCP App clients; paired with echo-app.app-tool.ts |
echo.prompt.ts | Prompt template (pure message generator) |
tests/**/echo.*.test.ts | Starter tests using createMockContext — edit alongside the definitions |
After init:
src/index.ts. Same for resources, or the app-tool pair if you're not targeting UI-capable clients.add-tool/add-resource/add-prompt skills introduce definitions/index.ts barrels per the framework convention.See the add-tool, add-app-tool, add-resource, add-prompt, add-service, and add-test skills for the scaffolding patterns when you start adding real definitions.
| Convention | Rule |
|---|---|
| File names | kebab-case |
| Tool/resource/prompt names | snake_case, prefixed with server name (e.g. tasks_fetch_list) |
| File suffixes | .tool.ts, .resource.ts, .prompt.ts, .app-tool.ts (UI-enabled), .app-resource.ts (paired UI resource) |
| Imports (framework) | @cyanheads/mcp-ts-core and subpaths |
| Imports (server code) | @/ path alias for src/ |
Copy all project skills into your agent's skill directory so they're available as context. skills/ is the source of truth.
*Don't edit `skills//SKILL.md or skills//references/.** These are external skill files synced from @cyanheads/mcp-ts-core — the maintenance skill overwrites them on package updates, so local edits get lost. Project-specific agent context belongs in CLAUDE.md / AGENTS.md`.
For Claude Code:
mkdir -p .claude/skills && cp -R skills/* .claude/skills/For other agents (Codex, Cursor, Windsurf, etc.) — copy to the equivalent directory (e.g., .codex/skills/, .cursor/skills/).
This step is the bootstrap — it creates the agent directory. From then on, use the maintenance skill to refresh it after package updates (Phase B). Maintenance only refreshes directories that already exist; it won't create a new agent directory on your behalf.
Complete these one-time setup tasks:
bun installbun update --latest. The scaffolded package.json pins minimum versions from when the framework was published; updating ensures you start with the latest compatible releases.chore: scaffold from @cyanheads/mcp-ts-coreinit runs without a [name] argument, the package name defaults to the cwd directory name. If that's not what you want as the published server name, update package.json, CLAUDE.md/AGENTS.md, and server.json to your actual server name.bun run devcheck. Fix any issues before starting real work.changelog/template.md ships as a format reference — never edit, rename, or move it. For each release, author a per-version file at changelog/<major.minor>.x/<version>.md (e.g. changelog/0.1.x/0.1.0.md) with YAML frontmatter (summary: + optional breaking: / security:) and grouped sections (Added / Changed / Fixed / Removed). Then regenerate the rollup with bun run changelog:build — CHANGELOG.md is an auto-generated navigation index, never hand-edited. See the release-and-publish skill for the full release flow.
The included skills form a rough progression — not a rigid sequence, but the typical flow through a new server:
bun update --latest, investigate upstream changelogs and re-sync skillsSkip or reorder as the project calls for it. The agent protocol's "What's Next?" section is the authoritative map once the first session is over.
CLAUDE.md and AGENTS.md present and in sync (or the unused one deliberately deleted)bun install runbun update --latest)chore: scaffold from @cyanheads/mcp-ts-core)package.json, agent protocol file, and server.jsonnode_modules/@cyanheads/mcp-ts-core/CLAUDE.md or AGENTS.md)src/index.ts)cp -R skills/* .claude/skills/ or equivalent)bun run devcheck passesdesign-mcp-server to plan the tool surface~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.