Skip to main content
Glama

kelpo_affiliate_program

Read-onlyIdempotent

Kelpo's affiliate program for this account: the terms (40 % of every credit pack bought by the customers brought, for 12 months), whether the account has joined, and once joined its link, the page the link leads to, how commissions are paid and its figures (clicks, sign-ups, customers, sales, commissions in validation / due / paid) with the next step. Free, changes nothing. Arguments: {}

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "kelpo_affiliate_program"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds value by disclosing the full return surface — terms (40% for 12 months), enrollment state, link target page, payout method, and metric breakdown — plus 'with the next step', which tells an agent it can chain onward. No rate limits or failure modes are mentioned.

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

Conciseness3/5

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

One long run-on sentence with a nested parenthetical inventory of metrics; the core identification is front-loaded but the middle is dense list-like prose that is harder to scan than a short structured breakdown.

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?

No output schema exists, so the description carries the burden of describing what comes back — and it does, enumerating terms, membership state, link, payout, and per-metric figures. An agent knows what it will receive and what to do next.

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

Parameters4/5

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

Zero parameters, so baseline is 4. The trailing 'Arguments: {}' is harmless restatement of the empty schema rather than an addition.

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

Purpose4/5

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

States a specific resource and scope: the affiliate program for this account, with explicit contents (terms, joined status, link, figures). It is distinguishable from kelpo_join_affiliate_program and kelpo_update_affiliate_settings only indirectly via 'changes nothing', not by naming them.

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

Usage Guidelines3/5

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

The phrase 'Free, changes nothing' implies this is a safe inspection call, and the sibling names join_affiliate_program / update_affiliate_settings make the read-vs-write split inferable. But the description never says 'call this to check enrollment before joining' or names the alternatives explicitly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources