Provides tools for interacting with the Amazon Selling Partner API (SP-API), enabling AI agents to discover, describe, and invoke operations across 49 API domains, manage reports, and handle large result artifacts for Amazon marketplace sellers.
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., "@Amazon SP-API MCP show me my orders from yesterday"
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.
A production-grade, version-aware Model Context Protocol server for the Amazon Selling Partner API (SP-API), maintained by Ailumia.
The server exposes a small six-tool MCP surface backed by a generated registry of 353 operations across 49 API domains and every model version currently published by Amazon. Agents discover the right operation at runtime instead of loading hundreds of endpoint schemas into their context.
This is an independent open-source project. It is not affiliated with, endorsed by, or sponsored by Amazon. Amazon, Selling Partner API, and SP-API are trademarks of Amazon.com, Inc. or its affiliates.
Complete model coverage — generated from amzn/selling-partner-api-models, not a hand-maintained endpoint subset.
Version aware — operation IDs include their API version; upstream model commit metadata is embedded in every registry build.
Small MCP surface — safe account listing, discovery, description, invocation, artifact retrieval, and a complete Reports workflow.
Safe by default — remote writes and deletes require explicit confirmation; credentials are injected server-side and never accepted as tool arguments.
Multiple seller accounts — configure stable account names; credentials remain server-side and multi-account calls must select an account explicitly.
Marketplace safety — account metadata is loaded from Amazon and account, marketplace, and regional endpoint combinations are validated before execution.
Production controls — per-account operation rate limiting, bounded concurrency, retries, dry runs, audit events, response size limits, structured errors, and request IDs.
Large result handling — oversized and binary responses become integrity-checked local artifacts that can be read in bounded chunks.
Two transports — stdio for local clients and stateless Streamable HTTP for controlled deployments.
Related MCP server: mcp-amazon-sp-api
Tool | Purpose |
| List safe account names, regions, metadata status, and marketplace participations. |
| Search operations by intent, domain, version, and access level. |
| Return the exact path, method, parameters, request body, and validation schema. |
| Execute any operation in the registry. Writes and deletes require |
| Read a bounded chunk from a large or binary result. |
| Create, poll, download, decompress, and persist an SP-API report. |
Node.js 20 or newer
An Amazon SP-API application
An LWA client ID, client secret, and seller refresh token for live calls
Discovery and operation descriptions work without Amazon credentials.
Clone and build the pinned source:
git clone https://github.com/ailumia/amazon-sp-api-mcp.git
cd amazon-sp-api-mcp
npm ci
npm run buildThe package is also prepared for public npm publication as @ailumia/amazon-sp-api-mcp. Until a release is present on npm, configure clients to run the local dist/index.js shown below.
Set SP_API_ACCOUNTS to a JSON array. Credentials stay in the MCP server environment and are never accepted through tool arguments. ACCOUNT_NAME is a stable routing key, not an Amazon store name. It is exposed as accountName in MCP tool arguments and responses.
Account fields:
Field | Required | Description |
| When two or more accounts exist | Stable lowercase name: letters, numbers, |
| Yes | LWA application client ID. |
| Yes | LWA application client secret. |
| Yes | Seller authorization refresh token. |
| No |
|
Use an array with one account. ACCOUNT_NAME can be omitted; the server assigns the internal name default. This explicit example uses all five supported account fields:
export SP_API_ACCOUNTS='[
{
"ACCOUNT_NAME": "primary",
"SP_API_CLIENT_ID": "amzn1.application-oa2-client...",
"SP_API_CLIENT_SECRET": "...",
"SP_API_REFRESH_TOKEN": "...",
"SP_API_REGION": "na"
}
]'Every account must have a unique ACCOUNT_NAME when more than one account is configured:
export SP_API_ACCOUNTS='[
{
"ACCOUNT_NAME": "hexai-na",
"SP_API_CLIENT_ID": "amzn1.application-oa2-client...",
"SP_API_CLIENT_SECRET": "...",
"SP_API_REFRESH_TOKEN": "...",
"SP_API_REGION": "na"
},
{
"ACCOUNT_NAME": "hexai-eu",
"SP_API_CLIENT_ID": "amzn1.application-oa2-client...",
"SP_API_CLIENT_SECRET": "...",
"SP_API_REFRESH_TOKEN": "...",
"SP_API_REGION": "eu"
}
]'At startup the server begins loading each account's marketplace participations from Amazon. Use list_accounts to inspect the safe result; credentials are never returned:
{}An example response includes accountName, region, metadataStatus, and marketplace objects containing marketplaceId, storeName, and participation status.
If metadata discovery fails, metadataStatus is error and the server logs the reason without exposing credentials. Marketplace-scoped calls fail closed with ACCOUNT_METADATA_UNAVAILABLE until discovery succeeds; operations without a Marketplace argument can still run.
Select an account by its stable name:
{
"operationId": "orders.2026-01-01.searchOrders",
"accountName": "hexai-eu",
"query": {
"marketplaceIds": ["A1PA6795UKMFR9"]
}
}When multiple accounts are configured, omitting accountName returns ACCOUNT_NAME_REQUIRED. With one account it remains optional. The server never guesses an account from a marketplace ID because multiple accounts can participate in the same marketplace.
Before a marketplace-scoped request, the server verifies that every requested marketplace is active for the selected account. Operations that require a Seller/Merchant ID accept sellerId in their normal operation arguments. Every step of run_report uses the same selected account.
The supported regions are:
Value | Endpoint |
|
|
|
|
|
|
Discovery and operation descriptions work when SP_API_ACCOUNTS is unset. list_accounts then returns an empty list and live calls return ACCOUNT_NOT_FOUND.
Environment values in JSON-based MCP client configuration must escape the account-array JSON:
{
"mcpServers": {
"amazon-sp-api": {
"command": "node",
"args": ["/absolute/path/amazon-sp-api-mcp/dist/index.js"],
"env": {
"SP_API_ACCOUNTS": "[{\"ACCOUNT_NAME\":\"hexai-na\",\"SP_API_CLIENT_ID\":\"...\",\"SP_API_CLIENT_SECRET\":\"...\",\"SP_API_REFRESH_TOKEN\":\"...\",\"SP_API_REGION\":\"na\"}]"
}
}
}
}The default transport is stdio. Logs are written to stderr so they never corrupt MCP messages on stdout.
First list accounts and enabled marketplaces:
{}Then discover an operation:
{
"query": "orders updated since a timestamp",
"domain": "orders",
"access": "read"
}Then describe the selected version:
{
"operationId": "orders.2026-01-01.searchOrders"
}Finally invoke it using the returned location-aware schema:
{
"operationId": "orders.2026-01-01.searchOrders",
"accountName": "hexai-na",
"query": {
"marketplaceIds": ["ATVPDKIKX0DER"],
"lastUpdatedAfter": "2026-07-01T00:00:00Z"
}
}Exact operation names and arguments evolve with Amazon's models. Always use discover_operations and describe_operation rather than relying on an example indefinitely.
POST, PUT, and PATCH operations require confirm=true. DELETE operations receive the stricter delete access classification and also require confirmation.
{
"operationId": "listingsItems.2021-08-01.patchListingsItem",
"accountName": "hexai-na",
"path": {
"sellerId": "SELLER_ID",
"sku": "SKU-123"
},
"query": {
"marketplaceIds": ["ATVPDKIKX0DER"]
},
"body": {},
"confirm": true
}Preview the validated regional request without sending the SP-API operation by using dryRun=true; confirmation is not required for a dry run:
{
"operationId": "listingsItems.2021-08-01.patchListingsItem",
"accountName": "hexai-na",
"path": {
"sellerId": "SELLER_ID",
"sku": "SKU-123"
},
"query": {
"marketplaceIds": ["ATVPDKIKX0DER"]
},
"body": {},
"dryRun": true
}Successful, failed, rejected, and dry-run operations emit JSON audit events with the account name, marketplaces, operation, confirmation state, request ID when available, resource identifiers, and a SHA-256 payload hash for writes. Results and structured errors include an auditId for correlation. Credentials and raw request bodies are not logged.
run_report manages the asynchronous Reports API lifecycle and returns an artifact reference:
{
"reportType": "GET_MERCHANT_LISTINGS_ALL_DATA",
"accountName": "hexai-na",
"marketplaceIds": ["ATVPDKIKX0DER"],
"confirm": true
}The workflow creates the report, polls getReport, fetches the report document, downloads the pre-signed URL, decompresses GZIP content when necessary, and stores the result with SHA-256 integrity metadata.
Local HTTP mode:
npm run build
node dist/index.js --transport httpEndpoints:
POST /mcp — stateless Streamable HTTP MCP
GET /health — registry and source-commit health information
The default bind address is 127.0.0.1. A non-loopback HOST requires MCP_ALLOWED_HOSTS to reduce DNS rebinding risk. Set MCP_BEARER_TOKEN for shared deployments:
HOST=0.0.0.0 \
MCP_ALLOWED_HOSTS=mcp.example.com \
MCP_BEARER_TOKEN="use-at-least-16-random-characters" \
node dist/index.js --transport httpTLS and internet-facing authorization should be terminated by a trusted reverse proxy or identity-aware gateway. See Security model.
Variable | Default | Description |
| unset | JSON array containing the five supported per-account fields above. |
|
| Retry limit for 429 and transient 5xx responses. |
|
| Maximum concurrent outbound SP-API requests. |
|
| Maximum inline response size before artifact storage. |
|
| Per-request timeout. |
|
| Local artifact storage directory. |
|
| Pino log level. |
|
| Streamable HTTP listener. |
| unset | Comma-separated HTTP Host allowlist. Required for non-loopback binds. |
| unset | Optional HTTP bearer token, minimum 16 characters. |
The tracked registry is deterministic for an upstream commit and records both the repository and commit SHA.
npm run registry:sync
npm run registry:checkThe weekly GitHub workflow runs the same process and opens a pull request when Amazon publishes model changes. Registry generation supports Swagger 2.0 and OpenAPI 3.x.
MCP tools
├── version-aware operation registry
├── account registry + marketplace validation
├── Reports workflow
└── execution pipeline
├── JSON Schema validation
├── write/delete confirmation policy
├── per-account LWA token provider
├── account + region + operation rate limiter
├── bounded concurrency + retry
├── dry-run + structured audit event
├── SP-API HTTP transport
└── inline result / artifact storeSee Architecture for module boundaries, operation identity, data flow, and extension rules.
npm ci
npm run checknpm run check runs formatting verification, ESLint, strict TypeScript, tests with coverage, the production build, and registry contract validation.
Useful commands:
npm run dev
npm run test:watch
npm run registry:generate -- /path/to/selling-partner-api-models/modelsContributions are welcome. Read CONTRIBUTING.md, the Code of Conduct, and SECURITY.md before opening a pull request or reporting a vulnerability.
Apache License 2.0. The generated registry derives structural metadata from Amazon's Apache-2.0-licensed Selling Partner API models; attribution is recorded in NOTICE.
Return the exact method, path, parameters, request body, and validation schema for an operation ID.
| Name | Required | Description | Default |
|---|---|---|---|
| operationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds what is returned but does not disclose error behavior, prerequisites, or any limitations beyond the annotations.
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 front-loads the verb and output, making it easy to parse.
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 simple read-only tool, the description adequately lists what it returns. It could mention that operationId comes from discover_operations, but the core purpose is clear and 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?
Schema coverage is 0% and the description only refers to 'operation ID', which adds little over the parameter name itself. It does not explain the format of operationId or how to obtain it (e.g., from discover_operations).
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 uses the specific verb 'Return' and clearly states the resource (operation details: method, path, parameters, request body, validation schema) for an operation ID. This distinguishes it from siblings like invoke_operation and discover_operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving operation details but provides no explicit when-to-use or alternative guidance. It does not mention discover_operations for obtaining operation IDs or when invoke_operation would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the version-aware Amazon SP-API registry. Use this before describe_operation or invoke_operation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| access | No | ||
| domain | No | ||
| version | No | ||
| includeDeprecated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that it is 'version-aware' and part of a registry search, but doesn't disclose any additional behaviors like result format or pagination. With no output schema, more detail would be beneficial, but the description is consistent with annotations.
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: the first states the purpose, the second gives usage guidance. No unnecessary words or repetition of schema 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?
Despite 6 parameters and no output schema, the description only provides a brief purpose and usage order. It doesn't explain search behavior, parameter meanings, or return values. This is insufficient for the tool's complexity and leaves agents guessing.
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% and the description mentions none of the six parameters (limit, query, access, domain, version, includeDeprecated). The agent must rely solely on parameter names and types, which is insufficient for a search tool with these filters. The description's 'version-aware' hint only tangentially relates to the version parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the version-aware Amazon SP-API registry, using the verb 'search' and specifying the resource. It also distinguishes itself by instructing to use it before describe_operation or invoke_operation, differentiating it from sibling tools.
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 says 'Use this before describe_operation or invoke_operation', providing a clear usage sequence. It doesn't mention when not to use it or alternative tools beyond that, but it does give direct contextual guidance for ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a chunk from a large or binary result saved by invoke_operation or run_report.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| length | No | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing that this reads a 'chunk' from 'large or binary' artifacts, which is a key behavioral trait beyond the annotations. However, it does not describe error behavior, chunk format (raw bytes, encoding), or how to iterate through the entire artifact. No contradiction with annotations.
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, front-loaded sentence of 17 words that efficiently conveys verb, object, and provenance. It contains no filler or redundant information, every word earns its place.
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?
The core idea and source of artifacts are clear, but for a chunked-read tool with no output schema, the description omits critical details like how output is represented (raw binary, base64, etc.), how to know total artifact size, and behavior when offset exceeds bounds. This leaves significant gaps in the agent's understanding of the tool's full behavior.
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 must compensate. It mentions 'chunk', which implies offset/length usage, and indicates id refers to artifacts saved by invoke_operation/run_report. However, it does not explain the units of length (bytes vs. characters), semantics of offset, or how the id relates to an artifact. The parameters are self-named but under-described, leaving the agent to guess.
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 'Read a chunk' and the resource 'a large or binary result saved by invoke_operation or run_report'. This specific verb+resource pairing distinguishes it from sibling tools that create or execute operations, making the purpose unmistakable.
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 implies use after invoke_operation or run_report, since artifacts are saved by those tools. It frames this tool as the way to access partial results, providing clear contextual guidance. However, it does not explicitly name alternatives or state when not to use it, so it lacks the exclusionary guidance seen in the highest examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an operation using a stable account name. Multiple-account configurations require accountName. Writes require confirm=true unless dryRun=true.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| path | No | ||
| query | No | ||
| dryRun | No | ||
| confirm | No | ||
| headers | No | ||
| accountName | No | Stable configured account name; optional only when one account is configured | |
| operationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true, but the description adds valuable context about the confirm and dryRun mechanism, which is not in the annotations. It also clarifies the accountName requirement, enhancing transparency about when the tool can be safely invoked. No contradictions with annotations.
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 two sentences long, front-loaded with the primary purpose, and every sentence adds value. It avoids redundancy with the schema and annotations, making it concise and well-structured.
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 complex tool with 8 parameters, nested objects, and no output schema, the description is adequate but has gaps. It gives key invocation rules but does not explain how to obtain operationId, construct body/path/query, or handle errors. The sibling tools may help fill these gaps, but the description itself is not fully 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?
Schema description coverage is only 13%, so the description must compensate. It explains accountName ('stable configured account name; optional only when one account is configured') and the semantics of confirm and dryRun. However, it leaves operationId, body, path, query, headers, and other parameters undocumented, leaving significant room for misinterpretation.
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 function: 'Execute an operation using a stable account name.' This is a specific verb+resource combination that differentiates it from sibling tools like list_accounts, discover_operations, and describe_operation. The title 'Invoke an Amazon SP-API operation' reinforces the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear conditions: 'Multiple-account configurations require accountName' and 'Writes require confirm=true unless dryRun=true.' These give explicit prerequisites for using the tool correctly. However, it does not explicitly mention when not to use this tool or name alternative tools for similar scenarios, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List safe account metadata, including account names, regions, and marketplace participations. Credentials are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds a valuable behavioral guarantee: 'Credentials are never returned.' This goes beyond annotations by addressing a security-relevant aspect of the tool's behavior, critical for an agent deciding to invoke 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 a single concise sentence that is front-loaded with the core action ('List safe account metadata') and includes just enough detail about the returned fields and a critical safety note. No waste.
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 simple list tool with no parameters and no output schema, the description fully covers what the agent needs to know: what the tool does, what it returns, and a safety guarantee. The sibling tools are more complex, and this description is sufficiently complete for its simple role.
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 tool has zero parameters, and the description correctly focuses on output content (account names, regions, marketplace participations). With 0 params, the baseline is 4, and the description provides appropriate context about what the list will contain.
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 function: listing safe account metadata (account names, regions, marketplace participations). It also adds a key differentiator by explicitly stating credentials are never returned, which distinguishes it from sibling tools that deal with operations, artifacts, or reports.
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 implies the tool is for retrieving account information with no parameters, making usage straightforward. It doesn't explicitly exclude alternatives or state when-not-to-use, but the context is clear for a simple list operation. Given no exclusions are needed, a score of 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a report for a stable account name, poll until completion, download and decompress it, then return an artifact reference.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | ||
| timeoutMs | No | ||
| reportType | Yes | ||
| accountName | No | Stable configured account name; optional only when one account is configured | |
| dataEndTime | No | ||
| dataStartTime | No | ||
| reportOptions | No | ||
| marketplaceIds | No | ||
| pollIntervalMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false and openWorld=true, and the description adds meaningful behavioral detail: the tool creates a report, polls until completion, downloads and decompresses it, and returns an artifact reference. It does not cover failure/retry behavior or rate limits, but the core side-effectful flow is disclosed.
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?
A single, front-loaded sentence conveys the entire workflow without filler. It is compact and every clause contributes essential information about the operation's lifecycle.
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?
With 9 parameters, no output schema, and no enums, the description needs to cover parameter selection and return expectations more thoroughly. It mentions 'artifact reference' but does not explain reportType options, data-window semantics, confirmation requirements, or how to interpret the output.
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 11%, but the description adds no parameter meaning beyond mentioning 'stable account name.' reportType, confirm, time windows, reportOptions, marketplaceIds, timeout, and pollInterval are left entirely unexplained by both the schema and the description.
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 uses a specific verb sequence (create, poll, download, decompress, return) tied to Amazon SP-API reports, and the title reinforces the resource. It clearly distinguishes this from sibling tools like get_artifact or invoke_operation by describing the complete report workflow rather than a generic call.
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 given about when to choose run_report over alternatives such as invoke_operation or get_artifact. The description only implies a report-download use case and does not state exclusions, prerequisites, or fallback scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0describe_operationdiscover_operationsget_artifactinvoke_operationlist_accountsrun_reportEach tool has a clearly distinct purpose: listing accounts, searching operations, describing an operation, invoking an operation, reading artifacts, and running reports. The overlap between discover_operation and describe_operation is minimal because one is for search and the other for detail.
All tool names follow a consistent verb_noun snake_case pattern: list_accounts, discover_operations, describe_operation, invoke_operation, get_artifact, run_report. There are no mixed conventions or vague verbs.
With 6 tools, the set is well-scoped. It provides a minimal but sufficient abstraction for interacting with the large Amazon SP-API surface, covering account management, operation discovery and invocation, and report handling.
The tool set covers the full workflow: discover operations, describe them, invoke them, and retrieve artifacts. The run_report tool handles the report lifecycle, and get_artifact reads large results. Given the generic invoke_operation, there are no obvious dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
Get recommended by Amazon's AI. Hosted MCP server for Amazon listing compliance & generation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ailumia/amazon-sp-api-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
