Provides a read-only, API-compatible replica of Bitbucket with repositories, pull requests and their reviews/approvals, issues and user lookups, all built on a coherent simulated org whose references resolve across hosts.
Exposes an API-compatible replica of the Buildkite surface as part of the simulated olympus-labs data set, so agents can exercise Buildkite-shaped requests read-only without test accounts or cleanup.
Exposes an API-compatible replica of the CircleCI surface as part of the simulated olympus-labs data set, so agents can exercise CircleCI-shaped requests read-only without test accounts or cleanup.
Provides a read-only, API-compatible replica of GitHub with tools to list and fetch repositories, pull requests (including reviews), issues, users, and commits by author with cross-referencing SHAs, served from a simulated org with months of coherent history and provider-form ids.
Provides a read-only, API-compatible replica of GitLab, letting agents list and fetch repositories, merge requests with their approvals, issues, users and commits by author against realistic simulated data.
Serves an API-compatible replica of the HubSpot surface as part of the simulated olympus-labs data set, allowing agents to make read-only HubSpot-shaped requests without credentials or rate limits.
Provides an API-compatible, REST-based replica of Jira, letting agents list issues from a simulated org's coherent project history, read-only and without a test account.
Provides an API-compatible replica of Linear that serves issues over GraphQL, querying the same simulated org history that is available through the other hosts.
Serves an API-compatible replica of the OpenAI surface as part of the simulated olympus-labs data set, letting agents issue read-only OpenAI-shaped requests with no credentials required.
Exposes an API-compatible replica of the PagerDuty surface as part of the simulated olympus-labs data set, so agents can exercise PagerDuty-shaped requests read-only without consequences.
Exposes an API-compatible replica of the Salesforce surface as part of the simulated olympus-labs data set, so agents can exercise Salesforce-shaped requests read-only without credentials.
Exposes an API-compatible replica of the Sentry surface as part of the simulated olympus-labs data set, so agents can exercise Sentry-shaped requests read-only without credentials or rate-limit anxiety.
Provides an API-compatible replica of the Slack surface, letting agents query a simulated organisation's messaging data read-only as part of the cross-referencing olympus-labs data set.
Exposes an API-compatible replica of the Statuspage surface as part of the simulated olympus-labs data set, so agents can exercise Statuspage-shaped requests read-only without a test account.
Exposes an API-compatible replica of the Zendesk surface as part of the simulated olympus-labs data set, so agents can exercise Zendesk-shaped requests read-only without credentials or cleanup.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@sandboxapis/mcp orient, then list the open pull requests awaiting review"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives an AI agent a realistic, read-only data set to work against — repos, pull requests, reviews, issues, sprints, commits — served through API-compatible replicas of GitHub, GitLab, Bitbucket, Azure DevOps, Jira, Linear, Slack, Microsoft Teams, Sentry, PagerDuty, Statuspage, CircleCI, Buildkite, Zendesk, Salesforce, HubSpot, Anthropic, OpenAI, ChatGPT, Cursor and Devin.
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, where the coverage manifest lives, and an access block saying what this server may spend — enough to make a correct call with no docs reading.
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 21 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.
Related MCP server: sandbox-seed
Tool | What it does |
| Start here. Full self-orientation, no docs required — including |
| Costs nothing. Call it before any loop of more than a handful of requests: limit, remaining, when the window resets. |
| Repos, provider-shaped, with provider-form ids. |
| PRs/MRs with their reviews or approvals. |
| Issues — REST on git hosts and Jira, GraphQL on Linear. |
| A user by login/username. |
| Commits by author, with SHAs that cross-reference across hosts. |
| 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.
Everything is optional — the server works with no configuration at all.
Variable | Effect |
| Lifts the anonymous limit (60 req/hr) to 600. Free key at sandboxapis.dev — agents exhaust 60/hr quickly. Without it, a refusal names this variable rather than a signup page; with it, a refusal names the rung the key is on. Either way the tool result carries |
| Point a surface elsewhere — a pinned snapshot host, or a self-hosted instance. |
Nothing is hidden behind a limit, but every caller has an hourly window and an agent in a loop will find it. Two things make that legible without parsing prose:
Ask first. check_budget reads the real window — limit, remaining, seconds until it resets — through an endpoint that is exempt from the budget it reports, so the check itself is free. orient returns the same facts in its access block, so an agent that oriented already knows.
The refusal is data. A refused tool result keeps its {provider, path, status, body} exactly as before and adds upgrade:
{
"provider": "github",
"path": "/users/athena",
"status": 403,
"body": { "message": "API rate limit exceeded. …", "documentation_url": "…", "status": "403" },
"upgrade": { "tier": "anonymous", "url": "https://sandboxapis.dev/upgrade?from=anonymous", "retryAfterSeconds": 600 }
}tier is the rung that refused; url is absent when there is nothing to offer; retryAfterSeconds is present when the provider sent a Retry-After. upgrade appears on over-limit refusals only — never on a success, a coverage 404, or a read-only refusal.
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.
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.
This repository is the source of the MCP server, the @sandboxapis/mcp package on npm. It is a thin client: it holds no data of its own and reads the hosted service at sandboxapis.dev over HTTPS. The hosted service, the API replicas and the engine that generates the data set are separate and are not included here.
The code is MIT licensed, see LICENSE. The copyright holder is Driftwork LLC, the company behind SandboxAPIs.
The source of record is the SandboxAPIs monorepo, and this repository is written from it by a script on every release, with the release's version as a tag. Bug reports and feature requests are welcome in this repository's issues. A pull request here is read and carried over by the SandboxAPIs team rather than merged in place, because the next release would otherwise overwrite it. Contact: team@sandboxapis.dev.
Docs: sandboxapis.dev/docs/mcp · Coverage: sandboxapis.dev/coverage
Costs nothing — call it before any loop of more than a handful of requests. Returns this server's real hourly window (limit, remaining, when it resets) read from the provider's own budget endpoint, which is exempt from the budget it reports, plus whether a key is set and where to raise the limit. The window is ONE bucket per caller shared across every provider host, so the numbers apply to all of them.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | The host you are about to call. Optional — the budget is one shared window, so the numbers are the same for every provider. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the call costs nothing, that the endpoint is exempt from the budget it reports, that the window is shared across all provider hosts, and that numbers are identical regardless of provider. These are critical behavioral facts an agent could not infer otherwise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the cost and usage condition, then the return details, then the shared-window caveat. Dense but every clause carries necessary information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple single-optional-parameter read tool with no output schema. It covers cost, when to call, what is returned, the shared-window semantics, key presence, and where to raise the limit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the provider parameter's enum and role. The description adds the non-obvious insight that the parameter value doesn't change the output because the budget is one shared window. That's meaningful beyond the schema but the parameter itself needs no further explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('check ... budget') and explains exactly what is returned: limit, remaining, reset time, key presence, and how to raise the limit. This is far more than a restatement of the name and clearly distinguishes it from siblings like orient or get_snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit conditions: 'call it before any loop of more than a handful of requests.' This is concrete and actionable guidance about when to use the tool that no sibling provides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one PR (GitHub) / MR (GitLab) plus its reviews (GitHub) / approvals (GitLab). Returns both in one result; each carries provider-form ids for cross-referencing.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| number | Yes | ||
| provider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the call returns both the PR and its reviews in one result and that ids are provider-form for cross-referencing, but it omits read-only/auth requirements and any rate-limit or pagination behavior. Fetch/Get implies a safe read, so the gap is moderate rather than severe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the payload ('one PR/MR plus reviews/approvals') front-loaded and the cross-referencing note last, with no filler. The slash-heavy provider hedging makes it slightly harder to parse than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param tool with no annotations and no output schema, the description does explain what comes back (PR + reviews/approvals, provider-form ids), so return-value coverage is adequate. It falls short on `repo` semantics, provider scope, and any operational constraints, leaving real gaps an agent must guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters, and the description compensates only partially: it explains `provider` in terms of GitHub vs GitLab and implies `number` identifies the single PR. The `repo` parameter is never mentioned, and the schema's 21-value provider enum is far broader than the two providers the description names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch one PR/MR') and spells out the bundled payload (reviews on GitHub, approvals on GitLab) and the cross-referencing id format. 'One' implicitly distinguishes it from the sibling list_pull_requests, though no sibling is named explicitly, keeping it short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: you call this when you need a single PR/MR together with its reviews/approvals. There is no explicit when-not guidance versus list_pull_requests, and no prerequisites stated (e.g. whether `repo` is mandatory for github/gitlab).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one repository by name (default: the flagship repo). Provider-shaped, with provider-form ids.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | Repo name, e.g. 'parthenon'. Defaults to the flagship repo. | |
| provider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Provider-shaped, with provider-form ids' is opaque jargon that does not tell the agent what the response contains, what happens on an unknown repo name, or whether authentication/scopes are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the core action and default front-loaded and no filler. The second sentence is short but cryptic rather than wasteful, so it is efficiently sized overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain the returned shape, error behavior, and provider-specific semantics, but it leaves all of that to an unexplained phrase. For a fetch tool keyed on a 21-value provider enum, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (the provider parameter has an enum but no description). The description merely restates the repo default that the schema already documents and adds the vague phrase 'provider-form ids' without explaining how provider affects lookup semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch one repository by name') plus the default behavior, which implicitly contrasts with the sibling list_repositories. It stops short of explicitly naming the sibling or the entity's scope, so it is clear but not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'fetch one repository by name' framing implies a single-entity lookup as opposed to list_repositories, and the default note hints at the no-argument case. However, it never states when to use this over orient, get_snapshot, or list_repositories, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the pinned, reproducible hostname for a provider — point your client's base URL at it for drift-free CI. A snapshot regenerates byte-identically on every request.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but does deliver a meaningful trait: the snapshot regenerates byte-identically on every request, implying idempotence and safe repeated calls. It omits auth requirements, error behavior for unsupported providers, and whether a network call is involved, so it clears the minimum without being rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, with the core action and resource front-loaded and the CI motivation immediately following. No filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one enum-constrained parameter, no output schema), and the description explains what is returned (a hostname) and how to use it, which is what's needed absent an output schema. It could mention failure behavior for an unsupported provider but that is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single `provider` parameter; it only says 'for a provider' without clarifying the enum's domain. The enum values (github, slack, sentry, ...) are self-explanatory provider names, which keeps this workable but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (return) and resource (the pinned, reproducible hostname) scoped per provider, and clarifies what the value is for. No sibling tool (orient, check_budget, list_repositories, etc.) overlaps this behavior, so the agent can select it unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Point your client's base URL at it for drift-free CI" gives a concrete use context, effectively telling the agent when this tool is the right choice. It stops short of naming alternatives or exclusions, which is acceptable since no sibling competes for this job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a user by login/username. Provider-shaped, with provider-form ids.
| Name | Required | Description | Default |
|---|---|---|---|
| login | Yes | The user's login (GitHub) / username (GitLab). | |
| provider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Provider-shaped, with provider-form ids' vaguely hints that the returned object and its id format depend on the provider, but it does not explain not-found/error behavior, auth requirements, or what the response actually looks like for each provider.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and lookup key. Every word is doing work, though 'Provider-shaped, with provider-form ids' is jargon that is concise but not fully self-explanatory.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter lookup with no annotations and no output schema, the description is minimally adequate: it identifies the key and hints at provider variance. It omits what happens when the user is not found and leaves the meaning of 'provider-form ids' unexplained, so an agent lacks confidence about return shape and failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: login is documented in the schema, while the 21-value provider enum has no prose. The phrase 'provider-shaped, with provider-form ids' does add meaning to the provider parameter by signaling that id formats vary by provider, partially compensating for the missing enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch a user') plus the lookup key ('by login/username'), so the operation is unambiguous. No sibling tool returns users, so sibling differentiation is not needed here, but the description never references its relationship to the list/get family around it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative guidance. The verb implies a simple lookup, but nothing tells the agent under what circumstances to reach for get_user versus another orient/snapshot-style tool, nor what prerequisites (auth, valid provider) apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a repo's issues. Optional state filter (open/closed/all).
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| state | No | ||
| provider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read, but nothing is said about pagination, result limits, auth/scope requirements, or what happens when the repo is missing — significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core purpose front-loaded and the filter qualifier second. Nothing is wasted, though it is under-specified rather than deliberately tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, 0% schema description coverage, and a required provider enum undocumented, the description is too thin for an agent to invoke the tool confidently. It should at minimum explain provider selection and the default state behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are 3 parameters. The description clarifies the state enum (open/closed/all) and implies repo, but leaves the required 'provider' parameter — with 21 enum values — entirely unexplained, so the agent cannot know it selects the source system. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (a repo's issues), which is enough to distinguish it from list_pull_requests or get_repository by resource type. It does not explicitly name siblings or scope boundaries, but the verb+resource pairing is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only notes that state is optional; it gives no guidance on when to use this versus list_pull_requests or get_repository, no prerequisites, and no exclusions. An agent must infer all routing decisions from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a repo's pull requests (GitHub) or merge requests (GitLab). Optional state filter.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| state | No | Provider state filter. | |
| provider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. 'List' implies a read-only operation, which is useful, but the description omits auth requirements, pagination behavior, rate limits, return format, and whether all provider types in the enum are supported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with purpose and followed by the filter note. Nothing is padded or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema and no annotations, the description is too sparse. It does not address provider scope, pagination, return shape, or authentication, leaving gaps an agent would need to fill before invoking correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description must compensate. It mentions 'repo' and the 'state' filter, and names GitHub/GitLab parenthetically, but does not explain the required 'provider' parameter, its enum of 21 values, or which providers actually apply to pull requests versus merge requests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('pull requests' / 'merge requests'), and ties them to providers (GitHub/GitLab). It is clear at a glance, but does not explicitly distinguish itself from the singular 'get_pull_request' sibling or from 'list_issues'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage cue is that the state filter is optional. There is no guidance on when to use this tool instead of 'get_pull_request', no prerequisites, and no exclusions for providers beyond GitHub/GitLab.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List repositories for the universe's org. Results are identical to the provider's REST API and carry provider-form ids (node_id / numeric id).
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that results mirror the provider's REST API and use provider-form ids (node_id/numeric), which is real behavioral context. However it says nothing about pagination, auth requirements, rate limits, or result ordering for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler, and the core action is front-loaded before the return-value caveat. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param list tool with no output schema, the id-format disclosure is helpful, but the description omits pagination behavior and how the single required provider param affects results — gaps an agent would hit when invoking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One required param ('provider') at 0% schema description coverage; the enum values are visible but the schema adds no meaning. The description only implies the param selects the provider/org, adding marginal semantics but not explaining how the provider shapes the returned ids.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('List repositories') scoped to the universe's org. It implicitly distinguishes itself from the singular sibling get_repository, but never names siblings or clarifies scope boundaries explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no exclusions, and no mention of alternatives such as get_repository for a single repo or search_commits_by_author. Usage must be entirely inferred from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
START HERE. Returns everything needed to use SandboxAPIs with no docs: the universe/theme, every API surface and its base URL (git hosts and issue trackers), live-vs-snapshot modes and how to pin, the org and its teams/repos, notable entry points (each with a ready-to-run REST path), where the coverage manifest lives, and this server's access block — whether a key is set and how many requests are left this hour. Writes: this server is READ-ONLY, including for a scratch-enabled key — the scratch layer (a per-key, 24-hour overlay: GitHub issues and issue comments, Jira comments and transitions, and Slack messages into existing channels) is a REST feature, so use the GitHub, Jira or Slack base URL above with your key for it, and expect the tools here to answer from the shared data set alone.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it declares the server READ-ONLY even for scratch-enabled keys, explains that the scratch layer is a 24-hour per-key overlay backed by REST (and which surfaces it touches), states responses come from the shared data set alone, and reports key/rate-limit status in the access block.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Content is front-loaded with 'START HERE' and every clause is substantive, but it is delivered as two long run-on sentences that are hard to scan. The writes/scratch-layer discussion in particular would benefit from being broken into shorter, ordered statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description must be self-sufficient, and it is: it covers the returned contents, the live-vs-snapshot modes, the write policy and where writes actually happen, and the access block fields. Nothing an agent needs to call a zero-argument orientation tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so per the rubric the baseline is 4; there is no argument surface the description needs to compensate for. No additional parameter meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific action and enumerates exactly what the tool returns (universe/theme, API surfaces with base URLs, modes, org/teams/repos, entry points, coverage manifest, access block), which lets an agent distinguish it from narrow siblings like get_snapshot or check_budget. The opening 'START HERE' frames it as the entry-point orientation call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'START HERE' is explicit guidance on when to call it, and the writes paragraph routes the agent to the GitHub/Jira/Slack REST base URLs for scratch-layer operations rather than the tools. It does not, however, explicitly state when to prefer it over siblings that overlap (get_snapshot, check_budget).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find commits authored by a given login in a repo. Returns SHAs (identical across GitHub and GitLab, invariant #5) with a REST path to fetch each — so you can cross-reference against either provider.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| author | Yes | Author login, e.g. 'athena'. | |
| provider | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the return shape (SHAs plus a REST path per commit) and a cross-provider invariance guarantee. However it says nothing about pagination, result limits, or whether a provider is required, which an agent needs before invoking a search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the purpose front-loaded and the value proposition second. The parenthetical reference to 'invariant #5' is an opaque pointer to documentation the agent cannot see, which costs a little clarity for the space it takes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description rightly explains the return (SHAs + REST path), which is a good use of the space. But it implies 'in a repo' while repo is optional and only author is required, leaving the cross-repo search case unexplained, and pagination behavior is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'author' is documented), so the description must compensate. It usefully clarifies author as a 'login' and ties it to 'a repo', but leaves the provider parameter's relational meaning (defaults, whether it constrains the SHAs returned) to the enum alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Find commits authored by a given login in a repo'), which is unambiguous. No sibling tool covers commits, so there is little to confuse it with, but the description never explicitly contrasts itself with anything.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the cross-reference sentence hints at a reason to call it, but there is no explicit when-to-use, when-not-to-use, or alternative named. An agent can infer intent from the purpose statement alone, which is the definition of minimum-viable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.14check_budgetget_pull_requestget_repositoryget_snapshotget_userlist_issueslist_pull_requestslist_repositoriesorientsearch_commits_by_authorScored across 10 tools
The data tools each target a distinct resource+action (repositories, pull requests, issues, users, commits), and the three meta tools (orient, get_snapshot, check_budget) serve clearly different setup/reproducibility/budget purposes. Minor risk that orient overlaps conceptually with check_budget and get_snapshot as 'introspection' tools, but descriptions clearly separate them.
Nearly all tools follow a predictable verb_noun pattern (get_snapshot, check_budget, list_repositories, get_repository, list_pull_requests, get_pull_request, list_issues, get_user, search_commits_by_author). The lone bare verb 'orient' is a minor deviation from the otherwise consistent scheme.
Ten tools is well-scoped for a read-only multi-provider API surface with a few setup helpers. Each tool earns its place with no obvious redundancy or filler.
The read-only surface covers lists/gets for repositories and pull requests plus issues, users, and commit search, matching the stated read-only, snapshot-oriented purpose. Asymmetries remain (list_issues with no get_issue, get_user with no user list, no issue/PR comment retrieval), but agents can work around these via the returned REST paths.
Hosted MCP endpoint with realistic fake data for prototyping agents. 12 tools, no setup.
Your AI dev team: agents that build, test, review and ship, each on its own cloud machine.
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
