Amazon SP-API MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on July 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, 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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 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.
Usage Guidelines4/5
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.

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:

[![amazon-sp-api-mcp MCP server](https://glama.ai/mcp/servers/ailumia/amazon-sp-api-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ailumia/amazon-sp-api-mcp)

Score Badge

Copy to your README.md:

[![amazon-sp-api-mcp MCP server](https://glama.ai/mcp/servers/ailumia/amazon-sp-api-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ailumia/amazon-sp-api-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/ailumia/amazon-sp-api-mcp'

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