The pabal-web-mcp server bridges ASO (App Store Optimization) and Web SEO data, enabling you to build and manage synced websites from App Store Connect and Google Play Console data.
ASO ↔ Web Conversion
Convert raw ASO pull data into structured public website format (locale JSONs, landing features, screenshot captions)
Prepare structured public data back into store-push-ready format with field length validation
ASO Optimization & Validation
AI-driven ASO optimization using saved keyword research data across primary and secondary locales (2-stage workflow)
Validate ASO metadata against App Store / Google Play field limits, detect duplicate keywords and invalid characters, with optional auto-fix
Keyword Research
Plan, execute, and persist keyword research per locale and platform (iOS/Android), storing results for use in optimization
Screenshot Localization & Processing
Translate app screenshot text into multiple languages using the Gemini API, with dimension validation
Resize and adapt screenshots for different device types (phone/tablet)
Content Creation
Generate static HTML blog posts with metadata, matching existing writing style, supporting multiple locales and app/developer categories
App Icon Generation
Generate app icon assets in required sizes
App & Project Management
Search registered apps by slug, bundleId, packageName, or name
Guide the full project initialization flow from ASO pull data to public product structure
Allows syncing and converting App Store Connect data for web SEO, including tools for keyword research and ASO (App Store Optimization) data management.
Enables the conversion of Google Play Console data for web SEO purposes, supporting the creation of synced websites and ASO data management.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@pabal-web-mcp Convert my App Store metadata into an SEO-optimized blog post"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for ASO ↔ Web SEO data conversion.
Build synced websites from App Store Connect and Google Play Console data.
💡 Example: labs.quartz.best
npm install pabal-resource-mcpRequirements: Node.js >= 18, pabal-store-api-mcp
Related MCP server: aso-mcp
{
"mcpServers": {
"pabal-resource-mcp": {
"command": "npx",
"args": ["-y", "pabal-resource-mcp"]
}
}
}For keyword research, add mcp-appstore:
{
"mcp-appstore": {
"command": "node",
"args": ["/PATH/TO/external-tools/mcp-appstore/server.js"],
"cwd": "/PATH/TO/external-tools/mcp-appstore"
}
}Set dataDir in ~/.config/pabal-mcp/config.json:
{
"dataDir": "/path/to/pabal-web"
}Category | Tools |
ASO |
|
Apps |
|
Screenshots |
|
App Icon |
|
Content |
|
See documentation for details.
MIT
Unified ASO + SEO management interface. Visit →
Converts ASO data from pullData to public/products/[slug]/ structure.
IMPORTANT: Always use 'search-app' tool first to resolve the exact slug before calling this tool. The user may provide an approximate name, bundleId, or packageName - search-app will find and return the correct slug. Never pass user input directly as slug.
This tool:
Loads ASO data from .aso/pullData/products/[slug]/store/ (path from ~/.config/pabal-mcp/config.json dataDir)
Generates per-locale conversion prompts to map fullDescription into structured locale JSON (template intro/outro + landing features/screenshots captions)
Next steps (manual): paste converted JSON into public/products/[slug]/locales/[locale].json and copy screenshots from .aso/pullData if needed
The conversion from unstructured to structured format is performed by Claude based on the conversion prompt.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's multi-step process (loading data, generating prompts, manual next steps), data sources (config.json dataDir), and transformation method (Claude-based conversion). However, it doesn't mention potential errors, performance characteristics, or authentication needs.
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?
The description is well-structured with clear sections: purpose statement, important usage warning, numbered steps of the process, and clarification about the conversion method. Every sentence serves a distinct purpose - no redundancy or filler content. The critical warning is appropriately front-loaded.
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?
Given the tool's complexity (multi-step data transformation with manual follow-up), no annotations, and no output schema, the description provides substantial context about the process, data flow, and prerequisites. However, it doesn't describe what happens on tool failure or what the immediate output looks like (though it explains the manual next steps).
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 schema has 100% description coverage for the single parameter 'slug', but the description adds significant value beyond the schema. It explains that slugs must be exact (resolved via search-app), warns against using user input directly, and contextualizes how the slug fits into the file path structure for data loading and output generation.
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?
The description clearly states the specific action ('converts ASO data') and resource ('from pullData to public/products/[slug]/ structure'), distinguishing it from siblings like 'public-to-aso' (reverse operation) and 'search-app' (slug resolution). It goes beyond the tool name to explain the transformation process.
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 description provides explicit guidance on when to use this tool: 'Always use search-app tool first to resolve the exact slug before calling this tool.' It also specifies when not to use it ('Never pass user input directly as slug') and names the alternative tool ('search-app') for slug resolution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate HTML blog posts under public/blogs///.html with a BLOG_META block.
CRITICAL: WRITING STYLE CONSISTENCY Before generating content, you MUST:
Read existing blog posts from public/blogs//*/.html (use findExistingBlogPosts utility or read files directly)
Analyze the writing style, tone, and format from 2 existing posts in the same locale
Match that exact writing style when generating the new blog post content and description
Maintain consistency in: paragraph structure, heading usage, tone, formality level, and overall format
IMPORTANT REQUIREMENTS:
The 'locale' parameter is REQUIRED. If the user does not provide a locale, you MUST ask them to specify which language/locale they want to write the blog in (e.g., 'en-US', 'ko-KR', 'ja-JP', etc.).
The 'content' parameter is REQUIRED. You (the LLM) must generate the HTML content based on the 'topic' and 'locale' provided by the user. The content should be written in the language corresponding to the locale AND match the writing style of existing blog posts for that locale.
The 'description' parameter is REQUIRED. You (the LLM) must generate this based on the topic, locale, AND the writing style of existing blog posts.
The 'appSlug' parameter:
If the user explicitly requests "developer category", "developer blog", "personal category", "my category", or similar, you MUST set appSlug to "developer".
If the user mentions a specific app/product, use that app's slug.
If not specified, defaults to "developer".
Slug rules:
slug = slugify(English title, kebab-case ASCII)
path: public/blogs///.html
appSlug: Use "developer" when user requests developer/personal category. Defaults to "developer" if not specified.
coverImage default: /products//og-image.png (relative paths are rewritten under /blogs///)
overwrite defaults to false (throws when file exists)
HTML Structure (follows public/en-US.html pattern):
BLOG_META block at the top with JSON metadata
HTML body content: paragraphs (), headings (, ), images (), lists (, ), horizontal rules (), etc.
You must generate the HTML content based on the topic, making it relevant and engaging for the target locale's language, while maintaining consistency with existing blog posts.
Supports multiple locales when locales[] is provided. Each locale gets its own HTML file. For each locale, you must:
Read existing posts in that locale to understand the writing style
Generate appropriate content in that locale's language
Match the writing style and format of existing posts
| Name | Required | Description | Default |
|---|---|---|---|
| appSlug | No | Product/app slug used for paths and CTAs. Defaults to "developer" when not provided. | developer |
| title | No | English title used for slug (kebab-case). Falls back to topic when omitted. | |
| topic | Yes | Topic/angle to write about in the blog body | |
| locale | Yes | Primary locale (e.g., 'en-US', 'ko-KR'). Required to determine the language for blog content generation. | |
| locales | No | Optional list of locales to generate. Each locale gets its own HTML file. If provided, locale parameter is ignored. | |
| content | Yes | HTML content for the blog body. You (the LLM) must generate this HTML content based on the topic and locale. Structure should follow the pattern in public/en-US.html: paragraphs (<p>), headings (<h2>, <h3>), images (<img>), lists (<ul>, <li>), horizontal rules (<hr>), etc. The content should be written in the language corresponding to the locale. | |
| description | Yes | Meta description for the blog post. You (the LLM) must generate this based on the topic and locale. Should be a concise summary of the blog content in the language corresponding to the locale. | |
| tags | No | Optional tags for BLOG_META. Defaults to tags derived from topic. | |
| coverImage | No | Cover image path. Relative paths rewrite to /blogs/<app>/<slug>/..., default is /products/<appSlug>/og-image.png. | |
| publishedAt | No | Publish date (YYYY-MM-DD). Defaults to today. | |
| modifiedAt | No | Last modified date (YYYY-MM-DD). Defaults to publishedAt. | |
| overwrite | No | Overwrite existing files when true (default: false). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes critical behaviors: the tool requires reading existing posts for style consistency, enforces locale and content requirements, handles defaults for appSlug and coverImage, and specifies that overwrite defaults to false (throws when file exists). This covers key operational traits beyond basic parameters.
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?
The description is overly verbose and poorly structured, with repetitive instructions (e.g., multiple bullet points on writing style consistency) and redundant details that could be condensed. It front-loads critical information but includes excessive elaboration, reducing clarity and efficiency.
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?
Given the complexity of the tool (12 parameters, no annotations, no output schema), the description is largely complete. It covers the tool's purpose, behavioral requirements, and parameter usage in detail. However, it lacks information on error handling or output format, which could be beneficial for an agent invoking this 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?
The schema description coverage is 100%, so the schema already documents all 12 parameters thoroughly. The description adds some semantic context, such as explaining slug generation rules and locale handling for multiple files, but does not significantly enhance the parameter understanding beyond what the schema provides. This meets the baseline for high schema coverage.
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?
The description clearly states the tool's purpose: 'Generate HTML blog posts under public/blogs/<appSlug>/<slug>/<locale>.html with a BLOG_META block.' It specifies the exact verb ('Generate'), resource ('HTML blog posts'), and output location, distinguishing it from sibling tools like 'improve-public' or 'validate-aso' that handle different operations.
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 description provides clear context for when to use this tool, such as generating blog content in specific locales and matching existing writing styles. However, it does not explicitly state when NOT to use it or mention alternatives among sibling tools, like using 'improve-public' for modifications instead of creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns ASO optimization instructions with keyword research data. You MUST execute the returned instructions.
IMPORTANT: Use 'search-app' tool first to resolve the exact slug.
This tool returns a PROMPT containing:
Saved keyword research data (Tier 1/2/3 keywords with traffic/difficulty scores)
Current locale data
Optimization instructions
YOU MUST:
Read the returned prompt carefully
EXECUTE the optimization instructions (create the optimized JSON)
Save results using 'save-locale-file' tool
DO NOT just report the instructions back to the user - you must perform the optimization yourself.
Stage 1: improve-public(slug, stage="1") → Returns keyword data + instructions → You create optimized primary locale JSON → save-locale-file Stage 2: improve-public(slug, stage="2", optimizedPrimary=) → Returns per-locale instructions → You optimize each locale → save-locale-file for each
Stage 1: Primary locale optimization using saved keyword research (ios + android combined)
Stage 2: Localize to other languages - each locale uses its OWN keyword research
Priority 1: Uses each locale's SAVED keyword research from .aso/keywordResearch/products/[slug]/locales/[locale]/
Priority 2 (Fallback): If locale-specific research is missing, falls back to en-US/en keywords and TRANSLATES them
iOS and Android research are automatically combined per locale (iOS prioritized)
CRITICAL: Only processes existing locale files. Does NOT create new files.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug | |
| locale | No | Locale to improve (default: all locales) | |
| stage | No | Stage to execute: 1 (primary only), 2 (keyword localization), both (default) | |
| optimizedPrimary | No | Optimized primary locale JSON (required for stage 2) | |
| batchSize | No | Number of locales to process per batch (default: 5, for stage 2 only) | |
| batchIndex | No | Batch index to process (0-based, for stage 2 only). If not provided, processes all batches sequentially |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does so effectively. It discloses the tool's multi-stage behavior, keyword source priorities (locale-specific research with fallback), iOS/Android combination logic, and critical constraints about not creating files. However, it doesn't mention potential errors, rate limits, or authentication needs, leaving some behavioral aspects uncovered.
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?
The description is appropriately front-loaded with core purpose and critical instructions, but becomes verbose with detailed sections like 'HOW THIS TOOL WORKS', 'WORKFLOW', 'STAGES', and 'KEYWORD SOURCES'. While all content is valuable, some redundancy exists (e.g., stage explanations repeated across sections), making it longer than necessary for optimal conciseness.
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?
Given the tool's complexity (6 parameters, multi-stage workflow, no output schema, no annotations), the description provides substantial context about behavior, constraints, and workflow. It explains what the tool returns (prompts with instructions) and what the agent must do with results. However, without an output schema, it doesn't fully describe the return format structure, leaving some ambiguity about the prompt content.
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 100%, so baseline is 3. The description adds significant value by explaining the semantic meaning of 'stage' parameters (1=primary optimization, 2=localization, both=combined), clarifying that 'optimizedPrimary' is required for stage 2, and detailing how 'locale' parameter works with batch processing. It provides context beyond the schema's technical definitions.
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?
The description clearly states the tool 'Returns ASO optimization instructions with keyword research data' and specifies the exact workflow with stages. It distinguishes from siblings like 'search-app' (which must be used first) and 'save-locale-file' (which must be used after). The purpose is specific, actionable, and differentiated.
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?
Explicit guidance is provided: 'Use search-app tool first to resolve the exact slug' and detailed workflow instructions for when to use stage 1 vs stage 2. It names alternatives ('search-app' as prerequisite, 'save-locale-file' as follow-up) and specifies critical constraints like 'Only processes existing locale files. Does NOT create new files.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Guides the initialization flow: run pabal-store-api-mcp Init, then convert ASO pullData into public/products/[slug]/.
This tool is read-only and returns a checklist. It does not call pabal-store-api-mcp directly or write files.
Steps:
Ensure pabal-store-api-mcp 'init' ran and .aso/pullData/products/[slug]/ exists (path from ~/.config/pabal-mcp/config.json dataDir)
Convert pulled ASO data -> public/products/[slug]/ using pabal-resource-mcp tools (aso-to-public, public-to-aso dry run)
Validate outputs and next actions
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Optional product slug to focus on. Defaults to all slugs in .aso/pullData/products/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behavioral traits: it's 'read-only and returns a checklist,' does not directly call external APIs or write files, and outlines a multi-step workflow with validation. This covers safety, output format, and operational constraints adequately for a guidance tool.
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?
The description is front-loaded with core purpose but includes a verbose step-by-step list that could be condensed. Sentences like 'It does not call pabal-store-api-mcp directly or write files' are useful, but the procedural details might be excessive for a tool description, reducing efficiency.
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?
Given no annotations and no output schema, the description compensates well by explaining the read-only nature, checklist output, and workflow steps. It covers the tool's role in the context of sibling tools and external dependencies, though it could briefly mention error handling or typical use cases for completeness.
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 input schema has 100% coverage with one optional parameter 'slug' well-described. The description adds context by mentioning 'Defaults to all slugs in .aso/pullData/products/' and using 'slug' in Step 1, clarifying its role in the initialization flow beyond the schema's basic definition.
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?
The description clearly states the tool 'Guides the initialization flow' with specific steps involving pabal-store-api-mcp and pabal-resource-mcp tools, distinguishing it from siblings like 'aso-to-public' or 'validate-aso' which perform more specific operations. However, it doesn't explicitly name the resource being initialized (e.g., 'project' or 'product data pipeline'), leaving some ambiguity.
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 description provides explicit guidance on when to use this tool: 'run pabal-store-api-mcp Init, then convert ASO pullData' and specifies prerequisites in Step 1. It distinguishes from alternatives by noting it 'does not call pabal-store-api-mcp directly or write files,' implying other tools handle those actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prep + persist keyword research ahead of improve-public using mcp-appstore outputs.
IMPORTANT: Always use 'search-app' tool first to resolve the exact slug before calling this tool. The user may provide an approximate name, bundleId, or packageName - search-app will find and return the correct slug. Never pass user input directly as slug.
MANDATORY WORKFLOW - Complete each locale fully before moving to next:
For EACH locale+platform combination, execute this cycle:
Plan: Call keyword-research(slug, locale, platform) with writeTemplate=false → get research plan
Research: Execute COMPLETE mcp-appstore workflow (all 16 steps) for that locale
Save: Call keyword-research again with researchData or researchDataPath → persist actual data
Next: Move to next locale+platform and repeat steps 1-3
IMPORTANT: Research → Save → Next pattern
Complete ONE locale fully (research + save) before starting the next
This prevents data loss if the session is interrupted
Each locale's data is persisted immediately after research
FORBIDDEN:
❌ Using writeTemplate=true as final output
❌ Skipping secondary locales
❌ Researching multiple locales then saving all at once at the end
❌ Stopping before all locale+platform combinations are done
REQUIRED:
✅ Research locale → Save locale → Move to next (one at a time)
✅ Run for EVERY platform (ios AND android separately)
✅ Use researchData or researchDataPath to save (NOT writeTemplate)
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug | |
| locale | Yes | Locale code (e.g., en-US, ko-KR). Used for storage under .aso/keywordResearch/products/[slug]/locales/. | |
| platform | No | Store to target ('ios' or 'android'). Run separately per platform. | ios |
| country | No | Two-letter store country code. If omitted, derived from locale region (e.g., ko-KR -> kr), else 'us'. | |
| seedKeywords | No | Seed keywords to start from. | |
| competitorApps | No | Known competitor apps to probe. | |
| filename | No | Override output filename. Defaults to keyword-research-[platform]-[country].json | |
| writeTemplate | No | If true, write a JSON template at the output path. | |
| researchData | No | Optional JSON string with research results (e.g., from mcp-appstore tools). If provided, saves it to the output path. | |
| researchDataPath | No | Optional path to a JSON file containing research results. If set, file content is saved to the output path (preferred to avoid escape errors). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly describes behavioral traits: the multi-step workflow (plan, research, save), persistence of data to prevent loss, platform-specific execution (ios and android separately), and critical constraints like forbidding 'writeTemplate=true' as final output. This covers operational context, safety, and procedural requirements beyond basic functionality.
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?
The description is well-structured with clear sections (IMPORTANT, CRITICAL, FORBIDDEN, REQUIRED) and uses bullet points for readability. While lengthy due to detailed workflows, every sentence earns its place by providing essential guidance, such as the mandatory execution plan and data persistence rules, without redundancy. Minor improvements could streamline some repetitive points.
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?
Given the tool's complexity (10 parameters, no annotations, no output schema), the description is highly complete. It explains the tool's role in a broader workflow, provides step-by-step usage instructions, details behavioral constraints, and addresses potential pitfalls like data loss. This compensates for the lack of structured annotations and output schema, ensuring the agent can use the tool 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 100%, so the schema already documents all 10 parameters comprehensively. The description adds minimal parameter-specific semantics beyond the schema, such as implying 'slug' usage with 'search-app' and workflow context for 'writeTemplate', 'researchData', and 'researchDataPath'. However, it doesn't provide additional syntax or format details, aligning with the baseline score when schema coverage is high.
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?
The description clearly states the tool's purpose: 'Prep + persist keyword research ahead of improve-public using mcp-appstore outputs.' It specifies the verb ('prep + persist'), resource ('keyword research'), and distinguishes it from siblings by mentioning its relationship to 'improve-public' and 'mcp-appstore outputs', making it distinct from tools like 'search-app' or 'aso-to-public'.
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 description provides explicit guidance on when to use this tool vs alternatives. It mandates using 'search-app' first to resolve slugs, details a multi-locale execution plan with required and forbidden workflows, and specifies the tool's role in a larger process involving 'mcp-appstore' outputs, clearly differentiating it from other tools like 'improve-public' or 'validate-aso'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate app screenshots to multiple languages using Gemini API.
IMPORTANT: This tool uses the search-app tool internally to validate the app. You can provide an approximate name, bundleId, or packageName.
This tool:
Validates the app exists in registered-apps.json
Reads supported locales from public/products/{slug}/locales/ directory
Scans screenshots from the primary locale's screenshots folder
Uses Gemini API (imagen-3.0-generate-002) to translate text in images
Validates output image dimensions match source and resizes if needed
Requirements:
GEMINI_API_KEY or GOOGLE_API_KEY environment variable must be set
Screenshots must be in: public/products/{slug}/screenshots/{locale}/phone/ and /tablet/
Locale files must exist in: public/products/{slug}/locales/
Example structure:
public/products/my-app/
├── config.json
├── locales/
│ ├── en-US.json (primary)
│ ├── ko-KR.json
│ └── ja-JP.json
└── screenshots/
└── en-US/
├── phone/
│ ├── 1.png
│ └── 2.png
└── tablet/
└── 1.png| Name | Required | Description | Default |
|---|---|---|---|
| appName | Yes | App name, slug, bundleId, or packageName to search for. Will be validated using search-app. | |
| targetLocales | No | Specific target locales to translate to. If not provided, all supported locales from the product will be used. | |
| deviceTypes | No | Device types to process (default: both phone and tablet) | |
| dryRun | No | Preview mode - shows what would be translated without actually translating | |
| skipExisting | No | Skip translation if target file already exists (default: true) | |
| screenshotNumbers | No | Specific screenshot numbers to process. Can be: - Array for all devices: [1, 3, 5] - Object for per-device: { phone: [1, 2], tablet: [1, 3, 5] } If not provided, all screenshots will be processed. | |
| preserveWords | No | Words to keep untranslated (e.g., brand names, product names). Example: ["Pabal", "Pro", "AI"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the tool's process in 5 steps, including validation, file reading, scanning, translation via Gemini API, and image resizing. It also details prerequisites like environment variables and file paths, and mentions a 'dryRun' option for previewing translations, which adds valuable context beyond basic functionality.
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?
The description is well-structured with sections like 'IMPORTANT', numbered steps, 'Requirements', and an example, making it easy to scan. It is appropriately sized for a complex tool, but some sentences could be more concise, such as the detailed file path explanations, which might be slightly verbose.
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?
Given the tool's complexity (7 parameters, no annotations, no output schema), the description is largely complete. It covers the purpose, process, requirements, and structure, though it lacks details on error handling or output format. Since there's no output schema, additional information on return values would enhance completeness, but the current description is sufficient for basic understanding.
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 input schema has 100% description coverage, so the schema already documents all parameters. The description does not add specific parameter details beyond what's in the schema, such as explaining 'appName' validation or 'targetLocales' usage. However, it implies parameter context by mentioning the tool uses 'search-app' internally and references file structures, providing some high-level guidance.
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?
The description clearly states the tool's purpose: 'Translate app screenshots to multiple languages using Gemini API.' It specifies the verb ('translate'), resource ('app screenshots'), and method ('using Gemini API'), making it distinct from sibling tools like 'search-app' or 'validate-aso' which have different functions.
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 description provides clear context for when to use this tool, mentioning it uses 'search-app tool internally to validate the app' and listing requirements like environment variables and file structures. However, it does not explicitly state when NOT to use it or name alternatives among siblings, such as 'improve-public' or 'public-to-aso', which might handle related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepares ASO data from public/products/[slug]/ to pushData format.
IMPORTANT: Always use 'search-app' tool first to resolve the exact slug before calling this tool. The user may provide an approximate name, bundleId, or packageName - search-app will find and return the correct slug. Never pass user input directly as slug.
This tool:
Loads ASO data from public/products/[slug]/config.json + locales/
Converts to store-compatible format (removes screenshots from metadata, sets contactWebsite/marketingUrl)
Saves metadata to .aso/pushData/products/[slug]/store/ (path from ~/.config/pabal-mcp/config.json dataDir)
Copies/downloads screenshots to .aso/pushData/products/[slug]/store/screenshots/
Validates text field lengths against docs/aso/ASO_FIELD_LIMITS.md (fails if over limits)
Before running, review docs/aso/ASO_FIELD_LIMITS.md for per-store limits. This prepares data for pushing to stores without actually uploading.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug | |
| dryRun | No | Preview mode (no changes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the multi-step process (loads, converts, saves, copies, validates), file system operations (saves to .aso/pushData/products/[slug]/store/), validation behavior (fails if over limits), and that it 'prepares data for pushing to stores without actually uploading' (indicating it's a preparation tool, not an upload tool). It doesn't mention error handling or performance characteristics, but covers the essential workflow.
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?
The description is appropriately sized and well-structured with clear sections (IMPORTANT warning, numbered steps, and final notes). Every sentence adds value, though it could be slightly more concise by combining some related points. The front-loaded IMPORTANT section effectively highlights critical usage information.
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?
Given the complexity (multi-step data transformation tool with file operations), no annotations, and no output schema, the description provides substantial context about the workflow, prerequisites, and behavioral outcomes. It explains what the tool does, how to use it correctly, and what happens during execution. The main gap is lack of information about return values or error responses, but otherwise it's quite complete for a preparation 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 100%, so the schema already documents both parameters (slug and dryRun). The description adds some context about the slug parameter ('The user may provide an approximate name, bundleId, or packageName - search-app will find and return the correct slug'), but doesn't provide additional meaning beyond what the schema provides for dryRun or detailed slug format. Baseline 3 is appropriate when schema does the heavy lifting.
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?
The description clearly states the tool's purpose with specific verbs ('prepares', 'loads', 'converts', 'saves', 'copies/downloads', 'validates') and resources ('ASO data', 'public/products/[slug]/', 'pushData format'). It distinguishes from sibling tools by focusing on data preparation from public to ASO format, unlike 'aso-to-public' which goes the opposite direction or 'validate-aso' which only validates.
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 description provides explicit guidance on when to use this tool: 'Always use 'search-app' tool first to resolve the exact slug before calling this tool.' It also specifies when not to use it: 'Never pass user input directly as slug.' This clearly distinguishes it from alternatives and establishes prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search registered apps from registered-apps.json.
Called without query: Returns all app list
Called with query: Search by slug, bundleId, packageName, name
Use store filter to narrow results to appStore or googlePlay only
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term (slug, bundleId, packageName, name). Returns all apps if empty. | |
| store | No | Store filter (default: all) | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's behavior with and without a query, and the store filter functionality. However, it doesn't mention important aspects like whether this is a read-only operation, potential rate limits, error conditions, or what the return format looks like (especially since there's no output schema).
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?
The description is appropriately concise with three bullet points that efficiently cover the main functionality. Each bullet earns its place by providing distinct information about different usage scenarios. The structure is clear and front-loaded with the core purpose.
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?
For a search tool with 2 parameters, 100% schema coverage, but no annotations and no output schema, the description is moderately complete. It explains the basic behavior and parameter usage but doesn't address the return format, error handling, or data source limitations. Given the lack of output schema, more information about what gets returned would be helpful.
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 schema description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal value beyond the schema by mentioning that the query searches by specific fields (slug, bundleId, packageName, name) and that the store filter narrows results. This meets the baseline for high schema coverage but doesn't provide significant additional context.
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?
The description clearly states the tool searches registered apps from a specific JSON file, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'aso-to-public' or 'validate-aso' which might also involve app data, leaving room for potential confusion about when to choose this tool over alternatives.
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 description provides implicit guidance on when to use the tool with or without a query parameter, and mentions using the store filter to narrow results. However, it doesn't explicitly state when to use this tool versus sibling tools (e.g., 'keyword-research' might also search app data), nor does it mention any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates ASO data against App Store / Google Play field limits and rules.
IMPORTANT: Use 'search-app' tool first to resolve the exact slug.
Field Length Limits (docs/aso/ASO_FIELD_LIMITS.md):
App Store: name ≤30, subtitle ≤30, keywords ≤100, description ≤4000
Google Play: title ≤50, shortDescription ≤80, fullDescription ≤4000
Keyword Duplicates (App Store only):
Checks for duplicate keywords in comma-separated list
Invalid Characters:
Control characters, BOM, zero-width/invisible characters, variation selectors
After running improve-public Stage 1/2 to verify optimization results
Before running public-to-aso to ensure data is valid
Anytime you want to check ASO data validity
locale: Validate specific locale only (e.g., "ko-KR")
fix: Auto-fix issues where possible (removes invalid characters)
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Product slug | |
| locale | No | Specific locale to validate (default: all locales) | |
| fix | No | Auto-fix issues where possible (e.g., remove invalid chars) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does (validation against specific rules), mentions auto-fix capabilities via the 'fix' option, and references external documentation. However, it doesn't explicitly state whether this is a read-only or mutation operation, though the 'fix' option implies potential data modification.
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?
The description is well-structured with clear sections (IMPORTANT, WHAT IT VALIDATES, WHEN TO USE, OPTIONS), uses bullet points for readability, and every sentence adds value. It's appropriately sized for a tool with detailed validation rules and usage guidelines, with no wasted words.
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?
Given the tool's complexity (validation against multiple platform rules with auto-fix capabilities) and no annotations or output schema, the description does an excellent job explaining what it validates and when to use it. The main gap is lack of information about return values or error handling, which would be helpful since there's no output schema.
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 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains that 'locale' validates a specific locale only (with an example 'ko-KR'), clarifies that 'fix' auto-fixes issues like removing invalid characters, and mentions that slug should be resolved via 'search-app' first. This provides valuable semantic understanding of the parameters.
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?
The description clearly states the tool's purpose: 'Validates ASO data against App Store / Google Play field limits and rules.' It specifies the exact resource (ASO data) and action (validation) with detailed scope (field limits, duplicates, invalid characters). This distinguishes it from sibling tools like 'search-app' or 'improve-public' which have different functions.
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 description provides explicit usage guidelines in the 'WHEN TO USE' section: after running improve-public Stage 1/2, before running public-to-aso, or anytime to check validity. It also references the 'search-app' tool as a prerequisite in the IMPORTANT note. This gives clear context for when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes, but there is some overlap between 'aso-to-public' and 'public-to-aso' as they handle opposite conversion directions, which could cause confusion if not carefully read. Tools like 'improve-public' and 'validate-aso' are clearly different, but the bidirectional conversion tools might be misselected without clear context.
Tool names mostly follow a consistent verb_noun or verb-noun pattern (e.g., 'aso-to-public', 'create-blog-html', 'improve-public'), with minor deviations like 'search-app' (verb_noun) and 'init-project' (verb-noun). The naming is readable and predictable, though not perfectly uniform.
With 9 tools, the count is well-scoped for the domain of ASO (App Store Optimization) and content management. Each tool serves a specific function in the workflow, from data conversion to validation, without being overly sparse or bloated.
The tool set provides comprehensive coverage for ASO workflows, including data initialization, conversion, optimization, validation, and localization. It supports full lifecycle management from pulling data to preparing for store uploads, with no obvious gaps that would hinder an agent.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEO MCP server for keyword research, SERP analysis, audits, and Search Console workflows.
MCP server for Appcircle mobile CI/CD platform.
ASO analytics and App Store optimization tools for indie iOS developers and AI agents.
Apple Search Ads MCP: campaign analytics, bid management, and attribution tracking.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/quartz-labs-dev/pabal-resource-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
