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., "@rollbar-mcp show the most recent Rollbar occurrences in production"
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.
A focused, read-only Model Context Protocol server for Rollbar investigations. It works with Amp, Claude Code, Codex, and other clients that support local stdio MCP servers.
The server deliberately exposes only two tools:
rollbar_list_environments lists configured credential environments without exposing their tokens.
rollbar_get performs one authenticated GET request to a Rollbar API path.
It does not expose writes, POST requests, or RQL. Tool output is limited to 2,000 lines or 50 KiB. Request paths and redirects remain confined to the configured HTTPS origin so access tokens are never forwarded elsewhere.
Related MCP server: sonarqube-api-mcp
Node.js 20 or newer
A Rollbar Project Access Token with only the read scope for each credential environment
Configure the process that runs your MCP client with environment variables named ROLLBAR_<ENVIRONMENT>_ACCESS_TOKEN:
export ROLLBAR_QA_ACCESS_TOKEN="your-qa-read-token"
export ROLLBAR_STAGING_ACCESS_TOKEN="your-staging-read-token"
export ROLLBAR_PROD_ACCESS_TOKEN="your-prod-read-token"The server discovers these variables and exposes their lowercased environment segments through rollbar_list_environments. Requests default to prod when no credential environment is specified. Treat all access tokens as secrets and do not commit them to MCP configuration files.
The Rollbar API base URL defaults to https://api.rollbar.com. Custom or proxied API endpoints can override it with ROLLBAR_API_BASE_URL; the value must use HTTPS and cannot include credentials, a query string, or a fragment.
Run the published package through an MCP client:
npx -y @andreimaxim/rollbar-mcpIt communicates over standard input and output, so running it directly appears to do nothing while it waits for an MCP client.
The distributable using-rollbar skill includes the MCP launch configuration and exposes only rollbar_list_environments and rollbar_get. Install that directory as a project, personal, or workspace skill.
For a project skill, copy it into the repository:
.agents/skills/using-rollbar/SKILL.mdFor an orb, add the required ROLLBAR_*_ACCESS_TOKEN values under personal, project, or workspace Secrets & Env Vars. The included skill forwards the common qa, staging, and prod profiles; add another environment-variable reference to its mcpServers.rollbar.env map if you use a different profile name. Amp starts the MCP server in the orb when it discovers the skill and reveals its tools only when the skill loads.
The previous amp.rollbar.* plugin settings are no longer read; the portable MCP server uses environment variables in every harness.
Register the same stdio server at user scope:
claude mcp add --scope user --transport stdio rollbar -- \
npx -y @andreimaxim/rollbar-mcpStart Claude Code with the desired ROLLBAR_*_ACCESS_TOKEN variables available in its environment. For team distribution, put the equivalent server entry in the project's .mcp.json and keep credentials as environment-variable references.
Add this entry to ~/.codex/config.toml, or to .codex/config.toml in a trusted project:
[mcp_servers.rollbar]
command = "npx"
args = ["-y", "@andreimaxim/rollbar-mcp"]
env_vars = [
"ROLLBAR_QA_ACCESS_TOKEN",
"ROLLBAR_STAGING_ACCESS_TOKEN",
"ROLLBAR_PROD_ACCESS_TOKEN",
"ROLLBAR_API_BASE_URL",
]
enabled_tools = ["rollbar_list_environments", "rollbar_get"]Forward only the credential environments you use. The env_vars list forwards existing variables without placing their values in the configuration file.
npm install
npm run check
npm pack --dry-runRepository layout:
src/rollbar.ts contains credential discovery, request validation, the Rollbar HTTP client, redirect confinement, and bounded output formatting.
src/server.ts registers the MCP tools and their read-only annotations.
src/index.ts starts the stdio server.
skill/using-rollbar/SKILL.md contains the Amp skill and its MCP launch configuration.
test/ contains HTTP-client and protocol-level integration tests.
Make one authenticated GET request to a Rollbar API path. This tool is read-only and may truncate large output.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Rollbar API path beginning with /, for example /api/1/items or /api/1/instance/12345 | |
| query | No | Optional query parameters. Array values are encoded as repeated parameters. | |
| environment | No | Credential environment. Use rollbar_list_environments to discover configured values. Defaults to prod. | prod |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond annotations by stating 'authenticated' (auth requirement) and 'may truncate large output' (response truncation behavior), which are not captured in the annotations.
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?
The description is two sentences, front-loaded with the verb and resource. Every sentence earns its place: the first states the core action, the second adds read-only and truncation caveats. No redundant or extraneous wording.
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 generic API GET tool with three parameters, one nested, and no output schema, the description covers purpose, auth, read-only, and truncation. It does not specify return format (e.g., JSON), but that is somewhat implied and the schema covers parameter details.
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 100%, so all three parameters (path, query, environment) have descriptions in the schema. The description text adds no additional parameter semantics, so the baseline 3 applies.
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 'Make one authenticated GET request to a Rollbar API path,' clearly specifying the verb, resource, and scope. It distinguishes itself from the sibling rollbar_list_environments by being a generic API path wrapper, while the sibling is a specific environment-listing tool.
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 provides clear context for when to use the tool: any authenticated GET to a Rollbar API path. It notes read-only behavior and truncation, but does not explicitly name alternatives or exclusions. The sibling tool is only referenced in the schema's environment parameter, not in the description text, so there is no explicit when/not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured Rollbar credential environments without exposing their access tokens.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful safety context by stating that access tokens are not exposed, which is meaningful behavioral information beyond the annotations.
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?
The description is a single, well-structured sentence that is front-loaded with the action and resource. No unnecessary words or repetition.
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 zero-parameter, read-only list tool with strong annotations, the description is reasonably complete. It specifies what is listed and clarifies a key safety boundary, though it does not explicitly describe the return format.
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 accepts zero parameters, and the schema coverage is 100%, so there are no parameter semantics to document. Baseline for zero parameters is 4, and the description appropriately focuses on the tool's purpose rather than parameters.
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 uses a specific verb and resource: 'List configured Rollbar credential environments.' It also differentiates from sibling tools by emphasizing that access tokens are not exposed, making the tool's scope clear.
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 does not explicitly state when to use this tool compared to alternatives like rollbar_get. The safety note implies one use case, but no direct guidance or exclusion is provided.
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.1.0rollbar_getrollbar_list_environmentsScored across 2 tools
rollbar_list_environments is clearly specific to listing environments, while rollbar_get is a generic authenticated GET. The risk of confusion is low, though rollbar_get could technically be used to list environments as well, making boundaries slightly blurred.
Both tools share the rollbar_ prefix and use verb-first naming. However, rollbar_list_environments has a verb_noun structure while rollbar_get is just a verb, so the pattern is not perfectly uniform.
Only two tools for a platform as feature-rich as Rollbar is very thin. The generic GET tool provides some flexibility, but the server feels understaffed for its domain.
The toolset is entirely read-only: listing environments and making GET requests. There are no create, update, or delete operations, leaving many Rollbar workflows inaccessible. The generic GET helps read data but cannot close the gap for write operations.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
MCP server for Statsig API - interact with Statsig's feature flags, experiments, and analytics
MCP server for Riveter's enrichment, scraping, and monitoring API
Public MCP server for discovering open jobs. Search, filter, and get application links.
