Skip to main content
Glama
Sign In
waydroid-mcp

waydroid-mcp

by TechyAditya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

logcat_follow

Read-only

Follow Android logs in the background across calls: start with logcat filters, read new lines, wait for a regex such as a crash, then stop or list sessions.

Instructions

Follows the Android log in the background across calls. start begins collecting new lines with the same filters as logcat and returns an id. read returns the lines since the last read; with wait_for it first waits up to timeout_s for a line matching that regex, such as a crash (FATAL EXCEPTION) or your own log message. stop ends it; list shows all.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "logcat_follow"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoFollower id for read and stop.
grepNoJavaScript regular expression a line must match.
tagsNologcat filter specs such as "ActivityManager:I" or "chromium:V"; tags not listed are hidden.
actionYes
buffersNo
packageNoOnly lines logged by this app's uid. System apps such as Settings share uid 1000 with system_server.
wait_forNoFor read: regex to wait for in new lines.
max_linesNoFor read: return at most the last N new lines.
timeout_sNoFor read with wait_for: the longest wait.
min_priorityNoLowest priority shown, for every tag not in tags.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

The description discloses state that annotations do not cover: the follower persists across calls, `start` returns an id, `read` is cursor-based ("lines since the last read"), and `wait_for` blocks up to `timeout_s`. `readOnlyHint: true` sits slightly awkwardly with a tool whose `start`/`stop` actions create and tear down background state, and the description does not say what a timeout returns or whether followers expire.

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

Conciseness4/5

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

Four sentences, front-loaded with the core purpose and then a compact per-action breakdown using backticked action names. Dense but readable; a couple of clauses pack two ideas at once ("returns the lines since the last read; with wait_for it first waits..."), though nothing is filler.

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 10-parameter, 4-action, stateful tool with no output schema, the description covers the action model well but leaves return shape and edge behavior unstated: it does not say what `read` returns when nothing matches, what happens on timeout or with a stale `id`. Adequate to call correctly, incomplete on what to expect back.

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 already 80%, yet the description still adds real meaning: it explains the `wait_for`/`timeout_s` interaction with a concrete example ("a crash (FATAL EXCEPTION)") and clarifies that `read` is incremental rather than a snapshot. It does not distinguish `grep` from `wait_for`, nor explain `tags`/`min_priority`/`buffers` beyond the schema text.

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?

"Follows the Android log in the background across calls" names a specific verb and resource plus the key differentiator (persistent, cross-call), and the four action branches are enumerated. It does not explicitly contrast with the sibling `logcat` for one-shot reads, so the agent must infer that from "same filters as logcat" and "background across calls."

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?

Each action carries explicit when-to-use semantics: `start` to begin collecting, `read` for lines since the last read, `read` + `wait_for` to block for a crash or your own log message, `stop` to end, `list` to see all. There are no exclusion rules (e.g., when a one-shot `logcat` call is preferable, or that a follower should be stopped when done).

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