Provides affiliate program integration for Webflow, enabling AI agents to generate tracked affiliate links and record conversions for Webflow's affiliate program through the AgentFuse platform.
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., "@agentfuse-mcp list all affiliate programs in the AI tools category"
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.
MCP server for AgentFuse -- the affiliate API middleware for AI agents.
Lets any MCP-compatible AI agent (Claude Code, Cowork, custom agents) browse affiliate programs, generate tracked links, and record conversions without writing HTTP code.
Tool | Description |
| Browse all programs in the catalog (filterable by category) |
| Get full details for one program by slug |
| Create an attribution-tagged short link for a user |
| Dashboard summary: clicks, signups, commissions |
| Log a conversion event when a user signs up |
| List all tracked links generated for your users |
| Log a commission event (purchase or renewal) |
Related MCP server: admitad-mcp
Node.js >= 18
An AgentFuse API key -- get one at agentfuse.io
Add to your project's .claude/mcp.json (or your global ~/.claude/mcp.json):
{
"mcpServers": {
"agentfuse": {
"command": "npx",
"args": ["-y", "agentfuse-mcp"],
"env": {
"AGENTFUSE_API_KEY": "af_live_your_key_here"
}
}
}
}Or, if you've cloned this repo locally:
{
"mcpServers": {
"agentfuse": {
"command": "node",
"args": ["/path/to/agentfuse-mcp/src/index.js"],
"env": {
"AGENTFUSE_API_KEY": "af_live_your_key_here"
}
}
}
}npm install
AGENTFUSE_API_KEY=af_live_... node src/index.jsnode src/index.js --testBrowse programs:
"List all affiliate programs in the AI tools category" -> calls
list_affiliate_programs({ category: "ai-voice" })
Generate a link:
"Create a tracked Webflow affiliate link for user alice@example.com" -> calls
generate_tracked_link({ program_slug: "webflow", end_user_id: "alice@example.com" })
Check stats:
"How many clicks and signups have we had this month?" -> calls
get_stats()
Variable | Required | Default | Description |
| Yes | -- | Your AgentFuse API key ( |
| No |
| Override the API base URL |
MIT (c) AgentFuse / GSK AIOrch LLC
Generate a tracked affiliate link for a program and an end user. Pass the human-readable program slug (e.g. 'webflow') -- the tool resolves the UUID automatically. The link records clicks and attributes any resulting signups or commissions back to the specified end user. Returns a short redirect URL and a tracking_code you should save -- it is needed for record_signup and record_commission.
| Name | Required | Description | Default |
|---|---|---|---|
| program_slug | Yes | Slug of the affiliate program (e.g. 'webflow', 'notion'). Use list_affiliate_programs to find available slugs. | |
| end_user_id | Yes | Your internal ID for the end user who will receive credit for this referral. Can be any stable unique string (UUID, email, username, etc.). | |
| metadata | No | Optional key-value metadata to attach to the link (e.g. { campaign: 'onboarding', source: 'chat' }). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the link records clicks, attributes signups/commissions, and returns a short redirect URL and tracking_code. It also mentions optional metadata. This is sufficient for a creation tool.
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 three sentences with no fluff. It front-loads the purpose, then provides usage details and behavioral implications. Every sentence is informative and earned.
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?
Given no output schema, the description explains the return values (short redirect URL and tracking_code) and their importance for sibling tools. All parameters are covered, and the context of the affiliate system is clear.
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%, but the description adds value by explaining that program_slug is human-readable with automatic UUID resolution, and that end_user_id can be any stable unique string. This goes beyond the schema descriptions.
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 'Generate a tracked affiliate link for a program and an end user' with a specific verb and resource. It clearly distinguishes from siblings by mentioning the tracking code needed for record_signup and record_commission, and clarifies that it uses human-readable slugs.
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 guidance on passing the human-readable slug and saving the tracking_code for later use. It implies usage context as a prerequisite for record_signup and record_commission, but does not explicitly state 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.
Get full details for a single affiliate program by its slug. Returns the program's UUID (needed for generate_tracked_link), commission structure, payout terms, description, and network info.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The program slug (e.g. 'webflow', 'elevenlabs', 'notion', 'zapier'). Use list_affiliate_programs to discover available slugs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately conveys this is a read-only lookup (no mention of side effects). It explains the output includes commission structure, payout terms, etc. The description is transparent about what the tool does, though it could mention if there are any rate limits or authentication requirements, but for a simple read operation this is sufficient.
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 with front-loaded key information. Every sentence adds value with no redundancy.
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 tool with one parameter and no output schema, the description fully explains the purpose, parameter, return contents, and links to related tools. Nothing 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?
The input schema has 100% coverage and the description adds meaningful context: it gives example slugs ('webflow', 'elevenlabs') and tells the user to use list_affiliate_programs to find more slugs. This goes beyond the schema alone.
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 it retrieves full details for a single affiliate program by slug. It lists specific return fields (UUID, commission, payout terms, etc.) and distinguishes from sibling tools like list_affiliate_programs (listing all) and generate_tracked_link (which requires the UUID from this tool).
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 notes that the slug parameter can be discovered using list_affiliate_programs, and that the returned UUID is needed for generate_tracked_link. While it doesn't state explicit when-not-to-use scenarios, the context is clear and provides helpful direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve AgentFuse dashboard summary stats: total clicks, signups, commissions, and top-performing programs. Useful for reporting to users or surfacing revenue data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves stats but does not disclose behavioral traits such as data freshness, caching, or whether it requires specific permissions. The simplicity of a zero-parameter tool partially mitigates this.
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 that is concise and front-loaded with the tool's purpose. Every word adds value.
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?
Given zero parameters and no output schema, the description is fairly complete. It specifies what stats are retrieved and a use case. It could mention if the stats are aggregate over all time or filtered, but not necessary for a simple endpoint.
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 input schema has no parameters, and schema description coverage is 100%. Baseline for zero parameters is 4, and the description adds no extra parameter info (none needed).
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 it retrieves dashboard summary stats and lists specific metrics (total clicks, signups, commissions, top-performing programs). It distinguishes from sibling tools like generate_tracked_link or record_commission, which focus on individual 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 mentions it is useful for reporting to users or surfacing revenue data, providing clear context. However, it does not explicitly exclude cases where other tools like list_affiliate_programs might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse available affiliate programs in the AgentFuse catalog. Returns each program's name, slug, category, commission rate, and network. Use this to discover programs before generating tracked links.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category slug. Examples: productivity, marketing, ai-voice, ai-writing, email-marketing, newsletter, automation, marketing-automation, seo-analytics, design, developer-tools. Omit to return all categories. | |
| limit | No | Number of programs to return (default: 50, max: 100). | |
| cursor | No | Pagination cursor returned from a previous call. Pass this to get the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lists the returned fields (name, slug, category, commission rate, network), which is helpful, but it does not disclose pagination behavior, rate limits, or authentication needs. Since no annotations are provided, the description carries full burden but falls short of giving rich behavioral context.
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 consists of two sentences that efficiently communicate purpose, return values, and usage context without extraneous 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?
While the description covers the basic return fields and usage context, it lacks details on pagination (despite a cursor parameter), ordering, error handling, and performance characteristics. The absence of an output schema makes this gap more significant, so completeness is only moderate.
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?
All three parameters have descriptions in the input schema (100% coverage), so the description adds minimal additional meaning. It does not elaborate on parameter details beyond the schema, so a baseline score of 3 is appropriate.
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 verb 'Browse' and identifies the resource 'available affiliate programs in the AgentFuse catalog', making the action and scope clear. It also hints at its role relative to siblings by stating 'before generating tracked links', distinguishing it from generate_tracked_link and get_affiliate_program.
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 advises using this tool 'to discover programs before generating tracked links', providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tracked affiliate links previously generated by this API key. Returns each link's tracked URL, tracking_code, click count, program, and end user. Use this to look up existing links before generating a new one, or to show a user their active referral links.
| Name | Required | Description | Default |
|---|---|---|---|
| end_user_id | No | Filter links by end user ID. Use this to fetch all links for a specific user. | |
| program_slug | No | Filter links by program slug (e.g. 'webflow'). The tool resolves the slug to a UUID automatically before querying. | |
| limit | No | Number of links to return (default: 20, max: 100). | |
| cursor | No | Pagination cursor from a previous call to get the next page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses return fields but does not explicitly state read-only nature, authorization needs, or potential side effects. The word 'list' implies read, but not confirmed.
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 sentences with no fluff: first defines purpose and output, second gives usage guidance. Every sentence 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?
For a list tool with good schema and no output schema, the description adequately covers purpose, return fields, and usage context. Could mention pagination behavior explicitly but schema covers cursor param.
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 100% with detailed parameter descriptions. The description adds no new parameter-level information beyond restating usage context, which does not exceed the baseline for high coverage.
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 it lists tracked affiliate links previously generated by this API key, with specific fields returned. It distinguishes from sibling tools like generate_tracked_link (creation) and list_affiliate_programs (programs).
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 tells when to use: 'to look up existing links before generating a new one, or to show a user their active referral links.' It does not explicitly exclude alternatives but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an affiliate commission event (e.g. when a referred user makes a purchase or renews a subscription). Requires the tracking_code from the original affiliate link. Idempotent -- safe to call multiple times with the same network + network_event_id.
| Name | Required | Description | Default |
|---|---|---|---|
| tracking_code | Yes | The tracking code from the affiliate link (returned by generate_tracked_link). | |
| network | Yes | The affiliate network that reported this event. One of: 'partnerstack', 'impact', 'direct'. | |
| network_event_id | Yes | Unique commission event ID from the affiliate network. Used for idempotency. | |
| amount | Yes | Commission amount in dollars (e.g. 29.99). | |
| currency | No | ISO 4217 currency code (default: 'USD'). | USD |
| commission_type | No | Type of commission. One of: 'initial', 'recurring', 'one_time'. Defaults to 'recurring'. | |
| period_start | No | Billing period start date in ISO 8601 format (optional). | |
| period_end | No | Billing period end date in ISO 8601 format (optional). | |
| metadata | No | Optional extra data (e.g. order ID, plan name). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must compensate. It discloses idempotency (safe to call multiple times with same network+network_event_id), which is key. However, it does not describe what happens on failure (e.g., invalid tracking_code), whether the endpoint is read-only or not, or any side effects. Some behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose with example, prerequisite, and idempotency note. No unnecessary words, front-loaded with key 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?
For a tool with 9 parameters and no output schema, the description covers the essential usage context but lacks explanation of return values or error handling. It adequately complements the detailed schema but could be more comprehensive (e.g., what the response looks like, permissions needed).
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?
Since schema description coverage is 100%, baseline is 3. The description adds minimal extra meaning: it emphasizes that tracking_code comes from generate_tracked_link (already in schema) and that network_event_id is used for idempotency (also in schema). No significant new parameter information.
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 ('Record an affiliate commission event') and provides a concrete example (purchase or renewal). It distinguishes from sibling tools like record_signup and generate_tracked_link by specifying the trigger (referred user purchase/renewal) and the required tracking_code from generate_tracked_link.
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 states when to use (upon purchase or subscription renewal) and notes the prerequisite of having a tracking_code from generate_tracked_link. It also mentions idempotency, suggesting safe retries. However, it does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an affiliate signup conversion event. Call this when one of your end users successfully signs up for a referred product. Requires the tracking_code returned by generate_tracked_link. Idempotent -- safe to call multiple times with the same network + network_event_id.
| Name | Required | Description | Default |
|---|---|---|---|
| tracking_code | Yes | The tracking code from the affiliate link (returned by generate_tracked_link). This ties the signup back to the original referral. | |
| network | Yes | The affiliate network that reported this event. One of: 'partnerstack', 'impact', 'direct'. | |
| network_event_id | Yes | Unique event ID from the affiliate network (or any unique string for 'direct'). Used for idempotency -- duplicate calls with the same ID are ignored. | |
| signup_email | No | Email address the user signed up with (optional but recommended). | |
| metadata | No | Optional extra data to attach to this event. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotency and safety of multiple calls. Without annotations, description provides essential behavioral context about side effects and dependency.
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?
Four sentences, no waste. Purpose first, then condition, prerequisite, and idempotency. Every sentence 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?
Covers purpose, trigger, prerequisite, and idempotency. Lacks return value or error handling, but no output schema expected. Adequate for a simple recording 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 coverage is 100%, so description adds limited value. It reinforces tracking_code's role and network_event_id's idempotency use, but doesn't go beyond 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?
Clear verb ('Record'), resource ('affiliate signup conversion event'), and condition ('when user signs up'). Distinguishes from siblings like generate_tracked_link (prerequisite) and get_stats.
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 states when to call (signup success) and prerequisite (tracking_code). Mentions idempotency but doesn't explicitly exclude alternatives; however, siblings don't overlap.
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.1.3generate_tracked_linkget_affiliate_programget_statslist_affiliate_programslist_tracked_linksrecord_commissionrecord_signupEach tool has a clear, unique purpose: generating links, retrieving program details, listing resources, recording different event types, and fetching stats. No two tools overlap in functionality; even record_commission and record_signup are distinctly about different events.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., generate_tracked_link, list_affiliate_programs, record_commission). The naming is predictable and easy to understand.
With 7 tools, the server is well-scoped for an affiliate link tracking service. Each tool serves a necessary function without being overwhelming or too sparse.
The tool surface covers core use cases: browsing programs, creating tracked links, listing links, recording signups and commissions, and viewing stats. Minor gaps like updating or deleting links exist but are not critical for the primary workflow.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Affiliate marketplace for AI agents: find tools, publish verified guides, earn. OAuth, no keys.
Directory of APIs, merchants, and tools AI agents can actually use.
Affiliate network reporting in your AI client. Bring your own keys. Most adapters experimental.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sai4447/agentfuse-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
