Reference

MCP server

Give an agent its own fake system to practise on. The Slurry MCP server lets any MCP client create, configure, observe and delete simulations.

Connection details

Setting	Value
URL	`https://api.slurry.io/mcp`
Transport	Streamable HTTP
Auth	`Authorization: Bearer slurry_acct_...`
Plan	Team or Scale

Use a dedicated account key for each agent, with only the scopes it needs and, where possible, an IP restriction and an expiry. Security-relevant actions taken through MCP are recorded in your audit log.

Claude Code

terminal

claude mcp add --transport http slurry https://api.slurry.io/mcp \
  --header "Authorization: Bearer $SLURRY_ACCOUNT_KEY"

Add --scope project to share the server with your team through .mcp.json, and keep the key itself in an environment variable rather than the file.

Cursor and other HTTP clients

Clients that support remote servers with headers take the config directly. For Cursor, put it in .cursor/mcp.json in the project or ~/.cursor/mcp.json globally.

mcp.json

{
  "mcpServers": {
    "slurry": {
      "type": "http",
      "url": "https://api.slurry.io/mcp",
      "headers": {
        "Authorization": "Bearer slurry_acct_..."
      }
    }
  }
}

Claude Desktop

Add Slurry as a custom connector with the URL above, or, if your version only runs local servers, bridge it with mcp-remote in claude_desktop_config.json:

claude_desktop_config.json

{
  "mcpServers": {
    "slurry": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote", "https://api.slurry.io/mcp",
        "--header", "Authorization: Bearer ${SLURRY_ACCOUNT_KEY}"
      ],
      "env": { "SLURRY_ACCOUNT_KEY": "slurry_acct_..." }
    }
  }
}

Tools

Read-only tools are annotated as such, and destructive ones (reset, delete) carry the destructive hint so clients can ask before running them.

Tool	What it does	Writes
`search_library`	Find a ready-made API in the library by name or vertical.	No
`list_simulations`	List your simulations with status and URL.	No
`create_simulation`	Create one from a library slug or an OpenAPI document.	Yes
`get_simulation`	Status, collections, record counts, behaviour, rules, keys, webhooks.	No
`list_records`	Read the records in one collection.	No
`recent_activity`	Latest data changes and API requests.	No
`fast_forward`	Run the behaviour plan as if N hours passed (up to 720).	Yes
`reset_simulation`	Restore the exact original seed.	Yes
`set_status`	Pause or resume a simulation.	Yes
`add_rule`	Add a fixed, error, latency, conditional or chaos rule.	Yes
`update_behaviour`	Replace the scheduled behaviour plan.	Yes
`add_webhook`	Send signed change events to a public https URL.	Yes
`update_access`	Change the IP allow-list or switch restriction on or off.	Yes
`create_api_key`	Issue another simulation key (shown once).	Yes
`delete_simulation`	Permanently delete a simulation and its data.	Yes

An agent evaluation, end to end

With the server connected, a single prompt is enough:

prompt

Create a Slurry simulation from the "asana" library entry called agent-eval,
with 200 tasks. Add a rule so POST /tasks fails with a 503 a third of the time.
Then run my triage agent against it, fast-forward 48 hours, and tell me which
tasks it touched and whether it retried the failed writes.

What happens

search_library and create_simulation build the world and return a URL and simulation key.
add_rule adds the error rule with probability: 0.33.
Your agent runs against the simulation URL as if it were the real API.
fast_forward moves the world on, and recent_activity shows exactly what changed and which requests failed.
reset_simulation puts it back for the next run, or delete_simulation removes it.

Next: Webhooks