Skip to main content
Glama

logs

Read-onlyIdempotent

Diagnose why an Android app crashed, froze, or misbehaved: pull logcat reports, grouped crashes, ANR events, or recent log lines, filtered by app, time, and text query.

Instructions

Android logs (logcat), to understand why an app crashed or misbehaves; newest last, about 30,000 characters at most. crash: crashes grouped one per block (time, package, Java exception and its "Caused by", first app frames; native crashes: signal, cause, backtrace). anr: "app not responding" events (Android's drop box, kept for days, and the recent event log) with their reason. recent: last lines log lines (default 200, max 2000). app: package or part of its name, as in launch (an uninstalled app: its full package name); for recent, its running processes, those Android started earlier, and lines naming it. since: 15m, 2h, 1d, 13:05 or 2026-10-19 13:05 (phone time). query: case-insensitive text filter, applied after masking. Security codes, tokens and secrets, e-mail addresses and phone numbers are masked. Banking, payment and identity apps: recent never; their crashes give only exception types and app frames.

Input Schema

NameRequiredDescriptionDefault
appNo
kindNocrash
linesNo
queryNo
sinceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.3

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: newest-last ordering, a ~30,000 character cap, crash/ANR grouping and retention details, masking of secrets and personal data, and special restrictions for sensitive app categories. The annotations already cover safety, and the description enriches them without contradiction.

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?

Despite being dense, every sentence adds operational meaning: purpose, output shape by kind, parameter semantics, and privacy constraints. The purpose is front-loaded, and the kind-specific labels make the longer description scannable.

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?

Complete for a read-only log retrieval tool with no output schema. It explains what each mode returns, the ordering and size limits, filtering behavior, masking, and sensitive-app restrictions, leaving no major ambiguity for correct invocation.

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?

Schema description coverage is 0%, so the description carries the full parameter burden and does so well. It defines the meaning of app, all three kind values, since with concrete formats, query filtering after masking, and lines defaults/maximums.

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?

States a specific resource (Android logcat logs) and a clear diagnostic purpose: understanding why an app crashed or misbehaved. It distinguishes the log kinds and their outputs, so an agent can identify the tool without opening the schema.

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?

Gives clear usage context for each kind: crash for grouped crashes, anr for non-responsive events, and recent for raw log lines. It also states important exclusions for banking/payment/identity apps, but it does not explicitly compare this tool with sibling diagnostic tools such as look, apps, info, or checkup.

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