Provides affiliate link generation for Gumroad products, enabling tracking of referrals with commission attribution.
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., "@affiliate-router-mcp Find affiliate programs for crypto APIs"
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.
Vendor-neutral monetization routing for agent tools. One MCP server that discovers, routes, and attributes revenue across paid APIs, referral links, and affiliate programs.
Source: https://github.com/forgemeshlabs/affiliate-router-mcp
The router is not tied to any single payment network or affiliate system. Adapters are pluggable. The registry is a local JSON file you control.
Status: experimental · v0.1.6
Disclaimer: This MCP does not guarantee payouts. It routes attribution data according to each vendor/program's rules. Commission distribution is enforced by the vendor's payment system, not by this router.
Agents need a way to call monetizable tools without hardcoding every affiliate
or payment system. affiliate-router-mcp provides:
Discovery — find vendors and products by category or intent
Routing — choose the right payment/attribution path automatically
Calling — execute payments with affiliate attribution
Link generation — inject tracking params into referral URLs
Telemetry — log every attributed call locally for tracking
Related MCP server: Refgrow MCP Server
Tool | Cost | Description |
| Free | Find products by category or keyword |
| Free | List all vendors and their programs |
| Free | Full details on a specific vendor/product |
| Free | Recommend the best route for an intent |
| Free | Build a tracked referral URL |
| varies | Pay and call a product with attribution |
| Free | Project monthly earnings at a call volume |
| Free | View local attribution log |
Each payment or attribution system is a separate adapter. Adding a new one does not affect existing adapters.
Adapter | How it works | Payment | Status |
| Approve USDC → | On-chain USDC split | Tested |
| EIP-3009 | On-chain USDC to vendor | Implemented |
| Inject affiliate param into URL | None — program-dependent | Implemented |
Pyrimid is the first fully tested paid affiliate adapter. It is not the only supported model. Future adapters may include: PartnerStack, Rewardful, Impact, Commission Junction, coupon/promo code injection, API-key partner programs, and other emerging agent commerce protocols.
npm install -g affiliate-router-mcpOr with Claude Code / any MCP client:
{
"mcpServers": {
"affiliate-router": {
"command": "affiliate-router-mcp",
"env": {
"WALLET_PRIVATE_KEY": "0x...",
"PYRIMID_AFFILIATE_ID": "af_your_id",
"GUMROAD_AFFILIATE_ID": "your-gumroad-id"
}
}
}
}Variable | Required | Notes |
| For | Base wallet with USDC + ETH for gas |
| No | Default affiliate ID for Pyrimid-registered products |
| No | Gumroad tracking ID |
| No | PartnerStack referral code |
CoinOpAI (x402_pyrimid) — crypto intelligence API on Base mainnet
Kronos Signals — $0.05/call, 20% commission
Kronos Decision — $0.15/call, 20% commission
Trade Preflight — $0.05/call, 20% commission
Trade Audit — $0.07/call, 20% commission
Image Generation — $0.10/call, 20% commission
Gumroad (referral_link) — digital product marketplace, ~30% commission per product
PartnerStack (referral_link) — SaaS affiliate programs stub (add your own products)
call_affiliate_product(vendor_id, product_id, params, affiliate_id?)
↓
resolve affiliate_id: tool arg → env var → null
↓
adapter = vendor.affiliate_system
↓
x402_pyrimid + affiliate_id present?
cache VALID → Pyrimid split flow (affiliate earns commission)
cache INVALID → x402_direct fallback (vendor gets 100%)
cache UNKNOWN → try Pyrimid → cache result → fallback on failure
x402_direct → EIP-3009 payment, no affiliate split
referral_link → inject tracking param, no paymentThese are independent concerns.
Package updates (this repo):
Adding or fixing adapters
Updating tool schemas
Changing routing or caching logic
Dependency bumps
Product/catalog updates (registry.json):
Registering new vendor endpoints
Changing prices or commission rates
Enabling affiliate eligibility on a product
Assigning network-specific product IDs (e.g. Pyrimid product IDs)
Adding a vendor to registry.json does not require a package release.
Releasing a new package version does not require products to be re-registered.
Edit registry.json. No code changes needed for referral-link vendors.
x402 vendors require a funded wallet. Pyrimid vendors additionally require
on-chain registration to obtain a vendor_id and per-product pyrimid_product_id.
{
"id": "my_vendor",
"name": "My Vendor",
"affiliate_system": "referral_link",
"affiliate_config": {
"tracking_param": "ref",
"affiliate_id_env": "MY_VENDOR_REF_CODE",
"commission_pct": 25
},
"products": [...]
}All call_affiliate_product calls append to logs/affiliate-telemetry.jsonl:
{
"ts": "2026-05-14T17:07:01Z",
"vendor_id": "coinopai",
"product_id": "kronos_signals",
"amount_usd": 0.05,
"affiliate_id": "af_your_id",
"payment_type": "x402_pyrimid",
"commission_est_usd": 0.0099,
"status": "success",
"tx_hash": "0x..."
}Remote registry sync
PartnerStack / Impact.com / Rewardful API integrations
Web dashboard
Multi-level commissions
Server-side redirect tracking for links
Infrastructure for monetized agent ecosystems.
Package | What | Install |
affiliate-router-mcp | Vendor-neutral monetization routing (this package) |
|
Paid crypto intelligence via x402 |
| |
Paid image generation MCP |
|
Each package works standalone. No shared dependency required.
MIT — CoinOpAI
Call a paid x402 API product with automatic affiliate attribution. Handles full payment (USDC on Base). Pyrimid affiliate routing used when eligible; falls back to direct x402 if affiliate_id is invalid. Costs USDC per call — amount shown in get_opportunity_details.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Query parameters for the endpoint (e.g. {symbol: 'BTC'} for kronos_decision) | |
| vendor_id | Yes | Vendor ID (must be an x402 vendor, e.g. 'coinopai') | |
| product_id | Yes | Product ID to call | |
| affiliate_id | No | Override affiliate ID. If omitted, uses PYRIMID_AFFILIATE_ID env var or no attribution. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: handles payment (USDC on Base), uses Pyrimid affiliate routing with fallback to direct x402 if affiliate_id invalid, and costs USDC per call. Without annotations, this provides sufficient transparency for the agent.
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 sentences, front-loaded with main purpose, followed by key details on payment and cost. No redundant or extraneous information. Each 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?
Lacks description of the return value/response format, which is important for a paid tool. Although cost info is referenced to another tool, the output of the call itself is not described. Given no output schema, this is a gap.
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 already describes all 4 parameters with 100% coverage. The tool description adds context about affiliate routing and payment but does not augment individual parameter meanings beyond what the schema provides. 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?
Description clearly states the action ('Call a paid x402 API product') and the resource (paid API product with automatic affiliate attribution). It distinguishes from sibling tools like estimate_commission and get_opportunity_details, which handle estimation or details rather than making the actual call.
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?
Implies usage context by mentioning payment and affiliate attribution, and references get_opportunity_details for cost info. However, it does not explicitly contrast with siblings or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate affiliate commission for a product based on known rates. Returns per-call and monthly estimates. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | Yes | Vendor ID | |
| product_id | Yes | Product ID | |
| calls_per_month | No | Estimated monthly call volume (default 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the tool is 'Free' and returns estimates, but does not disclose whether it is read-only, requires authentication, or has side effects. For a simple estimation tool, this is minimally adequate.
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 very concise: two sentences with no redundancy. It conveys the core purpose quickly, though it could be slightly more structured (e.g., listing outputs).
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 only vaguely mentions return values ('per-call and monthly estimates'). It lacks details on error conditions, data format, or edge cases. Adequate for a simple tool but not fully complete.
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 descriptions for all parameters. The description does not add additional meaning beyond the schema, so baseline 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 clearly states the tool estimates affiliate commission for a product, differentiating itself from siblings like `call_affiliate_product` (actual call) and `get_affiliate_telemetry`. It specifies outputs (per-call and monthly estimates) and notes it is free.
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 usage for estimating commissions but provides no explicit guidance on when to use this tool versus alternatives (e.g., `get_affiliate_telemetry` for telemetry). No exclusion criteria or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a tracked affiliate link for a referral-link or query-param-link vendor. No payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | Yes | Vendor ID (must be a link-based affiliate, not x402) | |
| product_id | Yes | Product ID within the vendor | |
| affiliate_id | No | Override affiliate ID (env var used if omitted) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It states 'Generate a tracked affiliate link' and 'No payment required,' but omits details on idempotency, side effects, authentication needs, or rate limits. The constraint on vendor type is only in the schema, not integrated into the description.
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 two sentences long, front-loads the primary action, and contains no unnecessary words. It is highly concise and structurally efficient.
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 and 3 parameters, the description covers the basic purpose and a key constraint (no payment). However, without annotations, it lacks details on behavioral aspects like mutability or error conditions, which affects completeness for an agent to use 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%, so the baseline is 3. The description adds no additional parameter meaning beyond what the schema provides; it mentions 'No payment required' but does not elaborate on how that relates to parameters. The schema descriptions are adequate but minimal.
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 tool generates a tracked affiliate link and specifies vendor types ('referral-link or query-param-link vendor'), distinguishing it from sibling tools like 'call_affiliate_product' or 'estimate_commission'.
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 includes the note 'No payment required,' which provides a condition, but it does not explicitly state when to use this tool versus alternatives like 'call_affiliate_product' or 'get_best_route.' Some guidance is present in the schema (vendor_id must be link-based), but not in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read local affiliate telemetry log — timestamps, vendors, products, amounts, affiliate IDs, statuses. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max entries to return (default 20) | |
| vendor_id | No | Filter by vendor | |
| affiliate_id | No | Filter by affiliate ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only adds 'Free' as a behavioral trait, but lacks details on mutability, auth requirements, rate limits, or pagination behavior.
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, efficient sentence with no fluff. Every word adds value, and important information is front-loaded.
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 partially describes return fields but omits details like default limit, ordering, or pagination. It adequately covers the basic purpose but could be more complete.
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%, baseline is 3. The description adds value by listing the fields in the log (e.g., timestamps, vendors), helping users understand what data the parameters filter and what the output contains.
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 verb 'Read' and the resource 'local affiliate telemetry log', and lists specific fields. It distinguishes itself from sibling tools like 'call_affiliate_product' and 'list_affiliate_programs' by focusing on telemetry data.
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 usage for reading telemetry logs but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a natural language intent, find the best matching affiliate opportunity ranked by relevance, trust, and commission. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | What you're trying to accomplish (e.g. 'get a crypto trading signal for BTC') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavior beyond the basic purpose, such as how ranking works, what 'Free' means, or any limitations like rate limits or idempotency. The safety profile of this tool is unclear.
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 two sentences: the first is informative and front-loaded, the second is a single word 'Free.' that adds minimal value. Overall concise and clear.
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 required parameter and no output schema, the description covers the basic purpose and input format. However, it lacks information about expected results, failure modes (e.g., no match), and behavioral context beyond what is stated.
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?
With 100% schema coverage and only one parameter, the description adds value by providing a concrete example of the intent parameter ('e.g. get a crypto trading signal for BTC'), clarifying its natural language nature.
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 tool finds the best matching affiliate opportunity based on natural language intent, ranked by relevance, trust, and commission. It distinguishes from sibling tools like search_opportunities and get_opportunity_details by emphasizing ranking and natural language input.
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 usage when a natural language intent is given, but does not explicitly state when to use this tool over alternatives like search_opportunities or estimate_commission. No exclusions or prerequisites are mentioned.
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 vendor and optionally a specific product — endpoint, pricing, commission, params. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | Yes | Vendor ID from list_affiliate_programs (e.g. 'coinopai') | |
| product_id | No | Optional product ID within the vendor |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions 'Free' (no cost) and lists returned data types, but does not state whether the tool is read-only, has side effects, or requires authentication. The term 'Get' implies read-only, but it's not explicit.
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 conveys all essential information without redundancy. It is front-loaded with the main action and details, making it easy for an agent to quickly grasp the 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?
The description mentions the types of information returned ('endpoint, pricing, commission, params'), but without an output schema, it does not describe the structure or format of the response. For a tool that returns multiple data points, more detail on the return value would improve completeness. Additionally, no usage guidance is given.
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?
Both parameters are documented in the schema (100% coverage), and the description adds context beyond the schema: it specifies the source for vendor_id ('from list_affiliate_programs') and gives an example ('coinopai'), and clarifies that product_id is optional. This helps the agent understand where to get the input values.
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 ('Get full details'), the resource ('a vendor and optionally a specific product'), and what's included ('endpoint, pricing, commission, params'). It distinguishes itself from sibling tools by specifying it provides comprehensive details for a single vendor/product.
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 lacks any guidance on when to use this tool versus alternatives. It does not mention when not to use it or compare it to siblings like 'search_opportunities' or 'list_affiliate_programs'. Only the word 'Free' hints at safety, but no explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered affiliate programs with commission rates, affiliate system type, and status. Free.
| 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 must carry the full burden. It discloses that the tool lists all programs and includes status and commission details, and mentions 'Free' which may indicate no cost. However, it does not state whether it is read-only, any rate limits, or if the list is paginated. For a simple list tool, this is adequate 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 extremely concise: one sentence that immediately states the action ('List') and the data returned. There is no wasted text. It is front-loaded and efficient.
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 that there is no output schema, the description should provide more detail about the return format. It mentions three fields (commission rates, affiliate system type, status) but does not specify whether the response is an array, paginated, or includes any nested objects. For a tool with no parameters, the description is somewhat complete but could be more thorough.
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% (empty). The description adds value by stating what the tool returns, which is beyond the schema. Since there are no parameters, the description does not need to elaborate on parameter semantics; the baseline is high.
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 tool lists all registered affiliate programs and specifies the fields returned: commission rates, affiliate system type, and status. The word 'list' and the mention of specific attributes make the purpose unambiguous. It distinguishes from siblings like 'call_affiliate_product' or 'estimate_commission' which have more specific actions.
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 that this tool is for retrieving a full list of programs, but it does not explicitly state when to use it versus siblings. For example, it doesn't say 'use this when you need an overview, and use search_opportunities for filtered queries.' The context of sibling tools suggests differentiation, but the description itself provides no usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search affiliate opportunities by keyword or category. Returns matching vendors and products with commission info. Free — no payment required.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keyword to search (e.g. 'crypto', 'image generation', 'saas tools') | |
| category | No | Filter by category (e.g. 'crypto', 'ai', 'tools') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It only states that the tool is free, but lacks information on rate limits, pagination, data freshness, authentication requirements, or any constraints on result size. This is insufficient for a search 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 concise, two sentences long, with no wasted words. The first sentence states the purpose, and the second adds the free aspect. It is well-structured and front-loaded.
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 the complexity (2-param search tool, no output schema, no annotations), the description provides a basic outline of what the tool does and returns. However, it lacks details on result limits, ordering, error behavior, and scope. It is adequate but could be more complete.
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% description coverage for both parameters. The description mentions 'by keyword or category,' which aligns with the schema. However, it adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not enhance understanding.
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 (search), the resource (affiliate opportunities), and the input methods (keyword or category). It mentions the output includes matching vendors and products with commission info. However, it does not explicitly differentiate from sibling tools like 'get_opportunity_details' or 'list_affiliate_programs', though the context implies a broad search.
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 includes a note about being free, which is helpful. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use 'search_opportunities' vs. 'get_opportunity_details' or 'list_affiliate_programs'). The usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: calling a paid product, estimating commissions, generating links, reading telemetry, finding the best route, getting details, listing programs, and searching opportunities. No two tools overlap in functionality.
All tools follow a consistent 'verb_noun' pattern in snake_case (e.g., call_affiliate_product, estimate_commission, list_affiliate_programs). There is no mixing of styles or irregular naming.
With exactly 8 tools, the set is well-scoped for the affiliate routing domain. It provides sufficient functionality without being overwhelming or sparse.
The tool set covers key user workflows: discovering, evaluating, and using affiliate products, plus telemetry. A minor gap is the lack of tools for creating or managing affiliate programs, but this may be outside the intended scope.
Agent-commerce MCP server for x402/USDC payments and affiliate splits on Base.
Agent-to-agent referral network. Discover, recommend, and refer users between AI agents via MCP.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Commerce MCP — agent-native A2A storefront. Discovery, Stripe checkout, affiliate program.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/forgemeshlabs/affiliate-router-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
