Which integrations are available for this server?

Provides tools to set up Bugfender SDK for Android applications, including retrieving platform-specific SDK snippets for onboarding. Provides tools to set up Bugfender SDK for Angular applications, including retrieving platform-specific SDK snippets for onboarding. Provides tools to set up Bugfender SDK for Flutter applications, including retrieving platform-specific SDK snippets for onboarding. Provides tools to set up Bugfender SDK for Ionic applications, including retrieving platform-specific SDK snippets for onboarding. Provides tools to set up Bugfender SDK for iOS applications, including retrieving platform-specific SDK snippets for onboarding. Provides tools to set up Bugfender SDK for JavaScript applications, including retrieving platform-specific SDK snippets for onboarding. Provides tools to set up Bugfender SDK for jQuery applications, including retrieving platform-specific SDK snippets for onboarding. Provides tools to set up Bugfender SDK for .NET applications (including .NET MAUI), including retrieving platform-specific SDK snippets for onboarding. Provides tools to set up Bugfender SDK for React applications, including retrieving platform-specific SDK snippets for onboarding. Provides tools to set up Bugfender SDK for Unity applications, including retrieving platform-specific SDK snippets for onboarding.

How do I use bugfender-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bugfender-mcp list my apps" 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.

bugfender-mcp

Official

by bugfender

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Bugfender MCP

Bugfender's hosted MCP service connects AI clients to Bugfender through remote Streamable HTTP and OAuth:

https://mcp.bugfender.com/mcp

The @bugfender/mcp npm package remains available as a deprecated local stdio fallback for existing and self-hosted installations.

What It Provides

user-scoped Bugfender read access through MCP
automatic access-token refresh when a refresh token is configured
logs, devices, app metadata, crash aggregation, and issue aggregation tools
SDK snippet retrieval for app onboarding
resource templates for snippets, logs, and issue groups
companion Bugfender skills distributed from bugfender/bugfender-skills

Related MCP server: bugsink-mcp

Maintainers

development workflow: DEVELOPMENT.md
release and publish flow: RELEASING.md

Recommended: hosted OAuth

In ChatGPT or Codex, install the public Bugfender plugin and connect the included Bugfender app. In any compatible remote MCP client, add https://mcp.bugfender.com/mcp and choose OAuth authentication.

The client discovers the protected resource and Bugfender authorization server, opens the Bugfender sign-in and consent UI, and manages short-lived access and refresh tokens. Hosted users must not manually copy an API token into the connection.

OAuth scopes

mcp:read grants read-only access to identity, teams, apps, SDK metadata, logs, devices, crashes, issues, feedback, network data, and summaries the signed-in user can already access.
mcp:issues:write grants only update_issue_status. It does not grant general Bugfender administration or other write operations.

Disconnect and revoke

Use the client's Bugfender Disconnect action to revoke the hosted grant and its access and refresh tokens. If a client lists the plugin and connection separately, disconnect the connection before uninstalling the plugin. A future tool call must start a new OAuth flow.

Privacy

The hosted MCP forwards the request bearer token to the Bugfender API and returns data the signed-in user is authorized to access. It does not persist user credentials or expose them in tool results. The MCP client and AI provider may separately process tool inputs and return Bugfender data under their own privacy and retention terms. See Bugfender's Privacy Policy and Terms of Service.

Deprecated: local stdio package

Existing installations and clients without remote OAuth can continue to run:

npx -y @bugfender/mcp

Do not use this setup for a new public-cloud connection. Prefer the hosted URL or public plugin instead.

After adding or updating the MCP server in your IDE or agent, restart that client so it reloads the new MCP configuration cleanly.

If you are running from inside this repository checkout, do not use npx @bugfender/mcp or npx -p @bugfender/mcp bugfender-mcp. npm can resolve the current package instead of the published tarball and fail with bugfender-mcp: not found.

For local development, build and run the generated entrypoint directly:

pnpm build
pnpm start

Local stdio configuration

BUGFENDER_API_TOKEN: required access token
BUGFENDER_REFRESH_TOKEN: recommended for automatic token refresh
BUGFENDER_API_URL: optional override, defaults to https://dashboard.bugfender.com/api
~/.bugfender/mcp.json: optional config file and local token store for rotated credentials

{
  "default": {
    "apiToken": "YOUR_ACCESS_TOKEN",
    "refreshToken": "YOUR_REFRESH_TOKEN",
    "apiUrl": "https://dashboard.bugfender.com/api"
  }
}

When a refresh token is provided, the MCP stores rotated credentials in ~/.bugfender/mcp.json so automatic refresh survives restarts. Updating the IDE config with a newly generated refresh token resets that local state.

These credentials and the local token store apply only to the stdio executable. The hosted HTTP executable reads a bearer token from each request and never reads or writes ~/.bugfender/mcp.json.

If you are using local or self-hosted Bugfender credentials, BUGFENDER_API_URL must point to the matching backend. For example, local credentials generated from https://dashboard:3000 will not work against https://dashboard.bugfender.com/api.

Legacy Cursor / Claude Code configuration

{
  "mcpServers": {
    "bugfender": {
      "command": "npx",
      "args": ["-y", "@bugfender/mcp"],
      "env": {
        "BUGFENDER_API_TOKEN": "YOUR_ACCESS_TOKEN",
        "BUGFENDER_REFRESH_TOKEN": "YOUR_REFRESH_TOKEN",
        "BUGFENDER_API_URL": "https://dashboard.bugfender.com/api"
      }
    }
  }
}

Legacy Codex CLI configuration

codex mcp add bugfender \
  --env BUGFENDER_API_TOKEN='YOUR_ACCESS_TOKEN' \
  --env BUGFENDER_REFRESH_TOKEN='YOUR_REFRESH_TOKEN' \
  --env BUGFENDER_API_URL='https://dashboard.bugfender.com/api' \
  -- npx -y @bugfender/mcp

After running codex mcp add, restart the Codex session before testing who_am_i or list_apps.

Legacy Gemini CLI configuration

gemini mcp add bugfender npx -y @bugfender/mcp \
  --env BUGFENDER_API_TOKEN='YOUR_ACCESS_TOKEN' \
  --env BUGFENDER_REFRESH_TOKEN='YOUR_REFRESH_TOKEN' \
  --env BUGFENDER_API_URL='https://dashboard.bugfender.com/api'

After running gemini mcp add, start a new Gemini CLI session or reload MCP servers before testing who_am_i or list_apps.

Legacy Codex App configuration

In the custom MCP server form:

Name: bugfender
Command to launch: npx
Argument 1: -y
Argument 2: @bugfender/mcp
BUGFENDER_API_TOKEN: YOUR_ACCESS_TOKEN
BUGFENDER_REFRESH_TOKEN: YOUR_REFRESH_TOKEN
BUGFENDER_API_URL: https://dashboard.bugfender.com/api

Add the arguments as separate rows, not as one combined string.

After saving the server, restart the app before testing who_am_i or list_apps.

Hosted Streamable HTTP deployment

Build and start the HTTP entry point with:

pnpm build
pnpm start:http

It exposes:

POST /mcp: stateless MCP Streamable HTTP endpoint
GET /healthz: liveness check
GET /readyz: readiness check

TLS is terminated by the production ingress. Every /mcp request must include Authorization: Bearer <token>. The process creates an isolated MCP server and Bugfender API client for that request; the token is neither shared nor persisted.

Hosted configuration:

BUGFENDER_API_URL (default https://dashboard.bugfender.com/api)
BUGFENDER_MCP_HOST (default 0.0.0.0)
BUGFENDER_MCP_PORT (default 3002)
BUGFENDER_MCP_MAX_REQUEST_BYTES (default 1048576)
BUGFENDER_MCP_MAX_RESPONSE_BYTES (default 524288)
BUGFENDER_MCP_MAX_CONCURRENCY (default 100)
BUGFENDER_MCP_REQUEST_TIMEOUT_MS (default 35000)
BUGFENDER_MCP_SHUTDOWN_TIMEOUT_MS (default 10000)

The hosted entry point uses JSON response mode within the Streamable HTTP protocol. It is intentionally stateless, so GET and DELETE on /mcp return 405 Method Not Allowed.

The production container can be built and exercised locally with:

docker build -t bugfender-mcp .
docker run --rm --read-only --tmpfs /tmp:rw,noexec,nosuid,size=16m \
  -p 3002:3002 bugfender-mcp

The image runs as UID/GID 10001, writes structured JSON logs to stderr, and exposes Prometheus metrics on GET /metrics for cluster-internal scraping.

Hosted mode publishes OAuth protected-resource metadata at GET /.well-known/oauth-protected-resource. Authentication challenges point clients to that document. Production defaults to resource https://mcp.bugfender.com, issuer https://app.bugfender.com, and API https://app.bugfender.com/api; staging deployments must override BUGFENDER_MCP_RESOURCE_URL and BUGFENDER_OAUTH_ISSUER and BUGFENDER_API_URL with their staging origins. Documentation, privacy, and terms links can be overridden with BUGFENDER_MCP_DOCUMENTATION_URL, BUGFENDER_MCP_PRIVACY_POLICY_URL, and BUGFENDER_MCP_TERMS_URL.

Hosted authentication troubleshooting

Use the exact endpoint https://mcp.bugfender.com/mcp; the OAuth resource is the origin https://mcp.bugfender.com without /mcp.
Do not configure BUGFENDER_API_TOKEN or paste a bearer token into a remote-hosted connection.
Disconnect and reconnect to recover from expired or revoked grants or to request different scopes.
update_issue_status requires mcp:issues:write; investigation tools require mcp:read.
A client must support remote Streamable HTTP, OAuth discovery, Authorization Code with PKCE, and resource indicators. Otherwise, use the deprecated local stdio fallback.
Hosted OAuth currently supports Bugfender's public cloud. Self-hosted deployments must use local stdio and set BUGFENDER_API_URL to their backend.

Tools

who_am_i
list_teams
list_apps
get_app
list_app_versions
get_sdk_snippet
get_crashes
get_crash_stats
get_crash_device_stats
get_crash_details
search_logs
count_logs
count_devices_with_logs
get_network_aggregates
get_network_details
search_devices
count_devices
list_issues
get_issue
update_issue_status
get_issue_stats
get_issue_device_stats
get_issue_devices
get_feedback
get_app_summary

Resources

bugfender://snippet/{app_id}/{platform}
bugfender://app/{app_id}/logs?...
bugfender://issue/{issue_id}?app_id={app_id}

Companion Skills

The companion skills now live in the separate bugfender/bugfender-skills repository. They encode opinionated workflows on top of the MCP tools:

use aggregation before logs
narrow time ranges early
size impact before deep-diving
end with a short triage summary

The MCP package gives the agent raw Bugfender capabilities. The skill adds an opinionated investigation workflow on top of those capabilities.

Use the skill when you want Cursor, Codex, or Claude Code to do things like:

help set up the Bugfender SDK in an app with the minimum required steps
fetch the SDK snippet for a platform and explain exactly where it goes
investigate the top crashes in an app
summarize issue or feedback trends over a time range
compare impact before and after an app version
identify likely cause, scope, and next checks

The investigation skill source lives in:

https://github.com/bugfender/bugfender-skills/tree/main/skills/bugfender

SDK Setup Skill

The dedicated onboarding skill also lives in bugfender/bugfender-skills.

Use it when you want Cursor, Codex, or Claude Code to:

detect the project platform automatically
fetch the correct Bugfender SDK snippet
map the setup to the real repository files
ask one short feature question when optional capabilities like crash reporting or Android logcat matter
apply the minimum integration changes
reduce the developer’s work to one final verification step

It also includes platform-specific references for:

iOS
Android
Flutter
Unity
.NET MAUI
Cordova
Ionic
Angular
React
Vue
JavaScript
jQuery
Titanium
Web
React Native

The skill source lives in:

https://github.com/bugfender/bugfender-skills/tree/main/skills/bugfender-sdk-setup

Install Skills In Cursor, Codex, Or Claude Code

Cursor, Codex, and Claude Code can install the skills directly from GitHub without cloning the repo manually.

In the agent chat inside your IDE, run this prompt with the built-in installer skill:

Use $skill-installer to install these skills from https://github.com/bugfender/bugfender-skills:
- skills/bugfender
- skills/bugfender-sdk-setup

After installation, restart the client and use:

Use $bugfender-sdk-setup to set up Bugfender in this app with the minimum required changes.

Available Tools

25 tools

count_devicesD

Name	Required	Description
`name`	No	Filter by device name.
`model`	No	Filter by device model.
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`enabled`	No	Filter by enabled (true) or disabled (false) devices.
`os_name`	No	Filter by operating system name.
`os_version`	No	Filter by OS version string.
`date_range_end`	No	ISO 8601 datetime. Count devices active up to this date.
`date_range_start`	No	ISO 8601 datetime. Count devices active from this date.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

count_devices_with_logsD

Name	Required	Description
`text`	Yes
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`date_range_end`	No
`date_range_start`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

count_logsD

Name	Required	Description
`tags`	No	Filter by log tags (e.g. ["ERROR", "NETWORK"]).
`text`	No	Full-text search across log messages.
`level`	No	Filter by log level. 0=Debug, 1=Warning, 2=Error, 3=Trace, 4=Info, 5=Fatal
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`app_version`	No	Filter by app version ID from list_app_versions.
`device_udid`	No	Filter to a specific device by its UDID.
`date_range_end`	No	ISO 8601 datetime string (e.g. 2026-04-28T23:59:59Z).
`date_range_start`	No	ISO 8601 datetime string (e.g. 2026-04-28T00:00:00Z).

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_appD

Name	Required	Description	Default
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_app_summaryD

Name	Required	Description	Default
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`date_range_start`	No	The date to summarize, as YYYY-MM-DD or ISO 8601. Returns stats for that single day only — not a range. Defaults to yesterday.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_crash_detailsD

Name	Required	Description	Default
`hash`	Yes
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_crash_device_statsD

Name	Required	Description
`hash`	No
`title`	No
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`date_range_end`	No
`date_range_start`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_crashesA

Returns a list of crash groups for an app, optionally filtered by date range. Does not support filtering by status — use list_issues with type=crash and issue_status if you need open/resolved/closed crashes only.

Name	Required	Description
`limit`	No	Max number of crashes to return. Defaults to 20.
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`date_range_end`	No	ISO 8601 datetime string (e.g. 2026-04-28T23:59:59Z).
`date_range_start`	No	ISO 8601 datetime string (e.g. 2026-04-21T00:00:00Z).

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the limitation on status filtering but does not disclose other behavioral traits such as pagination, rate limits, or whether the operation is read-only. It is adequate for a simple list operation but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, with the first sentence stating purpose and optionality, and the second providing exclusions and alternatives. Every word adds value, and the purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there are 4 parameters, no output schema, and no nested objects, the description covers the essential aspects: what is returned, optional filters, and what is not supported. It could mention the output structure or pagination behavior, but the schema covers limit details, so it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description only adds that filtering is optional by date range, which is consistent with the schema but does not provide additional meaning beyond what is already in the schema parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Returns' and the resource 'list of crash groups for an app', with optional date range filtering. It explicitly distinguishes from sibling tools by noting that status filtering is not supported and suggesting list_issues as an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when not to use this tool (when status filtering is needed) and directs the agent to the alternative tool list_issues with specific parameters, which is excellent for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_crash_statsD

Name	Required	Description
`hash`	No
`title`	No
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`date_range_end`	No
`date_range_start`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_feedbackD

Name	Required	Description
`page`	No
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`page_size`	No
`date_range_end`	No
`date_range_start`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_issueD

Name	Required	Description
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`issue_id`	Yes
`date_range_end`	No
`date_range_start`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_issue_devicesD

Name	Required	Description
`hash`	Yes
`page`	No
`order`	No
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`page_size`	No
`os_version`	No
`app_version`	No
`device_name`	No
`device_udid`	No
`device_model`	No
`date_range_end`	No
`date_range_start`	No

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_issue_device_statsD

Name	Required	Description
`hash`	No	Filter to a specific issue hash.
`type`	No	Filter by type: issue, crash, feedback
`query`	No	Filter by issue title text.
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`content`	No	Filter by issue body/content text.
`version`	No	Filter by app version ID.
`issue_status`	No	Filter by status: new, open, in_progress, resolved, closed, muted
`date_range_end`	Yes	ISO 8601 datetime string (e.g. 2026-04-28T23:59:59Z)
`date_range_start`	Yes	ISO 8601 datetime string (e.g. 2026-04-21T00:00:00Z)

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_issue_statsD

Name	Required	Description
`hash`	No	Filter to a specific issue hash.
`type`	No	Filter by type: issue, crash, feedback
`query`	No	Filter by issue title text.
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`content`	No	Filter by issue body/content text.
`version`	No	Filter by app version ID.
`issue_status`	No	Filter by status: new, open, in_progress, resolved, closed, muted
`date_range_end`	Yes	ISO 8601 datetime string (e.g. 2026-04-28T23:59:59Z)
`date_range_start`	Yes	ISO 8601 datetime string (e.g. 2026-04-21T00:00:00Z)

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_network_aggregatesD

Name	Required	Description
`os`	No	Filter by operating system name (e.g. iOS, Android).
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`os_version`	No	Filter by operating system version.
`app_version`	No	Filter by app version string.
`device_udid`	No	Filter network requests to a specific device UDID.
`domain_search`	No	Filter by domain text. Partial matches are supported.
`date_range_end`	No	ISO 8601 datetime string (e.g. 2026-04-28T23:59:59Z).
`date_range_start`	No	ISO 8601 datetime string (e.g. 2026-04-28T00:00:00Z).

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_network_detailsD

Name	Required	Description
`os`	No	Filter by operating system name (e.g. iOS, Android).
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`domain`	Yes	Domain to inspect (e.g. api.example.com).
`endpoint`	No	Endpoint path to inspect. Defaults to '/' when omitted.
`os_version`	No	Filter by operating system version.
`app_version`	No	Filter by app version string.
`device_udid`	No	Filter network requests to a specific device UDID.
`sample_page`	No	1-based page number for sample requests.
`date_range_end`	No	ISO 8601 datetime string (e.g. 2026-04-28T23:59:59Z).
`date_range_start`	No	ISO 8601 datetime string (e.g. 2026-04-28T00:00:00Z).
`sample_page_size`	No	Page size for sample requests. Max 100.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sdk_snippetD

Name	Required	Description	Default
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`platform`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_appsD

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_app_versionsD

Name	Required	Description	Default
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_issuesA

Lists issue groups for an app. Supports filtering by type (issue, crash, feedback) and status (open, resolved, closed). Use this instead of get_crashes or get_feedback when you need status filtering or combined results.

Name	Required	Description
`page`	No
`type`	No	Filter by type: issue, crash, feedback
`query`	No	Filter by issue title text.
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`content`	No	Filter by issue body/content text.
`version`	No	Filter by app version ID.
`page_size`	No
`issue_status`	No	Filter by status: new, open, in_progress, resolved, closed, muted
`date_range_end`	No	ISO 8601 datetime string (e.g. 2026-04-28T23:59:59Z)
`date_range_start`	No	ISO 8601 datetime string (e.g. 2026-04-28T00:00:00Z)

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It states 'Lists' implying a read-only operation, but does not explicitly confirm non-destructiveness or mention any side effects. It also does not describe pagination behavior, though page/page_size parameters exist in schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise—only two sentences. The first sentence defines the purpose, the second provides usage guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters, no output schema, and high parameter description coverage, the description provides enough context for basic use. However, it could mention what the response contains (e.g., list of issues) and pagination details, though these are inferable from schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high (80%), so the description needs to add little extra. The description mentions filtering by type and status, which aligns with schema fields, but adds no new semantic detail beyond what's already in the property descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists issue groups for an app and specifies filtering by type and status. It also distinguishes itself from sibling tools get_crashes and get_feedback by highlighting its status filtering and combined results capability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this instead of get_crashes or get_feedback when you need status filtering or combined results,' providing clear guidance on when to use this tool versus alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_teamsD

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_devicesD

Name	Required	Description	Default
`name`	No	Filter by device name. Use * as suffix wildcard (e.g. iPhone*)
`model`	No	Filter by device model.
`order`	No	Sort order. Defaults to last_active.	last_active
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`enabled`	No	Filter by enabled (true) or disabled (false) devices.
`os_name`	No	Filter by operating system name (e.g. iOS, Android).
`log_text`	No	Filter devices that have logs matching this text.
`log_level`	No	Filter devices that have logs at this level. 0=Debug, 1=Warning, 2=Error, 3=Trace, 4=Info, 5=Fatal
`page_size`	No
`os_version`	No	Filter by OS version string.
`next_cursor`	No	Cursor for next page, from pagination.next_cursor in previous response.
`date_range_end`	No	ISO 8601 datetime. Filter devices active up to this date.
`date_range_start`	No	ISO 8601 datetime. Filter devices active from this date.
`current_app_version`	No	Filter devices currently running this app version.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_logsD

Name	Required	Description
`tags`	No	Filter by log tags (e.g. ["ERROR", "NETWORK"]). Tags are user-defined string labels.
`text`	No	Full-text search across log messages.
`level`	No	Filter by log level. 0=Debug, 1=Warning, 2=Error, 3=Trace, 4=Info, 5=Fatal
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`cursor`	No	Pagination cursor from pagination.next in a previous response.
`page_size`	No	Number of results per page. Defaults to 100, max 200. Use smaller values (e.g. 25) to avoid truncation.
`app_version`	No	Filter by app version ID (integer). Get version IDs from list_app_versions.
`device_udid`	No	Filter to a specific device by its UDID from search_devices.
`date_range_end`	No	ISO 8601 datetime string (e.g. 2026-04-28T23:59:59Z). Date-only strings like 2026-04-28 are also accepted.
`date_range_start`	No	ISO 8601 datetime string (e.g. 2026-04-28T00:00:00Z). Date-only strings like 2026-04-28 are also accepted.

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_issue_statusA

Updates the status of an issue group (issues aggregation). Use this to mark issues as resolved, closed, in progress, etc.

Name	Required	Description
`app_id`	Yes	The public app ID (e.g. 5X3c4veRGV) from list_apps
`status`	Yes	New status: new, open, in_progress, resolved, closed, muted, or invalid
`issue_id`	Yes	The issue group hash from list_issues or get_issue

TDQS

A3.7/5.0

Behavior2/5

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 only states that the tool updates the status, but does not disclose any side effects (e.g., notifications, state transitions), required permissions, or whether the operation is idempotent. This is insufficient for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the purpose. Every word is necessary; there is no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with three simple parameters and no output schema, the description is adequate but minimal. It could be improved by mentioning the expected return value (e.g., success confirmation) or any prerequisites like the app_id must exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all three parameters with descriptions, achieving 100% coverage. The description adds no extra meaning beyond the schema; it only repeats the status enum values. Therefore, it meets the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Updates'), identifies the resource ('issue group'), and explicitly lists possible statuses ('resolved, closed, in progress, etc.'). It clearly distinguishes from sibling tools like 'get_issue' and 'list_issues' which are read-only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states when to use the tool ('Use this to mark issues as resolved, closed, in progress, etc.'), providing clear context. However, it does not mention when not to use it or suggest alternatives, such as using a different tool for other updates.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

who_am_iD

Name	Required	Description	Default
No parameters

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

25 tool updatesv0.6.0Jul 28, 2026
- First observedcount_devices
- First observedcount_devices_with_logs
- First observedcount_logs
- First observedget_app
- First observedget_app_summary
- First observedget_crash_details
- First observedget_crash_device_stats
- First observedget_crash_stats
- First observedget_crashes
- First observedget_feedback
- First observedget_issue
- First observedget_issue_device_stats
- First observedget_issue_devices
- First observedget_issue_stats
- First observedget_network_aggregates
- First observedget_network_details
- First observedget_sdk_snippet
- First observedlist_app_versions
- First observedlist_apps
- First observedlist_issues
- First observedlist_teams
- First observedsearch_devices
- First observedsearch_logs
- First observedupdate_issue_status
- First observedwho_am_i

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

D1.7/5.0

Scored 2026-07-28 09:00 across 25 tools

Disambiguation2/5

Many tools have similar names (e.g., get_crashes, get_crash_details, get_crash_stats) and most lack descriptions, making it hard to distinguish their exact purposes. An agent would likely misselect between crash-related tools.

Naming Consistency4/5

The naming generally follows a verb_noun snake_case pattern (e.g., list_apps, get_crashes, search_logs). However, 'who_am_i' is an outlier that breaks the pattern, and the mix of 'list', 'get', 'search', 'count' is acceptable but slightly inconsistent.

Tool Count3/5

With 25 tools, the server is on the heavy side for a monitoring/tracking API. While each tool may serve a specific need, the count is borderline and could be reduced by combining related tools (e.g., crash stats into one tool with parameters).

Completeness3/5

The tool surface covers reading and listing for most resources (crashes, issues, feedback, logs, devices, network). However, it lacks create, update (except for issue status), and delete operations, which limits the agent's ability to manage resources fully.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

Appcircle MCP
io.appcircle
MCP server for Appcircle mobile CI/CD platform.
CI/CD & DevOps Developer Tools
2
https://mcp.appcircle.io
SmartBear MCPOAuth
com.smartbear
MCP server for AI access to SmartBear tools, including BugSnag, Reflect, Swagger, PactFlow, QTM4J.
Monitoring Testing & QA Tools API Testing
144
https://zephyr.mcp.smartbear.com/mcp
sentry-mcpOAuth
io.github.getsentry
MCP server for Sentry - error monitoring, issue tracking, and debugging for AI assistants
Monitoring Observability
1944
https://mcp.sentry.dev/mcp
AgentCatOAuth
com.agentcat
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
Monitoring Observability
2
https://mcp.agentcat.com/mcp

Related MCP Servers

mcp-airq-cloud
Monitoring Research & Data Health & Wellness
CorantGmbH
A
license
Not graded
quality
C
maintenance
MCP server for the air-Q Cloud API, enabling remote retrieval of air quality sensor data and historical analysis through read-only tools like listing devices, fetching readings, and exporting charts or data.
Updated 3 months ago (2026-08-05 18:44 UTC)
56 PyPI
Apache 2.0
bugsink-mcp
Monitoring Developer Tools
Nshuti7
A
license
Not graded
quality
D
maintenance
Hosted MCP server that exposes your self-hosted Bugsink error tracker as tools for LLMs, enabling issue management, release tracking, and stacktrace retrieval via chat prompts.
Updated 4 months ago (2026-07-06 18:15 UTC)
100 npm
MIT
BountyProof MCP
Penetration Testing Security
skyxtools
A
license
B
quality
D
maintenance
An MCP server for authorized bug bounty work that enforces an evidence-driven workflow with session management, preflight checks, surface discovery, and verified scanning.
Updated 4 months ago (2026-07-11 08:01 UTC)
12
MIT
Auralogs MCP Serverofficial
Monitoring Observability
auralogs-ai
A
license
Not graded
quality
F
maintenance
A read-only MCP server for the Auralogs logging platform, enabling AI agents to query production logs, search errors, and retrieve AI analyses without write access. It allows you to ask your coding assistant 'what's broken in production right now?' by connecting to your logs via a simple bearer auth key.
Updated 5 months ago (2026-06-10 05:45 UTC)
MIT

Bugfender MCP

What It Provides

Maintainers

Recommended: hosted OAuth

OAuth scopes

Disconnect and revoke

Privacy

Deprecated: local stdio package

Local stdio configuration

Legacy Cursor / Claude Code configuration

Legacy Codex CLI configuration

Legacy Gemini CLI configuration

Legacy Codex App configuration

Hosted Streamable HTTP deployment

Hosted authentication troubleshooting

Tools

Resources

Companion Skills

SDK Setup Skill

Install Skills In Cursor, Codex, Or Claude Code

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Auralogs MCP Serverofficial