Provides retrieval over Amazon operating knowledge across Ads, Seller Central, and Vendor Central, enabling agents to search and access Amazon-related documentation and schemas.
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-agent-atlas-mcp Search for Amazon Seller Central FBA fee calculation tools"
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 retrieval layer your agent checks before it answers. It indexes Amazon operating knowledge across Ads, Seller Central, and Vendor Central.
Product page: https://www.kuudo.com/features/agent-atlas/ · Docs: https://www.kuudo.com/docs/amazon-agent-atlas/ · Pricing: https://www.kuudo.com/pricing.md
Kuudo runs in your own cloud. The Community plan deploys one instance of each Amazon MCP server into your account, and your client connects to that deployment:
{
"mcpServers": {
"amazon-agent-atlas-mcp": {
"url": "https://<your-host>/mcp",
"headers": {
"Authorization": "Bearer <your Kuudo API key>"
}
}
}
}Replace <your-host> with the hostname of your deployment and the bearer value with your Kuudo API key.
Related MCP server: MCP Knowledge Base Server
This repository holds registry metadata and a catalog-only stub. Live execution runs in your Kuudo deployment. The server source is not published. The stub in src/ answers tools/list with the catalog below, serves the same catalog as one resource (kuudo://catalog/tools.json), offers one prompt (connect) carrying the setup guidance, and returns an error with that guidance on any call, so registries and clients can inspect the surface without any access to Amazon.
The image runs the same catalog-only stub over stdio. It is not the live server.
docker build -t amazon-agent-atlas-mcp .
docker run -i --rm amazon-agent-atlas-mcpPoint a client at it with a stdio entry:
{
"mcpServers": {
"amazon-agent-atlas-mcp-catalog": {
"command": "docker",
"args": ["run", "-i", "--rm", "amazon-agent-atlas-mcp"]
}
}
}4 tools, read from a running instance of this server. Four tools front the whole corpus: browse tags, search, read a schema, then run a chained call.
Each tool carries the argument schema the live server publishes, so a client can inspect the full call signature here before it connects to your deployment.
Tool | Access | What it does |
| read | List available tool tags. Use to browse available tools by tag before searching. |
| read | Search for available tools by query. Returns matching tools ranked by relevance. |
| read | Get parameter schemas for specific tools. Use after searching to get the detail needed to call a tool. |
| write | Chain |
Read tools are safe to call freely. Write tools do work inside your deployment: they generate media, run a chained query, or hand back an upload URL. Each tool's access is recorded beside it in tools.json.
Website: https://www.kuudo.com/
Guides: https://www.kuudo.com/guides/
Community, bugs, and questions: https://github.com/KuudoAI/community
Machine-readable: https://www.kuudo.com/llms.txt · https://www.kuudo.com/pricing.md
Generated from KuudoAI/marketing. Do not edit by hand; changes are overwritten on the next sync.
Catalog entry. Runs in your Kuudo deployment, not here. Chain await call_tool(...) calls in one Python block and return the final value. Only call_tool(tool_name: str, params: dict) -> Any is available as an external function. Supported imports: asyncio, datetime, json, math, os, pathlib, re, sys, typing. Other standard-library and third-party imports, including collections, are unavailable in the sandbox. Use f-strings because str.format is unavailable. Limits: 10 seconds, 50,000,000 bytes of memory, and recursion depth 100.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python async code to execute tool calls via call_tool(name, arguments) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it is exceptionally transparent. It reveals that execution happens in a remote sandbox ('not here'), restricts the available function surface to only call_tool, lists supported imports, forbids collections, disables str.format, and states hard limits on time, memory, and recursion depth. This is far beyond a generic 'executes code' statement.
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 dense but every sentence carries needed operational detail. The opening 'Catalog entry.' is mild noise, but the rest is front-loaded with the location and primary action, followed by requirements and limits. The length is justified by the number of constraints the agent must respect to successfully invoke the tool.
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 1-parameter code-execution tool with no output schema and no annotations, the description covers all known operational aspects: where code runs, the callable API, allowed imports, forbidden syntax, and hard limits. It even states that the code must return the final value. Nothing an agent needs to call it correctly is missing.
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?
Although the schema already defines the code parameter (100% coverage), the description adds substantial semantics: the exact async style (await call_tool), the required use of f-strings instead of str.format, the allowed/intended import set, the function signature, and the resource limits. This tells the agent exactly how to write valid code and exceeds what the schema alone provides.
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 what the tool does: it runs Python code in the user's Kuudo deployment, not in the AI's environment, specifically for chaining await call_tool(...) calls. The verb 'Chain' and the resource 'your Kuudo deployment' make the purpose concrete and distinguish it from the sibling tools (tags, search, get_schema), which are direct data-retrieval 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 explains when to use this tool: when you need to compose multiple call_tool invocations in a single Python block and return a final value. It does not explicitly state when not to use it or name alternatives, but the use case is unambiguously conveyed, so clear context is provided even without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Catalog entry. Runs in your Kuudo deployment, not here. Get parameter schemas for specific tools. Use after searching to get the detail needed to call a tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tools | Yes | List of tool names to get schemas for | |
| detail | No | 'brief' for names and descriptions, 'detailed' for parameter schemas as markdown, 'full' for complete JSON schemas | detailed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context ('Runs in your Kuudo deployment, not here') and implies a read-only schema retrieval, but it does not describe return format, error behavior, or potential 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 short and front-loaded with the core action. The three sentences each add some value, though 'Catalog entry' is slightly redundant with the tool's purpose.
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 two-parameter schema-lookup tool with a complete input schema, the description is nearly sufficient. It explains the workflow position and the deployment context; no output schema exists, but the tool's return nature is implied by its name and 'get parameter schemas'.
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 100%, so the schema already documents both 'tools' and 'detail' thoroughly. The description adds only the ordering hint 'after searching' and does not meaningfully enrich parameter meaning beyond the schema.
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 a clear verb-resource pair: 'Get parameter schemas for specific tools,' which distinguishes it from search and execute. The opening phrase 'Catalog entry' is somewhat vague, but the main clause is unambiguous.
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 gives explicit usage context: use it after searching to obtain the detail needed to call a tool. It does not mention when not to use it or name alternative tools, but the placement in the workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Catalog entry. Runs in your Kuudo deployment, not here. Search for available tools by query. Returns matching tools ranked by relevance.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Filter to tools with any of these tags before searching | |
| limit | No | Maximum number of results to return | |
| query | Yes | Search query to find available tools | |
| detail | No | 'brief' for names and descriptions, 'detailed' for parameter schemas as markdown, 'full' for complete JSON schemas | brief |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context: the tool 'runs in your Kuudo deployment, not here' and returns results 'ranked by relevance.' It does not explicitly state that the operation is read-only or describe any side effects/auth requirements, but for a catalog search these are somewhat implicit. The provided context is meaningful but not comprehensive.
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 concise and front-loaded: it opens with the category ('Catalog entry'), gives the execution context, states the primary action, and closes with the result format. No sentence is redundant.
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 search tool with all parameters documented by the schema, the description covers the essential context: it runs remotely, searches the tool catalog, and returns relevance-ranked matches. It does not detail the result structure in the absence of an output schema, but 'Returns matching tools' is adequate for a discovery 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 100%, so the baseline is 3 even without parameter details in the description. The description adds no parameter semantics beyond what the schema already provides for query, tags, limit, and detail.
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 names a specific verb and resource: 'Search for available tools by query' and states the output ('Returns matching tools ranked by relevance'). It clearly identifies the tool as a catalog search, but it does not explicitly differentiate from siblings such as get_schema or tags, so it falls short of a 5.
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 when to use the tool ('Search for available tools by query'), which is appropriate for discovery. However, it does not explicitly state when not to use it or mention alternatives like get_schema for retrieving a tool's full schema. Usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Catalog entry. Runs in your Kuudo deployment, not here. List available tool tags. Use to browse available tools by tag before searching.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Level of detail: 'brief' for tag names and counts, 'full' for tools listed under each tag | brief |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds one useful behavioral detail: 'Runs in your Kuudo deployment, not here.' However, it does not say whether the operation is read-only, what the response looks like, or any side effects. This is a moderate disclosure.
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 short and front-loaded with the key verb 'List available tool tags.' The 'Catalog entry' phrase is unnecessary and slightly confusing, but overall there is minimal 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 low-complexity tool with one optional fully-documented parameter and no output schema, the description provides essential context: purpose, when to use, and runtime location. No critical information is missing for an agent to call it correctly.
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 100%, with the 'detail' parameter fully described via enum and its own description. The tool description adds nothing beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: 'List available tool tags.' It also indicates its role as a browsing step before searching, which helps differentiate it from search. However, the opening 'Catalog entry' is vague and could confuse, so it is not a 5.
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 says 'Use to browse available tools by tag before searching,' providing clear context for when to use it. It does not name alternatives or exclusions, but the guidance is specific enough for an agent to select it.
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.0executeget_schemasearchtagsThe tools are mostly distinct: tags and search both help discover tools, but by different routes (tag browsing vs. query search). get_schema and execute are clearly separate for detail retrieval and execution. Minor overlap exists between tags and search, but descriptions sufficiently clarify the difference.
Names are simple and lowercase, but not fully consistent: 'tags' is a noun while 'search', 'get_schema', and 'execute' are verbs (or verb_noun in the case of get_schema). There is no chaotic mixing of conventions, but the pattern is not uniform.
With 4 tools, the set is well-scoped for its purpose: discover by tag, search, get schema, and execute. Every tool serves a distinct role in the workflow and none is superfluous.
The set covers the core lifecycle of browsing, searching, schematizing, and executing remote tools. A minor gap is the lack of a direct 'list all tools' operation; discovery relies on tags or search, but the workflow is otherwise complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time Amazon product, seller, and search data for AI agents across 21 marketplaces.
Amazon Seller Central and Amazon Ads for AI assistants: catalog, orders, FBA, pricing, PPC.
Direct access to 40+ scraping and search tools. Extract structured data from Google (Search, Maps, Trends), Amazon, Airbnb, Social Media, and any web page directly into your AI agent.
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/KuudoAI/amazon-agent-atlas-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
