Skip to main content
Glama
heikowagner

Amazon Affiliate MCP Server

by heikowagner

Server Quality Checklist

67%
Profile completionA complete profile improves this server's visibility in search results.
  • Latest release: v1.0.0

  • Disambiguation5/5

    Each tool targets a distinct use case: search for general queries, product_link for specific ASINs, deals for promotions, bestsellers for category lists, gift_finder for personalized suggestions, compare for side-by-side comparisons, promo_content for content creation, and affiliate_info for configuration details. There is no overlap or ambiguity between any two tools.

    Naming Consistency5/5

    All tool names consistently follow the pattern `amazon_` followed by a descriptive noun or verb, with all names in lowercase snake_case. This creates a predictable and recognizable naming convention across the entire set, even though the second part varies between verbs and nouns.

    Tool Count5/5

    With 8 tools, the server is well-scoped for its purpose of generating Amazon affiliate links and supplementary content. Each tool covers a distinct aspect of affiliate marketing without redundancy or bloat, fitting comfortably within the ideal 3-15 tool range.

    Completeness5/5

    The toolset covers the full lifecycle of affiliate link generation: finding products (search, bestsellers, deals), creating links for specific products (product_link), enhancing engagement (gift_finder, compare), producing content (promo_content), and managing/understanding the setup (affiliate_info). There are no obvious missing operations for the declared domain.

  • Average 4.1/5 across 8 of 8 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 0 commits in the last 12 weeks
    • Last stable release on
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available
  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
      "$schema": "https://glama.ai/mcp/schemas/server.json",
      "maintainers": [
        "your-github-username"
      ]
    }

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

  • Behavior3/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are present, so the description carries the burden. It states the core behavior (search returns affiliate link) and lists supported countries/categories, but does not clarify result format (single link vs list of products), pagination, or potential errors. Thus a 3.

    Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

    Conciseness4/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is a single paragraph, front-loaded with the purpose, followed by usage and supported options. It efficiently conveys necessary information, though the long lists could be formatted better. Score 4.

    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 tool has 5 parameters and no output schema. The description covers the main function and supported constraints, but leaves ambiguity about the exact return shape (one link vs many) and does not detail edge cases or limitations. Score 3.

    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 coverage is 100% (all 5 parameters have descriptions). The description adds no additional parameter semantics beyond the schema; it merely lists available countries/categories which are also in the schema. Baseline 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    Description clearly states the verb (search), resource (products on Amazon), and output (affiliate link), and explicitly says when to use it for product recommendations or shopping suggestions, distinguishing it from sibling tools like amazon_deals or amazon_bestsellers.

    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?

    Provides explicit usage guidance: 'Use this tool whenever a user asks for product recommendations or shopping suggestions.' However, it does not mention alternatives or when not to use, so a 4 rather than 5.

    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?

    With no annotations provided, the description does carry the burden. It discloses key behaviors: incorporating affiliate tags, creating search links, and always including a gift card as fallback. Still, it does not mention output format, potential limitations, or any 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.

    Conciseness5/5

    Is the description appropriately sized, front-loaded, and free of redundancy?

    The description is three sentences long, front-loaded with the core purpose, and each sentence adds valuable context (country coverage, tailoring factors, gift card fallback). No unnecessary words.

    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?

    Without an output schema, the description should clarify what the tool returns. It mentions 'gift idea links' but does not specify the exact return format (e.g., array of URLs, text, structured data). It adequately conveys the core function but leaves some ambiguity.

    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 100%, so the baseline is 3. The description mentions the relevant parameters (recipient, interests, budget, occasion) but adds no new semantics beyond what the schema already provides.

    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: generating personalized Amazon gift idea links with affiliate tags. It distinguishes itself from sibling tools like amazon_search or amazon_deals by focusing on personalized gift recommendations.

    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?

    It indicates when to use the tool (when personalized gift ideas are needed) and describes tailoring by recipient description, interests, budget, and occasion. However, it does not explicitly exclude alternatives or mention when not to use it.

    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?

    With no annotations provided, the description carries the burden of disclosure. It clearly states the action (generating a link) and implies the output (a trackable link), but does not explain the return format, potential errors, or any side effects. It is adequate but does not go beyond the obvious for a simple link generator.

    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 core purpose, and contains no superfluous information. Every phrase adds value—'clean, trackable link' and 'any supported Amazon country' are useful context without bloating the text.

    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?

    Given the tool's simplicity and the schema's completeness, the description is sufficient to understand the tool's operation. However, since there is no output schema, the description does not specify the exact return structure (e.g., whether it returns just the URL or includes the product name), leaving a minor gap.

    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?

    The schema provides 100% coverage, including descriptions for asin, country, and product_name. The description adds no extra semantic details beyond what the schema already offers, so a baseline score of 3 is appropriate. It does align with the ASIN requirement and supported country concept.

    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: 'Generate a direct Amazon affiliate link for a specific product using its ASIN.' It uses a specific verb and resource, and distinguishes itself from sibling tools like amazon_search and amazon_deals by focusing on link generation rather than discovery. The mention of ASIN and supported countries adds specificity.

    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 explicit usage context: 'Use this when you already know the exact product (10-character ASIN) and want a clean, trackable link.' This tells the agent when to select this tool over siblings, though it does not explicitly mention alternatives or exclusions like when not to use it.

    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?

    With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output ('ranked product entries with names and affiliate URLs') and the affiliate-link aspect, which are behavioral traits beyond the schema. However, it does not disclose potential side effects or limitations, though none are apparent.

    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 appropriately concise with three short sentences. The first sentence front-loads the primary purpose, the second describes the return value, and the third provides a brief usage rationale. No wasted words; each sentence earns its place.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the lack of an output schema, the description appropriately explains the return format (ranked entries with names and URLs). It also covers the key inputs (2–5 products, supported countries) and the core functionality. It does not dive into edge cases or error handling, but for a low-complexity tool this is sufficient.

    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 100%, and the schema already fully documents parameters like asins, country, and produktnamen. The description adds no extra parameter-level detail beyond reiterating the 2–5 product range and supported countries, so it meets the baseline for high schema coverage.

    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: building a side-by-side product comparison of 2–5 Amazon items. It uses a specific verb ('Build') and resource ('comparison of Amazon products'), and distinguishes itself from sibling tools like amazon_search or amazon_bestsellers by focusing on comparison output with affiliate links.

    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 a use case (increasing engagement and click-through rates) but does not explicitly state when to use this tool vs. alternatives. No exclusions or direct references to sibling tools are provided, though the marketing benefit sentence offers some context.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior3/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description carries the burden. It states the primary output (affiliate link) and mentions a performance trait, but does not disclose potential error scenarios, whether the link is direct or requires affiliate setup, or any other edge-case behaviors. For a simple link-return tool, the core behavior is clear, but additional transparency is missing.

    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 exactly two sentences: the first states the purpose, the second provides a rationale and a compact list of valid categories. No filler words. The structure is front-loaded and every element earns its place, including the long list which is necessary for parameter clarity.

    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 low-complexity tool with two parameters and no output schema, the description is sufficiently complete: it states the return type (affiliate link), the key parameters (category and country), and provides the valid category list. It could be more explicit about the link format or behavior for invalid inputs, but these are minor given the tool's simplicity.

    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 schema already covers both parameters with descriptions (100% coverage). The description adds significant value by listing all valid categories, which the schema only gives examples of (e.g., 'elektronik', 'bücher'). This helps the agent know the exact accepted values, beyond what the schema provides.

    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 begins with a specific verb and resource: 'Return an affiliate link to the Amazon bestseller list for a specific category and country.' This clearly differentiates it from siblings like amazon_search or amazon_product_link by focusing on bestseller lists and affiliate links.

    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 a clear context for when to use this tool: 'Bestseller links consistently outperform generic search links in click-through and conversion rates.' This implies a preference over generic search, but it does not explicitly enumerate alternatives or exclusions, so it stops short of full guidance.

    Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

  • Behavior3/5

    Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

    No annotations are provided, so the description carries the full transparency burden. It clearly indicates the tool returns affiliate links and supports specific deal types, implying a read-only operation. However, it does not describe the return format or any potential quirks, leaving some ambiguity.

    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?

    Three sentences, each adding meaningful information: the core function, supported deal types, and a use case. No filler or redundancy.

    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 two-parameter tool with no output schema, the description covers purpose, scope, deal categories, and a practical use case. It does not explicitly state the return format, but that is less critical given the absence of an output schema.

    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?

    Schema descriptions cover both parameters fully (100%). The description adds value by mapping the deal_type enum to more human-readable alternatives (flash/lightning, outlet, warehouse, Prime), enriching the parameter context beyond the schema.

    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 retrieves affiliate links for current Amazon deals and offers, enumerating supported deal types. This provides a specific verb+resource+scope that distinguishes it from siblings like amazon_bestsellers or amazon_search.

    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 context by stating it is 'Great for sharing time-sensitive promotions that convert well,' guiding when to use the tool. It does not explicitly name alternatives or exclusions, but the use case is well-defined.

    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?

    With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context beyond the schema by noting that the output is 'ready-to-publish' and 'includes mandatory affiliate disclosure text,' which is important for compliance. However, it does not mention any potential side effects, limitations, or request-specific behaviors, so it is not a 5.

    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 concise: two sentences, no filler. The first sentence immediately states the primary purpose, and the second efficiently lists supported formats and languages. It earns its place without redundancy.

    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?

    The description provides a solid overall picture for a content-generation tool: what it produces, the output formats, languages, and the inclusion of disclosure text. It lacks details about the exact output structure, but there is no output schema, so the description does what is reasonably expected. It is slightly incomplete in not explaining when to choose this over sibling tools, but that is more of a usage guideline gap.

    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?

    The input schema already provides full descriptions for all 7 parameters (100% coverage). The description adds no additional parameter-specific information beyond the platform list and language list, which are also present in the schema. Since the schema does the heavy lifting, the baseline of 3 is appropriate.

    Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

    Purpose5/5

    Does the description clearly state what the tool does and how it differs from similar tools?

    The description clearly states the tool's purpose with a specific verb ('Generate') and resource ('ready-to-publish promotional content for Amazon products with embedded affiliate links'). It also distinguishes itself from sibling tools like amazon_search or amazon_deals by focusing on content creation rather than search or deal discovery.

    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 when to use the tool (when promotional content is needed) and provides context about supported platforms and languages, but it does not explicitly state when not to use it or name alternatives. Since sibling tools exist, a clear 'use this instead of X' statement would be helpful, but the context is still unambiguous.

    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?

    No annotations are present, so the description carries the burden. It clearly indicates a read-only operation by saying 'Return a full overview' and 'diagnose,' which implies no side effects. It also discloses what information is returned, though it does not explicitly state that it never modifies the configuration or mention response format.

    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 with no wasted words. The first sentence states the action and contents, and the second gives practical use cases. It is front-loaded with the verb and immediately informative.

    Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

    Completeness4/5

    Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

    Given the tool's simplicity (no parameters, no output schema, no annotations), the description adequately covers what is returned and why it might be used. It could be slightly more explicit about being a read-only diagnostic tool, but the current wording is sufficient for this low-complexity tool.

    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, so there is nothing to explain. Per the rubric, a 0-parameter tool gets a baseline of 4 because the description need not compensate for missing parameter details.

    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 identifies the resource ('active Amazon affiliate configuration') plus the exact content covered (tags, countries, domains, currencies, commission rates, tips). It also distinguishes itself from shopping-oriented sibling tools by focusing on configuration and diagnostics.

    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 states when to use it: 'to show users which countries are active or to diagnose missing affiliate tags.' It does not mention when not to use it or alternatives, but none of the sibling tools overlap with this configuration-focused purpose, so the guidance is clear.

    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

amazon-affiliate-mcp MCP server

Copy to your README.md:

Score Badge

amazon-affiliate-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/heikowagner/amazon-affiliate-mcp'

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