Provides tools for managing Android apps on the Huawei AppGallery, including app ID lookup, app info retrieval, obtaining file upload URLs, and submitting apps for review.
Provides tools for managing Android apps on the Samsung Galaxy Store, including listing apps, uploading binaries, updating store listings, submitting for review, and verifying IAP receipts.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@App Store Publisher MCP Check the details of my Samsung app with contentId 12345"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server to publish Android apps to Samsung Galaxy Store and Huawei AppGallery straight from AI agents — Claude Code, Claude Desktop, Cursor, VS Code, Google Antigravity, and OpenCode.
Wraps the Samsung Galaxy Store Developer (Seller) API and the Huawei AppGallery Connect API as Model Context Protocol tools, so your AI coding agent can check app status, upload binaries, update store listings, submit apps for review, and verify Samsung IAP receipts — without you ever leaving the editor.
Bonus: docs/app-store-publish-apis.md is a field-tested reference for publishing APIs across 7 stores — Samsung Galaxy Store, Huawei AppGallery, RuStore, Amazon Appstore, vivo, OPPO, and APKPure — including auth flows, endpoints, signing code, and the undocumented gotchas below.
🏪 Samsung Galaxy Store Seller API — app list & details, arbitrary Content Publish API calls (binaries, metadata, submission, staged rollout), JWT service-account auth handled for you
📱 Huawei AppGallery Connect Publishing API — appid lookup, app info, file upload URLs, submission; supports all three Huawei credential types (Connect API client, service-account key JSON, public API key)
🧾 Samsung IAP receipt verification — validate purchase receipt JWTs against your IAP public key
🔐 Tokens cached and auto-refreshed; credentials stay in a local .env, never in code
🤖 Works with any MCP client: Claude Code, Claude Desktop, Cursor, VS Code, Antigravity, OpenCode
Related MCP server: AndroidBuildMCP
Tool | What it does |
| Create/refresh a Seller API access token (JWT RS256 service account) |
|
|
| Any Galaxy Store Developer API request (list apps, add binary, submit, …) |
| Verify a Samsung IAP receipt JWT |
| Connect API client token (the only token type the Publish API accepts) |
| Any AppGallery Connect API request ( |
| JWT-bearer token from a service-account key JSON |
| Call Huawei/AGC service APIs with the service-account token |
| Call Huawei public APIs with an API key ( |
git clone https://github.com/qalvinahmad/app-store-publisher-mcp.git
cd app-store-publisher-mcp
npm install
cp .env.example .env # fill in your credentialsclaude mcp add app-store-publisher -- node /path/to/app-store-publisher-mcp/index.jsmcp.json){
"mcpServers": {
"app-store-publisher": {
"command": "node",
"args": ["/path/to/app-store-publisher-mcp/index.js"]
}
}
}~/Library/Application Support/Code/User/mcp.json){
"servers": {
"app-store-publisher": {
"type": "stdio",
"command": "node",
"args": ["/path/to/app-store-publisher-mcp/index.js"]
}
}
}~/.antigravity/mcp_config.json){
"mcpServers": {
"app-store-publisher": {
"command": "node",
"args": ["/path/to/app-store-publisher-mcp/index.js"]
}
}
}~/.config/opencode/opencode.jsonc){
"mcp": {
"app-store-publisher": {
"type": "local",
"command": ["node", "/path/to/app-store-publisher-mcp/index.js"],
"enabled": true
}
}
}Samsung Galaxy Store — Seller Portal → Assistance → API Service → create a service account (requires commercial seller status). You get a service-account ID and a private key → SAMSUNG_SERVICE_ACCOUNT_ID, SAMSUNG_PRIVATE_KEY.
Huawei AppGallery — AppGallery Connect → Users and permissions → API key → Connect API → create a client with Project = N/A (team-level; anything else returns 403) → APPGALLERY_CLIENT_ID, APPGALLERY_CLIENT_SECRET. Optionally add a service-account key JSON and/or an API key from Console → Credentials.
Huawei's Publish API only accepts Connect API client tokens. Service-account (JWT-bearer) tokens are rejected with 205524993 "client token auth failed" — no matter which headers you send.
Huawei's client token endpoint wants a JSON body. Sending application/x-www-form-urlencoded fails with an empty error body.
Huawei service-account JWTs must be RS256. PS256 (which the JSON key format suggests) is rejected with sub_error 20504.
Send both headers on Connect API calls: Authorization: Bearer <token> and client_id: <id>.
zod v4 breaks single-argument z.record(). If your MCP server's tools/list dies with Cannot read properties of undefined (reading '_zod'), change z.record(z.any()) to z.record(z.string(), z.any()).
Samsung tokens: the Seller API JWT needs scopes: ["publishing", "gss"] and the access token must be sent together with a service-account-id header.
Credentials live only in .env / the service-account JSON — both are gitignored. Use chmod 600 on them.
Never put store-publishing credentials in app runtime config; they are deploy-time secrets.
If a key leaks (chat, screenshot, log), rotate it in the store console.
Full 7-store publishing API reference (RuStore signature auth, Amazon Appstore edit flow, vivo HMAC signing with working code, OPPO and APKPure manual-only notes): docs/app-store-publish-apis.md
MIT © Alvin Ahmad
Make a request to AppGallery Connect API using the client OAuth token (use this for /api/publish/v2/* endpoints)
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| method | Yes | ||
| params | No | ||
| endpoint | Yes |
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.
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.
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.
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.
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.
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.
Generate/refresh AppGallery Connect API access token (client_credentials — required for the Publish API)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Alias of appgallery_api_request (kept from the old huawei-appgallery-connect MCP)
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| method | Yes | ||
| params | No | ||
| endpoint | Yes |
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.
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.
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.
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.
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.
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.
Alias of appgallery_get_access_token (kept from the old huawei-appgallery-connect MCP)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Generate/refresh a Huawei service-account token (JWT RS256 jwt-bearer, key file from Console > Credentials > Service account keys). NOT accepted by the Publish API — use appgallery_api_request for publishing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Make a request to a Huawei public API using the configured API key (sent as the key query parameter)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the Huawei public API endpoint | |
| data | No | ||
| method | Yes | ||
| params | No |
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.
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.
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.
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.
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.
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.
Make a request to a Huawei/AGC service API using the service-account Bearer token (for APIs that accept service-account auth; the Publish API does not)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the Huawei API endpoint | |
| data | No | ||
| method | Yes | ||
| params | No |
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.
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.
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.
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.
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.
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.
Make a request to the Samsung Galaxy Store Developer API
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| method | Yes | ||
| params | No | ||
| endpoint | Yes |
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.
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.
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.
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.
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.
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.
Generate/refresh Samsung Seller API access token
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
View Seller's App Details (GET /seller/contentInfo)
| Name | Required | Description | Default |
|---|---|---|---|
| contentId | Yes |
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.
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.
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.
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.
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.
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.
Verify Samsung IAP receipt JWT using configured public key
| Name | Required | Description | Default |
|---|---|---|---|
| receiptJwt | Yes |
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-agent operations for App Store Connect and Google Play, with approval before live publishing.
App Store Connect operator for AI agents: icons, TestFlight builds, listings, IAP, rejection fixes.
AI agent tools for FreeAppStore: deploy status, SDK docs, app info, platform guide.
Live App Store & Google Play data for AI agents: app discovery, ASO keywords, reviews.
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