getstoreready-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation5/5
Each tool targets a distinct action: Google Play push lifecycle (preview, push, status, link), screen content (images, text, design), store listings (languages, listing text), and auxiliary (credits, translation estimation). No two tools share the same purpose.
Naming Consistency4/5
Tools follow a consistent verb_noun snake_case pattern (e.g., push_to_google_play, update_screen_text). Minor inconsistencies: some tools use 'get' vs 'list' (get_google_play_link vs list_store_languages), and 'bulk_update_designs' deviates slightly from the verb_noun structure.
Tool Count5/5
15 tools is appropriate for a store management server. Each tool serves a specific function without being overwhelming or insufficient.
Completeness3/5
Covers core workflows for Google Play push, screen editing, and listing management. Notable gaps: no App Store push initiation (only status), no actual translation tool (only estimation), and no tool to delete screens or manage screens beyond design/ text.
Average 3.4/5 across 15 of 15 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. 'Update' implies mutation, but it does not disclose whether it performs partial or full replacement, permission requirements, or side effects like triggering jobs. The description lacks essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it is too brief for a tool with 10 parameters. It front-loads the action but omits important details, making it insufficient for proper tool usage.
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?
Given 10 parameters, no output schema, and no annotations, the description is incomplete. It does not explain parameter optionality, update behavior, or return value. The context signals indicate high complexity, yet the description does not address it.
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 only 10%, yet the description adds minimal parameter meaning. Only 'locale' is hinted at via 'in one language'. The other 9 parameters (appName, keywords, etc.) are not explained or linked to ASO text fields.
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?
The description clearly states it updates store listing/ASO text for a project in one language, aligning with the tool name. It implies distinction from siblings like get_listing (read) and push_to_google_play (publishing), but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives (e.g., for multiple languages or bulk updates). It mentions 'in one language' but does not explain constraints or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose behavior. It mentions waiting but omits polling mechanics, timeouts, error handling, or what 'status' includes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with optional clause. No superfluous text.
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?
For a tool that may wait, missing timeout details and output structure. Low schema coverage and no output schema increase burden, but description remains minimal.
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?
With 0% schema coverage, description should explain parameters. It only hints at 'wait' functionality; projectId and jobId are not described.
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?
The description clearly states it returns the status of a Google Play push job, with an optional wait. It is specific and distinguishes from sibling tools like push_to_google_play.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_app_store_push_job. No mention of prerequisites or when to use the wait option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'List' implying a read operation but does not disclose authentication requirements, rate limits, or the meaning of 'active and available'.
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?
The description is a single, clear, and concise sentence with no unnecessary words. It is front-loaded with the verb and resource.
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?
Although the tool is simple, the description lacks details about return format, pagination, error handling, and what constitutes 'active and available' languages. There is no output schema to supplement, so these gaps are significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'projectId' with no description (0% schema description coverage). The description only vaguely references 'for a project' without explaining the format, constraints, or semantics of the projectId.
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?
The description uses a specific verb 'List' and clearly identifies the resource 'store languages' for a project. It distinguishes from sibling tools like 'add_store_language' and 'update_listing', which are write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or context. For example, it does not mention that projectId must be a valid project or that the tool is read-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states it 'updates' without detailing behavioral traits (e.g., idempotency, permissions, error behavior, or side effects). Minimal disclosure beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. Front-loaded with action and scope. However, omission of key details (like image background) slightly reduces clarity.
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?
Complex parameters (nested background, textUpdates array) are barely explained. No output schema, no description of return values or error cases. The description is insufficient for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context by mentioning 'background color/gradient' and 'multiple text layers', but omits the image background option present in the schema. With 0% schema description coverage, this partially compensates but is incomplete.
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?
The description clearly states the tool updates a screen design, specifying it can modify background color/gradient and/or multiple text layers at once. It distinguishes from sibling tool 'update_screen_text' by implying it handles both background and text, though could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'update_screen_text' or other siblings. The description does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read-only operation ('Get'), but does not disclose behavioral traits like authentication requirements, rate limits, or error responses (e.g., if locale is invalid). Basic transparency is provided but insufficient for advanced safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 11 words, front-loaded with the core action. Efficient, though minor additions (e.g., clarifying output or constraints) could enhance clarity without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with 2 parameters and no output schema, the description is minimally adequate. It covers the main purpose but omits return value format, possible errors, and any prerequisites. Given the lack of annotations and output schema, more detail would benefit completeness.
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 50%: locale has a brief description, projectId has none. The description mentions 'project' and 'locale' but does not add meaning beyond the schema. It fails to clarify what projectId represents or what constitutes a valid locale, leaving the agent with gaps.
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?
The description clearly states it retrieves store listing/ASO text for a project in one locale. The verb 'Get' and resource 'store listing / ASO text' are specific, and the tool's read nature is implicitly distinguished from siblings like push_to_google_play and update_listing, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as update_listing or list_store_languages. No prerequisites or exclusions are mentioned, leaving the agent to infer context from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses bulk update behavior but omits details on atomicity, idempotency, error handling, rate limits, or reversibility. Minimal beyond obvious semantics.
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?
Two sentences, front-loaded with key information, includes an illustrative example. Zero fluff or redundancy.
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?
Given the tool's complexity (3 background types, textUpdates array, screenIndices, locale) and no output schema, description is too sparse. Does not explain full parameter behavior or return value. Incomplete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40%; description adds value by naming background and text updates with an example. However, it does not explain the complex structure of background (solid/gradient/image) or textUpdates array. screenIndices and locale are not mentioned, leaving gaps.
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?
Description uses specific verb 'Apply' and identifies resource 'background and/or text updates' across multiple or all screens. Example clarifies the intended use. Distinguishes from sibling single-screen tools like update_screen_design and update_screen_text by emphasizing bulk operation.
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?
Description implies use when needing uniform background/text across screens, but lacks explicit guidance on when to use vs alternatives (e.g., single-screen updates). No prerequisites or exclusions stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the wait feature but does not disclose key behavioral traits like read-only nature (implied but not explicit), permissions, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence. It avoids fluff but may be too terse, lacking necessary detail for some parameters and behavior.
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?
No output schema provided. The description does not explain the response format, possible status values, or what happens when a job is not found. The wait option is mentioned but not detailed. The tool is incomplete for an agent to use effectively.
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%. The description adds meaning for the 'wait' parameter but leaves projectId and jobId unexplained beyond their names. This is insufficient for an agent to understand their roles.
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?
The description clearly states the action ('Get status') and the resource ('App Store push job'). It distinguishes from siblings like get_google_play_push_job by specifying App Store.
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?
The description implies usage for checking status of an App Store push job, with an optional wait. The tool name and context make it clear when to use this versus Google Play siblings, but no explicit exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the general purpose. It omits whether the operation is read-only, potential side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the main action, including necessary prerequisites. It is efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check tool with one parameter and no output schema, the description covers prerequisites and purpose. However, it lacks details about what the output contains and potential error states, leaving gaps.
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?
The schema has 0% description coverage for the single parameter (projectId). The description does not elaborate on the parameter's format or meaning beyond its name, missing an opportunity to add value.
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?
The description clearly states the tool returns Google Play Console link status for a project, specifying the context (credential, package name). It distinguishes from siblings like push_to_google_play and get_google_play_push_job.
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?
The description explicitly notes prerequisites: requires Premium/Pro and prior credential setup in the web UI. It does not mention alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states it estimates cost, with no mention of side effects, permissions, rate limits, or other behaviors. Minimal disclosure for a tool that likely requires access to project data.
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?
Two sentences with no fluff. First sentence states purpose, second provides usage guidance. Front-loaded and efficient.
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?
Despite having 8 parameters and 3 required, the description is very brief. It does not explain what the output contains (e.g., cost structure, units) or how to interpret the estimate, leaving gaps for the agent. Incomplete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, description does not add significant meaning beyond the schema. It hints at content types (listing copy, screen text) but does not detail parameters like projectId, fromLanguage, toLanguage, or listingFields. At baseline 3, it provides adequate but not enhanced semantics.
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?
Description clearly states it estimates AI credit cost for translation of listing copy and/or screen text. It distinguishes from siblings by specifying 'before translate_project', implying a unique role.
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 instructs to always call before translate_project when credits matter, providing clear when-to-use guidance. Lacks explicit when-not-to-use or alternatives, but the instruction is direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It implies a read operation (review) but does not explicitly state it is non-destructive. It lists what is reviewed but does not describe the return format or side effects. With no output schema, the agent gets limited insight into expected results.
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?
Two sentences, zero waste. The first sentence immediately states the purpose and key components. The second sentence provides a clear usage hint. Every word is necessary and informative.
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?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is minimal. It omits parameter details, expected output, and behavioral specifics. For a preview tool that likely returns a structured report, the lack of detail reduces its completeness for an agent.
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 only 14% (only fetchRemoteDiff has a description). The description mentions 'optional remote diff' corresponding to fetchRemoteDiff, but it does not explain locales, displaySlots, includeAppIcon, includeListing, or includeScreenshots. Since coverage is low, the description should compensate but fails to add meaning for most parameters.
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?
The description clearly states the tool reviews what would be pushed to Google Play, listing specific components (blockers, warnings, locale plans, optional remote diff). It explicitly distinguishes from the sibling push_to_google_play by saying 'Call before push_to_google_play'.
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?
The description gives a clear usage directive: 'Call before push_to_google_play'. This tells the agent when to use it. However, it does not provide exclusions or mention alternatives like get_google_play_push_job, which might serve a different purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. However, it does not explain the asynchronous nature, whether a job ID is returned, or any potential side effects. The user is left to infer that it enqueues but not what happens next.
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?
Three short sentences, each adding distinct value: purpose, prerequisites, ordering. No redundant phrasing.
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?
Given the tool's complexity (8 params, no output schema, no annotations), the description is too sparse. It lacks information on return values, parameter details, and how to handle the enqueue process (e.g., polling via wait parameter). Sibling tools exist but are not referenced beyond preview.
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?
Only 2 of 8 parameters have descriptions in the schema. The description mentions 'listing, screenshots, app icon' which hints at includeListing, includeScreenshots, includeAppIcon, but does not explain the rest (locales, displaySlots, skipUnchanged, wait, projectId). This is inadequate for a tool with 8 parameters.
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?
The description clearly states the tool enqueues a Google Play push for listing, screenshots, and app icon, and distinguishes it from the sibling preview_google_play_push by requiring that call first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions requirements (Premium/Pro, linked app) and the recommended order (call preview first). This provides clear guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states only that it checks balance and availability, but does not disclose whether it is read-only, consumes credits, or requires authentication. The behavior is implied by the name but not explicitly stated.
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?
The description is a single sentence of 11 words, no filler, and starts with the verb 'Check'. It is maximally efficient for the amount of information conveyed.
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?
Given the complexity (no parameters, no output schema), the description is brief but lacks details on the return format or what the response contains. It does not specify whether it returns a numeric balance, a boolean, or other structure, leaving ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params), so schema coverage is 100%. The description adds no parameter-specific information, but with zero parameters, no additional explanation is needed. Baseline 4 is appropriate.
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?
The description clearly states the tool checks 'AI credit balance and whether translation is available', which is a specific verb-resource pair. It distinguishes from sibling tools that focus on pushing, updating, or listing store languages, as this is the only credit check tool.
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?
No explicit guidance on when to use or when not to use is provided. However, the tool is simple with no parameters, and usage is implied by its name and description. Sibling tools like 'estimate_translation' might require credits, but no context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns images and a JSON index, implying a read-only operation with no side effects. However, it does not disclose any rate limits, size constraints, authentication requirements, or format details of the images, leaving some ambiguity for an AI agent.
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?
The description consists of two concise sentences. The first immediately states the primary function, and the second provides a workflow tip. No superfluous information is included, and the most critical details are front-loaded.
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?
The description explains the return value (images and JSON index) and its role in a larger workflow. However, it omits details about the index structure, whether screenIndices is optional (though inferred from the schema), and the significance of locale. Considering the tool's simplicity and lack of output schema, the description is mostly complete but leaves minor gaps.
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 low (33%), with only the screenIndices parameter having a brief description. The tool description adds meaning about the output (images and index) but does not explain the purpose or constraints of the projectId or locale parameters. As a result, the description fails to compensate for the underdocumented schema.
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?
The description clearly states the tool returns raw app screenshot images and a JSON index mapping images to screen indices. It uses a specific verb ('return'), identifies the resource ('raw app screenshot images'), and hints at its role in a workflow with 'update_screen_text', distinguishing it from sibling tools that involve push or listing operations.
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?
The description explicitly directs to use this tool with client vision to read UI content before calling update_screen_text, providing clear context for when to use it. It does not, however, mention when not to use it or alternatives, but given the sibling list includes only update_screen_text as a closely related tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the tool's non-translation behavior but omits details like whether existing languages are duplicated, prerequisites (project existence), or side effects. The safety profile is implied but not explicit.
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?
The description is a single sentence that front-loads the purpose and adds critical workflow context without unnecessary words. Every word earns its place.
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?
Given the simple parameter set and no output schema, the description covers the core purpose and workflow adequately. Lacks information on return values or error conditions, but for a straightforward add tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2/3 parameters have descriptions). The description adds a usage example ('de_DE for German') that reinforces languageCode meaning, but does not explain projectId. Baseline is 3 due to moderate coverage; description adds marginal value.
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?
The description explicitly states the action ('Add'), the resource ('store languages to a project'), provides an example code, and distinguishes from translation by noting 'Does not translate'. This clearly differentiates it from sibling tools like translate_project.
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?
The description gives clear context on when to use the tool (adding languages) and directs to call translate_project after, indicating a sequential workflow. However, it does not explicitly contrast with sibling tools like list_store_languages, missing an opportunity for exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses preservation of highlight styling when runs are used, the optional highlightPhrase behavior, and the prerequisite of get_screens. This provides good insight beyond what the schema offers.
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?
Three sentences, each efficient and valuable: purpose and scope, styling behavior and prerequisite, optional parameter. No wasted words.
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?
Covers key aspects: operation, target layer, styling preservation, optional parameter, need for prior call. Lacks detail on locale and other params' effects, but overall adequate for a fairly complex mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%. The description adds meaning to highlightPhrase (controlling which word gets accent) and implies that layerId and styling info come from get_screens. It does not detail locale or other params, but compensates well for the 50% coverage.
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?
The description clearly states the tool updates marketing text on a specific type of layer, distinguishing it from in-app UI text. The sibling tools are unrelated (app store pushes, screen images, etc.), so it stands out as the only text update tool.
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?
The description advises calling get_screens first to understand styling, and explains the optional highlightPhrase parameter. It implies when to use (update marketing text) and what not to use for (in-app UI), but does not explicitly exclude alternatives, though none are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![getstoreready-mcp MCP server](https://glama.ai/mcp/servers/getstoreready/getstoreready-mcp/badges/card.svg)](https://glama.ai/mcp/servers/getstoreready/getstoreready-mcp)

Score Badge

Copy to your README.md:

[![getstoreready-mcp MCP server](https://glama.ai/mcp/servers/getstoreready/getstoreready-mcp/badges/score.svg)](https://glama.ai/mcp/servers/getstoreready/getstoreready-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/getstoreready/getstoreready-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server