Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@crashwebsite-mcp list top crashes this week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that exposes your plugin crash
reports to Claude. It is a thin, read-only client over the crash site's JSON API
(/api/...), authenticated by your personal API key and scoped to every
plugin you can see across all your teams.
Tool | Endpoint | Purpose |
|
| The plugins you can access (ids/codes for the |
|
| The teams you belong to and your role. |
|
| Top crash locations grouped by function, with counts. |
|
| Most recent individual crashes, newest first. |
|
| Search by crash filename / function text. |
|
| Full details + symbolicated stack for one crash. |
|
| Totals, last 7/30 days, unique functions, by version/platform. |
|
| Distinct versions and host apps (for filters). |
|
| Comments on a crash function. |
|
| Add a comment to a crash function (attributed to you). |
|
| Register a plugin under a team (owner/admin only). |
|
| Delete a plugin and all its data (owner/admin; needs |
Crash/comment tools take an optional plugin (id, code, or name) — only required
when you can access more than one plugin. The list tools also accept filters:
ver, verop (=/>=/<=), os (win/mac/linux), app, limit.
Write tools are permission-checked server-side: comments need team membership;
adding/deleting a plugin needs owner/admin on the team, and delete_plugin
requires confirm to equal the plugin's exact plugin_code.
Related MCP server: claude-oracle-mcp
Set via environment variables:
CRASH_API_KEY (required) — your personal API key. Generate it on the
crash site's Account page. It grants read access to every plugin you can
see; keep it secret, like a password.
CRASH_API_BASE_URL (optional) — defaults to
https://crashreports.rabiensoftware.com.
Run it on your own machine — it talks to the public crash site by default, so there's no server-side setup.
git clone https://github.com/PluginCrashReports/crashwebsite-mcp.git
cd crashwebsite-mcp
npm install
npm run buildClaude Code, one line:
claude mcp add crashwebsite -e CRASH_API_KEY=your-plugin-crash-api-key \
-- node /absolute/path/to/crashwebsite-mcp/dist/index.jsOr add to your MCP config (e.g. claude_desktop_config.json) directly:
{
"mcpServers": {
"crashwebsite": {
"command": "node",
"args": ["/absolute/path/to/crashwebsite-mcp/dist/index.js"],
"env": {
"CRASH_API_KEY": "your-plugin-crash-api-key"
}
}
}
}To point at a self-hosted instance instead of the public site, also set
CRASH_API_BASE_URL.
Then ask Claude things like "what are the top crashes this week?", "show recent mac crashes for 1.0.7", or "open crash 3 and explain the stack".
Add a comment to a crash function (a crash location) for a plugin. Attributed to you.
| Name | Required | Description | Default |
|---|---|---|---|
| func | Yes | The crash function/location to comment on. | |
| plugin | No | Which plugin to query: id, plugin code, or name. Omit if you have only one; otherwise required (see list_plugins). | |
| comment | Yes | The comment text. |
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 'Attributed to you' indicating authorship, but does not disclose permissions, reversibility, side effects, or any rate limits. For a write operation, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous words. It is front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of 3 parameters (well-documented in schema), no output schema, and no annotations, the description is adequate but brief. For a write tool, it could mention the outcome or confirmation, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds 'crash function' context but does not significantly expand on parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a comment'), the resource ('crash function/crash location'), and the scope ('for a plugin', 'Attributed to you'). It distinguishes from sibling tools like list_comments (read) and add_plugin (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (add a comment), but does not provide explicit guidance on when to use it versus alternatives, nor when not to use it. The plugin parameter description offers a usage hint (omit if only one plugin), but this is not in the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new plugin under one of your teams. Requires owner/admin on that team.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name, e.g. "Identity". | |
| team | No | Which team (id or name) to add the plugin to. Omit if you manage only one team (see list_teams). | |
| plugin_code | Yes | Bundle id / code used to match crashes, e.g. "com.socalabs.identity". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the authorization requirement (owner/admin) but does not mention output, idempotency, or side effects. For a creation tool, additional behavioral details would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose and a key requirement. It is front-loaded and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate given the tool's complexity, but it lacks information about return values, error handling, or potential side effects. While the authorization requirement is good, more completeness would improve usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no parameter meaning beyond what the schema already provides, thus no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers a new plugin under a team. It uses a specific verb 'Register' and resource 'plugin', distinguishing it from sibling tools like delete_plugin and list_plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite of owner/admin role but does not explicitly state when to use this tool vs alternatives. It provides minimal guidance beyond the basic usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a plugin and ALL its crashes, symbols and comments. Owner/admin only; irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| plugin | No | Which plugin to query: id, plugin code, or name. Omit if you have only one; otherwise required (see list_plugins). | |
| confirm | Yes | Must equal the plugin's exact plugin_code, as a safety check, to actually delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description fully discloses irreversible deletion of plugin and all associated crashes, symbols, and comments, plus authorization requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with primary action and key constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with 2 parameters and no annotations/output schema, description covers purpose, effects, authorization, and confirmation requirement completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters; description does not add significant extra meaning beyond what schema provides (plugin identification and confirmation).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Permanently delete a plugin' with clear verb and resource. Differentiates from sibling tools like add_plugin and list_plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'Owner/admin only; irreversible', giving clear context for when to use (with authority and certainty) and implying when not to. No explicit alternatives, but context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full details and symbolicated stack trace (crashlog) for a single crash by its numeric id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Crash id, as returned by the list/search tools. | |
| plugin | No | Which plugin to query: id, plugin code, or name. Omit if you have only one; otherwise required (see list_plugins). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries burden. It discloses output type (full details, stack trace) but no side effects, permissions, or limitations. Adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, direct sentence with no wasted words. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description lacks details on output fields. For a crash log retrieval tool, more completeness on returned data would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already documents parameters. Description adds no extra meaning beyond confirming 'numeric id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details and symbolicated stack trace for a single crash by numeric id, distinguishing it from list tools that return multiple crashes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies need for a numeric id but does not explicitly state when to use vs alternatives like get_crash_stats or list_recent_crashes. Lacks exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate crash statistics for a plugin: total, last 7/30 days, unique functions, and breakdowns by version and platform.
| Name | Required | Description | Default |
|---|---|---|---|
| plugin | No | Which plugin to query: id, plugin code, or name. Omit if you have only one; otherwise required (see list_plugins). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It states 'Get' implying read-only, but does not explicitly confirm no side effects, rate limits, or data freshness. More transparency would improve this score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the key return elements with no redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description lists the types of statistics but does not specify the output structure or format. Additional detail on the breakdowns (e.g., nested objects or separate fields) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and provides clear guidance on the 'plugin' parameter. The tool description adds no additional semantic meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get aggregate crash statistics for a plugin' with specific verb and resource, and lists distinct statistics (total, last 7/30 days, unique functions, breakdowns), which distinguishes it from sibling tools like get_crash_log or list_frequent_crashes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for aggregate stats and the input schema for 'plugin' provides guidance on when to provide it (omit if only one plugin, otherwise required with reference to list_plugins). However, no explicit when-not or alternatives to other crash-related tools are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the comments on a crash function (a crash location) for a plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| func | Yes | The crash function/location the comments hang off (as shown by list_frequent_crashes / get_crash_log). | |
| plugin | No | Which plugin to query: id, plugin code, or name. Omit if you have only one; otherwise required (see list_plugins). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It only states listing comments without mentioning side effects, permissions, rate limits, or result format, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence is concise and front-loaded. No wasted words, though slightly more structure could improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values or pagination. It does not, leaving the agent uninformed about what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (list), resource (comments), and context (crash function for a plugin), distinguishing it from sibling tools like add_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description does not mention when not to use it or provide context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most frequent crash locations for a plugin, grouped by function, with counts and the most recent date. Use this to find the top crashes.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | Platform filter (default "all"). | |
| app | No | Host application filter, e.g. "Ableton Live 11". Omit or "all" for every app. | |
| ver | No | Version filter, e.g. "1.0.7". Omit or "all" for every version. | |
| limit | No | Max rows to return (1-500, default 100). | |
| verop | No | Comparison operator for the version filter (default "="). Uses natural version ordering. | |
| plugin | No | Which plugin to query: id, plugin code, or name. Omit if you have only one; otherwise required (see list_plugins). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It mentions output fields (counts, date) but fails to disclose behavioral traits like whether it is read-only, performance implications, or the fact that the plugin parameter is conditionally required (this is only in the schema, not the description). The description adds minimal behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long with no redundant words. It effectively communicates the tool's operation and recommended use. Front-loaded with the main action and output, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters all described in the schema and no output schema, the description is somewhat complete. However, it lacks information on the return format (e.g., list of objects, how grouping is represented) and does not address pagination or error states. Given the tool's complexity (aggregated crash data), more detail on output structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description itself does not add further parameter meaning beyond what the schema provides (e.g., 'grouped by function' hints at grouping but does not detail parameter usage). The schema already describes each parameter adequately, so description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'frequent crash locations for a plugin', and specifies the output grouping by function with counts and date. However, it does not explicitly distinguish itself from siblings like 'list_recent_crashes' or 'search_crashes', which limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use this to find the top crashes,' which implies a use case but gives no explicit guidance on when to use this tool versus alternatives (e.g., search_crashes or get_crash_stats). No conditions, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the plugins you can access, across all your teams, with the id and code to pass as the plugin argument to the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses the scope (across all teams) and the fact that it returns id and code. It doesn't mention side effects, but it's clearly read-only. The description is transparent about the return value use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and immediately conveys the essential information. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters, no output schema, and no annotations, the description covers the core functionality: what it does, what it returns, and how the output is used. It could clarify that it returns a list, but 'list' implies multiple items, so it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and schema coverage is 100%, so baseline is 3. The description adds value by explaining the output fields (id and code), but this dimension focuses on parameters; with zero parameters, no additional param info is needed, hence a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the plugins you can access, across all your teams', which is a specific verb+resource+scope. It explains the output contains id and code for use in other tools, distinguishing it from sibling tools like list_comments or list_teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool (to get accessible plugins) and how the output is used (as the 'plugin' argument for other tools). It does not explicitly state when not to use, but the context of sibling tools implies the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recent individual crash reports for a plugin, newest first. Each row includes an id usable with get_crash_log.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | Platform filter (default "all"). | |
| app | No | Host application filter, e.g. "Ableton Live 11". Omit or "all" for every app. | |
| ver | No | Version filter, e.g. "1.0.7". Omit or "all" for every version. | |
| limit | No | Max rows to return (1-500, default 100). | |
| verop | No | Comparison operator for the version filter (default "="). Uses natural version ordering. | |
| plugin | No | Which plugin to query: id, plugin code, or name. Omit if you have only one; otherwise required (see list_plugins). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It states ordering (newest first) and id linkage, but does not disclose pagination behavior, rate limits, or empty result handling. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences without redundancy. First sentence states core purpose and ordering, second adds valuable information about the id for tool chaining.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and 6 parameters, the description combined with detailed parameter schema provides sufficient context for typical use. The missing return format detail is minor for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds little beyond parameter descriptions. Baseline 3 is appropriate as it does not further clarify parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'list the most recent individual crash reports for a plugin, newest first', providing a specific verb and resource, and distinguishes from sibling tools like get_crash_stats and search_crashes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are mentioned. The note about id being usable with get_crash_log hints at a workflow but does not provide usage guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the teams you belong to, with your role — useful for choosing where to add a plugin.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clarifies it's a read operation ('list') and returns membership data with roles. It's transparent about the scope (teams you belong to). No hidden side effects are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence conveys action and use case efficiently. No wasted words; front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers what the tool outputs and why to use it, making it complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so parameter documentation is irrelevant. The description adds value by indicating the output includes the user's role, which aids agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists teams the user belongs to, including roles. It distinctly separates from sibling tools like list_plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly suggests usage context: useful before adding a plugin. It doesn't exhaustively list when not to use, but the sibling tools are diverse enough that this guidance suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the distinct plugin versions and host application names present in a plugin's crash data. Useful for building filters.
| Name | Required | Description | Default |
|---|---|---|---|
| plugin | No | Which plugin to query: id, plugin code, or name. Omit if you have only one; otherwise required (see list_plugins). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only says it lists distinct values; no disclosure of behavioral traits like idempotency, rate limits, or side effects. Does not contradict annotations (none present).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Purpose and use case are front-loaded. Extremely concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose and parameter semantics adequately. Could mention the output format or that it returns distinct values, but not critical given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds extra meaning: explains that 'plugin' can be id, code, or name, that omitting is allowed if only one plugin exists, and references list_plugins for finding available plugins. This goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists distinct plugin versions and host application names from crash data. It also gives use case (building filters) and implicitly distinguishes from siblings like list_plugins by specifying it's for crash data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions 'useful for building filters', implying a use context. However, it does not explicitly state when to use vs. alternatives (e.g., when to use list_plugins instead), nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a plugin's crash reports by text matched against the crash filename and the extracted function name.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to search for in the crash name or function. | |
| limit | No | Max rows to return (1-500, default 100). | |
| plugin | No | Which plugin to query: id, plugin code, or name. Omit if you have only one; otherwise required (see list_plugins). |
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 does not mention that this is a read-only operation, nor does it disclose any permissions, rate limits, or side effects. The description only states what it does, not behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose. Every word is informative, and there is no redundancy or extraneous text. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is somewhat sparse. It does not explain return format, pagination, or the behavior when 'plugin' is omitted. However, it covers the core functionality adequately for a search tool with clear schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that text matches against crash filename and function name, which aids understanding of the 'text' parameter. However, no additional semantic detail beyond the schema is provided for the 'limit' or 'plugin' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('a plugin's crash reports'), and specifies the matching fields (crash filename and function name). It clearly distinguishes from sibling tools like list_recent_crashes which list without text matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like list_recent_crashes or get_crash_log. The description implies a search use case but does not provide criteria or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct action and resource type. Add, delete, list, get, search, and stats tools are clearly separated, with no overlapping purposes.
All tool names follow a consistent 'verb_noun' pattern (e.g., add_comment, list_plugins, get_crash_log), making it predictable for an agent.
12 tools is well-scoped for a crash reporting domain, covering viewing, searching, stats, comments, and plugin management without excess or deficiency.
The set covers core crash operations and plugin CRUD but lacks update tools for plugins and comments, which is a minor gap for full lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Public MCP server for discovering open jobs. Search, filter, and get application links.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PluginCrashReports/crashwebsite-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
