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.