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 "Install 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 Related Servers Score Discussions

TypeScript

Remote

`@bugfender/mcp`

Bugfender MCP server for local stdio clients such as Cursor, Claude Code, Codex, and Gemini CLI.

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: tokenless-zendesk-mcp

Maintainers

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

Install

npx -y @bugfender/mcp

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

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.

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.

Cursor / Claude Code

{
  "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"
      }
    }
  }
}

Codex CLI

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.

Gemini CLI

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.

Codex App

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.

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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.

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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.

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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

ParametersJSON Schema

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.

ParametersJSON Schema

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

ParametersJSON Schema

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

D1.7/5.0

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

ActivityStale

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Appcircle MCP
io.appcircle
MCP server for Appcircle mobile CI/CD platform.
CI/CD & DevOps Developer Tools
2
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
AgentCatOAuth
com.agentcat
Analytics and debugging for your MCP server — explore usage and sessions, then root-cause errors.
Monitoring Observability
2
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2

Related MCP Servers

mcp-airq-cloud
Monitoring Research & Data Health & Wellness
CorantGmbH
A
license
Not graded
quality
B
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 a month ago (2026-08-05 18:44 UTC)
Apache 2.0
tokenless-zendesk-mcp
Customer Support Communication
yutamago
A
license
A
quality
D
maintenance
MCP server that authenticates via browser session cookies to access Zendesk's REST API without API tokens, supporting reads and writes with agent permissions.
Updated 3 months ago (2026-06-12 23:40 UTC)
19
14
1
MIT
bugsink-mcp
Monitoring Developer Tools
Nshuti7
A
license
Not graded
quality
B
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 2 months ago (2026-07-06 18:15 UTC)
850
MIT
BountyProof MCP
Penetration Testing Security
skyxtools
A
license
B
quality
C
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 2 months ago (2026-07-11 08:01 UTC)
12
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bugfender/bugfender-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server