@sandboxapis/mcp
v0.3.1
Published
MCP server for SandboxAPIs — read-only, API-compatible replicas of GitHub, GitLab, Bitbucket, Azure DevOps, Jira, Linear, Slack, Microsoft Teams, Anthropic, OpenAI, ChatGPT, Cursor and Devin, preloaded with one realistic simulated engineering org.
Maintainers
Readme
@sandboxapis/mcp
An MCP server that gives an AI agent a realistic, read-only engineering org to work against — repos, pull requests, reviews, issues, sprints, commits — served through API-compatible replicas of GitHub, GitLab, Bitbucket, Azure DevOps, Jira, and Linear.
No test accounts. No credentials. No rate-limit anxiety. Nothing to clean up afterwards.
claude mcp add sandboxapis -- npx -y @sandboxapis/mcpThen have the agent call orient first. It comes back with the API surfaces and their base URLs, the org and its teams, notable entry points (each with a ready-to-run request), how to pin a reproducible snapshot, and where the coverage manifest lives — enough to make a correct call with no docs reading.
Why this exists
Agents that build or test integrations need something real to point at. The options are usually a hand-maintained fake org that's thin and stale, or a real account with credentials, rate limits, and consequences. This is the third option: one simulated company — olympus-labs — with months of coherent history, rendered into six different API dialects, where every reference resolves. A pull request's author is a fetchable user, its commits exist with matching SHAs, its reviewers belong to real teams, and the same story is queryable through every host.
Everything is read-only. Writes return the provider's own error shape with a plain explanation, so an agent that tries one learns something instead of breaking something.
Tools
| Tool | What it does |
|---|---|
| orient | Start here. Full self-orientation, no docs required. |
| list_repositories / get_repository | Repos, provider-shaped, with provider-form ids. |
| list_pull_requests / get_pull_request | PRs/MRs with their reviews or approvals. |
| list_issues | Issues — REST on git hosts and Jira, GraphQL on Linear. |
| get_user | A user by login/username. |
| search_commits_by_author | Commits by author, with SHAs that cross-reference across hosts. |
| get_snapshot | The pinned hostname for drift-free CI. |
Results come from the same public API a human would point a client at, so anything an agent learns here transfers directly to a curl or an Octokit call.
Configuration
Everything is optional — the server works with no configuration at all.
| Variable | Effect |
|---|---|
| SANDBOXAPIS_API_KEY | Lifts the anonymous limit (60 req/hr). Free key at sandboxapis.dev — agents exhaust 60/hr quickly. |
| SANDBOXAPIS_BASE_URL_GITHUB (and _GITLAB, _BITBUCKET, _ADO, _JIRA, _LINEAR) | Point a surface elsewhere — a pinned snapshot host, or a self-hosted instance. |
Live vs. pinned
The default hosts roll forward daily, so the newest activity is always hours old — good for demos and exploration. For tests you want data that never drifts, ask get_snapshot for a pinned hostname and set the matching SANDBOXAPIS_BASE_URL_*. A snapshot regenerates byte-identically on every request, so pinned assertions hold indefinitely.
Honest boundaries
Coverage is deliberately bounded and published. An uncovered REST endpoint returns a real 404 plus an X-SandboxAPIs-Coverage header pointing at the coverage manifest; an uncovered GraphQL field returns an explicit coverage error rather than a silent null. You will never get a plausible-looking invented value.
This package is a thin client: it holds no data of its own and reads the hosted service over the network.
Docs: sandboxapis.dev/docs/mcp · Coverage: sandboxapis.dev/coverage
