affiliate-router-mcp
Server Quality Checklist
Latest release: v0.1.7
- Disambiguation5/5
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.
Naming Consistency5/5All 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.
Tool Count5/5With exactly 8 tools, the set is well-scoped for the affiliate routing domain. It provides sufficient functionality without being overwhelming or sparse.
Completeness4/5The 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.
Average 3.7/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
- 4 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose4/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines2/5Does 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.
- Behavior3/5
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.
Conciseness4/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior2/5
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.
Conciseness4/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior2/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
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
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/forgemeshlabs/affiliate-router-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server