Skip to main content
Glama
Sign In
NexusAndroid

NexusAndroid

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

settings

Idempotent

Read or change Android phone options including Wi-Fi, Bluetooth, DND, brightness, and volume; provide a value to update and verify the state.

Instructions

Reversible phone settings: without value, reads the state; otherwise changes it, then reads it back. wifi/bluetooth/data/location/nfc: on|off (turning Wi-Fi off is refused when the link goes through it). dnd (do not disturb): on|off|priority|alarms. brightness: 1-100 (%) or auto. volume: 0-100 (%, media).

Input Schema

NameRequiredDescriptionDefault
nameYes
valueNo

Output Schema

NameRequiredDescriptionDefault
nameYes
textYes
valueYesvalue read back on the phone after any change
changedYestrue if a value was requested (change sent, then read back)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.9.3
    • changedOutput schema / properties / changed / description
      Previous value: -"true si une valeur a été demandée (changement envoyé, puis relu)"New value: +"true if a value was requested (change sent, then read back)"
    • changedOutput schema / properties / value / description
      Previous value: -"valeur relue sur le téléphone après le changement éventuel"New value: +"value read back on the phone after any change"
  2. Changed1 schema field changedv0.4.1
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "changed": {
+      "description": "true si une valeur a été demandée (changement envoyé, puis relu)",
+      "title": "Changed",
+      "type": "boolean"
+    },
+    "name": {
+      "title": "Name",
+      "type": "string"
+    },
+    "text": {
+      "title": "Text",
+      "type": "string"
+    },
+    "value": {
+      "description": "valeur relue sur le téléphone après le changement éventuel",
+      "title": "Value",
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "value",
+    "changed",
+    "text"
+  ],
+  "title": "SettingResult",
+  "type": "object"
+}
  3. First observedv0.3.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover idempotency, non-destructiveness and non-read-only status, and the description adds real value on top: changes are reversible, the state is read back after mutation, and turning Wi-Fi off is conditionally refused. It stops short of noting permission requirements or what happens on an invalid value/capability that doesn't exist on the device.

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

Conciseness5/5

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

Four short lines, front-loaded with the read/write rule, then per-setting grammars grouped by kind, then the single edge case as a parenthetical. Every clause carries information; nothing is repeated from the schema or annotations.

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?

With an output schema present, the description needn't detail return values, and stating the state is read back after a change is enough. Minor gaps remain around failure modes (invalid value, missing hardware, persistence timing), but nothing that would cause a wrong call.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden, and it does: it enumerates the accepted value grammar for each enum member (on|off for radios, on|off|priority|alarms for dnd, 1-100 or auto for brightness, 0-100 media for volume). Without this the free-form string 'value' would be guesswork.

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/resource pairing ('Reversible phone settings') and immediately disambiguates the dual mode: without value it reads, with value it writes then reads back. That is far more precise than the bare name 'settings' and distinguishes it from siblings like info or look.

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

Usage Guidelines4/5

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

Explicitly says when the tool reads vs writes ('without value, reads the state; otherwise changes it'), and calls out the one refusal condition (turning Wi-Fi off when the link goes through it). It does not name an alternative tool or state prerequisites, which keeps it short of a 5.

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