Skip to main content
Glama
Sign In
Flutter Lamp

Flutter Lamp

by itsonu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Prefer a wireless device transport

ensure_tcp_device
Idempotent

Reports Android device transports and recommends one, preferring TCP to keep the Flutter VM Service tunnel stable. Set promote:true to switch a USB device onto TCP via adb.

Instructions

Report Android device transports and recommend one, preferring wireless. A flutter run started on a USB transport loses its VM Service tunnel when the cable moves; one started on a TCP transport does not. Read-only by default. With promote:true it runs adb tcpip and adb connect to put a USB-attached device on a TCP transport — that restarts adbd on the device, needs the cable once, and is reversible with adb usb. Android-only: reports adbAvailable:false and changes nothing on iOS, desktop or web targets.

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": "ensure_tcp_device"
  }
}

Input Schema

NameRequiredDescriptionDefault
portNoDevice-side TCP port.
serialNoWhich USB device to promote. Defaults to the first promotable one.
promoteNoPut a USB-only device onto a TCP transport. Changes device state.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.21.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructiveHint=false and idempotentHint=true but leave readOnlyHint=false unexplained; the description resolves that by stating 'Read-only by default' and disclosing the mutation's side effects — adbd restarts on the device, the cable is needed once, and `adb usb` reverses it. That is material behavior beyond what the annotations convey, and it does not contradict them.

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?

Three sentences, front-loaded with the read-only report behavior before the promote path and platform caveats. Dense but essentially waste-free; the clause about the VM Service tunnel is justification, not filler, though the sentence count could be trimmed slightly.

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?

For a tool with no output schema and an optional state-changing mode, the description covers the return signal (adbAvailable:false on unsupported platforms), the mutation's preconditions and reversibility, and the default safety posture. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that promote performs `adb tcpip`/`adb connect`, and that serial selects which USB device to promote. Port is left to the schema, which fully documents it, so this is a modest but genuine uplift.

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 verb and resource ('Report Android device transports and recommend one, preferring wireless') and then scopes the mutation mode ('With promote:true it runs adb tcpip and adb connect'). No sibling tool overlaps this behavior, so an agent can route to it unambiguously.

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

Usage Guidelines5/5

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

Explicitly frames when the tool matters (a `flutter run` on USB loses its VM Service tunnel when the cable moves), what the default is (read-only), when to escalate (promote:true), when it does NOT apply (iOS, desktop, web), and how to undo it ('reversible with `adb usb`'). This is when/when-not/alternative guidance in full.

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

Deploy Server

Other Tools