Skip to main content
Glama
denshinji
by denshinji

validate_edit

Read-only

Check a Play Store edit for validation errors before committing, so staged changes are reviewed without publishing them.

Instructions

Asks Play to check an edit without committing it.

Input Schema

NameRequiredDescriptionDefault
edit_idYes
package_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description is consistent with that ('without committing it'). It adds the useful detail that the check is performed by Play externally, but doesn't disclose what validation results look like, whether failures throw or return, or any rate/permission constraints.

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?

A single front-loaded sentence with no wasted words. The core behavior and the key non-committing constraint are stated immediately.

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

Completeness2/5

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

With no output schema and 0% schema description coverage, the description should explain what validation returns, how failures are surfaced, and what package_name is for. It leaves an agent unable to predict the result or correctly populate the optional parameter.

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

Parameters2/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 for the two parameters, yet it says nothing about edit_id or package_name. At best 'an edit' loosely hints at edit_id; package_name is entirely unexplained.

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?

States a specific verb ('check') and resource ('an edit'), and the phrase 'without committing it' implicitly distinguishes it from commit_edit. However, it doesn't name the sibling or clarify what 'check' entails (syntax validation vs. policy review).

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?

'Without committing it' implies this is a pre-commit validation step, which gives some usage context. But it never explicitly says when to use this versus commit_edit or edit_summary, nor whether validation is required before committing.

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