affiliate-networks-mcp

affiliate_set_client_strategy

Writes confirmed brand strategy and KPI documents to local configuration, validating KPI grammar to prevent errors before saving.

Instructions

Write the advisory Strategy.md and/or KPI.md for one brand (the brand slug from brands.json) to the local config directory. Use this only after confirming the content with the operator; the onboarding skill drafts and confirms, this tool persists. kpiMarkdown is validated against the fenced ```kpi grammar and is rejected without writing if it has parse errors (returned as parseErrors); these are local-config writes, not network writes, and never authorise a network action.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "brand": "<brand>"
    },
    "name": "affiliate_set_client_strategy"
  }
}

Input Schema

Name	Required	Description	Default
`brand`	Yes
`kpiMarkdown`	No
`strategyMarkdown`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.20.0Jul 31, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does exceptionally well: it discloses local-config vs network writes, kpiMarkdown grammar validation, rejection on parse errors (returned as parseErrors), and the explicit safety note that it never authorizes a network action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no fluff, each covering a distinct aspect: purpose, usage workflow, and validation/safety. The third sentence is somewhat dense but still organized and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a local write tool with no annotations or output schema, it covers purpose, workflow, safety, and error behavior. The only minor gap is an explicit success return value, but the parseErrors mention provides partial return semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema coverage, the description adds meaning to all three parameters: brand is a slug from brands.json, kpiMarkdown is validated against a fenced grammar, and strategyMarkdown is the Strategy.md content. This far exceeds the bare string schema.

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

Purpose5/5

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

The description uses a specific verb ('Write'), identifies the resource (Strategy.md and/or KPI.md) and target (local config directory), and clearly distinguishes this write tool from sibling read/list tools like affiliate_get_client_strategy.

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

Usage Guidelines4/5

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

It explicitly states 'Use this only after confirming the content with the operator' and explains the workflow gate (onboarding skill drafts/confirms, this tool persists). This provides clear context but does not name alternative tools for when not to use it.

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

Deploy Server