Skip to main content
Glama
Sign In
NexusAndroid

NexusAndroid

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

launch

Opens an Android app by package name or fragment and optionally navigates to a specific screen or action, then reports the foreground screen.

Instructions

Open an app by package name (com.whatsapp) or a fragment of it ("whatsapp", "maps"), then show it. Precise screen: action (android.settings.WIFI_SETTINGS, android.intent.action.VIEW…) and/or data (URI or deep link), extras {name: string, integer or boolean}; app then limits the target to that app. The target is resolved first, then reported with the new foreground. Calling, sending or paying directly (CALL, auto-send extras, payment actions and links): confirm=true, set only on the user's explicit order for this intent, plus accord= returned for THIS exact intent once the user said yes to its summary. Banking, payment and identity apps: never opened by an intent (launch(app) opens them for reading). then: what to show once opened, as in act (auto by default: elements, the image only when nothing is readable; both: image and elements).

Input Schema

NameRequiredDescriptionDefault
appNo
dataNo
thenNoauto
accordNo
actionNo
extrasNo
confirmNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.10
    • addedInput schema / properties / then
      Added value: +{
+  "default": "auto",
+  "enum": [
+    "auto",
+    "both",
+    "image",
+    "elements",
+    "changes",
+    "none"
+  ],
+  "title": "Then",
+  "type": "string"
+}
  2. Changed9 schema fields changedv0.9.3
    • addedInput schema / properties / accord
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Accord"
+}
    • addedInput schema / properties / action
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Action"
+}
    • addedInput schema / properties / app / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / app / default
      Added value: +null
    • removedInput schema / properties / app / type
      Removed value: -"string"
    • addedInput schema / properties / confirm
      Added value: +{
+  "default": false,
+  "title": "Confirm",
+  "type": "boolean"
+}
    • addedInput schema / properties / data
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Data"
+}
    • addedInput schema / properties / extras
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "integer"
+          },
+          {
+            "type": "boolean"
+          }
+        ]
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Extras"
+}
    • removedInput schema / required
      Removed value: -[
-  "app"
-]
  3. First observedv0.3.1

TDQS

A3.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses how targets are resolved, that the new foreground is reported, and that direct calling/sending/paying requires explicit user confirmation plus a matching accord token. It also states the banking/payment/identity restriction and explains display behavior after launch.

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

Conciseness3/5

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

The description is front-loaded with the core action, but it becomes a dense run-on covering several unrelated concerns without bullets or clear separation. The content is useful, but the structure makes it harder to scan than necessary.

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

Completeness4/5

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

For a seven-parameter, no-output-schema tool, the description covers most operational behavior, safety constraints, and parameter meanings. It is not fully complete because it does not fully document return values or all then enum options.

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?

With 0% schema description coverage, the description compensates well by explaining app, data, action, extras, confirm, accord, and most of the then enum. It still leaves the changes and none values of then unexplained, so parameter semantics are strong but not complete.

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?

The first sentence gives a clear verb and resource: open an app by package name or fragment, then show it. It also describes precise-screen launching via action/data/extras. It only partially distinguishes itself from siblings such as act or apps, so it is clear but not fully differentiated.

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 description gives important conditional guidance for sensitive actions: confirm=true and accord are required for calling, sending or paying directly, and banking/payment/identity apps must not be opened by intent. However, it does not clearly state when to use launch versus siblings like act, look, apps, or web for ordinary navigation.

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