Skip to main content
Glama
Sign In
waydroid-mcp

waydroid-mcp

by TechyAditya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

crashes

Read-only

Lists recent Android Java and native failures and ANRs newest first, optionally for one app, and returns full reports with stack traces by ID.

Instructions

Lists recent Java crashes and native crashes and ANRs, newest first, from Android's dropbox (kept across reboots), tombstones and ANR traces, optionally for one app. Pass read with an id from the list for the full report and stack.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "crashes"
  }
}

Input Schema

NameRequiredDescriptionDefault
readNoAn id from the list, such as tombstone:tombstone_03, to return that report.
limitNo
packageNoOnly crashes of this process or package.
since_hNoHow many hours back to look.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered; the description adds genuinely new behavioral facts — persistence across reboots for dropbox entries, the three underlying data sources, result ordering, and the two-phase list-then-read pattern. It does not mention retention windows, volume caps, or what happens when an id is stale, which are the notable remaining gaps.

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?

Two compact sentences with the resource, sources, ordering, and the follow-up read pattern front-loaded; no filler or restatement of the tool name. The density is high and every clause carries information.

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?

With no output schema, the description does the work of telling the agent what comes back — a newest-first list, and a full report plus stack when `read` is used — which is what an agent needs to chain the calls. It is nearly complete for a four-parameter read tool, missing only detail on what fields each list entry carries.

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

Parameters4/5

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

Schema coverage is 75%, and the description adds meaning beyond it: `read` is explained as accepting an id from a prior list result to fetch the full report and stack, `package` scoping is reinforced as 'optionally for one app', and ordering is tied to the default listing. The `limit` parameter is undocumented in both schema and description, leaving one small hole.

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

Purpose4/5

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

The description names a specific verb and resource set — listing Java crashes, native crashes, and ANRs from dropbox, tombstones, and ANR traces — and adds ordering ('newest first') plus an optional per-app scope. It also discloses a second mode ('pass `read` with an id from the list for the full report and stack'). It stops short of explicitly contrasting itself with plausible siblings such as logcat or stack_dump, so it is clear but not fully differentiated.

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?

Usage context is explicit: default recency of the last 24 hours, newest-first ordering, optional narrowing to one app, and a clear instruction to re-invoke with `read` plus an id when the full report and stack trace are needed. There are no stated exclusions or named alternatives for cases like live streaming or a currently-running process, which keeps it below a 5.

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

Deploy Server

Other Tools