@perttu/app-store-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct data type (search, reviews, ratings, app details, etc.), but app_store_app and app_store_ratings have minor overlap since app metadata can include the rating histogram. Overall, descriptions clearly delineate purpose.
Naming Consistency5/5
All 11 tools follow a consistent app_store_ prefix with snake_case. While the suffix part of speech varies (nouns, verbs, adjectives), the pattern is highly predictable and recognizable.
Tool Count5/5
11 tools is well within the ideal range and each tool addresses a distinct read-only aspect of App Store data. No tool feels redundant or out of place.
Completeness5/5
The set covers all major App Store information surfaces: search, lookup, collections, developer listings, ratings, reviews, similar apps, suggestions, privacy, version history, and in-app purchases. There are no obvious dead ends for common use cases.
Average 3.9/5 across 11 of 11 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate these. However, the description adds no behavioral details beyond a basic purpose statement, such as what happens when both 'id' and 'appId' are supplied, parameter precedence, or locale defaulting behavior.
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, focused sentence of 12 words. It is front-loaded and contains no filler or redundant information, making it highly concise and easy to parse.
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 an output schema and annotations, the description is incomplete because it does not explain which of the four optional parameters is necessary to identify the app. This is critical for invocation and is not adequately covered by the schema descriptions alone.
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?
All 4 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds no extra semantic meaning, but the schema already documents each parameter adequately, so no deduction is warranted.
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 'Get the apps shown as related to a given App Store app' clearly states a specific verb and resource, distinguishing it from sibling tools like app_store_search, app_store_reviews, or app_store_ratings. It unambiguously conveys the tool's function of retrieving similar apps for a given app.
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, and there is no mention of prerequisites such as needing either 'id' or 'appId' to identify the app. The optional parameters make usage ambiguous without additional instructions.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, and the description's read-only 'Get' wording is consistent. It adds the behavioral detail that the rating histogram can optionally be included, but does not disclose other nuances such as precedence or identifier requirements; with annotations covering safety, this is adequate but not rich.
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 short sentences; the key verb, resource, and invocation options are front-loaded. No filler or redundancy, and every sentence 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 output schema, rich parameter schema, and read-only annotations, the description provides enough to invoke the tool correctly for common cases. It leaves a minor ambiguity about requiring at least one identifier, since the schema lists no required fields, but overall it is adequate.
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 five parameters. The description adds context that id and appId are two alternative identifier types and that ratings toggles the histogram, but does not go beyond the schema's own descriptions.
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'), the resource ('App Store metadata'), the scope ('for one app'), and the accepted identifiers ('numeric track ID or bundle identifier'). This distinguishes it from sibling search/review/ratings tools by emphasizing it targets a single app by identifier.
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 does not explain when to choose this tool over siblings like app_store_search or app_store_ratings, nor does it state exclusions or prerequisites (e.g., that id or appId should be provided). It implies usage through the identifier wording but gives no explicit context or alternatives.
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?
The readOnlyHint and openWorldHint annotations already indicate a safe read operation. The description adds minor context about pagination ('a page') and sorting ('recent or helpful'), but does not disclose requirements like needing either id or appId, or country defaults. This is a modest addition beyond annotations.
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 sentence that immediately conveys the tool's purpose. It is well-front-loaded and contains no redundant information, making it highly concise and easy to parse.
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 presence of an output schema and full parameter descriptions, the description is largely complete. It effectively communicates the core purpose, but it could benefit from noting that reviews differ from ratings (given the app_store_ratings sibling) or specifying that either id or appId is required. Overall, it is adequate for a simple read-only 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 coverage is 100%, with all six parameters described. The description's mention of 'recent or helpful' aligns with the sort parameter but adds no new semantic meaning beyond the schema. It neither clarifies the id/appId relationship nor parameter constraints, so it meets the baseline without exceeding it.
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 fetches a page of App Store reviews, with 'page' and 'recent or helpful' indicating pagination and sorting. However, it does not explicitly differentiate from the sibling tool app_store_ratings, which could cause confusion about scope (reviews vs ratings).
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 implies usage when you need app reviews but provides no explicit guidance on when to use this tool over alternatives like app_store_ratings or app_store_search. There are no exclusions or alternative tool mentions, leaving some ambiguity in tool selection.
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?
The description adds the output shape (histogram) but does not disclose additional behaviors beyond what annotations already cover. The readOnlyHint indicates a safe read, and openWorldHint suggests variable results, both provided by annotations. With annotations present, the description does not contradict or significantly extend them.
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, concise sentence that immediately communicates the tool's purpose. It contains no extraneous details, making it optimally front-loaded and easy to parse.
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?
For a simple read-only tool with a well-defined schema and output schema, the description is sufficient. It clearly states what the tool returns, and the schema covers parameter details, so an agent has all necessary context to use it 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?
The input schema already provides detailed descriptions for both parameters (id and country) with 100% coverage. The description adds no extra parameter context, so it meets the baseline but does not exceed schema documentation.
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 function: retrieving an app's total rating count and its 1-5 star histogram. It uses a specific verb ('Get') and resource ('an app's total rating count'), and it stands out from siblings like app_store_reviews by focusing on aggregate ratings rather than individual reviews.
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. The description implies its use for rating summaries, but it does not explicitly mention alternatives or when to prefer this over app_store_reviews or app_store_app.
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?
Annotations already cover readOnlyHint and openWorldHint, indicating a safe read operation. The description adds that it supports keyword search with country/locale/pagination controls, but does not disclose default pagination behavior or error handling. Given annotation coverage, this is adequate but not rich.
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, front-loaded sentence that communicates the core action and key controls without unnecessary words. It effectively summarizes the tool's purpose and parameters.
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 tool has a well-documented schema, annotations, and an output schema, so the description does not need to explain return values. It is complete enough for an agent to select and invoke the tool, though it could briefly mention that results are app listings. Overall, the description is sufficient for a straightforward search 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 input schema provides 100% description coverage for all six parameters, including term, num, lang, page, country, and idsOnly. The description's mention of 'country, locale, and pagination controls' adds no meaning beyond what the schema already states. A baseline score of 3 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 explicitly states 'Search the App Store by keyword' with a specific verb and resource. It also mentions country, locale, and pagination controls, making it distinct from sibling tools like app_store_reviews or app_store_app. This is clear and non-tautological.
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 implies usage for keyword-based App Store searches but does not explicitly contrast with alternatives. It does not state when to choose this over app_store_suggest or app_store_similar, leaving the agent to infer from the name and schema. No exclusions or alternative recommendations are provided.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and dynamic data. The description adds the scope constraint 'all apps,' but no additional behavioral details like pagination or response limits. This matches the baseline where annotations carry the safety burden.
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 concise sentence, front-loaded with the action and resource, with zero filler words. It is immediately scannable and directly addresses the tool's purpose.
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?
For a simple read-only tool with an output schema and annotations, this description is complete. The agent knows what to expect (all apps for a developer) and can rely on the schema for parameters and output, so no further elaboration is needed.
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%, with all parameters (devId, lang, country) having clear inline descriptions. The tool description does not add parameter-specific meaning, so it meets the baseline of 3 without needing to compensate.
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 ('Get') plus a clear resource ('all apps published under an App Store developer account'). It distinguishes from sibling tools like search or app lookup by scoping to a developer account, making the purpose unambiguous.
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 implicitly defines the use case: when you need all apps for a given developer ID. It does not explicitly compare to alternatives or state exclusions, but the resource scope (developer account) clearly differentiates it from search or listing tools, providing enough context for an agent.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about localization and the 'top' qualifier, but provides no additional behavioral details (e.g., pagination, limits). This aligns with the calibration example for get_calls.
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 well-structured sentence of 14 words. It is front-loaded with the primary action ('Get'), clearly states the target resource, and includes relevant output characteristics without unnecessary detail.
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 presence of a complete input schema, output schema, and annotations, the description is fully adequate. It specifies the purpose and important output details (localized names and prices), leaving no critical gaps for an agent to misuse the 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%, with both `id` and `country` fully described. The description adds marginal value by implying country affects localization and price formatting, but the schema already provides the necessary semantics for both 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 gets 'top in-app purchases shown on an app's App Store page' and specifies 'localized names and formatted prices.' This is a specific verb+resource combination that distinguishes it from sibling tools like app_store_reviews or app_store_app.
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: it is for the top in-app purchases on an app's App Store page. It does not explicitly name alternatives or exclusion conditions, but the purpose is unambiguous relative to the sibling tool names.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds that the data is 'published' privacy labels and policy info, but discloses no additional behaviors like rate limits or error handling. This is acceptable given the annotations but not exceptional.
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 about ten words, front-loaded with the action and resource, with zero waste or redundant content.
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 an output schema exists to explain return values, the annotations cover safety, and the parameters are self-explanatory via the schema, the description is sufficient for the agent to understand the tool's scope. No critical context is missing.
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 already provides full descriptions for both parameters (id and country), achieving 100% coverage. The description itself adds no parameter-level detail, so it remains at baseline.
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 the specific verb 'Get' and names a precise resource ('privacy labels and policy information') for an App Store app. It clearly distinguishes this tool from siblings like app_store_reviews or app_store_ratings, which target different data types.
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: it is for retrieving privacy-related app data. However, it stops short of explicitly stating when to use this tool over alternatives or noting exclusions, so it misses the top score for guidance.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and external access. The description adds the autocomplete context but discloses no additional behavioral traits such as rate limits, result limits, or error handling. With an output schema present, this is adequate but not deeply transparent.
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, focused sentence that clearly states the tool's purpose without any filler or unnecessary detail. It is well-structured and immediately understandable.
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?
For a simple 2-parameter read-only tool with full schema coverage and an output schema, the description is sufficiently complete. It covers the core purpose and appropriately relies on the schema for parameter details and return values.
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 provides 100% parameter coverage: 'term' is described as 'Partial search term' and 'country' is described with a default value. The description itself adds no parameter-specific information, so the baseline score of 3 applies.
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 function: 'Get App Store autocomplete suggestions for a partial search term.' This uses a specific verb ('Get') and resource ('autocomplete suggestions'), and explicitly distinguishes it from sibling tools like app_store_search (full search) and app_store_similar (similar apps) by focusing on partial-term suggestions.
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 states the intended scenario: providing autocomplete suggestions for a partial search term. This gives clear context for when to use the tool. However, it does not name alternatives or exclusions, though the autocomplete framing strongly implies it is for suggestion-style queries rather than full search or listing.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the specific data fields returned but does not disclose behavioral aspects like rate limits or pagination. No contradiction.
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, front-loaded with the verb and object, and contains no unnecessary detail. It is highly concise and structured effectively.
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?
With an output schema present and annotations covering read-only/open-world behavior, the description is complete enough. It names the return data categories (past versions, release dates, release notes), and remaining details like country default and return format are in the schema.
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 descriptions cover 100% of parameters (id and country, including the country default). The description adds no additional parameter semantics, but the schema already provides sufficient meaning, so the baseline score of 3 applies.
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 ('Get') and names the resource ('App Store app') with exact data fields (past versions, release dates, release notes). This clearly distinguishes it from sibling tools like app_store_reviews or app_store_ratings.
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 a clear use case—retrieving version history for an app—but does not explicitly mention when to use this tool over siblings or provide exclusions. The context is clear enough from the description and tool name.
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?
The description discloses a significant operational cost: 'Full detail makes one additional request per app,' which is beyond the readOnlyHint annotation. It doesn't contradict annotations. It could have mentioned pagination or default behavior, but the per-app request warning adds useful transparency.
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 short, front-loaded sentences with no filler. Each sentence adds essential information: the core purpose and the cost caveat.
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 covers the tool's core purpose, category filtering, and a cost caveat. With a fully-described schema and an output schema present, it is sufficient, though it could briefly mention how to select different collections or defaults.
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?
With 100% schema coverage, the baseline is 3. The description adds meaning for 'category' (optional narrowing) and 'fullDetail' (extra request per app), going slightly beyond the schema's descriptions.
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 identifies the tool as retrieving a ranked App Store collection, with optional category narrowing. This distinguishes it from siblings like app_store_reviews, app_store_search, and app_store_developer, which target different resources.
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 implies use for chart/collection retrieval and notes optional category narrowing, but does not explicitly compare with alternative tools like app_store_search or app_store_app, nor provide when-not-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

[![app-store-mcp MCP server](https://glama.ai/mcp/servers/plahteenlahti/app-store-mcp/badges/score.svg)](https://glama.ai/mcp/servers/plahteenlahti/app-store-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/plahteenlahti/app-store-mcp'

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