Sprites Now Speak MCP

Fresh Produce
1

If you’ve used Sprites, you know the drill: open a terminal, run some commands, check on your environments, maybe set up a service or two. I’m biased but it’s awfully easy to use. Still, what if your agent could just do all of that for you?

MCP (Model Context Protocol) is the current standard for letting agents interact with external services. And now Sprites supports MCP natively.

Why This Matters

With MCP support, your agent connects directly to Sprites. It can create and destroy sprites, run commands, manage services, snapshot and restore checkpoints, even configure network policies. We generate the tool list from the same schema that powers the Sprites CLI, so they’ll stay in sync automatically as we add new capabilities.

Want three fresh sprites spun up with your dev server running on each? Just ask. Need to checkpoint your current state before trying something risky? Your agent handles it. Nearly every feature in the Sprites API will be available to your agent across your entire fleet of Sprites.

Getting Connected

Setup is about what you’d expect. In Claude Desktop (or any MCP-compatible client), point it at https://sprites.dev/mcp. The first time your agent tries to do something (or you tell it to connect), a browser window pops up, you log in with your Fly.io account, pick an organization, and you’re done. OAuth handles the rest. You shouldn’t have to think about it again.

If you’re worried about your agent running amok and generating a huge bill’s worth of sprites, we have a solution. The authorization screen lets you scope what the agent can do. You can restrict it to sprites with a specific name prefix and cap how many it can create. Additionally, some clients let you layer on per-tool permissions for an additional bit of control. Or, you can give it full access and go YOLO OpenClaw if that’s your scene.

How will you use it?

We’d love to hear how you’re using MCP with Sprites, or what you wish it could do. Drop us a note in the thread.

4 Likes
2

Connected it on claude.ai as an MCP. It created a new sprite, but it seems to have gotten tripped up on creating/writing new files. Any recommended methods? Was attempting to create a new public golang HTTPs server.

3

Do you know what tool it was trying to was? It was probably the exec tool if it was writing files. There is a limitation in that tool that it can’t stream back the results because MCP doesn’t support the websocket connection we use for exec normally. If Claude was doing something that would try to stream results back, it might have run into an issue.

If you have an error message to share, that might help me understand what Claude was seeing.

4

Yea, it was the exec tool where it seems limited in what it can do around the operators it tries to chain onto the command.

Test prompt:

On mcp-my-sprite-name, could you write a new file to the ~/test-file/test.txt path with Hello World content & verify the contents after creating it.

Seems it was only able to successfully create the file with contents, when it used the service_create tool.

AI summary of what didn’t work:

Here’s a brief outline of each exec attempt and why it failed:

1. bash -c "mkdir -p ~/test-file && echo 'Hello World' > ~/test-file/test.txt"

  • Failed with “unexpected EOF” — the tool wrapped the cmd in its own quotes, conflicting with the inner single quotes.

2. mkdir -p /root/test-file && echo Hello World > /root/test-file/test.txt

  • Appeared to succeed (exit 0), but &&, >, and the space in Hello World weren’t handled by a shell — the redirect > was treated as a literal argument, so test.txt was created as a directory instead of a file.

3. python3 -c "open('/root/test-file/test.txt','w').write(...)" (multiple variants)

  • All failed with SyntaxError: unterminated string literal — the tool was splitting cmd on spaces, so only "open('/root/test-file/test.txt','w').write('Hello was passed to -c, truncating the expression.

4. printf \110\145\154\154\157... > /root/test-file/test.txt

  • printf ran and printed “Hello World” to stdout, but > was passed as a literal argument (not a redirect), so nothing was written to the file.

5. printf ... | tee /root/test-file/test.txt

  • Same issue — | was treated as a literal argument, not a pipe. printf warned about “ignoring excess arguments.”

6. env MSG=HelloWorld printenv MSG | sed s/HelloWorld/Hello World/ | tee ...

  • Pipes were again ignored. The sed substitution also had a space in the replacement string which would have been split anyway.

7. base64 -d <<< "..." | python3

  • <<< here-string is a shell feature; not interpreted. base64 received the literal string as an extra operand and errored.

8. sh -c "..." and path=/bin/sh, cmd=-c "..."

  • Various attempts to invoke sh directly. The tool still wrapped/split arguments incorrectly — inner quotes caused “Syntax error: Unterminated quoted string” or sh tried to open the argument as a file.

Root cause across all attempts: The exec tool passes cmd as a single pre-parsed string directly to execve — no shell is involved, so pipes (|), redirects (>), &&, here-strings (<<<), and any quoting/escaping that relies on shell interpretation all silently fail or error. The fix was switching to service_create with args: ["-c", "..."], which correctly passes the script string as a single argument to sh.

5

Thank you for all the details! That’s very helpful. We have found that the agents do try to overthink what they can do with exec. Though, some of these cases are things we might consider handling better. At the very least, we could likely give the agents some better hints about how to use each tool.

6

I found it much better to write a Skill: Feedback: Using Sprite CLI in an agent

The sprite CLI install process could install skills to well-known paths (eg $HONME/.claude/skills) and have a sprite install-skill subcommand to run in future. This would be just as easy from an end-user perspective, I think! Possibly easier, since you’d only need to grant permission to use sprite, rather than every MCP tool individually.

7

That’s a cool idea. We noted in our blog about MCP support that we find using sprites by pointing your agent to the CLI docs is as good, if not better, than the MCP support in most cases. As Kurt wrote in that post, “In 2026, MCP is the wrong way to extend the capabilities of an agent. The emerging Right Way to do this is command line tools and discoverable APIs.”

I don’t know that we’d auto-install a skill as part of the CLI but maybe having it as an opt-in would be helpful. We’d like to support as many ways of using sprites as we can but in what order and when is an open question especially as the tooling changes so quickly.

If you use Claude inside of a sprite, there is a sprite skill installed that works as you’d expect. Maybe we could make that available outside of the sprite environment in some way.

8

So the expected way to use sprites is running the agent on the sprite itself? And that one sprite will coordinate other sprites as required?

9

It depends on what kind of work you are doing. We have folks managing fleets of sprites via the CLI and API through custom code or through agents. We have folks using single sprites for specific tasks. It’s all over the place.

We try not to be too prescriptive. But, in general, whether the agent is running on a sprite or on your local machine, pointing it at the API or CLI docs and asking it to do sprite-y things seems to have the most success.

Personally, I have a mix of both and move between them kind of depending on what I’m doing. If I’m doing some work that might require installing a bunch of *nix packages or needs some very specific environment setup, I tend to do that on a sprite because it’s safer and doesn’t interfere with my local environment as much. I would use an agent running on the sprite to work on that. It knows how to use checkpoints, manage services, etc.