The Rollbar MCP Server integrates Rollbar error monitoring with AI tools (Claude, Cursor, VS Code, etc.), enabling you to monitor, investigate, and manage errors and deployments via natural language.
List Projects: View all Rollbar projects accessible to the configured token(s), useful for multi-project setups.
Get Item Details: Retrieve full details for a specific Rollbar item by its counter, including its most recent occurrence with stack traces and error context.
List Items: Search and filter items by status (active/resolved/muted), severity level, environment, or free-text query, with pagination support.
List Occurrences: Fetch individual occurrence instances for a Rollbar item, with cursor-based pagination and configurable response size limits.
Get Top Items: See the highest-frequency errors in a given environment over the last 24 hours for quick triage.
Get Deployments: List recent deployments to correlate deploy timing with error spikes or resolutions.
Get Version: Look up how a specific version (e.g., a git SHA) has performed in an environment, including first/last occurrence timestamps.
Get Replay: Fetch session replay metadata and payload to see what a user did leading up to an error, delivered as a file or rollbar:// resource link.
Update Item: Modify a Rollbar item's status, severity level, title, assignee, resolved version, snooze state, or owning team (requires write access).
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 Server Show me the top errors in production from the last 24 hours"
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 Model Context Protocol (MCP) server for Rollbar.
This MCP server implements the stdio server type, which means your AI tool (e.g. Claude, Cursor) will run it directly; you don't run a separate process or connect over http.
Related MCP server: GlitchTip MCP Server
To read item history and post comments as yourself, configure a Rollbar user-scoped account access token with ROLLBAR_USER_ACCESS_TOKEN, or use a config file:
{ "userToken": "<user access token>" }Use read scope for reads, or read and write to post comments. The MCP resolves your project through GET /projects (read scope), then posts with write scope. Your Rollbar user also needs view permission to read history and comment permission to post in that project. Project tokens and ordinary account tokens cannot post comments.
User mode sends every request with the configured user's token, including when per-project tokens are also present. Comment authorship comes from that token; you cannot supply a different author. The backend marks posted comments with via_api: true and handles normal subscriptions and notifications.
Configure exactly one of userToken / ROLLBAR_USER_ACCESS_TOKEN or accountToken / ROLLBAR_ACCOUNT_ACCESS_TOKEN. Configuring both fails at startup, including when one comes from a file and the other from the environment. A file value overrides the environment value for the same token type. apiBase in a file or ROLLBAR_API_BASE in environment-only configuration selects a custom API endpoint.
Use list-projects to find the project name or numeric ID for the tools' project argument. It is optional when your user token can see exactly one enabled project. A token supplied only through the legacy ROLLBAR_ACCESS_TOKEN setting is not inferred to be a user token; set ROLLBAR_USER_ACCESS_TOKEN explicitly for posting.
Configure a single Rollbar Account Access Token to read and update items across projects in that account. Posting comments requires user mode above:
ROLLBAR_ACCOUNT_ACCESS_TOKEN (env var), or
accountToken (a top-level key in .rollbar-mcp.json, alongside projects/token/apiBase)
To create one: in Rollbar, go to your account settings → Account Access Tokens, create a new named, enabled token, and choose read (or read and write, if you plan to use update-item) scope. Copy the full generated secret right away, Rollbar only shows it once, and store it securely (a secrets manager or your shell's env config, not committed to source control).
{
"accountToken": "acct_tok_abc123"
}If you want tighter controls on some projects, give the account token read scope so you can read every project, then explicitly list the few projects that need update-item with their own read+write project tokens. Those override the account token for that project only, per the precedence rule below (explicit project token always wins).
{
"accountToken": "acct_tok_abc123",
"projects": [
{ "name": "backend", "token": "tok_backend_readwrite" }
]
}Project-token configs are completely unchanged by this feature: if you don't set an account token, nothing about existing single- or multi-project setups behaves any differently. The two modes can also coexist: if a project name matches an explicitly configured project that has its own token, that project's own token is always used for that project, even when an account token is also present.
Single Project: Environment variable
ROLLBAR_ACCESS_TOKEN: access token for your Rollbar project.
ROLLBAR_API_BASE (optional): override the API base URL (defaults to https://api.rollbar.com/api/1).
Multiple Project: Config file
Create .rollbar-mcp.json in your working directory or home directory, or set ROLLBAR_CONFIG_FILE to point to a custom path. A checked-in template is available at rollbar-mcp-example.json; copy it to .rollbar-mcp.json and fill in your real tokens.
Single project shorthand:
{ "token": "tok_abc123" }Multiple projects:
{
"projects": [
{ "name": "backend", "token": "tok_abc123" },
{ "name": "frontend", "token": "tok_xyz789" }
]
}Config file lookup order:
ROLLBAR_CONFIG_FILE env var
.rollbar-mcp.json in current working directory
~/.rollbar-mcp.json in home directory
ROLLBAR_ACCESS_TOKEN, ROLLBAR_ACCOUNT_ACCESS_TOKEN, or ROLLBAR_USER_ACCESS_TOKEN env var
If a config file exists but is invalid, the server exits with an error instead of falling back to a lower-priority config source.
Required scopes:
Read-only tools (get-item-details, get-deployments, get-version, get-top-items, list-items, get-replay, list-projects, list-occurrences, list-item-events) work with a read-scope account or user token, subject to project permissions.
update-item requires an account token with both read and write scope: every account-token call resolves the target project via GET /projects first (read), then makes the PATCH request (write). A write-only token will fail at the project-resolution step before ever reaching the update.
As with project tokens, prefer a read-scope token unless you specifically need update-item.
post-item-comment requires a user token with read and write scope and project comment permission.
If the server detects only ROLLBAR_ACCESS_TOKEN is set (no explicit account token), it makes a one-time, cached check against GET /projects to see whether that token is actually an account token; if so, account mode activates automatically. A single project-scoped token continues to work exactly as before.
list-projects(): See which Rollbar projects this server can talk to. If you're using a single project token, this just confirms the one project you've configured. If you're using an account token that can reach multiple projects, this is how you find the project name or id to pass into the other tools' project parameter.
get-item-details(counter, max_tokens?, project?): Get the full picture on a single Rollbar item: its details plus its most recent occurrence, so you don't have to look up the item and then separately fetch the latest error. Give it the item's counter (the number you see in the Rollbar UI).
max_tokens (default 20000) caps how large the occurrence data in the response can get. Some occurrences carry a lot of detail (long stack traces, request data), so this keeps a single item lookup from ballooning the response. Optional project selects which project to use, by configured name or by real project name/id in account-token mode. Example prompt: Diagnose the root cause of Rollbar item #123456
get-deployments(limit, project?): List recent deploys for a project, so you can line up when a deploy went out against when errors started or stopped happening. Optional project when multiple projects are configured or in account-token mode. Example prompt: List the last 5 deployments or Are there any failed deployments?
get-version(version, environment, project?): Look up how a specific version (like a git SHA) has performed in an environment, including when it first and last showed up in occurrences. Useful for checking whether a particular release introduced or fixed an issue. Optional project when multiple projects are configured or in account-token mode.
get-top-items(environment, project?): See what's actually breaking right now. Returns the items with the most occurrences in the last 24 hours for the given environment, so you can triage what to look at first instead of scanning the full item list. Optional project when multiple projects are configured or in account-token mode.
list-items(status?, level?, environment?, page?, limit?, query?, project?): Search and filter Rollbar items instead of pulling the whole list. Filter by status (default active, so resolved and muted items stay out of your way), level, and environment, or search by query text. Use page and limit to control how much comes back at once. Optional project when multiple projects are configured or in account-token mode.
list-occurrences(counter, limit?, page?, last_id?, max_tokens?, project?): Look up the actual occurrences behind a Rollbar item, not just the item summary. Give it the item's counter and it returns the individual instances, each with its own timestamp, environment, and error detail.
Use limit to control how many occurrences come back (default 3, max 100), and page or last_id to move through more of them. last_id is cursor-based pagination: pass the id of the last occurrence you got back, and you'll get the next batch after it. We added this because plain page numbers can skip or repeat results if occurrences shift around between calls, and last_id doesn't have that problem, so use it when you're paging through a lot of occurrences. If you pass both, last_id wins. Occurrences within a page are always ordered by timestamp (newest first), so the last one you see is reliably the right one to hand back as last_id.
Occurrence data can get big fast, especially for errors with large stack traces or request payloads. max_tokens (default 20000, minimum 100) caps roughly how large the whole response can get, in about max_tokens * 4 characters. We built this because without a cap, a handful of occurrences could blow way past what fits in a conversation. Every occurrence you asked for still shows up in the response, though. Instead of dropping any of them to stay under budget, the tool shrinks the biggest ones down step by step, keeping the most useful fields (level, environment, exception message, and similar) for as long as it can before falling back to just an id and timestamp. A top-level _truncation field tells you when this happened. If your limit and max_tokens genuinely can't fit even a minimal version of every occurrence, you'll get a clear error telling you to lower limit or raise max_tokens, instead of a silently incomplete page.
Some Rollbar items are actually groups of several items bundled together. Rollbar's public API can't correctly list occurrences for these yet, so calling this tool on a group item returns an explicit group_item_not_supported message saying so, instead of quietly showing you an empty list that looks like the item has no occurrences at all.
Optional project when multiple projects are configured. Example prompt: Show me the last 3 occurrences of item #24265
list-item-events(item_id?, counter?, type?, page?, limit?, project?): Read item history, including system events, oldest first. Provide exactly one of the global item_id or the project-local counter shown in Rollbar. page defaults to 1; limit defaults to 20 and accepts 1–5000. The result is { events, page, total_count }, where the count reflects the filters. Empty pages are valid. Pages and event details are returned intact; lower limit for smaller responses.
Set type to an array of any of these values, or omit it for all available types:
Type | Additional event fields |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All events include id, type, item_id, user_id, username, and timestamp; author fields may be null. Ordering is by timestamp, then type, then ID, ascending. Different event types can have the same ID; identify an event by (type, id). Resolve notes appear in item_status_history.comment, so include that type when looking for resolution context. The history endpoint has no cursor, date, text, or author filter. Snooze history is omitted when unavailable for the account; explicitly requesting it then returns a permission error.
Example list-item-events arguments:
{ "project": "Backend", "counter": 42, "type": ["item_comment", "item_status_history"], "page": 1, "limit": 20 }post-item-comment(item_id?, counter?, comment, project?): Add a comment using the connected user's identity. Provide exactly one item identifier and nonblank comment text. It returns the created comment with id, type: "comment", source: "comment", item_id, user_id, username, timestamp, text, and via_api: true. Read it back with list-item-events filtered to item_comment.
{ "project": "Backend", "counter": 42, "comment": "Investigated the regression; the fix is in PR #123." }The backend caps the full serialized stored comment data at 65,535 bytes, including author metadata and JSON escaping. This is not a character limit or a text-only byte limit. The MCP sends the text unchanged and reports a backend size error instead of truncating it. It does not retry failed posts: an uncertain result may already have created the comment. Inspect history before retrying.
Both tools preserve backend errors. Common failures are invalid arguments (400/422), authentication (401), scope/project permissions or unavailable snooze history (403), an item outside the selected project or not found (404), and comment size (413). Posting requires JSON (415); the tool supplies that content type. The server rejects posting without configured user credentials before making any HTTP call.
get-replay(environment, sessionId, replayId, delivery?, project?): Fetch a session replay's metadata and payload for a specific session, so you can see what a user actually did leading up to an error.
By default (delivery="file"), the replay JSON is written to a temp file on disk and the tool returns the file path. This works everywhere, but the file sticks around until you clean it up yourself. Set delivery="resource" instead to get back a rollbar:// link that MCP-aware clients can read directly, with no file left behind, but this only works when the server only ever talks to a single project (either single-project-token mode, or account-token mode with exactly one project). If you're set up for multiple projects, stick with delivery="file" and pass project explicitly.
Optional project when multiple projects are configured or in account-token mode. Example prompt: Fetch the replay 789 from session abc in staging.
update-item(itemId, status?, level?, title?, assignedUserId?, resolvedInVersion?, snoozed?, teamId?, project?): Change an item's status, level, title, assignee, resolved version, snooze state, or owning team, so you can act on an item directly instead of switching to the Rollbar UI.
This needs write access: a project token with write scope, or an account/user token with both read and write scope, subject to the user's permissions. A read-only token will fail here. Optional project when multiple projects are configured or in account-token mode. Example prompt: Mark Rollbar item #123456 as resolved or Assign item #123456 to user ID 789.
Configure your .mcp.json as follows.
Using an environment variable (single project):
{
"mcpServers": {
"rollbar": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@rollbar/mcp-server@latest"],
"env": {
"ROLLBAR_ACCESS_TOKEN": "<project read/write access token>"
}
}
}
}Optionally include ROLLBAR_API_BASE in the env block to target a non-production API endpoint.
Using an account access token (every project on the account, no per-project tokens needed):
{
"mcpServers": {
"rollbar": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@rollbar/mcp-server@latest"],
"env": {
"ROLLBAR_ACCOUNT_ACCESS_TOKEN": "<account access token>"
}
}
}
}Using a config file (single or multiple projects):
{
"mcpServers": {
"rollbar": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@rollbar/mcp-server@latest"],
"env": {
"ROLLBAR_CONFIG_FILE": "/path/to/.rollbar-mcp.json"
}
}
}
}Add to your ~/.codex/config.toml:
[mcp_servers.rollbar]
command = "npx"
args = ["-y", "@rollbar/mcp-server@latest"]
env = { "ROLLBAR_ACCESS_TOKEN" = "<project read/write access token>" }Or with a config file:
[mcp_servers.rollbar]
command = "npx"
args = ["-y", "@rollbar/mcp-server@latest"]
env = { "ROLLBAR_CONFIG_FILE" = "/path/to/.rollbar-mcp.json" }Configure your .junie/mcp/mcp.json as follows (env var or ROLLBAR_CONFIG_FILE for config file):
{
"mcpServers": {
"rollbar": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@rollbar/mcp-server@latest"],
"env": {
"ROLLBAR_ACCESS_TOKEN": "<project read/write access token>"
}
}
}
}Configure Cursor’s MCP servers (Cursor Settings → Features → MCP, or search for “MCP” in settings). Use either an environment variable or a config file.
With an environment variable (single project):
{
"mcpServers": {
"rollbar": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@rollbar/mcp-server@latest"],
"env": {
"ROLLBAR_ACCESS_TOKEN": "<project read/write access token>"
}
}
}
}With a config file (single or multiple projects):
{
"mcpServers": {
"rollbar": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@rollbar/mcp-server@latest"],
"env": {
"ROLLBAR_CONFIG_FILE": "/path/to/.rollbar-mcp.json"
}
}
}
}Restart Cursor (or reload the window) after changing MCP settings. To use a local build instead of npx, see CONTRIBUTING.md.
Configure your .vscode/mcp.json as follows (env var or ROLLBAR_CONFIG_FILE for config file):
{
"servers": {
"rollbar": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@rollbar/mcp-server@latest"],
"env": {
"ROLLBAR_ACCESS_TOKEN": "<project read/write access token>"
}
}
}
}Or using a local development installation, see CONTRIBUTING.md.
This is the same file GitHub Copilot's agent mode reads in VS Code. Put it in .vscode/mcp.json to share the server with everyone on the repo, or in your user-profile mcp.json (Command Palette → MCP: Open User Configuration) to keep your token out of the repository. After saving, start the server with MCP: List Servers → rollbar → Start, then pick the tools via the 🛠️ icon in the Copilot Chat agent-mode toolbar.
Add to ~/.copilot/mcp-config.json. Note that Copilot CLI uses mcpServers (not VS Code's servers) and spells the stdio transport as "type": "local":
{
"mcpServers": {
"rollbar": {
"type": "local",
"command": "npx",
"args": ["-y", "@rollbar/mcp-server@latest"],
"env": {
"ROLLBAR_ACCESS_TOKEN": "<project read/write access token>"
},
"tools": ["*"]
}
}
}Or with a config file, swap the env block for ROLLBAR_CONFIG_FILE:
{
"mcpServers": {
"rollbar": {
"type": "local",
"command": "npx",
"args": ["-y", "@rollbar/mcp-server@latest"],
"env": {
"ROLLBAR_CONFIG_FILE": "/path/to/.rollbar-mcp.json"
},
"tools": ["*"]
}
}
}tools: ["*"] enables every Rollbar tool; narrow it to specific tool names if you'd rather opt in explicitly. To scope the server to one repository instead of your whole account, put the same JSON in .mcp.json or .github/mcp.json at the repo root — Copilot CLI loads project-level config only after you confirm folder trust on first launch, and project definitions take precedence over ~/.copilot/mcp-config.json.
Run /mcp inside an interactive session (or copilot mcp list from your shell) to confirm the server is connected.
Get deployments data from Rollbar
| Name | Required | Description | Default |
|---|---|---|---|
| limit | Yes | Number of Rollbar deployments to retrieve | |
| project | No | Project name (optional when only one project is configured) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'Get' but does not explicitly confirm safety, mention pagination behavior despite the limit parameter, describe the return format, or note any rate limits or auth requirements.
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, efficient sentence with no redundancy or filler. However, it is arguably too minimal, lacking the additional sentences needed to address behavioral transparency or usage guidelines.
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?
Given the presence of numerous sibling tools dealing with different Rollbar entities (items, projects, versions), the description fails to clarify what deployments are or how they relate to these other resources. With no output schema and no annotations, this minimal description leaves significant gaps in contextual understanding.
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%, with limit and project adequately documented in the schema. The description adds no parameter-specific context, but this is acceptable given the complete schema coverage establishes the baseline of 3.
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 clearly states the verb (Get) and resource (deployments data) and identifies the external system (Rollbar). However, it fails to differentiate from siblings like get-version or list-items, leaving ambiguity about what constitutes a 'deployment' versus other Rollbar entities.
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 guidance provided on when to use this tool versus alternatives like get-version or list-projects. The optional 'project' parameter lacks usage guidance (e.g., when to omit it), and there are no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get item details for a Rollbar item
| Name | Required | Description | Default |
|---|---|---|---|
| counter | Yes | Rollbar item counter | |
| project | No | Project name (optional when only one project is configured) | |
| max_tokens | No | Maximum tokens for occurrence data in response (default: 20000). Occurrence response will be truncated if it exceeds this limit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden, yet discloses no behavioral traits. Fails to explain the truncation behavior mentioned in the max_tokens schema description, what 'occurrence data' means, or the structure/format of returned item details. The verb 'Get' implies read-only, but safety profiles and return schemas remain undocumented.
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?
While brief (single sentence), this represents under-specification rather than effective conciseness. The sentence wastes the opportunity to add value beyond the tool name, failing to front-load critical distinctions or behavioral warnings that an agent would need to select this tool correctly.
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?
Given no output schema and no annotations, the description must explain what details are returned and how they relate to Rollbar's data model (items vs occurrences). It omits this entirely. For a 3-parameter retrieval tool with 100% schema coverage, the description inadequately compensates for missing structured metadata about return values.
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%, establishing baseline 3. The description adds no parameter context beyond the schema (e.g., doesn't explain that 'counter' is a unique identifier, or clarify the project auto-detection behavior). However, schema adequately documents all three parameters including the optional nature of 'project' and truncation logic for 'max_tokens'.
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 'Get item details for a Rollbar item' essentially restates the tool name (tautology) with the addition of the domain 'Rollbar'. It fails to specify what constitutes 'item details' (e.g., error metadata, stack traces, occurrences) or how this differs from siblings like list-items or update-item.
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 guidance provided on when to use this tool versus alternatives. Critical distinction missing between this single-item retrieval and list-items (presumably for multiple items), or when project parameter is required versus optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get replay data for a specific session replay in Rollbar
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name (optional when only one project is configured) | |
| delivery | No | How to return the replay payload. Defaults to 'file' (writes JSON to a temp file); 'resource' returns a rollbar:// link. | |
| replayId | Yes | Replay identifier to retrieve | |
| sessionId | Yes | Session identifier that owns the replay | |
| environment | Yes | Environment name (e.g., production) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the read operation without disclosing behavioral traits. It omits crucial details about the delivery modes (file vs resource), payload size limits, or what format the replay data takes.
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 single 9-word sentence is efficiently structured and front-loaded with the action verb. However, given the absence of annotations and output schema, the extreme brevity leaves critical behavioral context undocumented.
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 has 5 parameters with complex delivery options and no output schema or annotations. The description fails to compensate by explaining return values, payload structure, or behavioral differences between 'file' and 'resource' delivery modes, leaving significant gaps.
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?
Input schema has 100% description coverage, documenting all 5 parameters including the enum values for 'delivery'. The description implies required identifiers ('specific session replay') but adds no semantic meaning beyond what the schema already provides, warranting the baseline score.
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 clear verb ('Get'), target resource ('replay data'), and scope ('specific session replay in Rollbar'). It distinguishes from siblings like list-items or get-deployments by specifying 'replay' context, though it could clarify relationship to get-item-details.
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 implies usage context ('for a specific session replay') but provides no explicit when-to-use guidance, prerequisites for the identifiers, or comparison to sibling tools like get-item-details that might overlap in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of top items in the Rollbar project
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name (optional when only one project is configured) | |
| environment | No | Environment name (default: production) | production |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to explain what criteria define 'top' items, whether results are paginated, rate limits, or the structure of returned data. The description only implies a read-only operation through the verb 'Get' but provides no substantive behavioral context.
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 sentence and appropriately front-loaded. However, it prioritizes brevity over clarity—while not verbose, it wastes the single sentence on vague terminology ('top items') rather than precise functional description.
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?
Lacking annotations and output schema, the description should explain the return format and sorting logic. It fails to clarify the critical distinction between 'top items' and regular item listing, and omits operational details like default result limits or time ranges, leaving significant gaps for a 2-parameter tool.
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%, with both 'environment' and 'project' parameters fully documented in the schema. The description adds no parameter-specific guidance, but the baseline score of 3 is appropriate given the schema already carries the semantic load.
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 the basic action ('Get list') and resource ('top items'), but fails to define what 'top' means (frequency? severity? impact?). Given the sibling tool 'list-items', this ambiguity prevents the agent from selecting the correct tool. It restates the tool name with slightly more detail but lacks specificity.
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 guidance provided on when to use this versus the sibling 'list-items' tool, or when the optional 'project' parameter is required. The description lacks any 'when-to-use' or 'when-not-to-use' instructions, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get version details for a Rollbar project
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name (optional when only one project is configured) | |
| version | No | Version string (e.g. git sha) | |
| environment | No | Environment name (default: production) | production |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to indicate whether this is a safe read operation, what happens if the version is not found, rate limits, or what specific details are returned. The phrase 'Get version details' implies data retrieval but lacks explicit safety or behavioral context.
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 single sentence wastes no words and immediately states the core function. However, given the lack of annotations and output schema, the description is arguably under-sized for the tool's complexity, though the sentence itself is efficiently constructed.
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 tool with three simple string parameters and full schema coverage, the description is minimally adequate. However, with no output schema provided, the description should ideally characterize the returned version details (e.g., deployment metadata, commit info). The absence of this information leaves a gap in contextual completeness.
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?
With 100% schema description coverage, the baseline score is 3. The description adds no additional parameter context (e.g., valid formats for version strings, environment constraints), but the schema adequately documents all three parameters including the optional nature of 'project' and default for 'environment'.
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 clear verb ('Get') and identifies the resource ('version details for a Rollbar project'). However, it does not distinguish from the sibling tool 'get-deployments' or clarify what constitutes a 'version' in the Rollbar context (e.g., code deployment vs. API version).
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 no guidance on when to use this tool versus alternatives like 'get-deployments', nor does it mention prerequisites such as project configuration requirements. Zero guidance on selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List an item's history, oldest first, including system events. Requires read scope and project view permission. Omit type for all available event types. Resolve notes are in item_status_history.comment, not item_comment. This lists history, not error occurrences.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | One-based page number (default 1). No cursor pagination. | |
| type | No | Filter to these event types. Snooze history requires the account's snooze feature. | |
| limit | No | Events per page (default 20, max 5000). Lower this for smaller responses; events are never dropped or truncated. | |
| counter | No | Project-local item counter shown in Rollbar. Provide exactly one of counter or item_id. | |
| item_id | No | Global Rollbar item ID. Provide exactly one of item_id or counter. | |
| project | No | Project name (optional when only one project is configured) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true; the description adds meaningful behavior beyond that — required scopes/permissions, the fact that resolve notes live in item_status_history.comment rather than item_comment, and the boundary that this returns history not errors. It does not discuss pagination behavior in prose, though the schema covers pages.
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?
Four tight sentences with the core action front-loaded, followed by permission, filtering, field-mapping, and disambiguation notes. Every sentence carries a distinct, non-redundant fact; nothing repeats the schema or annotations.
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, the description compensates by naming ordering and where resolve notes appear in the result, and it covers auth prerequisites and the error-vs-history boundary. It is complete enough to call correctly, though it does not describe the overall response structure for a history listing.
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%, so the baseline would be 3, but the description adds semantics the schema does not: omitting 'type' means all event types, and the mapping of resolve notes to item_status_history.comment clarifies how to interpret the type enum. This is genuine interpretive value for the type parameter.
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 ('List an item's history'), plus ordering ('oldest first') and scope ('including system events'). It also actively distinguishes itself from a sibling concern with 'This lists history, not error occurrences', so an agent can separate it from list-occurrences.
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 concrete usage conditions: omit 'type' to get all event types, and it is explicitly not for error occurrences. It states prerequisites (read scope, project view permission). It does not name a specific alternative tool to use for error lists, so it stops short of full when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all items in the Rollbar project with optional search and filtering
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1) | |
| level | No | Filter by severity levels (e.g., ['error', 'critical', 'warning']) | |
| limit | No | Number of items per page (default: 20, max: 5000) | |
| query | No | Search query to filter items by title or content | |
| status | No | Filter by item status (e.g., 'active', 'resolved', 'muted') (default: 'active') | active |
| project | No | Project name (optional when only one project is configured) | |
| environment | No | Filter by environment (e.g., 'production', 'staging') (default: 'production') | production |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden but fails to explain key behaviors: it does not clarify what 'items' represent (errors/exceptions), describe the pagination model (despite page/limit parameters), mention rate limits, or explain the default 'production' environment behavior.
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?
While the single sentence is efficiently structured and front-loaded, it is inappropriately brief given the lack of annotations and output schema. The description fails to compensate for missing structured metadata with necessary explanatory context, making it under-specified rather than optimally concise.
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?
Given seven parameters, zero annotations, and no output schema, the description is insufficiently complete. It omits explanation of the pagination behavior, the nature of Rollbar 'items', how results are ordered, and guidance on the project parameter's conditional requirement.
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 input schema has 100% description coverage, so the description does not need to replicate parameter details. The phrase 'optional search and filtering' broadly acknowledges the filtering capabilities, but adds no specific semantic value beyond what the schema already provides, warranting the baseline score.
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 clearly states the verb (List) and resource (items in the Rollbar project), and mentions 'optional search and filtering' which hints at the tool's capabilities. However, it does not explicitly differentiate this from sibling tools like get-top-items or get-item-details, though the 'all items' phrasing implies comprehensiveness versus 'top'.
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 guidance is provided on when to use this tool versus alternatives like get-item-details (for specific items) or get-top-items (for trending issues). The description lacks prerequisites, such as when the 'project' parameter is required versus optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List occurrences (instances) for a Rollbar item by counter
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (default: 1) | |
| limit | No | Number of occurrences to return (default: 3, max: 100) | |
| counter | Yes | Rollbar item counter | |
| last_id | No | id of the last occurrence from a previous page, for cursor-based pagination. Takes precedence over page when both are provided. | |
| project | No | Project name (optional when only one project is configured) | |
| max_tokens | No | Target budget for the complete response, in tokens (default: 20000, minimum: 100; approx. max_tokens*4 characters). Every occurrence selected by the backend for this page is always represented, in backend order — never dropped. Each occurrence is rendered at one of four tiers depending on available budget: "full" (complete/lightly-truncated occurrence), "compact" (small diagnostic summary: level, environment, framework, language, platform, context, code_version, version, exception class/message), "id_timestamp" (id + timestamp only), or "id_only" (id only). The allocator fills the budget by upgrading occurrences tier-by-tier rather than splitting it evenly up front, so several occurrences can retain real diagnostic detail instead of all being collapsed to bare stubs. The response includes a top-level "_truncation" field describing what happened when any occurrence is below "full". The final response is bounded at max_tokens*4 characters plus a small, fixed overhead margin — never a hard byte-exact cap, but drops are never used to enforce it. If even the id_only representation cannot fit every occurrence in "limit", the call fails with an actionable error asking you to lower limit or raise max_tokens, rather than returning a silently partial page. |
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, yet it discloses nothing about pagination behavior, the last_id precedence rule, budget/tiering of results, or failure modes. For a tool with this much non-obvious behavior, the single-sentence description is a significant gap.
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?
A single, efficient, front-loaded sentence with zero filler. It is concise, though its brevity veers into under-specification for a tool with this much complexity.
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 has sophisticated pagination and token-budget tiering and no output schema, so the description should explain the return shape and selection behavior. It does none of this, leaving an agent unable to anticipate the tiered results or the budget-failure error without reading the schema.
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 the schema already documents all six parameters thoroughly; baseline is 3. The description only alludes to 'counter', adding nothing beyond what the schema provides.
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 occurrences (instances) for a Rollbar item') and clarifies the ambiguous term 'occurrences' with '(instances)'. However, it does not explicitly differentiate itself from siblings like get-item-details or list-items, leaving the agent to infer the boundary.
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 is a pure purpose statement with no when-to-use guidance, no prerequisites, and no named alternatives. Nothing tells the agent when to prefer this over get-item-details or get-replay.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured Rollbar projects available to this MCP server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but discloses minimal behavioral traits. While 'configured' and 'available to this MCP server' hints at access scope, it fails to clarify read-only safety, pagination behavior, error cases, or the return structure.
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, efficient sentence of nine words with no redundancy. It leads with the action verb and immediately identifies the resource, placing critical information first.
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 discovery tool, the description adequately identifies what is returned (projects), but lacks explanation of how the results relate to sibling operations or what 'configured' implies for the integration setup. No output schema exists to compensate.
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, establishing a baseline of 4 per the scoring rubric. The input schema is trivially complete with no additional semantic context required from the 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?
The description clearly states the verb (List) and resource (configured Rollbar projects) with scope limitation ('available to this MCP server'). It implicitly distinguishes from the sibling 'list-items' by targeting 'projects' rather than 'items', though explicit contrast would strengthen this.
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 no guidance on when to use this tool versus alternatives, nor does it mention that this is a prerequisite discovery tool likely needed before calling project-specific siblings like 'list-items' or 'get-deployments'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a comment as the connected Rollbar user. Requires a configured user token with read and write scope and project comment permission. May notify subscribers. The backend limits the full stored comment data to 65,535 bytes. Do not automatically retry an uncertain result: this operation is not idempotent.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | Yes | Comment text. Author identity is taken from the connected user's token. | |
| counter | No | Project-local item counter shown in Rollbar. Provide exactly one of counter or item_id. | |
| item_id | No | Global Rollbar item ID. Provide exactly one of item_id or counter. | |
| project | No | Project name (optional when only one project is configured) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses auth/scope requirements, the side effect that subscribers may be notified, the 65,535-byte backend storage limit, and actionable retry guidance ('Do not automatically retry an uncertain result: this operation is not idempotent'). The retry advice operationalizes the idempotentHint=false annotation into concrete agent behavior rather than merely restating it.
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?
Four tight sentences, front-loaded with the action, then prerequisites, side effects, limits, and the retry caveat in descending priority. Every sentence carries distinct information and none is 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?
For a non-idempotent mutation with no output schema, the description covers everything an agent needs to call it safely: identity source, permission requirements, notification side effect, size ceiling, and retry policy. Annotations plus this text leave no material behavioral 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 description coverage is 100%, so the schema already documents every parameter, including the counter-vs-item_id mutual exclusivity and the author-identity note. The description adds no additional parameter-level detail, so the baseline 3 is appropriate.
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: 'Post a comment as the connected Rollbar user.' The action and the actor identity are unambiguous, and it is clearly distinct from the read-oriented siblings (get-item-details, list-items, etc.). It stops short of explicitly naming a sibling alternative, but the operation is self-evidently unique in the set.
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?
It gives real prerequisites — a configured user token with read and write scope and project comment permission — which tell the agent when the call can succeed. However, it names no alternatives and gives no when-not-to-use guidance (e.g. when to prefer update-item or how to locate the target item first), leaving usage context largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an item in Rollbar (status, level, title, assignment, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | The new level for the item | |
| title | No | The new title for the item | |
| itemId | Yes | The ID of the item to update | |
| status | No | The new status for the item | |
| teamId | No | The ID of the team to assign as owner (Advanced/Enterprise accounts only) | |
| project | No | Project name (optional when only one project is configured) | |
| snoozed | No | Whether the item should be snoozed (paid accounts only) | |
| assignedUserId | No | The ID of the user to assign the item to | |
| resolvedInVersion | No | The version in which the item was resolved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description fails to disclose mutation safety, idempotency, or return values. Critically omits account-tier restrictions visible in schema (paid/Enterprise-only features for 'snoozed' and 'teamId').
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?
Single sentence, front-loaded with action. Efficient though 'etc.' is vague given specific account restrictions exist in schema. Appropriate length for overview but misses opportunity to highlight critical constraints.
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?
Inadequate for a 9-parameter mutation tool with no output schema. Fails to address success/failure behavior, required permissions, or the fact that some parameters require paid/Enterprise accounts despite these being documented in the schema parameters.
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?
With 100% schema description coverage, baseline is 3. Description provides high-level categorization ('assignment' covering both user and team assignment) but adds no semantic depth beyond schema (e.g., explaining status lifecycle or snooze behavior).
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?
Clear verb ('Update') and resource ('item in Rollbar') with parenthetical examples of updatable fields. Distinguishes from sibling get/list tools by operation type, though could clarify distinction from get-item-details.
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?
Lists mutable attributes (status, level, title, assignment) but provides no guidance on when to use versus read-only alternatives or prerequisites like item existence. No mention of partial vs full update semantics.
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.7.0list-item-eventspost-item-commentv0.6.1list-occurrencesv0.5.0get-deploymentsget-item-detailsget-replayget-top-itemsget-versionlist-itemslist-projectsupdate-itemScored across 11 tools
Most tools are clearly distinct (list-item-events vs list-occurrences well-differentiated; get-top-items vs list-items differentiated by ranking/existence). However, get-item-details and list-items could be slightly confused, and get-deployments/get-version are distinct enough.
Mixed conventions: some use hyphens (list-item-events) while others use underscores (update-item, get_deployments—wait, all appear hyphenated in the given list except 'get-top-items' etc. Actually all use hyphens but structure varies: 'list-item-events' vs 'list_items' is not present; the inconsistency is verb_noun vs noun_verb and some use 'item' while others omit. For example: list-item-events, post-item-comment, get-item-details, get-deployments, get-version, get-top-items, list-items, update-item, get-replay, list-projects, list-occurrences. Mostly verb_noun but with inconsistent hyphenation and some use 'item' as a separate token. Still readable.
11 tools is a reasonable count for a Rollbar MCP server, covering key operations. Slightly heavy but each tool addresses a distinct need (items, occurrences, comments, events, deployments, versions, replays, projects).
Covers item lifecycle (list, get details, update, list occurrences, list events, post comment), deployments, versions, top items, replays, projects. Missing explicit create item (but Rollbar items are created by errors, not API) and delete item may be unnecessary. Minor gaps like no bulk update or item creation, but core workflows covered.
Manage uptime monitors and incidents and search logs, metrics and traces from an AI assistant.
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Query your Logspot analytics, companies, and revenue from any AI assistant, and run your actions.
Deploy apps from GitHub, read build/runtime logs, and manage your app's users from your AI agent.
