Android Studio MCP

Overview Schema Source Related Servers Discussions Admin

Run configuration

ide_run

Run or debug an Android Studio run configuration, equivalent to toolbar buttons, and deploy it to the IDE's selected device. Defaults to the active configuration.

Instructions

Run or debug a run configuration in Android Studio, like its toolbar buttons (deploys to the IDE's selected device). Defaults to the selected configuration.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ide_run"
  }
}

Input Schema

Name	Required	Description
`name`	No
`debug`	No
`project`	No	Open project name or base path. Defaults to the project containing `path`, else the active one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 26, 2026

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose a key side effect: it deploys to the IDE's selected device, taking the action out of the pure-IDE realm. It omits whether the call blocks until deployment finishes, what it returns, how to observe progress (job_status exists as a sibling), and what permissions or setup are required.

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

Conciseness4/5

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

Two short sentences, front-loaded with the action and side effect before the default behavior. The parenthetical 'like its toolbar buttons' earns its place by conveying device deployment, though it could be tightened.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a side-effecting launch tool with no annotations and no output schema, the description is just adequate: it explains what happens but leaves return values, async/blocking behavior, and failure modes unaddressed. An agent could call it, but would not know how to confirm the deployment succeeded.

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

Parameters3/5

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

Schema coverage is only 33% ('project' documented in schema only), so the description must compensate. It partially does: 'Run or debug' explains the `debug` boolean, and 'Defaults to the selected configuration' explains `name`'s default. `project` semantics beyond the schema's own text are not extended, keeping this at minimum-viable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (run/debug) and resource (a run configuration in Android Studio), and clarifies the mechanism ('like its toolbar buttons'). It stops short of naming how it differs from close siblings such as run_app, app_launch, gradle_run, or ide_run_configurations, so the agent must infer the distinction.

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

Usage Guidelines3/5

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

The closing sentence 'Defaults to the selected configuration' implies the tool can be invoked with no arguments and will act on the IDE's current selection, which is useful usage context. However, there are no explicit when-to-use/when-not statements and no routing to alternatives like app_launch or gradle_run.

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