adb-tv-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Most tools have clearly distinct purposes (screenshot vs screenrecord vs tap vs swipe are all different actions). The only mild overlap is adb_shell vs adb_start_intent vs adb_open_url, since all involve running commands on the device, but their descriptions clarify distinct use cases. Overall agents can distinguish between them well.
Naming Consistency4/5The adb_ prefix is applied to all 24 tools, giving a strong and clear prefix pattern. However, the verb portion varies in style: verbs like screenshot, reboot, shell, push, pull are nouns/imperatives mixed together, and there's no action-object convention (e.g. adb_launch vs adb_launch_app). The ubiquitous adb_ prefix creates consistency, but the verb style is somewhat inconsistent.
Tool Count4/524 tools is near the high end of what feels appropriate for a device-management server, and the count is justified by the breadth of ADB capabilities (network, input, apps, screen, properties). Each tool addresses a distinct real operation, making the size defensible, though it does edge toward heavy.
Completeness4/5The surface covers the core ADB workflows well: connectivity (pair/connect/disconnect/devices), input (tap/swipe/key/text), screen (screenshot/record), app lifecycle (launch/install/uninstall/list/current), file transfer (push/pull), properties/settings, shell, logcat, and URL/intent launching. Minor gaps include no clear reboot/couple of state management helper, but the essential ADB operations are present with no dead ends.
Average 3.1/5 across 24 of 24 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the 'all if omitted' behavior, but does not describe side effects, whether the device remains listed in adb_devices with an offline status, or what happens to active connections using that port. For a state-changing tool with zero annotation coverage, this is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the primary behavior. It is appropriately concise with no waste. It doesn't elaborate on parameters, but for its length it is well-formed and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters, 0% schema coverage, no annotations, and no output schema, the description should compensate heavily. It fails to document parameter semantics, error behavior, or the state implications of disconnecting. For a state-changing tool with this level of structured-data absence, the description is notably incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither the schema nor the description explains the host and port parameters. The description references 'host:port' format conceptually to match the adb disconnect syntax, but provides no concrete guidance on whether host is required without port, whether port has a default, or how the two fields interact. The agent must infer adb CLI conventions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb (disconnect) and resource (a device or all), which is clear. However, it only says 'host:port' format implied but doesn't clarify which fields map to host and port, nor does it distinguish from adb_connect clearly beyond being the inverse operation. Compared to siblings like adb_connect (its natural inverse), the purpose is understandable but not strongly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the behavior when parameters are omitted ('or all if omitted'), which provides some usage context. However, it does not explain when to use this tool vs adb_connect, when disconnecting is appropriate, or any prerequisites (e.g., must be connected first). No explicit when-not guidance or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention that this tool can execute arbitrary, potentially destructive commands (rm, reboot, etc.) with no confirmation, or that some devices may require root. The 'use only with devices you own' line is an ethics note, not a behavioral transparency statement about side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a one-line ethical caveat. It's efficiently brief with no filler words. The ethical warning is a legitimate addition worth including, and the entire thing is properly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero annotations and no output schema, this is a serious gap. This is a high-risk arbitrary-execution tool — arguably the highest-risk operation in the adb family — yet it lacks any behavioral detail about output capture, exit codes, error handling, or the fact that commands run with shell (often root) privileges. Sibling tools like adb_getprop, adb_settings, adb_logcat already cover structured queries, and the description should note this tool is the general-purpose escape hatch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% — the 'command' parameter is entirely undocumented in the schema (no description field). The description says 'shell command' which clarifies command's nature somewhat, but adds no detail about what commands are supported, shell language (sh, bash?), or escaping requirements. The serial parameter is well documented in the schema already.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it runs a shell command on the device, which is a clear verb+resource pairing. However, it doesn't differentiate from siblings like adb_getprop, adb_settings, or adb_logcat, which are more specialized forms of reading device state. The broad nature of 'shell command' is clear but the description doesn't scope what kinds of commands are appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'Use only with devices that you own' — an ownership/ethics constraint, not operational guidance. There's no when-to-use versus alternatives (e.g., when to use adb_getprop vs adb_shell for property queries), no mention that many sibling tools cover common shell operations, and no safety warnings about destructive commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. A mutation tool like uninstall should disclose that it permanently removes the app, potentially destroys user data, and cannot be undone, but none of this is stated. The single sentence is entirely silent on behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, zero waste, efficient. However, several dimensions are under-specified, so conciseness here reflects brevity more than quality that earned its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A mutating tool with no annotations and no output schema, and the description provides minimal context. It doesn't mention what happens to app data, whether it prompts for confirmation, or whether it can be applied to system apps. Given the gravity of an uninstall operation, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (package lacks a schema description). The description names the package parameter ('by package name'), confirming its semantics. The serial parameter's own schema description covers it, so the description adds modest value but doesn't exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Uninstall an app by package name'), which distinguishes it from install-oriented siblings like adb_install and list-oriented ones like adb_list_apps. However, it lacks differentiation from other device-management siblings (e.g., doesn't clarify that this is a mutating operation vs. read-only tools).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs adb_install or adb_shell alternatives, nor any mention of prerequisites like needing app uninstall permissions or the package being uninstallable. The description does not give context for when this is appropriate beyond the obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It states the core behavior (swipe over duration) but doesn't mention that duration defaults to 300ms, whether the gesture is synchronous/precise, or any side effects on the device. For an input tool, it provides minimal behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficiently communicates the core purpose. No wasted words. However, given the low param coverage, extra sentences clarifying coordinate semantics and duration default would have been beneficial without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool, but with 5 undocumented parameters, no output schema, and no annotations, the description leaves significant gaps. It doesn't explain the coordinate system origin, the effect of duration_ms default (300ms), or behavior when coordinates are out of screen bounds. The description is adequate for identifying the tool but insufficient for correct parameter handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (1 of 6 params documented). The description explains what x1,y1,x2,y2 mean collectively but doesn't clarify the origin/coordinate system (e.g., screen pixels, top-left origin), or that duration_ms has a default. The serial param is documented in schema but its structure (host:port format) is only partially conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (swipe/drag) with clear coordinates (x1,y1 to x2,y2) and a duration parameter. It clearly distinguishes from sibling tools like adb_tap or adb_key by describing gesture semantics. It could state the screen dimension context but is clear enough about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use swipe vs tap vs text. No context about use cases like scrolling, dismissing dialogs, or gesture navigation. It doesn't mention when this is appropriate versus alternative input methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description says 'launch' which implies a side-effecting action, but it doesn't state whether this replaces the current activity, requires specific permissions, what happens if the app is already running, or what the typical output/return looks like. With zero annotation coverage for a state-changing tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with minimal waste. The example package name adds useful concrete context. It's appropriately brief for a simple tool, though it could argue for slightly more detail about serial handling or output without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a side-effecting tool (launches an app) with no annotations, no output schema, and only 50% parameter documentation. The description explains the core action but omits crucial context: prerequisites (device connected via adb), error handling (app not found), idempotency (what if already running), and return value semantics. For a tool that mutates device state, more completeness is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: the 'package' parameter has no description in the schema, while 'serial' has one. The description adds value by explaining that 'package' is a package name and giving an example (com.spotify.tv.android). However, it doesn't add meaning beyond what the parameter name implies, and the serial parameter's semantics ('omit if only one device') are covered by the schema, not the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource combination: 'Launch an app by package name'. This clearly states what the tool does and includes a concrete example package name. It distinguishes from siblings like adb_start_intent (which launches intents, not apps) and adb_current_app (which queries current app). However, it doesn't explicitly differentiate from adb_start_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as adb_start_intent, adb_open_url, or adb_key. There's no mention of prerequisites (e.g., app must be installed, device must be connected), no exclusion scenarios, and no context for when launching via package name is preferred over other launch methods. The usage context is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure. 'Open a URL' implies launching a browser/WebView, but it doesn't state what happens if no browser is installed, whether this requires the screen to be unlocked, whether it opens in a specific default browser, or any error behaviors. For a device-mutation action with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence. The parenthetical example adds user value without bloat. No wasted words, though the use-case note could arguably be considered decoration rather than essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only 50% parameter schema coverage, this simple tool description is somewhat thin. For a two-parameter tool it's not catastrophic, but it lacks behavioral expectations (what browser opens, whether results are returned), and the url parameter's format is entirely undocumented. It covers the basics but leaves the agent guessing on important operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — only the 'serial' parameter is documented in schema (with a clear 'omit if only one device' instruction). The 'url' parameter has no schema description, and the tool description doesn't add details about URL format (http/https, whether file:// or adb: schemes are valid). The description adds no parameter-level meaning beyond what the schema provides, landing at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Open a URL on the device' with a clear resource (device/URL). The parenthetical adds a useful use-case example (casting a webpage/dashboard/game to TV). It's distinct enough from siblings like adb_launch (apps) and adb_start_intent (intents), though it doesn't explicitly differentiate from them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There's no guidance on when to use this vs alternatives like adb_start_intent or adb_launch. The parenthetical hints at a use case (casting to TV) but doesn't clarify when a URL open is preferred over launching an app or sending an intent. No exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It doesn't mention whether the local path will be created/overwritten, what happens if the remote file doesn't exist, whether permissions are needed, or what the tool returns on success/failure. For a file operation tool with zero annotation coverage, this is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero wasted words. The description is appropriately terse for a simple file transfer operation, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mechanically straightforward file copy tool with no output schema and only 2 required params. The description covers the core operation adequately. However, given the complete lack of annotations and no behavioral details, the description is at minimum completeness for a simple tool but doesn't address failure modes, path validation, or overwrite behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% - only the 'serial' parameter has a description. The description adds that 'remote' refers to the file on the device and 'local' is the local destination, but only implicitly through the tool description. It doesn't specify path formats (absolute vs relative, remote path constraints) beyond what the schema provides. The description partially compensates for the low coverage by clarifying the direction of transfer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (copy a file) and direction (device to local), distinguishing it from its sibling adb_push which copies in the opposite direction. Verb+resource+direction are all specified, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The direction is implied by the name (pull = device to local) and the description, but there's no context about prerequisites (device connected, file existence) or when adb_push would be appropriate instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention that rebooting disconnects the adb session, may require reconnect (adb_connect exists as a sibling), that the operation is disruptive/destructive to active sessions, or that bootloader/recovery modes require manual exit. These are significant behavioral gaps for a disruptive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence that conveys the core purpose efficiently. No filler, no redundant elaboration. The mode enumeration in the description is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a disruptive operation (reboot) with no annotations, no output schema, and ambiguous post-conditions (does the tool wait for reboot completion? does it return immediately? does it need reconnect?). For a 2-param tool, one might argue minimal here suffices, but the disruptive nature and connect/disconnect sibling tooling means the description should clarify expectations about session behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% — the serial parameter has a description but mode does not (though mode's meaning is fairly self-evident from its enum values). The description restates the mode enum values but adds minimal semantic value beyond what the schema's enum already conveys. The serial parameter is explained in the schema, so the description adds nothing new there.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb+resource: 'Reboot the device' with specific modes. It distinguishes from siblings since it's the only reboot-related tool among the adb_* family. Though it names the modes, it doesn't elaborate the purpose of each mode (e.g., recovery vs bootloader), which slightly limits richness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives or when not to use it. There are no sibling reboot tools, so a when-to-use note isn't critical, but there's no mention of prerequisites (e.g., device must be connected, reboot disconnects the session) or cautionary notes about interrupting running operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose that 'put' mutates device state, whether changes persist across reboots, whether some settings are read-only, or if certain namespaces require root/adb-write permissions. The namespace list is mentioned but key behavioral nuances like potential for bricking/system instability from unsafe puts are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence, front-loaded with the primary verb+resource. Zero waste. However, it's arguably too terse given the criticality of settings mutation and the absence of annotations — brevity here trades away necessary safety context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema mean the description must do heavy lifting. For a 5-parameter, 2-enum tool that can mutate system settings (a potentially destructive operation), the description is inadequate. It doesn't address what `get` returns, whether `value` is required for `put` but not `get`, or the risk profile of modifying settings. It's a minimal viable spec at best.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (20%), with only serial having a description. However, the description does clarify the namespace parameter's allowed values (system|secure|global), which maps to the enum. The action parameter (get|put) and key/value are self-evident from the schema. The description adds modest value but doesn't fully compensate for the low coverage gap on other parameters like value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (get/put) and resource (Android setting), and notes the three namespaces. It distinguishes reasonably from siblings: every other sibling tool is about shell/reboot/push/pull/screenshot/etc., so this uniquely identifies the settings operation, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. It doesn't explain that 'get' is for reading settings and 'put' is for modifying them, nor when one would use adb_settings versus adb_getprop or adb_shell. Usage context is essentially absent beyond the operation names in the schema enum.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It doesn't disclose whether the tap is injected as a single touch, whether it waits for the UI to settle, whether requires an unlocked screen, or what happens on invalid coordinates. Minimal behavioral context is given beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with zero waste. The verb-subject-object structure is front-loaded and clear. Could add a bit more context without becoming verbose, but current brevity is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a hardware interaction tool with no annotations and no output schema, the description is thin. It doesn't mention coordinate origin, screen resolution matching, timing behavior, or whether the tap blocks until completion. Given the sibling set includes similar interaction tools (swipe, key, text), more context would help disambiguation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (the serial param is described in schema, while x and y are not). The description says coordinates are pixels, which adds some meaning for x/y, but doesn't clarify coordinate system origin (top-left) or resolution constraints. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Tap the screen at pixel x,y' with a clear verb (tap) and resource (screen) plus coordinates. It differentiates reasonably from siblings like adb_swipe and adb_key, though it doesn't explicitly distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use tap vs swipe or key, no mention of coordinate system origin or units (pixel vs dp), and no note about device screen resolution. The serial parameter hint in schema helps but the description itself offers no usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. It correctly implies stateful behavior (requires a focused field) though not explicitly. It doesn't disclose whether text replaces existing content, requires the field to be empty, or what happens on failure. For a write/intent tool with zero annotations, more behavioral context would help, but the core interaction is somewhat self-evident.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with zero waste. It states the key action and target in 8 words. Appropriately concise, though it could earn the extra length to add usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with a simple action (typing text), the description is arguably near-sufficient. No output schema exists, so return behavior isn't required. The main gap is the missing precondition about focus and interaction with adb_key. Given moderate complexity and zero annotations, it's adequate but could state the 'must be focused first' precondition explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with the 'serial' parameter having a description but 'text' being undocumented. The description adds minimal param semantics—it conveys that 'text' is the string to type, which roughly matches its name. But it doesn't clarify formatting, escaping rules, or limits for the text parameter beyond what's inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Type a string into the focused field' uses a specific verb (type) and resource (focused field), clearly distinguishing it from siblings like adb_tap, adb_key, and adb_swipe. However, it doesn't clarify what 'focused field' means or how text entry compares to adb_key which may also handle input. It's clear but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't mention prerequisites (e.g., that a field must already be focused, likely via prior tap), and doesn't distinguish from adb_key or other input-related siblings. The description implies a precondition but doesn't state it explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the action (connecting to a device) but doesn't disclose what happens on failure (e.g., if the device isn't paired), whether connection state persists, or what the response/return looks like. The 'wireless-debug' qualifier adds some context about prerequisites but not enough for full transparency on a connection-establishing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence, no filler. The parenthetical adds the key clarification about which port type this is. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a connection-establishing tool with no annotations, no output schema, and 0% schema description coverage, the description is thin. It doesn't explain failure modes, whether pairing is a prerequisite (beyond implying 'wireless-debug'), what happens on successful connect, or how this differs from adb_pair. Given the sibling set of 24 ADB tools, more context about connection lifecycle would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are 2 params with no descriptions. The description mentions 'host:port' as a unit, which maps to the two parameters, and calls out it's the wireless-debug port. However, it doesn't clarify host format (IP vs hostname), port range constraints, or whether the port differs from the pairing port shown in the wireless-debug UI. With no schema descriptions, the description should compensate more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Connect') with a clear resource (device ADB endpoint host:port), and clarifies this is the wireless-debug 'connect' port. It's clear what the tool does, though it doesn't explicitly distinguish from its sibling adb_pair or adb_disconnect beyond the action itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Siblings like adb_pair, adb_disconnect, and adb_devices exist but there's no mention of when connect is appropriate versus these. The description mentions wireless-debug 'connect' port, which implies pairing context, but no explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it says nothing about whether this is a read-only operation, what the output format looks like, or whether it requires an unlocked device or active display. For a query-style tool with zero annotation coverage, the description should at minimum disclose its read-only nature and output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It states the exact purpose without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a minimal description. For a query tool that returns app/activity info, it doesn't describe the output format (e.g., package name, activity name, format details), which is valuable context an agent needs to parse results. The description is too thin for the richness of the return value it would produce.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'serial' has 100% schema description coverage ('device serial (host:port); omit if only one device'). The description adds no additional meaning beyond the schema. With 100% schema coverage, baseline 3 is appropriate since the schema already handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Report the foreground app/activity' uses a clear verb ('report') and a specific resource ('foreground app/activity'). It distinguishes this from siblings like adb_list_apps (list all apps) and adb_launch (launch an app), making it reasonably clear this queries the currently visible app. However, it could benefit from mentioning it does not modify anything.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you want to know the foreground app), but provides no explicit when-to-use, when-not-to-use, or alternative tool guidance. Given the sibling set includes adb_launch and adb_list_apps, explicit differentiation would help, but the purpose is clear enough that an agent could infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. Installing an APK is a significant mutating operation that could modify/replace existing apps, require signature validation, or fail due to version conflicts. None of these behaviors are disclosed. The description is purely functional with zero behavioral context about what happens to the device or existing state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that communicates the essential purpose with zero waste. There is no filler, no redundancy, and the structure is clean. Being concise is appropriate here given the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool (installing software onto a device) with no annotations and no output schema, the description should provide more context. It doesn't mention what success looks like, what errors might occur, whether this replaces existing installations, or any device compatibility requirements. The tool complexity is moderate (2 params, 1 required), but the mutating nature and lack of structured metadata warrant a richer description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% — apk_path has no schema description while serial does ("device serial (host:port); omit if only one device"). The tool description clarifies that apk_path is a local file path, adding meaning beyond the bare schema property. However, it doesn't explain path format requirements, supported file types, or the relationship between apk_path and serial. Marginal value added over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description "Install an APK from a local file path onto the device" uses a clear verb (Install) with a specific resource (APK) and scope (from local file path onto device). It clearly distinguishes from siblings like adb_push (which transfers files) and adb_uninstall (which removes apps). It doesn't explicitly call out the sibling distinction, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you want to install an APK that exists at a local file path. However, there's no explicit when-to-use or when-not-to-use guidance, no mention of alternatives like adb_push-then-install, and no mention of prerequisites such as package compatibility or the serial requirement for multi-device setups. It's adequate but relies on the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The description does not disclose any side effects, whether it overwrites existing remote files, whether it requires the device to be connected/authorized, or what happens on failure. For a tool that modifies device filesystem state, the absence of such information is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and free of filler. Every word earns its place. This is appropriately minimal for a simple file-copy operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description is thin. It doesn't cover destination behavior (overwrite semantics), prerequisites (connected device), or common failure modes (nonexistent local path, permission denied). Sibling verbs like adb_install and adb_uninstall suggest a broader device-management context, and this simple description provides insufficient guidance for an agent deciding how to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% — the 'local' and 'remote' parameters have no descriptions in the schema. The description says 'local file' for local and 'to the device' for remote, which partially clarifies direction, but does not elaborate on path formats (device-relative vs absolute) or how the serial parameter interacts with multi-device setups beyond what the schema's serial description already states. The description adds some directional meaning but compensates only partially for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb+resource pair: 'Copy a local file to the device.' This is specific and unambiguous for an adb push operation. It distinguishes from sibling adb_pull (which copies device-to-local) though not explicitly naming it, and is clearly distinct from shell, reboot, and other sibling verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to transfer a local file to the device), but does not explicitly state when NOT to use it or name alternatives. With sibling tools like adb_pull and adb_install nearby, explicit guidance about distinguishing push from pull would strengthen this dimension, but the direction of transfer is clear enough to infer the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly implies a read-only operation, which matches adb semantics, but provides no detail on output format, whether properties are system/device-specific, or behavior when a filter matches nothing. The read-only implication is reasonably clear from 'Read device properties'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence: 'Read device properties (all, or filter by substring).' Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only property-listing tool with 2 optional parameters and no output schema, the description is close to adequate. It covers the main function and filter option but omits what the return looks like, which matters since there's no output schema to communicate that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; the 'serial' parameter is documented in the schema while 'filter' is not. The description adds meaning to 'filter' (filter by substring) which helps. However, no detail on filter syntax (case sensitivity, prefix vs substring matching) or on filter matching multiple properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Read device properties') with an explicit resource (device) and scoping option (all or filter by substring). It distinguishes this from siblings like adb_settings (settings vs generic properties) and adb_shell, though it doesn't explicitly name which sibling to prefer for property reads vs other reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. With 23 sibling adb tools ranging from screenshots to settings to shell, an agent has no basis to distinguish reading device properties from adb_settings or adb_shell. No mention of required device connection state or when the filter is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this tool may require an authorized/connected device, what happens on failure (offline device, no devices), whether output is large/needs filtering, or whether results are cached. For a read-only list operation, the risk is lower, but the absence of annotations plus minimal behavioral detail leaves transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that conveys purpose and the key parameter nuance with zero waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 2 params and no output schema, the description is reasonably complete in purpose. However, there is no output schema and no annotation coverage, so the description could add value by noting return format (package names vs full package info) or clarifying what 'all packages' vs 'third_party=true' produces in output. The tool is simple enough that this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (serial described, third_party not described). The description adds meaning to third_party ('user-installed only') which the schema lacks, compensating for the third_party gap. However, 'serial' is already fully described in the schema, and the description adds nothing about the omit-if-only-one-device behavior beyond what schema provides. Net: partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb+resource ('List installed packages') and clarifies the meaning of third_party=true ('user-installed only'). It distinguishes from siblings like adb_install/uninstall, though it doesn't explicitly differentiate from adb_shell (which could also list packages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case of listing installed packages but provides no explicit guidance on when to use this vs adb_shell with pm list commands, and no context on device requirements (device must be connected/authorized). No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. For a read-only listing tool, the lack of annotations is mitigated somewhat by the obvious non-destructive nature implied in the description, but it doesn't add behavioral context beyond what's in the name/schema. No risk disclosed, but for listing devices the risk is inherently low.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently communicates the tool's purpose and expected output. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description mentions the output fields (serial + state) which is helpful. However, it doesn't specify potential failure states (e.g., what happens when no devices are connected) or whether the output format is plain text vs structured. Aside from the output field hint, it's fairly minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there's nothing to document. Baseline for 0 params is 4, and the description appropriately focuses on the output (serial + state) rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List connected ADB devices with serial + state' uses a specific verb (List) and resource (ADB devices) with clear output scope (serial + state). It distinguishes from siblings like adb_screenshot or adb_reboot, which are clearly different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There's no guidance on when to use this tool versus alternatives. It doesn't explain that this is a diagnostic/prerequisite step before connecting or that it verifies availability of devices. No exclusions or alternative tool references provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation (dump recent lines) but doesn't disclose whether this requires specific device permissions, what the output format looks like, or how the 'recent' window is determined (ring buffer size, etc.). For a benign read-diagnostic tool this is moderately adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. 'Dump recent logcat lines (optionally grep-filtered)' is compact, front-loaded with the action, and adds the key optional behavior in a parenthetical. It's appropriately brief for a simple diagnostic tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only diagnostic tool with only 3 optional parameters and no output schema, the description is mostly sufficient. However, it doesn't clarify the interaction between 'lines' and 'filter' (whether filtering applies before or after the line limit), which is a meaningful operational detail an agent would need when invoking with both parameters. The absence of a device-requirement note is also a small gap but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'serial' has a description). The description adds meaning by explaining 'filter' as a 'grep-filter' for logcat output, and 'lines' as the count of recent lines. This goes beyond the schema, though the 'filter' parameter's format/recipe with 'lines' (does filtering happen before or after truncation?) could be clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Dump recent logcat lines') and mentions the grep-filtering option, which gives a clear sense of what it does. However, it doesn't explicitly distinguish it from sibling tools like adb_shell (which could also be used to run logcat) or other adb diagnostic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or exclusions are provided. The description implies usage for reading logcat output but offers no direction on when to prefer this over adb_shell, or any caveats about device requirements, buffering, or alternative diagnostic tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It explains the pairing mechanism (6-digit code with IP:port) which is helpful, but it doesn't disclose post-pairing expected behavior such as whether adb connect is then required, whether pairing is persistent across reboots, or state requirements (developer mode, wireless debugging enabled).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-formed sentence that packs the key information (Android 11+, wireless debugging, 6-digit code, IP:port, exact UI source quote) with no wasted words. The quoted source helps the agent know exactly where to look for the values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides the core pairing context but omits preconditions (developer options enabled, wireless debugging toggled on) and follow-up steps (adb_connect needed after pairing succeeds). It's adequate for basic invocation but leaves the end-to-end workflow implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for what the three parameters (host, port, code) mean. The description defines the code parameter contextually ('6-digit code') and implies host/port come from the pairing dialog, but it doesn't explicitly map each parameter to its source or give format guidance for host (IP vs hostname) — partial compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (pair), resource (Android 11+ device via Wireless debugging), and method (6-digit code + IP:port). It distinguishes from siblings like adb_connect and adb_disconnect by specifying the pairing-code workflow, though a slight overlap with adb_connect exists since both establish connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (for Android 11+ wireless debugging pairing) and quotes the exact UI prompt source. However, it doesn't explicitly contrast with adb_connect (which handles already-paired connections) or state when NOT to use this tool, leaving the distinction between pairing and connecting implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal the full pipeline (record → pull → path) and implies the output is a local file path rather than raw bytes. However, it doesn't disclose the default file location, that the file persists on disk, or that a device-side temp file is created/managed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the core action and states the full workflow compactly. No filler words. Could arguably add one more sentence about defaults without bloating it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 params with no output schema and no annotations, so the description is the sole source of behavioral info. It covers the main flow adequately, but given the absence of annotations and output schema, it would benefit from disclosing defaults (10s, /tmp path), max duration limit (180s), and that the return value is a file path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'serial' has a schema-level description). The description mentions N seconds and a local mp4, mapping loosely to 'seconds' and 'local_path', but doesn't define whether local_path is an absolute/relative path, file format requirements, or destination directory existence. It adds some value beyond the sparse schema but doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Record') with a specific resource ('screen') and describes the full workflow (record, pull to local mp4, return path). This distinguishes it from siblings like adb_screenshot (static capture) and adb_logcat (stream logging), though it doesn't explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing video over a duration, which contrasts with adb_screenshot for stills, but it doesn't explicitly state when to choose this vs alternatives. No exclusions or prerequisites (e.g., device must support screen recording) are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It conveys the tool is a read-only visual capture (clearly non-destructive by nature), which is somewhat implied by 'Capture the screen'. However, it doesn't disclose behavioral details like potential latency, whether it fails on locked/off screens, refresh timing, or that it returns a viewable image the agent can process — leaving some assumptions to the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, zero waste, immediately front-loaded with the action and output format. Every word carries meaning. This is near-ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 optional param, no output schema, read-only by nature), and the description adequately captures what it does. However, it could benefit from noting limitations (screenshot may fail or show blank on locked screens) or confirming the device must be powered on and unlocked. For a simple tool this is acceptable, but a small note on failure conditions would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% since the only parameter (serial) is fully described in the schema. The description adds nothing about the parameter, but the schema already documents 'device serial (host:port); omit if only one device', so a baseline 3 is appropriate given the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Capture the screen as a PNG image') and clarifies the purpose is so the agent can SEE the device, distinguishing it from sibling tools that operate on device data (getprop, settings, logcat). It clearly communicates the visual-offload intent, though it doesn't explicitly name a sibling alternative like adb_screenrecord for video capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage — capture the screen when you need visual context — but doesn't explicitly state when to use it vs alternatives. It doesn't mention exclusions (e.g., use adb_screenrecord for video) or context such as when screenshots fail (screen off, lockscreen). The intent is clear but not explicit about when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It notes this is 'advanced' and passes 'raw am args', implying it bypasses validation and can start arbitrary activities, which is meaningful context. However, it doesn't disclose failure modes (e.g., crashes if intent malformed, no error handling) or what happens with invalid args.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The 'advanced' flag, the raw-args note, and a concrete example all pack maximum signal into minimal length. Front-loaded with the core purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool (2 params, flat schema, no output schema) the description is reasonably complete for the core use case. However, for an 'advanced' raw-intent tool with no annotations and no output schema, it could add a warning about arbitrary-target risk, exit code/return behavior, or mention when it's inappropriate (e.g., use adb_launch for simple package launches). Gaps exist but the description covers the essential calling pattern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'args' is documented only by type (array of strings) with no description, while 'serial' has a description. The example clarifies that args are raw am arguments (e.g., '-n','pkg/.Activity'), adding value beyond the schema, but it doesn't fully document all the forms args can take or the format expectations beyond the single example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it fires a generic Android intent via `am start` and that it's 'advanced' requiring raw am args. It clearly uses a specific verb+resource (fire intent via am start), and distinguishes itself as the raw/generic path among siblings like adb_launch and adb_open_url, though it doesn't explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is the advanced/generic tool among a large family of adb tools, and the example clarifies it expects window-mapper-style raw args like ['-n','pkg/.Activity']. However, it doesn't explicitly state when to prefer this over adb_launch or adb_open_url, nor any exclusions or safety cautions for the advanced mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates this is an input injection action (pressing keys), which implies it sends events to the device. It doesn't disclose whether key injection requires specific authorization, whether certain keys fail on unrooted devices, or whether the injection targets the foreground app only. Minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and key examples. Every element earns its place. Slightly dense with the long key list, but the list itself is informative and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is reasonably complete. It covers what keys are accepted and both input formats. It's missing guidance on serial semantics (present in schema) and edge cases like invalid keys, but given the simplicity this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (serial is described, key is not). The description partially compensates by listing valid key names and noting numeric keycodes are accepted, which adds syntax detail beyond the bare 'key: string' schema. However, it doesn't clarify the numeric keycode range or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource+mechanism: 'Press a remote/D-pad key by name... or numeric keycode'. Clearly distinguishes from siblings like adb_tap (screen coordinate) and adb_text (text input). Lists concrete key examples that disambiguate the input style.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what keys can be pressed and that both names and numeric keycodes are accepted, which implies usage context. However, it doesn't state when to prefer this over adb_tap or adb_shell for input, nor any exclusions. The serial 'omit if only one device' guidance is in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/mosesmrima/adb-tv-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server