Read an app's public Google Play contact email, website, and phone via API instead of automating the console form.
Read the public contact details of the app's Play listing.
These fields (contactEmail, contactWebsite, contactPhone) ARE covered by the API — do not automate the console form for them.
| Name | Required | Description | Default |
|---|---|---|---|
| package_name | 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?
No annotations are provided, so the description carries the full burden. It discloses that these fields are API-covered (preventing a wasteful console-automation detour), which is real behavioral value, but it says nothing about auth requirements, rate limits, or whether the listing must exist/is published. Read-only nature is only implied by 'Read'.
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 short sentences, purpose front-loaded, zero filler. The second sentence is somewhat tangential but earns its place by preventing a wrong approach.
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-value explanation is unnecessary, and this is a simple one-parameter read. The description covers purpose and the API-vs-console caveat; the only real omission is guidance on the package_name parameter.
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?
The single parameter package_name has 0% schema description coverage, and the description only indirectly refers to 'the app's Play listing' without defining the package name format or where to obtain it. The description does not compensate for the documentation gap.
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: 'Read the public contact details of the app's Play listing,' and even enumerates the three returned fields. The read/set distinction from the sibling play_set_contact_details is inferable from the verb, though the sibling is never named outright.
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?
The second sentence gives a when-not-to-use rule ('do not automate the console form for them'), which is genuinely useful routing guidance. However, it addresses a browser-automation fallback rather than competing sibling tools, and there is no stated precondition or pointer to play_set_contact_details for the write path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.