Click on "Deploy 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., "@Affilync MCP Server search for new affiliate campaigns and show my earnings summary"
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 (Model Context Protocol) server for Affilync — manage affiliate marketing directly from Claude.
This package ships two servers that expose the same tools:
Transport | Auth | Who runs it | |
| local subprocess |
| each user, locally |
| hosted at | OAuth 2.1 ("Connect Affilync") | Affilync (one deployment) |
The remote server is the one Claude connects to by URL with one-click OAuth — see Remote server. The stdio server (below) is for local/manual use with a pasted token.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"affilync": {
"command": "npx",
"args": ["@affilync/mcp-server"],
"env": {
"AFFILYNC_TOKEN": "<your-jwt-token>"
}
}
}
}claude mcp add affilync -- env AFFILYNC_TOKEN=<your-jwt-token> npx @affilync/mcp-serverThe server sends AFFILYNC_TOKEN as Authorization: Bearer <token>, so it
must be a JWT access token (from your Affilync login session or the OAuth
flow) — a developer API key (af_live_...) will NOT work with this server
as-is. To obtain one: log in at https://app.affilync.com, or complete the
OAuth flow (see the Affilync CLI / SDK), and use the access token value as
AFFILYNC_TOKEN. Note tokens expire (~60 min); re-issue as needed.
Related MCP server: agentfuse-mcp
Least authority. Every tool proxies to /api/gpt/v1/* and carries only
your bearer token. The backend independently enforces authentication, token
revocation, user type (affiliate vs. brand) and write-scope — this server
grants no capability the API wouldn't grant your token directly.
Read-only mode. Set AFFILYNC_READONLY=1 to register only read tools.
Mutating tools (joinCampaign, generateAffiliateLink, requestPayout,
createCampaign, decideApplication) are not exposed at all — the model
cannot invoke a state change or move money. Recommended for exploration.
Tool safety hints. Mutating tools are annotated so the client can prompt
before running them; money-moving / approval tools carry a destructiveHint.
Bounded I/O. Requests time out after 15s; responses are truncated to a
safe size; backend error bodies are sanitized (status + short detail only)
so raw server internals never reach the model.
Tool | Description |
| Health check — API reachable and token accepted |
| Get your profile (affiliate or brand) |
| Search campaigns by name/category |
| View recent notifications |
Tool | Description |
| Browse campaigns to join |
| Apply to join a campaign |
| Create a tracking link |
| View your tracking links |
| Total/pending/available earnings |
| Individual commission records |
| Click stats (today/week/month) |
| Cash out available earnings |
| Your joined campaigns |
Tool | Description |
| Create a campaign with commission structure |
| View your campaigns |
| Campaign metrics (clicks, conversions, EPC) |
| Review applications |
| Approve/reject an application |
| Overall brand performance |
| Affiliates working with you |
npm install
AFFILYNC_TOKEN=<token> npm run devVariable | Required | Default | Description |
| Yes | — | JWT access token |
| No |
| API base URL |
| No |
| Set to |
affilync-mcp-remote is an HTTP server that Claude (or any MCP client) adds by
URL and authenticates against with OAuth — no token to paste. It exposes the
same tools as the stdio server, registered per-request from the user's token.
Per the MCP authorization spec it is an OAuth 2.0 Protected Resource:
GET /.well-known/oauth-protected-resource (RFC 9728) points clients at the
Affilync Authorization Server (api.affilync.com).
Unauthenticated MCP calls get 401 + WWW-Authenticate: Bearer resource_metadata="…",
so the client knows where to start the OAuth flow.
Each request's bearer token is verified offline against the AS's published JWKS and MUST be audience-bound to this server (RFC 8707) — a token minted for another Affilync client cannot be replayed here.
The token is then forwarded to /api/gpt/v1/*, where the backend re-enforces
auth, user-type and write-scope. A token without api:write runs read-only.
npm ci && npm run build
AFFILYNC_API_URL=https://api.affilync.com \
MCP_RESOURCE_URL=https://mcp.affilync.com \
npm run start:remote # or: affilync-mcp-remoteVariable | Default | Description |
|
| This server's public URL (its OAuth resource identifier) |
|
| Authorization Server + API origin |
|
| HTTP port (Render sets this) |
render.yaml defines the affilync-mcp-remote web service. Two operator steps
are required to go live (they can't be done from CI):
Create the service from the blueprint (Render → New → Blueprint on this repo).
Add DNS + custom domain: Cloudflare CNAME mcp → <service>.onrender.com
(proxied) and add mcp.affilync.com as a custom domain on the Render service.
Health check: GET /healthz.
Create a new affiliate marketing campaign with a commission structure
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Campaign name | |
| category | No | Campaign category | |
| description | No | Campaign description | |
| commission_rate | Yes | Commission rate (e.g. 10.0 for 10%; 0–100) | |
| commission_type | No | Commission type (default: percentage) | |
| destination_url | No | Landing page URL (must be a valid http(s) URL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the description's 'Create' adds no extra behavioral context. No mention of side effects, permissions, or error scenarios.
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 without extraneous information, though 'with a commission structure' is slightly vague.
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 tool has 6 parameters and no output schema, the description should explain return values or expected behavior, but it only states the action.
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 baseline is 3. The description adds no additional meaning beyond what the schema already provides.
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 'Create' and the resource 'affiliate marketing campaign', which is specific and distinguishes it from sibling tools like listBrandCampaigns or joinCampaign.
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?
No guidance is provided on when to use this tool versus alternatives like joinCampaign or listBrandCampaigns, 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.
Approve or reject an affiliate's application to join your campaign. Consequential — affects who can earn commissions on your campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Reason for the decision | |
| decision | Yes | Approve or reject | |
| application_id | Yes | Application ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true (destructive action) and idempotentHint=false. The description adds that it 'affects who can earn commissions,' but does not detail what happens on approval vs rejection or whether the action is reversible. This adds minimal extra transparency.
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 with no redundancy. It fronts the main purpose ('Approve or reject') and adds a single impactful consequence statement. Every word 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 consequential tool with no output schema, the description lacks details on what happens after the decision (e.g., confirmation, error cases) or prerequisites (e.g., must have listAffiliateApplications first). It provides adequate but not comprehensive context.
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 schema fully documents the three parameters. The description does not elaborate on them, especially 'reason,' which could benefit from context. 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 clearly specifies the action ('Approve or reject') and the resource ('affiliate's application to join your campaign'). It distinguishes this tool from siblings like listAffiliateApplications and joinCampaign by focusing on the decision-making step.
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 this tool is for consequential decisions affecting commission eligibility, providing context for use. However, it does not explicitly state when not to use it or mention alternatives like listAffiliateApplications for review before deciding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a tracking link for a campaign you've joined
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign ID to generate a link for | |
| destination_url | No | Custom destination URL (must be a valid http(s) URL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's a mutation (readOnlyHint=false) and not idempotent, but the description adds no extra behavioral context such as output format, prerequisites (must have joined campaign), or side effects. It fails to disclose what the tool returns.
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?
Single sentence, front-loaded, no unnecessary words. Every word 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?
With no output schema, the description should explain what the tool returns (the generated link) and any prerequisites (must have joined the campaign). It lacks these details, making it incomplete for a mutation 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% with clear descriptions for both parameters. The description adds no additional meaning beyond the schema, so baseline score of 3.
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 (generate), the resource (tracking link), and the context (for a campaign you've joined). It distinguishes from siblings like listMyLinks and joinCampaign.
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 needing a tracking link for an already-joined campaign, but lacks explicit guidance on when not to use it (e.g., if a link already exists, use listMyLinks) or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your brand's overall performance dashboard
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds minimal behavioral context. It does not disclose what data the dashboard includes, how it is aggregated, or any limitations. A score of 2 reflects that the description does not add value beyond annotations.
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, which is concise. However, it is minimal and does not fully leverage the space to add useful context. It is not overly verbose but also not optimally informative for an agent.
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 and the tool is simple (no params), the description should still clarify what the dashboard shows. It does not describe return values or the structure of the dashboard, leaving the agent uninformed about what to expect from the response.
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 zero parameters, so the description naturally adds no parameter meaning. With 100% schema coverage and no params, the baseline is 4. The description does not need to explain parameters.
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 'Get your brand's overall performance dashboard', which is a specific verb ('Get') and a resource ('brand's overall performance dashboard'). It distinguishes itself from siblings like getCampaignPerformance and getEarningsSummary by referring to the overall brand dashboard. However, 'overall performance dashboard' is somewhat generic, reducing clarity slightly.
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?
No usage guidelines are provided. There is no indication of when to use this tool versus alternatives like getCampaignPerformance or getEarningsSummary. The description lacks any context cues for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed performance metrics for a campaign — clicks, conversions, revenue, EPC
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond what the annotations already provide (readOnlyHint and openWorldHint). It does not mention side effects, error behavior, rate limits, or data freshness. The listed metrics are informational but not behavioral. With annotations present, a score of 3 reflects that the description meets the minimum for a read-only 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 a single sentence with no filler. It front-loads the purpose and lists specific metrics without redundancy. Every word contributes to understanding, achieving maximum conciseness.
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 one simple parameter and no output schema, the description is partially complete. It tells what metrics are returned but does not clarify if those are the only metrics, the format of the response, or whether pagination applies. It is adequate but leaves gaps that might require the agent to make assumptions.
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 the only parameter 'campaign_id' described as 'Campaign ID'. The description does not elaborate on format, source, or constraints beyond the schema's minLength. Since schema coverage is high, the baseline is 3, and the description adds no extra semantic value for the parameter.
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 'Get' and resource 'detailed performance metrics for a campaign', and explicitly lists specific metrics (clicks, conversions, revenue, EPC), making it unmistakable what the tool does. It naturally distinguishes from siblings like getClickAnalytics or getEarningsSummary by focusing on campaign-level aggregated metrics.
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 no guidance on when to use this tool versus related tools (e.g., getClickAnalytics, getEarningsSummary, listCommissions). It does not mention prerequisites, campaign_id source, or when not to use the tool. This omission forces the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get click analytics — totals, today, this week, this month
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, so description adds context by specifying the time periods for analytics. No contradiction; the description is consistent and provides useful behavioral hints beyond annotations.
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, well-structured sentence that communicates the tool's purpose and scope efficiently. No redundant 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?
Given no parameters, output schema, and simple read-only nature, the description covers the essential functionality. It could briefly mention what 'click analytics' includes (e.g., counts), but is otherwise complete for agent use.
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?
No parameters exist, so baseline is 4. The description does not need to add parameter details. It correctly describes the return categories.
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 retrieves click analytics with time periods (totals, today, this week, this month). It distinguishes from siblings like getUserProfile or listBrandCampaigns which serve different purposes.
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 retrieving click analytics but does not explicitly state when to use or not use this tool over alternatives. No guidance on exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your earnings summary — total, pending, available balance, paid out
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds the specific fields returned but lacks details about data freshness or authentication requirements, which are partially covered by the annotations.
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?
A single, front-loaded sentence conveys the purpose and scope without any wasted words.
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 read tool with no parameters, the description is adequate but does not explain periodicity, real-time behavior, or differences between balance types. Output schema is absent, so more details could help.
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 zero parameters, the schema provides full coverage. The description adds meaning by listing the returned fields, which is sufficient.
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 returns an earnings summary with specific fields (total, pending, available balance, paid out). It distinguishes from siblings like getCampaignPerformance or listCommissions by focusing on aggregated earnings.
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 using this tool to retrieve the user's own earnings summary. It doesn't explicitly exclude alternatives, but the context is clear enough for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your recent notifications (approvals, payouts, messages)
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| page_size | No | Items per page (default 20, max 50) | |
| unread_only | No | Only show unread notifications |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly implies a read-only operation, consistent with the readOnlyHint annotation. It adds minor context about notification types but does not disclose any behavioral traits beyond what annotations already provide (e.g., openWorldHint).
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 succinct sentence that front-loads the primary purpose. Every word adds value without 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 read tool with no required parameters and full schema coverage, the description is adequate but lacks explicit clarification of what 'recent' means (e.g., time window). No output schema exists, but the output is likely straightforward. Overall, it meets minimum completeness but could be slightly more informative.
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 tool description adds no parameter-specific semantics beyond the input schema, which already has 100% coverage with clear descriptions for page, page_size, and unread_only. The baseline 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?
Clearly identifies the action ('get') and resource ('recent notifications') with specific types listed in parentheses (approvals, payouts, messages), distinguishing it from sibling tools like listBrandCampaigns or getEarningsSummary. However, it does not specify the scope or context further.
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 no guidance on when to use this tool versus alternatives or any prerequisites. It simply states what the tool does, leaving the agent to infer usage context from the name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Affilync profile. Call this first to check if you are an affiliate or brand.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that the tool checks user role, but does not disclose other behavioral traits such as caching or data freshness. It provides some additional context without contradiction.
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, zero wasted words. Information is front-loaded and every word serves a 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?
For a zero-parameter tool with good annotations, the description sufficiently explains the purpose and recommended usage. However, it lacks detail on the return structure or fields beyond role checking, which is minor for this simplicity level.
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?
No parameters exist, and schema coverage is 100%. The description doesn't need to add parameter details, so a baseline score of 4 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 action ('Get your Affilync profile') and the specific resource. It also provides a usage hint to call it first to check role, which adds value beyond the tool name.
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 advises to call this first to check affiliate or brand status. While it doesn't specify when not to use, the context is clear given the sibling tools list covers other functionalities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply to join an affiliate campaign. Some campaigns auto-approve.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | ID of the campaign to join |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation and non-idempotence. The description adds the 'auto-approve' nuance, which is helpful, but doesn't disclose other behaviors like error states or authentication needs.
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 concise single sentence with no wasted words. It front-loads the purpose and includes a key nuance.
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 covers the main action and a behavioral nuance. However, it could mention response format or prerequisites for a fuller picture.
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 single parameter 'campaign_id' is clearly described in the schema. The description adds no further meaning beyond the schema, so baseline 3 applies.
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 ('apply to join') and the resource ('affiliate campaign'), and adds a key nuance about auto-approval. It is distinct from sibling tools like 'createCampaign' or 'decideApplication'.
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 joining campaigns but lacks explicit guidance on when to use this tool versus alternatives, or when not to use it (e.g., campaigns that are not open).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List campaigns you've joined and are currently active in
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| page_size | No | Items per page (default 20, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and openWorld hints. The description adds clarity by specifying the filter (joined and active), providing behavioral context beyond annotations.
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?
Single sentence with no fluff, though it could be slightly more informative. 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?
Given no output schema, the description covers the tool's purpose adequately. Pagination hints are in params. Could mention return format but not necessary for list operations.
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 has 100% coverage with descriptions for both parameters. The description adds no extra semantic meaning beyond the 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?
The description clearly states the tool lists campaigns the user has joined and are active, with a specific verb and resource. It distinguishes from siblings like listAvailableCampaigns or listBrandCampaigns.
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?
No explicit when-to-use or alternatives are mentioned. The description implies filtering by personal active campaigns, but lacks guidance on when to prefer this over other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List affiliate applications for your campaigns
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| page_size | No | Items per page (default 20, max 50) | |
| application_status | No | Filter by application status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description does not add behavioral details beyond what annotations provide, which is acceptable but not enhanced.
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?
Single sentence with no waste. It is front-loaded with the core purpose. Every word is necessary.
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 simple tool with optional parameters and no output schema, the description is adequate. It provides the essential purpose, and the schema covers parameter details. However, it could explicitly mention that it returns a paginated list of applications. Still, it is mostly complete for the tool's simplicity.
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 does not add any meaning beyond the schema; it does not explain parameter usage or interactions (e.g., pagination behavior, filter effect).
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 (list) and resource (affiliate applications) with scope (for your campaigns). It is specific and distinguishes from sibling tools like listBrandAffiliates and decideApplication. The verb 'List' indicates a read operation.
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?
No guidance on when to use this tool versus alternatives. The description does not specify context, exclusions, or prerequisites. The agent must infer usage from the name and context signals alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List campaigns available to join as an affiliate. Shows active campaigns accepting new affiliates.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| category | No | Filter by category | |
| page_size | No | Items per page (default 20, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds value by clarifying the result set contains only 'active' and 'accepting new affiliates' campaigns, which is not in annotations.
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, no wasted words, front-loaded with the main action. 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?
No output schema, and description does not specify what fields the returned campaigns contain (e.g., id, name, category). For a data-fetching tool, this omission reduces completeness.
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 has 100% coverage with descriptions for all 3 parameters. Description does not add extra parameter context beyond schema, so baseline 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 'List campaigns available to join as an affiliate' and specifies 'active campaigns accepting new affiliates', making it distinct from sibling tools like listBrandCampaigns (brand-side) and listActiveCampaigns (likely different criteria).
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?
No explicit guidance on when to use this tool versus alternatives like joinCampaign, searchCampaigns, or listActiveCampaigns. Context signals show many related tools but no comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all affiliates working with your brand
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| page_size | No | Items per page (default 20, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no behavioral traits beyond 'list all affiliates', which aligns but doesn't extend transparency.
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?
Single sentence, no wasted words, front-loaded with essential 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 simple list tool with two parameters and good annotations, the description is sufficient. It lacks output format details but is adequate for its complexity.
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 covers both parameters fully (100% coverage). The description adds no additional meaning beyond what the schema provides, so baseline 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 a specific verb ('List') and resource ('affiliates working with your brand'), clearly distinguishing it from siblings like listAffiliateApplications or listBrandCampaigns.
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?
No guidance on when to use this tool instead of alternatives, no prerequisites or context provided. The description only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all campaigns owned by your brand
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| page_size | No | Items per page (default 20, max 50) | |
| campaign_status | No | Filter by status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. Description adds 'owned by your brand' which limits scope but doesn't disclose additional behavioral traits beyond annotations.
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?
One concise sentence, no filler. Efficient but could be slightly more structured with bullet points or examples.
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?
No output schema and description omits information about return format, sorting, or default pagination behavior. Acceptable for a simple list 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 description coverage is 100% with parameter descriptions already present. Description adds no additional semantic meaning beyond what schema provides.
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 explicitly states 'List all campaigns owned by your brand', clearly specifying verb (List) and resource (campaigns). This distinguishes it from sibling tools like listAvailableCampaigns or listActiveCampaigns.
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?
No explicit when-to-use or when-not-to-use guidance. The purpose is clear but lacks context about alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your individual commission records from conversions and sales
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| page_size | No | Items per page (default 20, max 50) | |
| commission_status | No | Filter by commission status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'list' is consistent and adds the source (conversions and sales). However, it does not disclose pagination behavior, response format, or any side effects, which is acceptable given annotations cover safety.
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, front-loaded sentence of 9 words with no wasted text. It efficiently conveys the tool's purpose without 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 list operation with 3 optional parameters and no output schema, the description covers the core purpose and source. While it omits mention of pagination or filtering capabilities, the schema handles parameter details, making the description reasonably 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 description coverage is 100%, with each parameter adequately described (page, page_size, commission_status). The tool description adds no additional meaning beyond what the schema provides, landing at baseline 3.
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 individual commission records from conversions and sales, using a specific verb and resource. It distinguishes from siblings like getEarningsSummary which summarizes earnings, and listAffiliateApplications which handles applications.
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 listing personal commission records, but offers no explicit when-to-use or when-not-to-use guidance. No alternatives or exclusions are mentioned; usage context is only vaguely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all your affiliate tracking links
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1) | |
| page_size | No | Items per page (default 20, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and scope. The description adds that it lists 'your' links, implying user-specific data, but no further behavioral traits like pagination behavior or response format are disclosed. This is adequate given the annotations, but not exceptional.
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 with no wasted words, achieving conciseness. However, it is perhaps too minimal and could benefit from additional context without sacrificing brevity.
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 tool's simplicity and the presence of full parameter descriptions in the schema, the description is mostly adequate. However, it lacks information about the response format or the nature of the links, and does not differentiate from siblings, which affects completeness.
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 already provides full descriptions for both parameters (page, page_size) with 100% coverage. The description adds no additional meaning about parameters, so it meets the baseline but does not exceed it.
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 'List' and the resource 'your affiliate tracking links', making the purpose distinct from other list tools. However, it does not explicitly differentiate from sibling tools like listCommissions or listActiveCampaigns, which could cause ambiguity.
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 no guidance on when to use this tool versus its siblings. There is no mention of prerequisites, context, or exclusions, leaving the agent without criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check — verify the Affilync API is reachable and your token is accepted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) already indicate safety. Description adds specific verification targets (reachability, token acceptance) beyond annotations, providing useful 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?
Single sentence, front-loaded, every word necessary. 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 health check tool with no parameters and no output schema, the description fully covers the purpose and behavior. 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?
Input schema has 0 parameters, so no parameter explanation is needed. Description adds no parameter info but none is required.
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 it's a health check to verify API reachability and token acceptance, distinguishing it from all sibling tools which are functional 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?
Description implies usage for verifying connectivity and authentication. While explicit when-to-use vs alternatives is absent, the tool's unique purpose among siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a payout of your available earnings. IRREVERSIBLE — moves real money. Omitting the amount requests your full available balance.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Amount to request (defaults to full available balance) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is irreversible and moves real money, which aligns with the destructiveHint: true annotation and adds valuable behavioral context beyond what annotations alone provide.
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: first states purpose, second provides critical warning and parameter behavior. No unnecessary words.
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 one parameter, no output schema, and annotations covering safety profile, the description is complete. It covers purpose, side effects, and parameter behavior adequately.
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 single parameter 'amount' is fully described in the schema, and the description adds clarity about default behavior (full balance) that is not in the schema's description field. Schema coverage is 100%, so baseline is 3; the additional context raises it to 4.
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 'Request a payout of your available earnings,' using a specific verb and resource. No sibling tool overlaps, making it distinct.
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 clear context (irreversible, moves real money) and explains default behavior when amount is omitted. However, it does not explicitly state when to use this tool over alternatives, though no direct alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for campaigns by name, description, or category
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search query | |
| page | No | Page number (default 1) | |
| category | No | Filter by category | |
| page_size | No | Items per page (default 20, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds no additional behavioral details such as pagination behavior, result structure, or permission requirements, but does not contradict annotations.
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?
One concise sentence with no wasted words. It efficiently conveys the tool's 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?
For a search tool with 4 parameters and no output schema, the description is adequate but incomplete. It does not explain pagination behavior or the nature of the response, though parameter names are 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 descriptions cover all 4 parameters (100% coverage), so baseline is 3. The description adds slight context that the q parameter searches name/description and that category filters, but does not fully clarify the interaction between parameters.
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 searches campaigns by name, description, or category. It distinguishes from sibling list tools by implying a query-based search, but does not explicitly differentiate from listBrandCampaigns or listAvailableCampaigns.
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?
No guidance on when to use this tool versus alternatives. With siblings like listBrandCampaigns and listAvailableCampaigns, the description should provide context for when a search is appropriate.
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.
v1.1.0createCampaigndecideApplicationgenerateAffiliateLinkgetBrandDashboardgetCampaignPerformancegetClickAnalyticsgetEarningsSummarygetNotificationsgetUserProfilejoinCampaignlistActiveCampaignslistAffiliateApplicationslistAvailableCampaignslistBrandAffiliateslistBrandCampaignslistCommissionslistMyLinkspingrequestPayoutsearchCampaignsScored across 20 tools
Tools are largely distinct with clear purposes, separating brand and affiliate roles. Potential overlap between campaign listing tools (listBrandCampaigns, searchCampaigns, listAvailableCampaigns, listActiveCampaigns) is resolved by descriptive text, but could still cause initial confusion.
Naming follows a consistent camelCase convention with verbs like list, get, create, join. Minor outliers like 'decideApplication' and 'ping' deviate from the pattern, but overall it is predictable and readable.
20 tools is well-scoped for an affiliate marketing server covering both brand management and affiliate participation. Each tool serves a distinct function without being excessive.
Core workflows for both roles are covered: brands can create campaigns, manage applications, view performance; affiliates can join, generate links, track earnings, and request payouts. Missing update/delete for campaigns and leave campaign for affiliates are minor gaps.
Affiliate network reporting in your AI client. Bring your own keys. Most adapters experimental.
Create geo-targeted affiliate smart links, pull analytics, and rewrite YouTube descriptions.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Your professional network in Claude — search contacts, log notes, and send warm intros.
