App Store Publisher MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Multiple tools are aliases (appgallery_api_request / huawei_api_request, appgallery_get_access_token / huawei_get_access_token), causing ambiguity. Additionally, there are three different token-related tools for Huawei with overlapping purposes, making it hard for an agent to choose the correct one without deep knowledge.
Naming Consistency2/5
Naming is inconsistent: tools for AppGallery use 'appgallery_' prefix, but some have 'huawei_' duplicates, and Samsung tools have 'samsung_' prefix. Verb patterns vary (api_request, get_access_token, get_app_details, iap_verify_receipt), lacking a unified structure.
Tool Count3/5
11 tools is a moderate count, but the presence of redundant aliases inflates it unnecessarily. The effective count of distinct functionalities is lower, suggesting the set could be streamlined.
Completeness2/5
The tools only provide low-level API requests and token management for three app stores. High-level publishing operations like uploading, updating, or submitting apps are missing, leaving significant gaps for a publishing workflow.
Average 2.9/5 across 11 of 11 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits: no mention of authentication requirements, side effects, error handling, or rate limits. The alias reference implies behavior but doesn't specify it.
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 extremely short (one sentence), but it fails to convey essential information. It does not earn its place because it omits critical details about tool behavior and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema), the description is completely inadequate. It should explain the tool's purpose as a raw HTTP client, authentication context, and parameter roles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning to the four parameters (method, endpoint, data, params). It doesn't explain expected format, constraints, or how parameters interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is an alias of appgallery_api_request, but does not explain what it does (e.g., 'make direct API calls to Huawei AppGallery'). The purpose is vague and relies on knowledge of the aliased tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like appgallery_api_request, huawei_public_api_request, etc. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as authentication requirements, side effects, or whether it is read-only or destructive. The alias claim does not convey behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified. While it is concise, it fails to provide essential information, so it is not effectively structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description should explain what the tool returns and any side effects. It does not, and only references another tool without details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters, the schema coverage is 100%, but the description adds no meaning beyond that. It does not explain the context or purpose of the token, leaving the agent with minimal understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it is an alias of another tool, but does not specify what the tool actually does. The agent must infer that it obtains an access token, which is not clearly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus its siblings or any alternatives. The alias nature suggests backward compatibility, but this is not explicitly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as authentication requirements, rate limits, error handling, or whether the tool can modify data (note the method enum includes destructive operations). The agent is left without safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly terse. It could be expanded with key details without losing brevity. The structure is acceptable but under-utilized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, nested objects, no output schema, and no annotations, the description is woefully incomplete. It fails to explain request format, authentication context, or expected response behavior, leaving the agent without sufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning beyond the parameter names. 'data' and 'params' are objects without explanation; 'endpoint' format is partially inferred from the pattern but not described. The description does not clarify how parameters should be used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it makes a request to the Samsung Galaxy Store Developer API, which is clear but vague. It does not specify what endpoints or operations are available, and it does not distinguish itself from sibling tools like samsung_get_app_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings exist for specific operations (e.g., samsung_get_access_token for auth), but no explicit when-to-use or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('View') but does not disclose authentication requirements, error behavior, or any side effects. With no annotations, the description bears full burden and provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, but arguably too terse. It front-loads the purpose but omits important details, sacrificing helpfulness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with one parameter, the description still lacks information about output, error handling, and authentication. It feels incomplete for an agent to correctly invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% and the description does not explain the 'contentId' parameter beyond its name and pattern. No additional meaning is added for the agent to understand what value to provide.
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 action ('View') and the resource ('Seller's App Details'), with the HTTP endpoint providing additional context. However, it does not explicitly differentiate from sibling tools like 'samsung_api_request' which could also access this endpoint.
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 such as 'samsung_api_request' or other platform-specific tools. There is no mention of prerequisites, authentication, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It mentions the API key is sent as a query parameter, which is useful. However, it fails to disclose other critical behaviors like rate limits, error handling, idempotency, or whether the tool is destructive (e.g., POST/PUT may have side effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and resource. However, the brevity sacrifices necessary detail; a slightly longer description could improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required), nested objects, and no output schema, the description is too minimal. It does not explain the return format, error responses, pagination, or how to handle authentication failures. This leaves significant gaps for an agent using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description adds minimal meaning beyond the schema. It implies the 'key' parameter is automatically added, but does not explain the purpose of 'data', 'params', or the expected formats for 'url' and 'method'. This leaves agents uncertain about how to populate the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it makes requests to a Huawei public API and specifies the API key is sent as a query parameter. This distinguishes it from non-Huawei tools, but not from other Huawei API request tools like huawei_api_request or huawei_sa_api_request, which may have different authentication methods.
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 its siblings. The description lacks context about prerequisites, such as the need for a configured API key, or scenarios where alternative tools (e.g., huawei_get_access_token) might be required first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states 'verify' but doesn't mention side effects, error states, or rate limits. Insufficient for confident use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, it could be slightly more structured by separating purpose from usage notes. Still effective for its brevity.
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?
Simple tool with one parameter and no output schema, yet description omits what the return value indicates (e.g., success/failure). Incomplete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should clarify the parameter's format or constraints. It names 'JWT' but provides no detail on expected structure or validation.
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's action ('Verify') and resource ('Samsung IAP receipt JWT'), distinguishing it from sibling tools that handle API requests or access tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor prerequisites like needing a configured public key. The agent lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions the token type and endpoint prefix, but does not disclose behavior such as side effects, error handling, rate limits, or authentication prerequisites beyond the token. The generic nature of the tool limits what can be said, but more transparency is needed.
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 a single sentence that front-loads the purpose and key constraint (endpoint prefix). It is concise, but could benefit from a slightly more structured format to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, nested objects, enum, no output schema), the description is incomplete. It omits details on parameter usage, response format, error handling, and authentication flow beyond mentioning the token. For a generic API request tool, this is insufficient for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the endpoint pattern but does not explain the method, data, or params parameters. Without this, an AI agent lacks guidance on how to construct a valid request, making the tool difficult to use correctly.
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 it makes requests to AppGallery Connect API using client OAuth token, specifically targeting /api/publish/v2/* endpoints. This distinguishes it from sibling tools that target other platforms (Huawei, Samsung) or different authentication flows.
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 recommends using this tool for /api/publish/v2/* endpoints, providing context on when to use it. However, it does not specify when not to use it or mention alternative tools for other endpoints, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action (generate/refresh) but does not disclose whether tokens are cached, how credentials are obtained, any side effects, or if the operation is idempotent. This lack of detail impairs behavioral understanding.
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 a single sentence front-loaded with the key action. It is efficient but may be too brief, missing important context. Still, it earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a token generation tool with no parameters and no output schema, the description should explain how the token is obtained (e.g., from environment variables or service account) and what the agent should expect. It does not, leaving the agent with insufficient context to use the tool safely.
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 0 parameters, and schema description coverage is 100% (as there are none). According to guidelines, 0 parameters give a baseline of 4. The description does not need to add parameter details since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates/refreshes a Samsung Seller API access token. It uses a specific verb ('Generate/refresh') and identifies the resource ('Samsung Seller API access token'), distinguishing it from sibling tools like 'huawei_get_access_token'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While the sibling tools include other get_access_token tools for different platforms, the description does not explain the context for using Samsung's token generation or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions auth type but does not address potential destructive actions (POST/PUT/DELETE), rate limits, idempotency, or error states. The warning about Publish API not accepting service-account auth is useful but insufficient for a generic request tool.
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 a single sentence that efficiently conveys the core action and a key exclusion. It is front-loaded with the main purpose and includes a parenthetical clarification. However, it could be slightly more detailed without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, nested objects, no output schema), the description lacks completeness. It does not explain the request body/data format, query parameters, expected response structure, or authentication setup. The absence of such details makes it insufficient for an agent to reliably invoke the tool without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'url' has a description). The tool description adds no additional explanation for parameters like 'data', 'params', or 'method' beyond what the schema provides. Given the low coverage, the description should compensate but does not, leaving agents uncertain about how to structure the request body or query 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: making requests to Huawei/AGC service APIs using service-account Bearer token. It specifies the verb 'make a request' and resource 'Huawei/AGC service API', and distinguishes that the Publish API does not accept this auth, differentiating it from siblings like huawei_public_api_request.
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 contextual guidance by noting it is for APIs that accept service-account auth and explicitly excluding the Publish API. While it doesn't name alternatives, the sibling tool names (e.g., huawei_public_api_request) imply the appropriate alternative for Publish API. This gives clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It discloses the OAuth2 grant type ('client_credentials') and the token's purpose. Missing details like token lifetime, security prerequisites, or side effects beyond generation. Acceptable but minimal.
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?
Single sentence of 15 words, instantly communicates purpose and prerequisite. No filler or repetition. Front-loaded with essential 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 zero parameters and no output schema, description sufficiently covers the tool's role and prerequisite. Lacks explicit mention of any required configuration steps, but for a simple token getter, it is largely complete.
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?
No parameters defined; schema coverage is 100%. The description implicitly explains the absence by mentioning 'client_credentials' (implying pre-configured credentials). Adds value by clarifying the authentication flow, so baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear action ('Generate/refresh'), specific resource ('AppGallery Connect API access token'), and protocol ('client_credentials') with explicit linkage to the Publish API. Differentiates from sibling token tools like 'huawei_get_access_token' by naming the platform and use case.
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?
States that the token is 'required for the Publish API', giving a clear when-to-use context. However, it does not explicitly mention when not to use or compare to alternatives like 'appgallery_api_request' for direct calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the token type and a constraint (not for Publish API), but does not mention any side effects (e.g., token expiration or invalidation of previous tokens).
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 concise sentences, front-loaded with purpose. 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 zero parameters and no output schema, the description provides essential context (token type, key source, incompatibility with Publish API). Could mention return format or that token is used for subsequent API calls, but overall adequate.
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?
Input schema has zero parameters, so schema coverage is trivially 100%. Description adds context about token generation process, meeting the baseline of 4 for no 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?
Clearly states it generates/refreshes a Huawei service-account token, specifies JWT RS256 jwt-bearer and source of key file. Distinguishes from sibling tool for publishing (appgallery_api_request).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when NOT to use (for Publish API) and points to alternative. Does not specify when to generate vs refresh, but this is minor given the tool's simplicity.
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-publisher-mcp MCP server](https://glama.ai/mcp/servers/qalvinahmad/app-store-publisher-mcp/badges/card.svg)](https://glama.ai/mcp/servers/qalvinahmad/app-store-publisher-mcp)

Score Badge

Copy to your README.md:

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

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