Documentation 40
Tutorials · 6 pages · 10 to 15 min each
Test your agent against a world that never moves.
An agent that reads the tools your team works in is only as testable as the data underneath it, and a real account gives you neither a fixed answer nor a safe place to be wrong. Each page below points a tool client at a pinned host whose bytes never change, runs one small task against it, and asserts the answer, so the run in CI tonight is the run you did in your terminal this morning. Three are for people building an agent; the fourth is for people building the MCP server the agent calls; the fifth and sixth set up Cursor and Antigravity to do the same job with no script at all.
01 / The pages
Three for agent builders, one for server builders, two for agent platforms.
The first three are deliberately the same lesson three times, because the thing worth learning is the shape: fetch what a tool would return, decide something from it, assert the decision. They also read the SAME incident from three sides, so following all three is itself an exercise in whether an agent can cross tools. The fourth turns the same idea around and points a real GitHub MCP server at a pinned host, for the reader whose problem is that nothing supplies the API their tool server is translating. The fifth installs the SandboxAPIs plugin in Cursor and asks Cursor's own agent to cross the three tools, which is the same exercise with a product's agent in the loop instead of a script. The sixth does the same setup in Antigravity, by URL, with nothing installed.
02 / The story they read
Cassandra files it, Tiresias ships it.
On 2026-06-17 an engineer at olympus-labs opens a thread in #incident-bridge about events dropped during a rebalance. Six minutes earlier the same person filed FATE-51. Two days later a colleague merges pull request 53 from hotfix/backfill-job-ooming, and twenty-four minutes after the thread's all clear the tracker marks the issue Done.
Three vendors' APIs, asked independently, tell that one story, because one simulated company is underneath rather than three sets of fixtures somebody keeps in step by hand. The four-hop demo walks it end to end in a terminal, and the tour shows who the people in it are.
03 / The shape
Fetch, reason, assert.
Every script on these pages runs in three labelled beats: plain requests on the three agent pages, the MCP SDK's stdio client on the fourth. The middle beat is a pure function of the fetched rows, which is the one you replace with a model call when you want an eval rather than a smoke test:
rows = fetch(...) # what a tool call would return
answer = decide(rows) # swap in a model call here
assert answer == {"shipped": True} # the row it read never changes, so this holdsThe assertions are values read off a pinned host, never values typed into a page: apps/web/src/lib/tutorials.ts holds each script as the one string the page renders, and apps/web/src/lib/tutorials.test.ts compiles every one of them on each run and executes them against the pin hosts under SANDBOXAPIS_LIVE_TUTORIALS=1.
SANDBOXAPIS_LIVE_TUTORIALS=1 pnpm exec vitest run --project @sandboxapis/web src/lib/tutorials.test.tsNext
Where to go from here.
The answer-key eval pack is the next step after these three: the same pinned hosts, but as a downloadable file of known facts with a harness that scores an agent against all of them at once. SandboxAPIs for agents is the wider case for pointing an agent here, and MCP setup is the same data set through tools instead of HTTP.
Verified quickstarts · Versioning and pinning · Coverage manifest · All docs