What can you do with this server?

The Clicks Protocol server enables AI agents to autonomously earn yield on idle USDC through DeFi integration (Aave V3 and Morpho) on Base network. * Quick Start (clicks_quick_start): One-call setup that registers an agent, approves USDC, and processes the first payment — skipping already-completed steps. Optionally accepts a referrer address. * Register Agent (clicks_register_agent): Register a new AI agent with the protocol, making the caller the operator. * Receive Payment (clicks_receive_payment): Process incoming USDC payments, automatically splitting them 80% to the agent's liquid wallet and 20% to DeFi yield. * Set Yield Percentage (clicks_set_yield_pct): Customize the yield split percentage per operator between 5% and 50%. * Withdraw Yield (clicks_withdraw_yield): Withdraw accumulated yield plus principal, fully or partially, accessible by the agent, operator, or contract owner. * Get Agent Info (clicks_get_agent_info): Retrieve an agent's registration status, operator, deposited principal, yield percentage, and USDC balance. * Simulate Split (clicks_simulate_split): Preview how a USDC payment would be divided between liquid and yield before committing. * Get Yield Info (clicks_get_yield_info): View the active yield protocol (Aave or Morpho), current APYs, total balance, and total deposits across all agents. * Get Referral Stats (clicks_get_referral_stats): Check referral network statistics including direct referral count, total earned, claimable rewards, and referral chain.

Which integrations are available for this server?

Integrates with Coinbase Agentic Wallets on the Base network to enable automated DeFi yield generation for agent-held USDC between transactions. Allows CrewAI agents to programmatically manage USDC deposits, yield routing to Aave and Morpho, and monitor agent team TVL milestones. Provides tools for LangChain agents to interact with the Clicks Protocol for yield-bearing payment management and autonomous agent registration.

de en es ja ko ru zh

Clicks Protocol

Official

by clicks-protocol

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

One call. Yield starts.

import { ClicksClient } from '@clicks-protocol/sdk';

const clicks = new ClicksClient(signer);
await clicks.quickStart('100', agentAddress);
// 80 USDC → agent wallet (instant)
// 20 USDC → treasury yield route

That's it. No config. No dashboard. No human required.

Related MCP server: atv

What Clicks does

Every USDC payment your agent receives gets auto-split:

Payment in
    ├── 80% → Agent Wallet (liquid, instant)
    └── 20% → DeFi Yield (Aave V3 or Morpho, auto-routed to best APY)
                 │
                 └── Withdraw anytime → Agent gets principal + yield (minus 2% fee on yield only)

No lockup. Withdraw anytime.
No manual steps. Fully autonomous.
2% fee on yield only. Never on principal.
Auto-rebalances between Aave V3 and Morpho for best APY.

Install

npm install @clicks-protocol/sdk ethers@^6

x402 + Coinbase Agentic Wallets

Clicks is designed to sit after x402-style payment flows on Base.

x402 handles authorization and payment. Clicks routes USDC after receipt:

import { ClicksClient } from '@clicks-protocol/sdk';
import { CoinbaseWalletSDK } from '@coinbase/wallet-sdk';

const wallet = new CoinbaseWalletSDK({ appName: 'YourAgent' });
const signer = wallet.makeWeb3Provider().getSigner();

const clicks = new ClicksClient(signer);
await clicks.quickStart('1000', agentAddress);

// Your agent now has a settlement policy
// 80% liquid for operations
// 20% routed through treasury yield

Same chain (Base), same USDC contract
80% liquid for operations
20% routed through treasury yield
No lockup, withdraw anytime

SDK

Quick Start (recommended)

One call: registers agent, approves USDC, splits first payment.

const result = await clicks.quickStart('100', agentAddress);
// result.registered → true (skips if already done)
// result.approved   → true (skips if allowance sufficient)
// result.paymentSplit → true

Individual operations

// Register
await clicks.registerAgent(agentAddress);

// Approve USDC spending
await clicks.approveUSDC('max');

// Receive payment (auto-splits)
await clicks.receivePayment('500', agentAddress);

// Check yield info
const info = await clicks.getYieldInfo();
// { activeProtocol: 'Morpho', aaveAPY: 700, morphoAPY: 950, ... }

// Withdraw everything
await clicks.withdrawYield(agentAddress);

// Custom yield split (5-50%)
await clicks.setOperatorYieldPct(30); // 30% to yield, 70% liquid

Read-only (no signer needed)

const clicks = new ClicksClient(provider); // provider, not signer

const agent = await clicks.getAgentInfo(agentAddress);
// { isRegistered: true, deposited: 1000000n, yieldPct: 20n }

const split = await clicks.simulateSplit('100', agentAddress);
// { liquid: 80000000n, toYield: 20000000n }

MCP Server

AI agents can discover and use Clicks via MCP:

npm install @clicks-protocol/mcp-server
CLICKS_PRIVATE_KEY=0x... clicks-mcp

16 tools available: clicks_quick_start, clicks_register_referral, clicks_get_agent_info, clicks_simulate_split, clicks_get_yield_info, clicks_get_referral_stats, clicks_verify_receipt, clicks_get_settlement_status, clicks_reconcile_settlement, clicks_replay_policy, clicks_get_receipt_trail, clicks_receive_payment, clicks_withdraw_yield, clicks_register_agent, clicks_set_yield_pct, clicks_explain

Works with Claude, Cursor, LangChain, and any MCP-compatible client.

Referral Network

Referral contracts exist on-chain. Treat them as a separate attribution layer from the current SDK quickStart() helper.

Level	Share of protocol fee
L1 (direct referral)	40%
L2	20%
L3	10%
Treasury	30%

The referred agent pays nothing extra. Rewards come from the 2% protocol fee once referral attribution has been registered through a dedicated flow.

Recommended flow:

const deadline = BigInt(Math.floor(Date.now() / 1000) + 3600);
const signature = await clicks.signReferralApproval(agentAddress, referrerAddress, deadline);

const result = await clicks.quickStartWithReferral(
  '100',
  agentAddress,
  referrerAddress,
  deadline,
  signature,
);

Important:

quickStart() handles treasury setup.
registerReferralWithSig() handles explicit attribution.
quickStartWithReferral() is a convenience wrapper over those two steps, not an atomic one-shot contract call.

Economics per $10k deposit at 7% APY:

Your tree	Passive income/year
10 agents	$56
100 agents	$560
1,000 agents	$9,800
10,000 agents	$98,000

Agent Teams

Form squads, hit TVL milestones, earn bonus yield:

Tier	TVL threshold	Bonus yield
🥉 Bronze	$50k	+0.20%
🥈 Silver	$250k	+0.50%
🥇 Gold	$1M	+1.00%
💎 Diamond	$5M	+2.00%

Contracts (Base Mainnet)

Contract	Address
ClicksRegistry	`0x23bb...0C0a3`
ClicksSplitterV4	`0xB7E0...f3C8`
ClicksYieldRouter	`0x0531...EECD`
ClicksFeeV2	`0x8C4E...0fb5`
ClicksReferral	`0x1E5A...4ccC`
Safe Multisig (Owner)	`0xaD82...D6A9`
USDC	`0x8335...913`

All contracts verified on Basescan. Owned by Gnosis Safe multisig — single-key compromise is not possible.

ERC-8004 Trustless Agent

Clicks is registered on the ERC-8004 Identity Registry on Base as agentId 45074. On-chain reputation accrues per completed agent job. Attestors who follow the Clicks Attestor Schema V1 become eligible for the reputation-aware fee multiplier (shipping in V5).

Manifest: /.well-known/agent-registration.json
Schema V1: clicksprotocol.xyz/strategy/ATTESTOR-SCHEMA-V1.md

Architecture

clicks-protocol/
├── contracts/           Solidity (^0.8.20)
│   ├── ClicksSplitterV4    Splits payments, manages yield %
│   ├── ClicksYieldRouter   Routes to best APY (Aave/Morpho)
│   ├── ClicksFeeV2           2% fee collection on yield
│   ├── ClicksRegistry      Agent ↔ Operator mapping
│   └── ClicksReferral      Multi-level referral system
├── sdk/                 TypeScript SDK
├── mcp-server/          MCP Server (16 tools)
├── site/                Landing page + llms.txt + agent.json
└── test/                227 tests (Hardhat)

Agent Discovery

llms.txt: clicksprotocol.xyz/llms.txt — full protocol docs for LLMs
agent.json: clicksprotocol.xyz/.well-known/agent.json — agent manifest
MCP: @clicks-protocol/mcp-server — tool discovery for MCP clients

Connect Your AI Agent

The Clicks MCP server is live at https://mcp.clicksprotocol.xyz/mcp — connect any MCP-compatible client in seconds.

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "clicks-protocol": {
      "url": "https://mcp.clicksprotocol.xyz/mcp"
    }
  }
}

OpenClaw

openclaw mcp set clicks-protocol --url https://mcp.clicksprotocol.xyz/mcp

Codex CLI

Add to .codex/config.json:

{
  "mcpServers": {
    "clicks-protocol": {
      "type": "url",
      "url": "https://mcp.clicksprotocol.xyz/mcp"
    }
  }
}

Gemini CLI

{
  "mcpServers": {
    "clicks-protocol": {
      "url": "https://mcp.clicksprotocol.xyz/mcp"
    }
  }
}

Available MCP Tools

Tool	Description
`get_protocol_stats`	TVL, APY, agent count
`get_agent_info`	Check if an agent is registered
`get_yield_info`	Yield balance for an agent
`simulate_yield`	Project earnings over time
`clicks://protocol/overview`	Resource: protocol overview

See examples/integrations/ for ready-to-use config files.

Works with

Any agent framework that handles USDC on Base:

x402 · LangChain · CrewAI · AutoGen · Eliza · OpenClaw · Claude · Cursor · Codex · Gemini · Hummingbot · Phidata

Development

npm install
npx hardhat compile
npx hardhat test          # 227 tests

License

MIT

Available Tools

9 tools

clicks_get_agent_infoA

Check how much yield an AI agent earns on idle USDC. Returns current APY, balance, deposited principal, and pending rewards.

ParametersJSON Schema

Name	Required	Description	Default
`agent_address`	Yes	Ethereum address of the AI agent

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided. Description states it's a 'Check' (read-only) and lists return fields, but does not disclose side effects, auth needs, or rate limits. Adequate for a simple read tool, but not rich.

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

Conciseness5/5

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

Single sentence, 16 words, front-loaded with action and resource. Every word earns its place. Efficient.

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?

Low complexity (1 param), no output schema but description enumerates return fields. Sufficient for an agent to select and invoke correctly.

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

Parameters3/5

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

One parameter (agent_address) with schema description 'Ethereum address of the AI agent'. Description adds no extra meaning beyond schema. Schema coverage is 100%, so baseline 3 is appropriate.

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 clearly states the verb 'Check' and the resource 'yield on idle USDC', listing return fields. It distinguishes from siblings like clicks_get_referral_stats by focusing on yield. Specificity level: high.

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 description implies usage when yield details for an agent are needed but provides no explicit when-to-use, when-not-to-use, or alternatives. With many sibling tools, guidance is necessary but absent.

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

clicks_get_referral_statsB

Earn extra yield by referring agents. Track how much you earn from agents you refer to earn yield on idle USDC. See direct referrals, total earned, and team bonuses.

ParametersJSON Schema

Name	Required	Description	Default
`agent_address`	Yes	Ethereum address of the AI agent

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided. The description suggests a read operation ('track how much you earn') but does not explicitly state behavioral traits like read-only, authentication needs, rate limits, or any side effects. The burden of disclosure falls entirely on the description, which is insufficient.

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?

The description is two sentences, front-loading the purpose with minimal waste. The first sentence is slightly promotional but acceptable. Overall efficient.

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

Completeness3/5

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

The description mentions key return values (direct referrals, total earned, team bonuses) but lacks complete detail expected without an output schema. Given the simple input, it is partially sufficient but could be more comprehensive about output structure or limitations.

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

Parameters3/5

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

The input schema covers the single parameter (agent_address) with a description. The tool description adds no extra meaning about the parameter beyond what the schema provides. Baseline score of 3 is appropriate for 100% schema coverage.

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 clearly states the tool's purpose: tracking referral earnings from agents, specifying outputs like direct referrals, total earned, and team bonuses. It distinguishes from sibling tools (e.g., clicks_get_agent_info, clicks_get_yield_info) which serve different functions.

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 description implies usage for viewing referral stats but does not explicitly state when to use this tool versus alternatives like clicks_get_agent_info or clicks_get_yield_info. No when-not-to-use guidance is provided.

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

clicks_get_yield_infoA

Find the best APY for idle USDC. Returns current yields on Aave vs Morpho, total protocol balance, fees collected, and yield earned.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior fully. It describes the return data but does not explicitly state that the tool is read-only or lacks side effects. The description is adequate but could be more transparent.

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

Conciseness5/5

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

The description is two sentences: the first states the purpose, the second lists the return values. It is front-loaded and every sentence earns its place. No wasted words.

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

Completeness4/5

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

Given no parameters and no output schema, the description covers the main return items (yields, balance, fees, yield earned). It is fairly complete, though it could specify units or format for yields. Still, it provides sufficient context for a simple get tool.

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?

The input schema has no parameters (100% coverage vacuously), so the description adds value by explaining the return data. Baseline 3 is appropriate, and the description provides additional context beyond the 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 clearly states it finds the best APY for idle USDC and lists specific return data. The verb 'find' and resource 'APY' are specific, and it distinguishes itself from sibling tools like clicks_get_agent_info or clicks_get_referral_stats.

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 description implies usage when yield information is needed but lacks explicit guidance on when to use or not use this tool versus alternatives. No exclusions or alternative tool references are provided.

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

clicks_quick_startA

Start earning yield on idle USDC in one command. Registers agent, approves USDC, and deposits first payment automatically.

ParametersJSON Schema

Name	Required	Description
`amount`	Yes	First payment amount in USDC (e.g. "100")
`agent_address`	Yes	Ethereum address of the AI agent
`referrer`	No	Optional: address of the agent who referred you (earns 40% of your protocol fee)

TDQS

A3.8/5.0

Behavior3/5

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

Discloses the multi-step behavior (register, approve, deposit), which is helpful. But no annotations are provided, and description does not cover edge cases like re-registration or failure handling.

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

Conciseness5/5

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

Single, front-loaded sentence with no waste. Every word adds value: 'one command' emphasizes ease, and the three verbs are explicit.

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

Completeness4/5

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

Covers main action well for a combined setup tool. Lacks description of return value (e.g., success confirmation) and error scenarios, but given no output schema, this is acceptable.

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

Parameters3/5

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

Schema has 100% description coverage with clear parameter docs (amount example, agent_address pattern, referrer fee). Description adds marginal value by calling amount 'first payment'. Baseline 3 is appropriate.

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?

Description clearly states the verb 'start earning', the resource 'idle USDC', and the three-step process (register, approve, deposit). Distinct from sibling tools like 'clicks_register_agent' which only registers.

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?

Implied usage as a one-command setup, but no explicit guidance on when to use this vs. individual steps (e.g., if already registered). No when-not-to-use or alternatives mentioned.

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

clicks_receive_paymentC

Stop wasting idle USDC payments. Automatically split payments: 80% stays liquid, 20% earns DeFi yield. Turn idle treasury into working capital.

ParametersJSON Schema

Name	Required	Description	Default
`amount`	Yes	Payment amount in USDC (e.g. "100")
`agent_address`	Yes	Ethereum address of the AI agent

TDQS

C2.7/5.0

Behavior3/5

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

The description discloses the automatic split (80% liquid, 20% DeFi yield) but lacks details on side effects, state changes, irreversibility, or failure scenarios. Given no annotations, the description partially covers behavior but is incomplete.

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?

The description is concise (two sentences) but not front-loaded with the core action. The first sentence is a benefit statement rather than a clear description of the tool's function. It could be more direct.

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

Completeness2/5

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

Given no annotations and no output schema, the description should explain the overall behavior and results. It omits important context like whether an on-chain transaction occurs, what the return value is, and prerequisites. The description is insufficient for a complete understanding.

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

Parameters3/5

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

The input schema already provides descriptions for both parameters (amount and agent_address) with 100% coverage. The description adds no additional meaning beyond what's in the schema, so a baseline score of 3 is appropriate.

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

Purpose3/5

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

The description uses marketing language ('Stop wasting idle USDC payments') but does not explicitly state that the tool receives a payment and splits it. The verb 'receive payment' is implied rather than stated. While it mentions splitting, the primary action is unclear.

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

Usage Guidelines2/5

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 clicks_register_agent or clicks_set_yield_pct. Prerequisites (e.g., having a registered agent or an existing treasury) are not mentioned.

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

clicks_register_agentA

ParametersJSON Schema

Name	Required	Description	Default
`agent_address`	Yes	Ethereum address of the AI agent to register

TDQS

A3.5/5.0

Behavior2/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 mentions 'Register' but does not disclose side effects like on-chain transaction costs, idempotency, or error conditions (e.g., if already registered). The return value is also not described.

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

Conciseness5/5

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

The description is very concise with two short sentences. It front-loads the purpose and includes a critical prerequisite, making it efficient and easy to parse.

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

Completeness3/5

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

Given the tool has a single parameter and no output schema, the description is fairly complete but lacks behavioral details (e.g., gas costs, idempotency). It sufficiently explains the tool's purpose but could provide more context for reliability.

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

Parameters3/5

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

The input schema has 100% coverage, describing the agent_address parameter with type and pattern. The description does not add any additional semantics beyond what the schema already provides, so it meets the baseline for this score.

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 clearly states the action ('Register your AI agent') and the purpose ('to start earning yield on idle USDC'). It also indicates this is a prerequisite ('Required before first deposit'), which distinguishes it from sibling tools like clicks_get_agent_info or clicks_get_yield_info.

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 description gives usage context ('Required before first deposit') but does not specify when not to use it, such as if the agent is already registered, or mention alternative tools. It provides a clear condition but lacks exclusions.

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

clicks_set_yield_pctA

Control how much idle USDC earns yield vs stays liquid. Set custom split (5-50%) for your agent.

ParametersJSON Schema

Name	Required	Description	Default
`pct`	Yes	Yield percentage (5-50, integer). Default is 20.

TDQS

A4/5.0

Behavior3/5

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

Discloses the percentage range (5-50%) but lacks details on side effects (e.g., immediate effect, fees, impact on pending yields). Since no annotations exist, the description should be more informative about mutation 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/5

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

Two sentences, front-loaded with purpose, no redundant information. Every word serves a purpose.

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

Completeness4/5

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

For a single-parameter, no-output-schema tool, the description covers purpose, constraints, and default. It lacks only optional details like return value or confirmation, but overall it's sufficiently complete.

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?

Schema coverage is 100%, and the description adds the default value (20%) beyond the schema's min/max, providing practical guidance. The baseline is 3, and the added default merits a 4.

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 clearly states the verb ('Control', 'Set') and resource ('idle USDC yield percentage'), and distinguishes from siblings like clicks_get_yield_info (read) and clicks_simulate_split (simulation).

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?

Implied when to use (customizing yield split) but no explicit when-not-to-use or alternative tools like clicks_simulate_split are mentioned, which would be helpful for guiding agent decisions.

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

clicks_simulate_splitA

See how idle USDC gets split: what stays liquid vs what earns yield. Preview before depositing.

ParametersJSON Schema

Name	Required	Description	Default
`amount`	Yes	Payment amount in USDC (e.g. "100" for 100 USDC)
`agent_address`	Yes	Ethereum address of the AI agent

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. The word 'Preview' implies a read-only simulation with no side effects, which is transparent. It could be more explicit about being non-destructive, but the intent is clear.

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

Conciseness5/5

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

Two concise sentences front-load the key purpose and usage context. Every word adds value, with no redundancy.

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

Completeness4/5

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

For a simple simulation tool with two parameters, the description adequately covers the purpose and outcome. It could briefly mention the return format (e.g., amounts or percentages) but is otherwise complete.

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

Parameters3/5

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

Both parameters are fully described in the schema (100% coverage). The tool description adds context ('idle USDC') but does not provide new details beyond what the schema already offers, so baseline 3 is appropriate.

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 clearly states the tool's function: simulating the split of idle USDC into liquid and yield components. It distinguishes itself from sibling tools like clicks_receive_payment and clicks_withdraw_yield by being a preview/simulation action.

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?

The phrase 'Preview before depositing' clearly indicates when to use this tool. However, it does not explicitly mention when not to use it or provide alternatives among siblings, though the context of sibling names suggests it's for simulation.

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

clicks_withdraw_yieldA

Withdraw earned yield from idle USDC. Get principal + yield back anytime, no lockups.

ParametersJSON Schema

Name	Required	Description	Default
`agent_address`	Yes	Ethereum address of the AI agent
`amount`	No	Amount to withdraw in USDC. Omit to withdraw everything.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description provides behavioral context: the operation is non-locking and returns principal plus yield. It is safe and straightforward, though it could detail what happens if no yield or the transaction outcome.

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

Conciseness5/5

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

Two short sentences, front-loaded with the action, and no wasted words. Every sentence adds value.

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

Completeness3/5

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

Given no output schema or annotations, the description is adequate but could be more complete by mentioning that the withdrawn USDC is sent to the agent address, or prerequisites (e.g., must have deposited USDC). It covers basic context but lacks depth.

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

Parameters3/5

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

The description does not add meaning beyond the input schema, which already covers 100% of parameters with clear descriptions (agent_address and amount). The schema sufficiently documents parameters, so baseline 3 is appropriate.

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 clearly states the action ('withdraw'), the resource ('earned yield from idle USDC'), and key benefits ('get principal + yield back anytime, no lockups'). It is specific and distinguishable from sibling tools like 'clicks_set_yield_pct' or 'clicks_get_yield_info'.

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?

The description implies when to use (withdrawing yield/principal) and highlights that there are no lockups, but it does not explicitly state when not to use or compare with alternatives. Context is clear but exclusions are absent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.4May 8, 2026
- Changedclicks_get_agent_info1 field changed
  - addedInput schema / properties / agent_address / pattern
```
Added value: +"^0x[0-9a-fA-F]{40}$"
```
- Changedclicks_get_referral_stats1 field changed
  - addedInput schema / properties / agent_address / pattern
```
Added value: +"^0x[0-9a-fA-F]{40}$"
```
- Changedclicks_quick_start2 fields changed
  - addedInput schema / properties / agent_address / pattern
```
Added value: +"^0x[0-9a-fA-F]{40}$"
```
  - addedInput schema / properties / referrer / pattern
```
Added value: +"^0x[0-9a-fA-F]{40}$"
```
- Changedclicks_receive_payment1 field changed
  - addedInput schema / properties / agent_address / pattern
```
Added value: +"^0x[0-9a-fA-F]{40}$"
```
- Changedclicks_register_agent1 field changed
  - addedInput schema / properties / agent_address / pattern
```
Added value: +"^0x[0-9a-fA-F]{40}$"
```
- Changedclicks_set_yield_pct2 fields changed
  - changedInput schema / properties / pct / description
```
Previous value: -"Yield percentage (5-50). Default is 20."New value: +"Yield percentage (5-50, integer). Default is 20."
```
  - changedInput schema / properties / pct / type
```
Previous value: -"number"New value: +"integer"
```
- Changedclicks_simulate_split1 field changed
  - addedInput schema / properties / agent_address / pattern
```
Added value: +"^0x[0-9a-fA-F]{40}$"
```
- Changedclicks_withdraw_yield1 field changed
  - addedInput schema / properties / agent_address / pattern
```
Added value: +"^0x[0-9a-fA-F]{40}$"
```
9 tool updatesv1.0.0Apr 2, 2026
- First observedclicks_get_agent_info
- First observedclicks_get_referral_stats
- First observedclicks_get_yield_info
- First observedclicks_quick_start
- First observedclicks_receive_payment
- First observedclicks_register_agent
- First observedclicks_set_yield_pct
- First observedclicks_simulate_split
- First observedclicks_withdraw_yield

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-08 18:10 across 9 tools

Disambiguation5/5

Each tool targets a distinct action: agent info, referral tracking, yield info, registration, deposit/splitting, yield management. No two tools have overlapping purposes, allowing clear agent selection.

Naming Consistency5/5

All tools follow a consistent `clicks_<verb>_<noun>` pattern, using underscores and verbs like get, register, set, simulate, withdraw. The pattern is predictable and uniform.

Tool Count5/5

9 tools is well within the ideal 3-15 range, covering the main operations without being excessive or insufficient for the domain of idle USDC yield management.

Completeness4/5

The set covers core lifecycle: registration, deposit (via quick_start and receive_payment), yield configuration, simulation, withdrawal, and info retrieval. Missing an explicit standalone deposit tool or agent deletion, but these are minor gaps.

Maintenance

ActivityStale

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-server A
io.github.bitcompare
Crypto yield data for AI agents: lending, savings, staking, borrowing & stablecoin rates. 18 tools.
Cryptocurrency Finance
212
Axiom Agentic Tools A
io.github.0xAxiom
x402-paid Base agent tools (USDC). 5 deterministic tools. No API keys. No NFT pass.
Autonomous Agents Cryptocurrency
931
Blixtworks A
com.blixtworks.www
63 pay-per-call tools for agents: vision, text, data, web, blockchain. USDC on Base via x402.
Blockchain Cryptocurrency AI & Machine Learning
681
Agentic Endpoints A
com.oliverkiss
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Autonomous Agents Payments & Billing Blockchain
201

Related MCP Servers

agentfi-mcp-server
Blockchain Cryptocurrency Web3 & Decentralized Tech
felippeyann
F
license
A
quality
F
maintenance
DeFi execution and agent-to-agent economy tools for AI agents — swaps, yield, transfers, policy enforcement, trust scoring, A2A jobs, and P\&L across Ethereum, Base, Arbitrum, and Polygon.
Updated 4 months ago (2026-05-17 17:49 UTC)
31
1
-
atv
Cryptocurrency Blockchain
aarna-ai
A
license
Not graded
quality
C
maintenance
Provides AI-native access to Aarna's tokenized yield vaults on Ethereum and Base, with tools for vault discovery, performance metrics, transaction building, and portfolio tracking.
Updated 6 months ago (2026-03-27 11:59 UTC)
MIT
hyre-mcp
Blockchain Cryptocurrency Finance
cryptoeights
A
license
B
quality
D
maintenance
Provides 13 Solana DeFi intelligence tools for AI agents, paid per-call via micropayments (USDC). Enables pulling live DeFi data and automatic payment settlement.
Updated 3 months ago (2026-06-26 10:04 UTC)
13
27 npm
1
MIT
Grey Ridge x402 MCP
Cryptocurrency Blockchain
rezearcher
A
license
Not graded
quality
C
maintenance
Enables AI agents to access crypto prices, DeFi yields, Polymarket data, Base chain info, and security scans with pay-per-call via USDC on Base mainnet.
Updated 20 days ago (2026-09-01 20:36 UTC)
MIT

Appeared in Searches

A guide to building wealth and financial success