@savvy-web/mcp

The savvy-mcp Model Context Protocol server. It serves Silk Suite tooling to coding agents as structured tools, so an agent can read workspace facts and run Silk checks instead of parsing console output or guessing. It is a tools-only server — ten tools, no resources.

Install

npm install --save-dev @savvy-web/mcp
# or
pnpm add -D @savvy-web/mcp

The Silk Suite Claude Code plugins spawn this server for you, so you rarely install it directly. Installing @savvy-web/silk also brings it in.

Quick start

The server speaks MCP over stdio and is meant to be spawned by an MCP client. A client declares it like this:

{
  "mcpServers": {
    "savvy-mcp": {
      "command": "savvy-mcp",
      "args": ["."]
    }
  }
}

The single positional argument is the project directory; if omitted, the server resolves it from SAVVY_MCP_PROJECT_DIR, then CLAUDE_PROJECT_DIR, then the current working directory.

To exercise it by hand during development, run it through the MCP inspector:

npx @modelcontextprotocol/inspector savvy-mcp .
# opens the inspector UI against a live savvy-mcp instance

Tools

• workspace_info — returns a flat, structured projection of the workspace analysis: linked and fixed package groups as name arrays plus resolved registry targets. Backed by the same silk-effects analyzer the savvy CLI uses.
• turbo_inspect — read-only Turborepo inspection over turbo --dry: diagnose a task's per-package cache hits, derive the task graph or list the packages affected by recent changes. It never runs a task. Backed by the same silk-effects Turbo inspector an agent would otherwise drive by hand.
• changeset_inspect — read-only changeset analysis for release work: mode=branch diffs the current branch against its base and attributes every changed file to its owning package — an unmapped file carries a hint when a configured glob or a known template mirror explains it, and attribution works from a git worktree of the repository — mode=config surfaces the resolved .changeset/config.json with its release surfaces, version files and ignore list, and mode=classify reports how the branch's pending changesets classify each package's bump. It never writes a changeset. Backed by the same silk-effects changeset services the savvy CLI uses.
• changeset_validate — read-only validation of the files in a changeset directory against the section-aware rules, returning typed diagnostics (file, rule, line, column, message) plus an ok flag and error count. Use it instead of shelling out to savvy changeset lint.
• changeset_preview — read-only preview of the next release: it runs the genuine changesets engine over the pending changesets and returns each package's version bump (old to new) plus the rendered CHANGELOG block, exactly as it would ship. It never mutates the repo. Backed by the same silk-effects release planner the savvy changeset version command applies.
• changeset_deps_detect — read-only preview of the cumulative dependency diff (merge-base to working tree): one entry per affected workspace package with its resolved dependency-table rows — catalog: specifiers resolve per snapshot side to the range the catalog declares (e.g. ^0.7.0), while workspace: specifiers resolve to the exact workspace version — plus a coexisting bucket naming the prose-only changesets that already release an affected package (informational, never touched). It never writes a changeset. Backed by silk-effects' Changesets.DepsRegen.plan.
• changeset_deps_regen — regenerates pure-dependency changesets: deletes stale ones and writes fresh single-package, patch-bump changesets from the cumulative dependency diff. Mutating unless dryRun is set, in which case it reports what it would delete and write without touching the filesystem. Results carry the same coexisting bucket as changeset_deps_detect. Backed by silk-effects' Changesets.DepsRegen.
• biome_check — run Biome over a path and get structured diagnostics back: mode=check (lint, format and organize-imports) or mode=lint. Unlike most of the other tools it can mutate — pass write for safe fixes or unsafe for unsafe ones (both git-reversible) — so it returns the same diagnostics the Biome LSP surfaces for files you have edited.
• repos_inspect — read-only inspection of vendored repositories: mode=status reports per-repo presence, the gitlink as a staged/committed/checked-out triple, working-tree dirtiness, and stale note ids; mode=config surfaces the validated .repos/config.json manifest and its entries; mode=drift reconciles the manifest, .gitmodules, the worktree, git submodule status and the repo's local git config, reporting any mismatch as a typed drift kind; mode=gitmodules lists the parsed .gitmodules entries. Returns markdown-escaped output since vendored-repo content is untrusted input. Backed by the same silk-effects Repos services the savvy CLI uses.
• repos_manage — manages vendored repositories (mutating counterpart to repos_inspect): action=sync initializes any missing submodules (git submodule update --init --depth 1), applies sparse-checkout from the manifest, and clears stale git locks; action=pin fetches and checks out the new ref, staging the updated gitlink and manifest; action=add adds a new repo entry, optionally with the orientation block a preceding remove reported, so a re-vendor keeps it; action=note appends a short note to a repo; action=remove unvendors an entry and echoes back the entry it removed; action=rename renames one in place; action=restore hard-resets one or more dirty checkouts back to their pinned commit, and names any that stayed dirty afterwards instead of reporting the reset as a success. Pin, add, remove and rename stage git changes for the caller to commit; restore only resets the submodule's own working tree to its already-staged or already-committed gitlink commit, so there is nothing new to stage. sync, pin, add, remove, rename and restore unlock the vendored worktree for the duration of their git work and leave it read-only again afterwards (files 0444, directories 0555 — an executable file locks at 0555 instead, unlocking back to 0755 rather than losing its executable bit), so an agent that hits EACCES writing into .repos/ should route the change through this tool rather than chmod. The submodule gitdir stays writable and sync/add mark the boundary in local git config, so ordinary git commands skip these trees rather than failing against them. Backed by the same silk-effects Repos services the savvy CLI uses.

License

MIT