Skip to main content
Glama
Sign In
waydroid-mcp

waydroid-mcp

by TechyAditya
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

host_logs

Read-only

Retrieve and filter host-side Waydroid logs from waydroid, container, session, or kernel sources to debug startup, mount, binder, GPU, and overlay errors.

Instructions

Host-side logs of Waydroid: waydroid is /var/lib/waydroid/waydroid.log (container start, mounts, errors), container the waydroid-container service's journal, session the session's journal, and kernel the kernel log (binder, GPU and overlay errors).

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": {
      "source": "<source>"
    },
    "name": "host_logs"
  }
}

Input Schema

NameRequiredDescriptionDefault
grepNoRegex a line must match.
linesNo
sinceNoFor journal sources: journalctl --since, such as "10 min ago".
sourceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine value by mapping each source to its underlying location and telling the agent which failure classes appear where (container start/mounts/errors, kernel binder/GPU/overlay errors), but it says nothing about return format, volume, or truncation behavior when lines is capped.

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?

A single dense sentence that front-loads the resource and then walks through the four sources in a parallel structure. Nothing is wasted, though the parenthetical detail makes it slightly harder to scan than a bulleted mapping would be.

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 read-only log-fetching tool with no output schema, the description covers the source dimension well but omits practical call details an agent would want: whether since is ignored for file-based sources (waydroid) and how output is truncated. The kernel-vs-journal distinction partially compensates.

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 coverage is 50%, with grep and since described in the schema and lines carrying default/min/max. The description's main contribution is explaining the four enum values of source, which the schema only lists as bare strings — that is meaningful added meaning, but grep/lines/since behavior (regex semantics, interaction with journal-only since) is left undocumented.

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?

Names the resource precisely ('Host-side logs of Waydroid') and enumerates the four log sources with what each corresponds to (waydroid.log path, container service journal, session journal, kernel log). An agent can tell it apart from Android-side log tools by the explicit 'host-side' framing, though the verb ('retrieve logs') is only implied.

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

Usage Guidelines3/5

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

The word 'host-side' implicitly contrasts with sibling tools like logcat, which cover Android-side logs, and the source descriptions hint at when each source is relevant (e.g. kernel for binder/GPU/overlay errors). However, there is no explicit statement of when to prefer this over logcat or logcat_follow, and no stated prerequisites such as root access.

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