Grant runtime permissions like android.permission.CAMERA to Android app packages via pm grant, enabling access to protected device features.
Grant a runtime permission, e.g. 'android.permission.CAMERA' (pm grant).
| Name | Required | Description | Default |
|---|---|---|---|
| serial | No | ||
| package | Yes | ||
| permission | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses little beyond naming `pm grant`. It does not say whether the grant takes effect immediately or requires an app restart, whether it persists across reboots, what happens if the permission is not declared in the manifest, or what errors look like.
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?
A single tight sentence that front-loads the action and packs in the permission format plus the underlying ADB command. Nothing wasted.
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, but this is a state-changing device operation with no annotations, no parameter documentation, and no prerequisites or side-effect disclosure. It is under-specified for a mutation tool.
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% across three parameters. The description clarifies only the `permission` parameter via an example string; the `package` format (application ID) and the `serial` device-selector parameter are left entirely undocumented.
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 (grant) and resource (runtime permission) and even names the underlying command `pm grant`, with a concrete example permission string. It does not explicitly distinguish itself from the sibling revoke_permission, but the action is unambiguous.
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?
Usage is only implied: the agent can infer this applies to granting runtime permissions to an installed package. There is no statement of when to use this versus revoke_permission, nor prerequisites such as the target app being installed or the permission being declared in the manifest.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.