Moving Claude Skills Server-Side with Remix Servers

MCP solved tool connectivity. It didn't solve tool choreography.

I watch teams give Claude access to GitHub, Slack, and Linear, then ask it to ship a feature. The agent has all the tools. It can call any of them. But when you say "ship the PR I was working on," the agent has to figure out the orchestration from scratch. Sometimes it gets lucky. More often, it calls things in the wrong order, forgets steps, or hallucinates parameters.

The tools work fine. What's missing is the workflow knowledge that stitches them together.

Skills address this. You write a markdown file that describes the sequence: check CI, merge the PR, announce in Slack. Claude loads this file when relevant, and the multi-step workflow executes reliably.

This is good design. Progressive disclosure keeps context lean. The instructions version with your code. Teams can share workflow knowledge by sharing files. Anthropic got a lot right here.

Skills attempt to solve a problem that's been bothering Jeremiah and me for a while: how do you describe a workflow that spans multiple MCP servers? You install servers A and B, and both expose tools, but the orchestration knowledge lives nowhere.

The limitation is that skills are client-side. The skill describes a workflow across servers A and B, yet the skill itself lives in Claude's filesystem. Claude knows how to ship a PR. Cursor doesn't. Your weekend hackathon agent doesn't. The workflow is powerful but not portable.

The Portability Problem

Skills live in Claude's filesystem. That's fine if your team standardizes on Claude for everything. But we see teams using Cursor for coding, Claude Desktop for research, and custom agents for automation. The engineer who wrote your "ship feature" skill uses Claude Code. The PM checking deployment status uses Claude Desktop. The CI/CD pipeline uses a custom agent built on the API.

Three clients. Three copies of the same workflow knowledge. Or more likely: one copy in Claude, and the other two clients flying blind.

This is the M×N problem all over again. MCP solved it for tools by creating a standard protocol. But workflow knowledge still fragments across clients.

The question we kept asking: Skills are Claude teaching Claude how to orchestrate tools. Could we move that teaching to the server? Could any client connecting to the server get the same workflow knowledge?

Server-Side Orchestration

MCP has a feature that almost no one uses: prompts.

They're one of the protocol's three core primitives, but I rarely see them in production. Most teams build MCP servers with tools and resources, then document the workflows separately in Notion or Slack threads. The spec defines prompts as "reusable templates for LLM interactions," which undersells what they actually do. In practice, prompts let you author workflow guidance directly on the server, and any client connecting to that server receives the same guidance.

The distinction that matters is where the orchestration logic lives.

Client-side, with Skills: Claude holds the workflow knowledge. Works great if you're committed to one client. Breaks down when your team uses multiple AI tools.

Server-side, with prompts: The server holds the workflow knowledge. Any client connecting to that server inherits the orchestration logic. Portable by default.

The question becomes: how do you write prompts that reference tools from multiple servers?

Remix Servers

At Prefect, we've been unintentionally running the global help desk for MCP. Because we maintain FastMCP, we see the architecture diagrams of enterprises, startups, and weekend hackers every day. The best ideas don't come from us. They come from our community.

The pattern we keep seeing people converge on: remix servers.

Take servers A and B. Stand up a virtual server C that sits in front of them. Server C can cherry-pick tools from A, cherry-pick tools from B, and then author prompts that reference tools from both. The workflow knowledge lives on C, and any client connecting to C gets access to that knowledge.

Connect Cursor to this remix server, and Cursor knows how to ship features. Connect a custom agent, same workflow. Switch from Claude Desktop to ChatGPT. The orchestration logic moves with you because it's infrastructure, not configuration.

Skills vs. Prompts: Same Intent, Different Architecture

Skills and server-side prompts solve the same problem from opposite ends of the architecture. A Claude Skill says: "When the user wants to ship a feature, here's the sequence of steps using these tools." A remix server prompt says the same thing. The difference is where that knowledge lives and who can access it.

If your team is standardized on Claude Desktop, skills work great. Personal preferences, experimental workflows, per-project customization: client-side is the right layer for that variability. Keep writing skills for what's local.

But the moment you have Cursor for coding, Claude Desktop for research, and custom agents for automation, you're maintaining the same workflow in three places. That's when server-side orchestration starts making sense. The workflow represents organizational knowledge. It should live in infrastructure.

Both patterns have their place. Write skills for personal preferences. Author server-side prompts for shared workflows that should work everywhere.

Curating the Tool Surface

When you compose servers A and B into server C, you don't have to expose everything. You can selectively include only the tools relevant to the workflow. Instead of connecting an agent to a "God Mode" GitHub server with 40 tools, you connect it to a curated workspace with 3 tools and a prompt that explains exactly how to use them.

This is progressive disclosure applied at the server level. Show the agent what it needs for the task at hand, hide the complexity until requested.

Different workflows get different remixes. Your deployment agent gets GitHub + Slack + the shipping workflow. Your triage agent gets Linear + GitHub + the bug investigation workflow. Same underlying servers, different curated surfaces.

This connects to the browser tab heuristic. Count the open tabs of the person doing the work. Expose exactly that, nothing more. Remix servers let you apply that principle systematically across workflows.

Where Skills Still Make Sense

Skills remain the right choice for personal preferences. "Always use uv over pip." "Format code with ruff." "Prefer composition over inheritance." These are how you like to work, not how the work gets done.

And if you only ever use a single client, skills work fine for workflows too. The overhead of server-side orchestration is worth it for portability. You don't need USPS to send a package to yourself.

But the moment you're coordinating across clients, remix servers win. Your skills aren't versioned alongside your services. When your deployment process changes, you update the remix server and every client gets the new workflow immediately. With skills, you're updating markdown files scattered across laptops.

Where This Goes

The tribal knowledge that currently lives in your head, in Slack threads, in onboarding docs: it can become infrastructure.

Start with one workflow. Not your entire deployment pipeline, just one specific job that requires touching multiple systems. Identify the 2-4 MCP servers that power that workflow. Stand up a remix server that composes them, curates the tool surface, and encodes the sequence in a prompt.

Test it locally. Connect Claude Desktop, verify the workflow works. Then connect Cursor. Same workflow, no additional configuration. That's the portability principle in action.

You can remix your first servers today in FastMCP Cloud. The workflow you document once becomes the workflow that works everywhere.