Skip to main content
Glama

Read device logs

android_logcat
Read-only

Fetch a filtered snapshot of Android device logs. After a crash, read the crash buffer for stack traces; filter by app, tag, or priority; clear before reproducing a bug for a clean read.

Instructions

Read logcat from the device, filtered down to what is actually relevant.

Returns a snapshot of the existing buffer and exits; it does not stream. Filter by package to see only your app's output — this is usually what you want after a crash, because the unfiltered buffer is mostly unrelated system noise.

Args:

  • serial (string, optional): target device

  • package_name (string, optional): show only lines from this app's process

  • tag (string, optional): show only this log tag

  • priority ('V'|'D'|'I'|'W'|'E'|'F'): minimum level (default: 'V', or 'E' when crashes_only is set)

  • crashes_only (boolean): read the crash buffer — fatal exceptions and ANRs. This buffer survives the process, so it works after the app has died (default: false)

  • lines (number): how many lines to return, 1-2000 (default: 200). Normally the most recent N; with crashes_only it is the first N of the crash, since that is where the exception and the top frames are

  • clear_only (boolean): wipe the buffer and return immediately without reading (default: false)

  • response_format ('markdown' | 'json')

Returns: { "lines": string[], "count": number, "truncated": boolean, "serial": string, "pid": number, "diagnosis": string }

'diagnosis' is present when a crash matches a known Android failure mode.

Examples:

  • Use when: the app crashed and you need the stack trace -> crashes_only=true, package_name="com.example.app"

  • Use when: watching your own Log.d output -> tag="MyTag"

  • Use when: reproducing a bug cleanly -> clear_only=true, reproduce it, then call again to read

  • Don't use when: you want to see the screen (use android_screenshot)

Error Handling:

  • Filtering by package uses the process id, which requires the app to be running. After a crash there is no process, so combine package_name with crashes_only — that path filters the crash buffer by name instead

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNoOnly show this log tag.
linesNoMost recent N lines to return.
serialNoDevice serial from android_list_devices. Optional when exactly one device is connected; required when several are.
priorityNoMinimum log priority: Verbose, Debug, Info, Warn, Error, Fatal.
clear_onlyNoClear the log buffer and return immediately without reading. Use before reproducing a problem, then call again to see only what the reproduction produced.
crashes_onlyNoRead the crash buffer only (fatal exceptions, ANRs).
package_nameNoOnly show logs from this app's process. The app must be running.
response_formatNoOutput format: 'markdown' for human-readable, 'json' for machine-readable.markdown
Behavior5/5

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

Annotations provide readOnlyHint=true and destructiveHint=false, but the description goes well beyond: it clarifies the non-streaming snapshot behavior, explains that the crash buffer survives process death, and discloses that clear_only wipes the buffer. Error-handling notes about package filtering requiring a live process add important behavioral context not present in annotations.

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 organized into clear sections (Intro, Args, Returns, Examples, Error Handling), front-loaded with the core behavior, and every sentence provides practical value. It is longer than a one-liner but appropriately sized for 8 parameters and multiple usage modes, with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/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 supplies a detailed return type including fields like 'truncated' and 'diagnosis'. It covers parameter behaviors, default values, edge cases (crash buffer), and error handling, making it complete for an 8-parameter tool with branching semantics.

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

Parameters5/5

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

Although schema description coverage is 100%, the description adds substantive meaning: e.g., lines behaves differently with crashes_only (first N of the crash vs most recent N), package_name filtering uses the process id and 'the app must be running' is expanded with the crashes_only fallback, and priority's default changes when crashes_only is set. This goes well beyond the schema.

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 opens with a specific verb+resource: "Read logcat from the device, filtered down to what is actually relevant." It immediately clarifies the scope (device logs filtered) and distinguishes from sibling tools like android_screenshot and android_shell. The snapshot-vs-stream clarification further sharpens the purpose.

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 Examples section explicitly states when to use the tool (after crash, watching Log.d, reproducing a bug) and when not to use it ('Don't use when: you want to see the screen' with the alternative android_screenshot). The Error Handling section also gives concrete conditional guidance (combine package_name with crashes_only after a crash).

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

Install Server

Other Tools

Latest Blog Posts

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/jjs03111/android-build-mcp'

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