Connected vs MCP: which one actually runs the skill

The difference in one sentence

With MCP your agent is the brain and it calls out to our tools. With Connected our brain calls back in to your machine, and your machine is the hands.

That single inversion explains everything else on this page — the wire, the credential, the permissions, and what of yours is exposed. Both are built on server-side execution, so in neither one does the skill file reach you.

MCP: your agent calls out

Our MCP server is a client surface — a way in. It speaks the Model Context Protocol over stdio and exposes exactly two tools: list_skills, which returns catalog metadata, and run_skill, which sends your inputs up and returns the output. Nothing of yours is touched; nothing of the seller's comes down.

This is the right surface when you want a result handed back — a draft, an analysis, a rewrite. It is also the surface you wire into Claude Code, Cursor, or anything else that speaks MCP. Setup is in add Sealed to your agent.

Connected: our brain calls in

Connected is an execution mode, not a transport. The skill's brain stays in our cloud and never touches a disk. It sends typed control messages — read_file, write_file, list_dir, run_command — to a brainless hands client running on your machine, which executes them inside a scope you granted and answers with one typed result.

This is the right mode when you want files in your own project changed in place rather than a block of text handed back. It is also the more defensible shape for a seller, since the value is the doing rather than the dispensing.

They don't overlap: MCP refuses Connected skills

This is the part that trips people up. MCP is not a way to run a Connected skill. run_skill resolves to the plain run endpoint, and that endpoint rejects a Connected skill before it validates your inputs or places a wallet hold — so a mistaken call costs nothing and returns a fixed message telling you to use the hands client instead.

The only path to a Connected skill is sealed hands run <skillId>. A Connected listing is also hand-reviewed before it goes up, because its scope contract will run commands on a stranger's machine.

What you grant, and where it's enforced

Connected is the only mode that asks for anything from your side, so the grant is explicit and narrow. You name the paths it may read, the paths it may write, the exact commands it may run, and how long the session lives. Anything outside that is refused, and sensitive commands need a separate confirmation each time.

The scope is enforced on your machine and nowhere else. It is never sent to us — the cloud side of the session cannot read it, and cannot widen it. Before the session starts, the client prints the skill's declared permissions and your grant side by side and waits for you to agree.

• Read and write roots: directories, not your whole disk.
• Commands: an exact allow-list, checked against what the seller declared.
• Expiry: every session dies on a clock you set.
• Disclosure: file contents read under the grant reach the model. The grant is the consent boundary.

Which one are you using?

• Want a result handed back — a draft, an analysis, a rewrite: a Hosted skill, called over MCP.
• Want files in your project changed in place: Connected.
• Wiring Sealed into Claude Code, Cursor, or any agent: MCP.
• Calling from CI with no repo checked out: Hosted, over MCP or plain HTTP.
• Not sure what a skill is in the first place: start with skills vs MCP tools vs prompts.

Sell the skill. Keep the secret.

Sealed is live and early — claim the founding-seller deal while you'd be among the first skills buyers find. Hosted skills you can publish yourself today; Connected listings are hand-reviewed, so write to us.

Building in the open · @sealedrun