v0.14.0 — 62 tools become 7

Sixty-two tools became seven. Nothing broke.

84.7% less schema in every conversation

The server advertised 62 flat tools. Every one of them injected its full JSON schema into the context before you typed a word: 34,409 characters. That is a tax paid on every single turn, and it makes the model worse at picking a tool, not better.

The same capability is now seven grouped verbs:

inspect · diagnose · edit · mark · generate · transcript · deliver

Each takes {"action": "...", "args": {...}} and dispatches into exactly the same 62 handlers. Same code, same behaviour, same results. 5,258 characters.

If you pass an action a group does not own, the error lists the valid ones rather than just failing.

Nothing breaks

call_tool resolves handlers from a registry that is independent of what list_tools advertises. So an existing config calling trim_clip by name keeps working exactly as before, whether or not the flat tools are advertised. Not a shim, not a translation layer — the flat names were never the dispatch mechanism.

Want the old list back? FCP_MCP_LEGACY_TOOLS=1 advertises the original 62 alongside the seven groups. They will not be removed before 1.0.

See the cut before you import it

Editing FCPXML through an MCP server was blind. You called a tool, got text back, and had no idea what the timeline looked like until you imported into Final Cut Pro.

Reading preview://<path> now returns a self-contained HTML render of the timeline: clip blocks sized in proportion to duration, connected clips drawn on lane rows above and below the spine, marker ticks, everything escaped, served as real text/html.

A Claude Code skill

skill/ ships a final-cut-pro skill that wraps this server with the workflow order and the FCPXML gotchas that do not fit in a tool description — which silence-removal path actually reads your audio, why offset and start are different numbers, what a lane means, and why you diagnose before you edit.

This closes the design question @MikeChongCan raised in #2 back in March: should this be a skill instead of an MCP server? The answer turned out to be both, in that order.

git clone https://github.com/DareDev256/fcp-mcp-server
ln -s "$PWD/fcp-mcp-server/skill" ~/.claude/skills/final-cut-pro

The dependency floor was wrong

server.py imports mcp.server.lowlevel.helper_types, which does not exist before mcp 1.3.0 — while pyproject.toml declared mcp>=1.0.0. In any environment where another package held mcp below 1.3.0, this server died at import and the client just showed "disconnected" with no surfaced error.

The floor is now mcp>=1.3.0,<2.0.0, verified by execution rather than assumption: 1.2.1 fails, 1.3.0 works.

A week ago the upper bound was the problem — mcp 2.0.0 removed the low-level decorator API and broke every fresh install for seven days before anyone said anything. Both failures are the same shape: a declared version range that was not true. So CI now runs the suite against the minimum supported mcp, not only the latest, and runs daily at 06:00 UTC instead of only when someone pushes.

Also fixed

• preview:// and file:// resource URIs are percent-decoded, so filenames containing spaces work. ~/Movies is full of them.
• The five built-in prompts no longer instruct the model to call tools it cannot see.
• Five rows of the README security matrix described protections that were never implemented. They are gone, and the remaining thirteen are backed by tests.

Upgrading

uvx fcp-mcp-server            # or
pip install -U fcp-mcp-server

Your config needs no changes. Your client will refresh from 62 tools to 7. Anything calling a flat name by hand keeps working.

Full Changelog: v0.13.2...v0.14.0