pabal-web-mcp

Server Quality Checklist

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

Latest release: v1.5.9
Disambiguation4/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.2/5 across 9 of 9 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- 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

Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness2/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/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 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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters4/5
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.
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 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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

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:

[![pabal-resource-mcp MCP server](https://glama.ai/mcp/servers/quartz-labs-dev/pabal-resource-mcp/badges/card.svg)](https://glama.ai/mcp/servers/quartz-labs-dev/pabal-resource-mcp)

Score Badge

Copy to your README.md:

[![pabal-resource-mcp MCP server](https://glama.ai/mcp/servers/quartz-labs-dev/pabal-resource-mcp/badges/score.svg)](https://glama.ai/mcp/servers/quartz-labs-dev/pabal-resource-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/quartz-labs-dev/pabal-resource-mcp'

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