put_setting

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. It does not disclose that writing settings typically requires WRITE_SETTINGS permission or root, whether the change is persistent across reboots, or what happens on an invalid namespace/key. For a mutation tool with zero annotation coverage 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.

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

Two tight sentences with the core action front-loaded and the namespace constraint immediately after. No filler, though the extreme brevity is partly the source of the missing detail rather than deliberate economy.

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

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

An output schema exists, so return values need not be explained. However, for a 4-parameter mutation tool with no annotations, the description omits prerequisites (permissions/root), the role of the serial parameter for multi-device setups, and any usage context — leaving the agent under-equipped to call it correctly.

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

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

Schema description coverage is 0% and there are 4 parameters, so the description must compensate. It clarifies the namespace enum values ('system' | 'secure' | 'global') but says nothing about key, value, or the optional serial parameter, which is entirely undocumented in both schema and description.

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

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

States a specific verb and resource ('Write an Android setting') and enumerates the valid namespace values, which distinguishes it from sibling read/write tools like get_setting and set_prop. It does not, however, explain what an Android setting is or how it differs from set_prop for an agent unfamiliar with the platform.

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

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

No when-to-use guidance is given. The description never says how this differs from set_prop, run_shell, or get_setting, nor whether the device must be rooted or the setting pre-exist. The agent must infer usage entirely.

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