Skip to main content
Glama

Server Details

Generate Amazon affiliate sales funnels from product URLs. AI-powered, free.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.7% over 38 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.8/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: one kicks off generation, one polls status, and one lists available style axes. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb_noun pattern: generate_funnel, get_funnel_status, list_axes. The naming convention is uniform and predictable.

Tool Count5/5

Three tools is well-scoped for a focused one-shot funnel generator. Each tool earns its place and there is no unnecessary bloat.

Completeness4/5

The core workflow is covered: list options, submit a URL, and check generation status. Post-generation management like canceling or deleting funnels is not included, but the tool's irreversible one-shot design makes that a minor gap rather than a critical omission.

Available Tools

3 tools
generate_funnelAInspect

Generate a hosted Amazon affiliate landing page from a US amazon.com product URL the user gave you. One call takes ~4 minutes and costs real money, with no undo and no refund, so call it only for a link the user actually supplied. Never build a URL from an ASIN you remember, and never submit an example URL. If you do not have the user's link, ask for it instead of calling. No account needed.

ParametersJSON Schema
NameRequiredDescriptionDefault
axesNoStyle axes, all 0-100, omitted default to 50. Use list_axes for details.
store_idNoThe user's own Amazon Associates Store ID, if they gave it to you in this conversation (US tags end in -20). Omit it when unsure. Never guess one and never reuse a tag from an example or another conversation: a wrong tag pays the user's commissions to somebody else. It can be added later at https://funn.to.
amazon_urlYesThe amazon.com product URL exactly as the user gave it to you: copy it, do not retype or reconstruct it. Shape: https://www.amazon.com/<product-slug>/dp/<ASIN> or https://www.amazon.com/dp/<ASIN>. There is deliberately no example ASIN here: example ASINs get submitted as real products and bill the user for a page about something nobody asked for. If the user has not given you a link, ask for one rather than composing it from an ASIN you recall.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses the critical behavioral traits: ~4-minute latency, real monetary cost, no undo, and no refund. It also states that no account is needed, covering the main operational risks an agent must know before invoking.

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 few short sentences, with the core action first and the critical warnings following. Every sentence carries risk-relevant or scoping information; nothing is redundant filler.

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 covers the preconditions, costs, latency, and irreversibility needed to invoke safely. It does not explicitly describe what the call returns or how it connects to get_funnel_status, but the absence of an output schema and the presence of a status sibling make this a minor gap rather than a fatal one.

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% and the schema's own descriptions already explain the URL shape, the store_id policy, and axes defaults, so the description doesn't need to add parameter-level detail. The description reinforces sourcing rules but adds no new semantic meaning for the parameters themselves.

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 opening sentence states a specific action ('Generate'), a specific deliverable ('hosted Amazon affiliate landing page'), and an exact input source (a US amazon.com product URL supplied by the user). This makes the tool's role immediately distinguishable from the sibling status/axes tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Calls out the precise precondition ('only for a link the user actually supplied') and the disqualifying cases (never reconstruct from a remembered ASIN, never submit an example URL), with the alternative action ('ask for it instead of calling') stated explicitly. This is clear when-to and when-not-to guidance.

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

get_funnel_statusCInspect

Check the status of a funnel being generated.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesFunnel slug from the URL

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must carry the burden of disclosing behavioral traits. It only says 'check the status' without indicating whether it is read-only, idempotent, or what side effects (if any) occur. No information about return format or possible errors.

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 very concise, containing one sentence with no redundant information. However, it may be too brief, missing valuable context that could be added without losing conciseness.

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?

Given the simplicity of the tool (one parameter, no output schema), the description is minimally complete. It does not explain what the status response looks like, possible values, or how to handle errors, leaving the agent without sufficient context.

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% with the slug parameter having a description. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate. No further parameter detail is provided.

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

Purpose4/5

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

The description clearly states the tool checks the status of a funnel being generated, using the verb 'check' and specifying the resource. It distinguishes from siblings 'generate_funnel' (creates) and 'list_axes' (lists), but could be more specific about what status means (e.g., progress, completion).

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 provided on when to use this tool compared to siblings. It does not specify prerequisites (e.g., funnel must be generating) or conditions for use, leaving the agent to infer context.

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

list_axesAInspect

List available style axes for funnel generation.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are present, and the description does not disclose behavioral traits such as side-effects, authentication requirements, or whether it is read-only. The description adds minimal value beyond the name.

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 highly concise with a single sentence that conveys the tool's purpose without extraneous information.

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 has no parameters and no output schema, the description is minimal. It does not describe the format or content of the returned list, which may leave an agent uncertain about the output.

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 no parameters, so the description does not need to add parameter-level meaning. Baseline score of 4 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 it lists style axes for funnel generation, using a specific verb and resource. It distinguishes itself from siblings 'generate_funnel' and 'get_funnel_status' which perform different actions.

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?

No explicit usage guidance is provided. The purpose is implied by the tool name and description, but there are no when-to-use or when-not-to-use instructions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedgenerate_funnel3 fields changed
      • changedInput schema / properties / amazon_url / description
        Previous value: -"Amazon product URL (e.g. https://www.amazon.com/dp/B0DWN2KR9W)"New value: +"The amazon.com product URL exactly as the user gave it to you: copy it, do not retype or reconstruct it. Shape: https://www.amazon.com/<product-slug>/dp/<ASIN> or https://www.amazon.com/dp/<ASIN>. There is deliberately no example ASIN here: example ASINs get submitted as real products and bill the user for a page about something nobody asked for. If the user has not given you a link, ask for one rather than composing it from an ASIN you recall."
      • changedInput schema / properties / amazon_url / pattern
        Previous value: -"^https?:\\/\\/(www\\.)?amazon\\.(com|co\\.uk|de|fr|it|es|ca|com\\.au|co\\.jp|in|com\\.br|com\\.mx|nl|sg|ae|sa|pl|se|com\\.be|com\\.tr)(\\/|$)"New value: +"^https?:\\/\\/(www\\.)?amazon\\.com\\/"
      • changedInput schema / properties / store_id / description
        Previous value: -"Amazon Associates Store ID (e.g. mystore-20). Optional."New value: +"The user's own Amazon Associates Store ID, if they gave it to you in this conversation (US tags end in -20). Omit it when unsure. Never guess one and never reuse a tag from an example or another conversation: a wrong tag pays the user's commissions to somebody else. It can be added later at https://funn.to."
  2. 1 tool update
    • Changedgenerate_funnel3 fields changed
      • addedInput schema / properties / axes / properties / factness
        Added value: +{
        +  "description": "0=Anchored, 100=Fictional",
        +  "maximum": 100,
        +  "minimum": 0,
        +  "type": "number"
        +}
      • addedInput schema / properties / axes / properties / format
        Added value: +{
        +  "description": "0=Sales page, 100=Blog review",
        +  "maximum": 100,
        +  "minimum": 0,
        +  "type": "number"
        +}
      • addedInput schema / properties / axes / properties / persona
        Added value: +{
        +  "description": "0=Third person, 100=First person",
        +  "maximum": 100,
        +  "minimum": 0,
        +  "type": "number"
        +}
  3. 1 tool update
    • Changedget_funnel_status1 field changed
      • changedInput schema / properties / slug / description
        Previous value: -"Funnel slug (from the URL, e.g. 'abc123' from funn.to/f/abc123)"New value: +"Funnel slug from the URL"
  4. 3 tool updates
    • First observedgenerate_funnel
    • First observedget_funnel_status
    • First observedlist_axes

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Enables AI assistants to search products and generate affiliate links across European and global affiliate networks, automating product discovery and link creation for monetization.
    2
    5
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Generate AI UGC video ads from any product URL in 5 minutes. Realistic AI avatars, natural voiceover, proven ad templates. No actors, no editing, no experience required.
    39 npm
    1
    MIT
  • F
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to search products across affiliate networks, compare commissions, find arbitrage opportunities, and get auto-injected affiliate links via MCP.
    -
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources