Skip to main content
AllMCPs
BrowseBestCategoriesStackCompareToolsGuidesBlog Log in Submit MCP

Stay in the loop

Get new MCP servers and top picks in your inbox.

AllMCPs

The open directory for discovering and installing Model Context Protocol servers.

Explore

  • Browse servers
  • Best MCP servers
  • Categories
  • MCP clients
  • Agent prompts
  • Stack Builder
  • Compare servers
  • Tags index
  • Submit a server
  • Pricing

Learn

  • Guides hub
  • What is MCP?
  • Install guide
  • Troubleshooting
  • Security
  • Blog
  • Blog RSS

Tools

  • All tools
  • Config generator
  • Config validator
  • MCP playground
  • OpenAPI β†’ MCP
  • Badge generator

For agents

  • API docs
  • Trust & traffic
  • llms.txt β†— (opens in a new tab)
  • Catalog JSON β†— (opens in a new tab)
  • Remote MCP β†— (opens in a new tab)

Company

  • About
  • Contact
  • X (@AllMCPs) β†— (opens in a new tab)
  • GitHub β†— (opens in a new tab)
  • Terms
  • Privacy
AllMCPs VerifiedAllMCPs VerifiedFeatured on Nick LaunchesFeatured on Nick LaunchesLaunch Llama NewsletterLaunch Llama NewsletterVerified DR - allmcps.comVerified DR - allmcps.comFeatured on SaaSGrowFeatured on SaaSGrowFeatured on Twelve ToolsFeatured on Twelve ToolsFeatured on Saaspa.geFeatured on Saaspa.geFeatured on Findly.toolsFeatured on Findly.toolsFeatured on Startup FameFeatured on Startup FameFeatured on LaunchKiwiFeatured on LaunchKiwiFeatured on ScrollLaunchFeatured on ScrollLaunchFeatured on DailyPingsFeatured on DailyPingsFazier badgeFazier badgeFeatured on NewTool.siteFeatured on NewTool.siteFeatured on saasfame.comFeatured on saasfame.comDR Checker - Domain RatingDR Checker - Domain RatingListed on Turbo0Listed on Turbo0Launched on LaunchBoard - Product Launch PlatformLaunched on LaunchBoard - Product Launch PlatformList on SimilarlabsList on Similarlabshttps://codetrendy.comhttps://codetrendy.comListed on DevTool.ioFeatured on BuildlistFeatured on BuildlistAllMCPs VerifiedAllMCPs VerifiedFeatured on Nick LaunchesFeatured on Nick LaunchesLaunch Llama NewsletterLaunch Llama NewsletterVerified DR - allmcps.comVerified DR - allmcps.comFeatured on SaaSGrowFeatured on SaaSGrowFeatured on Twelve ToolsFeatured on Twelve ToolsFeatured on Saaspa.geFeatured on Saaspa.geFeatured on Findly.toolsFeatured on Findly.toolsFeatured on Startup FameFeatured on Startup FameFeatured on LaunchKiwiFeatured on LaunchKiwiFeatured on ScrollLaunchFeatured on ScrollLaunchFeatured on DailyPingsFeatured on DailyPingsFazier badgeFazier badgeFeatured on NewTool.siteFeatured on NewTool.siteFeatured on saasfame.comFeatured on saasfame.comDR Checker - Domain RatingDR Checker - Domain RatingListed on Turbo0Listed on Turbo0Launched on LaunchBoard - Product Launch PlatformLaunched on LaunchBoard - Product Launch PlatformList on SimilarlabsList on Similarlabshttps://codetrendy.comhttps://codetrendy.comListed on DevTool.ioFeatured on BuildlistFeatured on Buildlist
Β© 2026 Jackalope Digital LLC. All rights reserved.
  1. Home
  2. πŸ’° Finance & Fintech
  3. YieldSignal
Y
Health: Not checked yetWe have not completed a health check for this listing yet.Last checked 8/11/2026, 12:16:00 AM

YieldSignal

Enrichment pendingWe haven’t run our AI enrichment pass on this listing yet, so the overview, use cases, and FAQ below may be sparse or missing. We work through the catalog over time β€” check back soon.
View Repository

Real-time risk-weighted USDC lending APY across 6 protocols on Base, paid via x402

Quick Install

Automated & IDE Setup

Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β€” or use 1-click editor setup below.

Add to CursorAdd to VS Code
Manual Client & Custom JSON ConfigExpand JSON β–Ύ

Install Config Generator

Choose your client
claude_desktop_config.json
{
  "mcpServers": {
    "yieldsignal": {
      "command": "npx",
      "args": [
        "-y",
        "yieldsignal"
      ]
    }
  }
}

πŸ’‘ Paste into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows)

Install Directory Badge Claim listing AlternativesπŸ’° More in Finance & Fintech

Documentation Overview

YieldSignal

CI

Risk-weighted yield signals for autonomous agents, paid per call via the x402 protocol β€” no API key, no signup. Every product route is paid: $0.10 signal, $0.25 analytics (durability/capacity/sensitivity/exposure), $0.50 decision, $1.00 persistence. There is no free tier and no bypass parameter.

  • ETH liquid staking (Ethereum mainnet) across Lido, Rocket Pool, Coinbase Wrapped Staked ETH, Frax Ether and Binance Staked ETH
  • USDC and WETH lending (Base) across Aave, Compound, Morpho, Moonwell, Euler and Fluid

Seven products: the raw signal (what pays best right now), the decision (given where your money already sits, is moving it worth the cost β€” MOVE/HOLD with expected net gain and break-even in days), the durability report (how much of that APY survives if incentives stop), the capacity report (can you actually withdraw your size from that market), the sensitivity report (how close the market is to the kink where borrow rates explode), the exposure report (how much of your portfolio sits behind the same risk, no matter how many venues it is spread across), and the persistence report (how long a call here actually holds before the leader flips β€” measured from this service's own on-chain attestations, which is why no competing feed can produce it).

Live: https://yieldsignal.vercel.app

Code
GET https://yieldsignal.vercel.app/signal/eth-staking-yield
GET https://yieldsignal.vercel.app/signal/usdc-base-yield
GET https://yieldsignal.vercel.app/signal/weth-base-yield

GET https://yieldsignal.vercel.app/decision/eth-staking-yield?position=lido&amountUsd=25000&horizonDays=30

GET https://yieldsignal.vercel.app/durability/weth-base-yield
GET https://yieldsignal.vercel.app/capacity/usdc-base-yield?amountUsd=200000
GET https://yieldsignal.vercel.app/sensitivity/usdc-base-yield
GET https://yieldsignal.vercel.app/exposure/usdc-base-yield?positions=aave:200000,morpho:150000
GET https://yieldsignal.vercel.app/persistence/usdc-base-yield

Bare /signal and /decision (no asset) redirect to the ETH staking route β€” the asset with the strongest verified track record. Short forms like /signal/usdc redirect to the canonical path.

Which asset should you trust?

Don't take our word for it: GET /accuracy.json is free and returns the per-asset within-tolerance hit-rate and average regret in bps, computed 1:1 from the public on-chain EAS track record. As of writing, the staking signal holds up far better than the USDC lending one (Base USDC churns too fast for a call to stay true) β€” which is exactly why the flagship is staking. The numbers are recomputed from chain data, not asserted here, so check them yourself before paying.

Call it without payment first and you'll get a 402 Payment Required with the exact price/asset/network to pay. Any x402-compatible client can complete the payment automatically β€” for example with @x402/fetch:

server.ts
import { wrapFetchWithPayment } from "@x402/fetch";
import { CdpX402Client } from "@coinbase/cdp-sdk/x402"; // or any other x402 client/signer

const client = new CdpX402Client(); // needs CDP_API_KEY_ID/SECRET/WALLET_SECRET + a funded wallet
const fetchWithPayment = wrapFetchWithPayment(fetch, client);

const res = await fetchWithPayment("https://yieldsignal.vercel.app/signal/usdc-base-yield");
console.log(await res.json());
// { bestProtocol: "compound", gapBps: 57, rates: [...], asOf: "..." }

MCP

Also available as paid MCP tools at https://yieldsignal.vercel.app/mcp β€” get_yield_signal and get_yield_decision, both with an optional asset ("ETH_STAKING", "USDC" or "WETH"; defaults to "USDC" for backwards compatibility with already-published integrations). Most autonomous-agent frameworks discover/call tools via MCP rather than hand-rolled x402 HTTP clients. Uses the official @x402/mcp package; payment is gated per tool call (tools/list/initialize stay free, only the tool call requires payment). There's also an elizaOS plugin in the official registry.

Response shape

Every rate is tagged with where it came from β€” onchain/api (Aave, Compound, Morpho β€” read directly from the protocol) or defillama (Moonwell, Euler, Fluid β€” via the DefiLlama yields API). No estimated or fabricated numbers: a source that fails or returns invalid data is omitted from the response, never guessed at.

Every rate is also compared on one explicit basis (apyBasis: "supply-apy-total-incl-rewards"): base interest plus incentives. This matters because the raw sources disagree on what "APY" means β€” an on-chain liquidityRate/getSupplyRate is base-only, while DefiLlama's aggregate and Morpho's netApy already include reward tokens. Ranking them side by side without reconciling that compares different things. Each rate itemizes apyBaseBps/apyRewardBps where the source separates them, and rewardBasis says how the incentive component was obtained (reported, inferred, included-not-itemized, unavailable). Any protocol whose incentive could not be established at all is listed in incompleteRewardData β€” its APY is a floor, not a verdict.

config.json
{
  "asset": "USDC",
  "bestProtocol": "compound",
  "gapBps": 150,
  "rates": [
    { "protocol": "compound", "apyBps": 601, "apyBaseBps": 601, "apyRewardBps": 0, "rewardBasis": "reported", "tvlUsd": 8446455, "tvlBasis": "total-supplied", "weightedApyBps": 595, "source": "onchain", "asOf": "2026-07-30T..." },
    { "protocol": "moonwell", "apyBps": 434, "apyBaseBps": 403, "apyRewardBps": 31, "rewardBasis": "reported", "tvlUsd": 2643239, "tvlBasis": "aggregator-reported", "weightedApyBps": 382, "source": "defillama", "asOf": "..." }
  ],
  "omittedProtocols": ["euler"],
  "coverage": { "read": 5, "expected": 6 },
  "apyBasis": "supply-apy-total-incl-rewards",
  "incompleteRewardData": [],
  "asOf": "2026-07-30T..."
}

Depth, and whether the yield is a campaign

Each rate also carries tvlUsd with a tvlBasis saying what that number measures β€” total-supplied when it comes from the protocol's own books (Aave totalAToken, Comet totalSupply, Morpho totalAssetsUsd), aggregator-reported when it comes from DefiLlama, which reports available liquidity for lending markets. They are not the same quantity and the field says which one you got. Depth matters because the top of a thin market is not an executable rate for size: at the time of writing, the WETH signal leads with a $716k market whose yield is 59% incentive campaign.

The decision routes act on both: /decision/* returns gainDependsOnIncentives and positionShareOfDestinationPct, states them in the human-readable reason, and lowers confidence when your position would be a large share of the destination. A real response:

MOVE, confidence medium β€” "Moving aave β†’ euler yields +106bps risk-adjusted … Note: the entire gain rests on euler's incentive campaign (172bps of its 291bps) β€” it disappears if the campaign ends. Note: your $200,000 would be 27.9% of euler's $716,897 market β€” large enough that entering dilutes the rate you are moving for."

Is the yield real? β€” /durability/*

Splits every protocol's APY into base interest vs incentive and reports the post-incentive floor: what you keep if the reward campaign stops. On a live reading (2026-08-05), WETH on Base led with euler at 299bps β€” 57.9% of it incentive, floor 126bps β€” while aave's 153bps was entirely base. Without incentives the ranking flips. The signal endpoint alone would have pointed you at euler.

Two rules keep this from becoming a false-alarm generator:

  • Only itemized sources are decomposed. rewardBasis: "included-not-itemized" or "unavailable" means the floor is unknown, and the protocol is listed in undecomposable β€” never treated as incentive-free. Absence of a reported incentive is not evidence of absence.
  • No ranking claim when the leader is opaque. If the current best protocol can't be decomposed, rankingChangesWithoutIncentives is null, not false. You still get bestVerifiableFloor β€” the highest yield provably independent of incentives β€” which is a fully measured statement either way.

Base lending only (USDC/WETH). Checked live on 2026-08-05, all five liquid-staking sources report apyReward: null on DefiLlama β€” 0 of 5 decomposable on every call β€” so an ETH staking durability route would charge for "cannot establish". Staking yield being incentive-free is plausible, but a missing apyReward doesn't prove it, and that's the same inference this service refuses to make for fluid/morpho on the lending side.

Deliberately not a date forecast. The obvious source for "when does this campaign end" is Merkl's API (earliestCampaignEnd). Checked live on 2026-08-05 against api.merkl.xyz/v4/opportunities?chainId=8453&status=LIVE: Aave, Compound, Euler and Fluid have zero LEND campaigns there, and Morpho/Moonwell appear only as curated MetaMorpho vaults that aren't the markets this service reads. status=PAST returns null timestamps, so renewal history isn't measurable either. Covering 2 of 6 protocols by guessing at vault matches β€” with most campaigns being weekly and auto-renewing β€” would produce a confident-looking number that is wrong, which is the opposite of what this service sells.

Can you actually get out? β€” /capacity/*

A lending market at 99% utilization pays beautifully and won't let you withdraw; the high rate is the symptom. tvlUsd can't tell the two apart β€” $100M supplied with $99M borrowed and $100M supplied with $10M borrowed are the same number.

Utilization and free liquidity come from the protocol's own books, in the same call that already fetched the rate (Aave: the getReserveData tuple; Compound: getUtilization() + totalSupply()), so this costs zero extra RPC. Pass ?amountUsd= and each protocol reports whether that size can exit now (canExitNow), the coverage ratio, and what share of the market it would be.

Morpho and the DefiLlama-sourced protocols don't publish borrowed-vs-supplied, so they're marked measured: false and are never returned as bestProtocolExecutable. Unmeasured is not the same as liquid. USD figures are USDC-only β€” converting a WETH balance would need a price oracle inside a paid response path; WETH still gets utilization, which is unitless.

How close is the repricing? β€” /sensitivity/*

A lending rate is not a number, it is a function of utilization with a kink. Below it the rate creeps; above it, it explodes. Read live on 2026-08-05:

Code
             utilization   kink   headroom   borrow APY at 90% β†’ 93%
compound USDC   89.82%      90%    0.18pp        4.08%  β†’  15.95%
aave     USDC   86.16%      90%    3.84pp        4.60%  β†’   7.79%

Compound's USDC market was eighteen hundredths of a point from the knee. The signal endpoint alone shows a healthy 3.29% supply APY and says nothing about that.

The kink and both slopes are read from each protocol's own interest rate contract β€” for Compound the reconstructed curve is checked against getBorrowRate(u), the contract's own pure function, and matched it wei-for-wei at 50/85/90/93/99% utilization; for Aave the shape is checked against the ceiling the contract itself reports (base + slope1 + slope2 == getMaxVariableBorrowRate). If either check fails the protocol is dropped rather than served with a number derived from a formula that changed.

This is also the first route that speaks to the borrower rather than the lender.

Aave and Compound only. Morpho's AdaptiveCurveIRM fails on three independent counts, checked live: its curve constants aren't exposed on-chain (CURVE_STEEPNESS, TARGET_UTILIZATION, ADJUSTMENT_SPEED and INITIAL_RATE_AT_TARGET are all internal constant, so using them would mean hardcoding numbers copied from a repo); what is readable, rateAtTarget(id), is state that drifts over time, not a static curve, so "the rate at 95%" has no fixed answer there; and this service reads a vault (Gauntlet USDC Prime, $429M across 5 Blue markets with different collateral) whose curator reallocates at will. Moonwell, Euler and Fluid come from DefiLlama with no curve access at all. All of them are reported as measured: false β€” never as stable.

One risk in three wrappers β€” /exposure/*

Code
GET /exposure/usdc-base-yield?positions=aave:200000,compound:50000,morpho:150000

The market is full of event detectors β€” depeg alerts, hack alerts, liquidation alerts β€” and most of them are free. None of them answer the question that actually costs money: am I exposed, and through what path?

In the Stream Finance collapse, only 1 of ~320 MetaMorpho vaults held the broken asset directly ($700k of bad debt), yet $93M of loss became $285M of contagion because the exposure arrived indirectly. The event was public within hours; what hurt people was not knowing they were two hops from it.

A real reading on 2026-08-06 for the portfolio above:

Code
$400k across 3 venues β€” $200k attributable

  collateral  cbBTC       81.0%   via compound+morpho   ← shared
  curator     0x9e33fa…   75.0%   via morpho
  collateral  WETH        13.4%   via compound+morpho   ← shared
  parameter   kink=9000  100.0%   via aave+compound     ← shared

  unattributed: aave $200k

Three venues, and 81% of what can be attributed sits behind one collateral. The kink line says something else: Aave and Compound both reprice at exactly 90% utilization, so splitting capital between them buys no protection at all against a utilization shock.

Attribution differs by protocol, because the risk topologies differ, and the basis field says which one you got:

  • Morpho (isolated-market) β€” each Blue market is isolated with a single collateral, so the attribution is exact.
  • Compound (collateral-basket) β€” one base asset against a defined basket, weighted by what is actually posted (totalsCollateral Γ— the Comet's own price feed). Measured: cbBTC 43.1%, WETH 37.4%, tBTC 7.8%, cbETH 6.9%, wstETH 4.8%.
  • Aave β€” reported unattributed, and not for lack of effort: a v3 supplier is exposed to the entire pool's collateral set. Attributing it to one asset would be false, and splitting it across all of them would imply diversification that does not exist.

Percentages are of attributable capital, not of the total β€” over the total they would shrink and read as low concentration when the truth is low visibility. coverage reports both.

This measures structural shared exposure β€” the factual claim "these positions depend on the same thing" β€” not statistical correlation. Saying how much they move together would need a price history this service does not have, and would be a weaker claim dressed as a stronger one.

Recursive-collateral detection is deliberately absent. Checked live across the 77 live Morpho markets on Base: zero cycles, and zero assets that are both collateral and loan asset. Worse, the recursion that killed Stream was not in the lending graph at all β€” it was in the issuance of the synthetic (xUSD backed by positions funded with the borrowed USDC). A cycle detector would have reported "all clear" throughout the collapse. False safety is worse than a false alarm.

How long does the answer hold? β€” /persistence/*

Code
GET /persistence/usdc-base-yield

Every other endpoint here β€” and every competing yield feed β€” answers what pays best now. None answers how long that stays true, which is the number that decides whether moving capital is worth the gas.

This one answers it from this service's own hourly attestations on Base. Over 24 days and 439 attestations, the three assets are not the same product at all:

AssetLeadership changesMedian time on topWorth chasing, per $10k, before gas
WETH lending0> 518h (floor, censored)$6.50
ETH liquid staking1026h$0.018
USDC lending1672h$0.011

Half of those 167 USDC switches are a round trip between the same two protocols (compound <-> fluid). Following that signal literally costs more in gas than the edge is worth β€” and until this endpoint existed, nothing in the catalogue said so.

It also settles, empirically, an assumption almost everyone makes: a bigger lead does not last longer. Spearman -0.04 across 177 completed leadership spells, with the 0-24bps and >=300bps bands both sitting at a 2h median. Gap size is not a usable proxy for confidence, and this is the only place that number is published β€” including when it is unflattering to the service publishing it.

The /decision/* routes consume this internally: expected gain is projected over the horizon you asked for or the measured lead duration, whichever is shorter. A 30-day projection on a 2h edge is exactly how a MOVE that only pays gas gets recommended.

Honest limits, stated in the payload rather than in a footnote: the observation interval is 1h, so leads shorter than that are invisible; assets whose lead has not yet changed report a floor with a censoring flag, never a median; and every figure travels with its sample size, with null wherever the sample is too small. Every input is a public attestation UID β€” recompute the whole report from base.easscan.org and you get the same numbers without trusting this server.

How long is a signal good for?

GET /accuracy.json (free) carries two independent measures, both derived from the public on-chain attestations:

  • score β€” directional: was the flagged protocol still the leader (or within 25bps) when scored against the market right now.
  • windowedScore β€” each attestation judged over its own validity window, i.e. until the next attestation for that asset replaced it. medianWindowHours is the practical answer to "how often should I re-check?" and it differs sharply per market: on the record as of 2026-07-30, 13h for ETH liquid staking and WETH lending, 1h for USDC lending on Base. USDC rotates fast; that is a property of the market, not a defect the endpoint hides.

The track record now covers more than the signal

The whole argument of this service is verifiable, not promised β€” and until 2026-08-06 the EAS record covered only the signal. The four analytics products were sold leaning on credibility the signal had built, contributed nothing back to it, and could not be scored.

SENSITIVITY_SCHEMA is the first to change that, and sensitivity was chosen to go first for a specific reason: it is the only product whose record turns into an empirical question later. With utilization and kink stamped on-chain at each reading, the history eventually answers "markets that sat within half a point of the kink β€” how often did they cross, and how fast?" β€” and the headroom number stops being merely descriptive.

Only measured entries can be attested (encoding a non-measured one throws), and only markets within 5 percentage points of the kink are written: attesting everything on every read has no cost ceiling, and a market parked at 60% utilization produces no information a month later would not.

Gated by EAS_SENSITIVITY_SCHEMA_UID. Empty means the trigger simply does not run β€” the same switch-by-omission the v2 signal migration used. Registering it costs real gas and requires a typed CONFIRM via npm run register-schema.

Verifiability

Full write-up with every on-chain artifact, the exact command to verify each one, and an honest list of what the stack does not solve: docs/verifiable-agent-trust.md.

Two independent ways to check a response wasn't tampered with or fabricated, neither requiring you to trust this server's uptime at the moment you check:

  • Signed responses β€” every REST/MCP response is signed (EIP-712 typed data) by the same payTo address the 402 payment requirement names. The struct (asset, bestProtocol, weightedApyBps, gapBps, asOf, contentHash) mirrors the on-chain EAS schema below, plus a contentHash (keccak256 of the exact response body) binding it to the full response. REST: X-Signal-Signature/X-Signal-Signer/X-Signal-Eip712-Payload headers. MCP: a sibling content block. Verify with viem's verifyTypedData β€” or just call getSignalVerified() from the yieldsignal-client package, which does both checks for you.
  • On-chain attestations (EAS, Base mainnet) β€” periodic, public, permanent records of "at time T, protocol X paid Y bps, Z ahead of the runner-up," independently checkable on easscan.org without trusting this server at all. Same attester address as the signed responses above. Published automatically whenever the signal changes materially (best protocol flips, or the gap moves β‰₯25bps) or gets stale (>12h since the last one) β€” see src/attestation/autoAttest.ts and POST /internal/auto-attest (cron-triggered, not on every paid call β€” that would have no cost ceiling). npm run attest still exists for manual, on-demand publishing. Full history at GET /track-record (or /track-record.json).
  • Agent discovery (ERC-8004, Base mainnet) β€” GET /agent-card.json is the registration file; agentId 59272 already minted on IdentityRegistry. Any REAL buyer (a wallet other than the service's own β€” the contract blocks owner/operator self-feedback) can leave verifiable feedback on ReputationRegistry by running npm run give-feedback β€” addresses/ABI in src/attestation/erc8004.ts.

Architecture

Sibling project to YieldPilot (a personal Aave/Morpho/Compound rebalancer), but fully separate: own CDP credentials, own receiver wallet, no shared runtime code. See CLAUDE.md and SECURITY.md for the full technical writeup and threat model.

  • src/expressApp.ts β€” the Express app + x402 payment gate (createX402Server, @x402/express), reused by both the local dev server (src/server.ts) and the Vercel serverless entrypoint (api/index.ts). Registers one payment-protected route per asset (RESOURCE_PATHS) plus an unpaid /health liveness check.
  • src/signal/ β€” the pure, deterministic comparison logic (no I/O, fully unit tested).
  • src/market-data/ β€” the two-layer data sourcing (direct reads + DefiLlama), parametrized by asset (AssetId, USDC/WETH) via config/networks.ts's BASE_ASSETS.
  • src/wallet/walletLock.ts β€” pins the receiver wallet address (via EXPECTED_WALLET_ADDRESS in production, since serverless has no persistent disk) so a CDP credential rotation is caught loudly instead of silently redirecting payments.
  • src/mcp.ts β€” the get_yield_signal MCP tool (optional asset param), gated per-call with @x402/mcp's createPaymentWrapper (not the whole-route Express middleware, which would paywall tools/list/initialize too).
  • src/market-data/cache.ts β€” 30s TTL on every rate reader (direct + DefiLlama), one cache instance per asset, so a burst of concurrent paid calls doesn't hammer public RPC/API endpoints.
  • src/notify/paymentLog.ts β€” logs payer/tx/network/amount for every settled payment (onAfterSettle, both the REST and MCP payment servers) and alerts on a payment from a wallet that isn't the owner's (a real sale).
  • src/usage/ β€” durable funnel counters (usageStore.ts + usageMiddleware.ts), readable at GET /usage.json (auth required). Counts 402s served, paid attempts, settlements, failures and 404s per route/asset. The sale-side stages (paid_attempt/served/settled/failed) are exempt from the daily event budget β€” crawler noise used to exhaust it before midday and erase exactly the rows that answer "does this sell?". Exists because platform runtime logs aren't reachable from outside, so the only auditable signal used to be on-chain revenue β€” which can't distinguish "nobody arrives" from "they arrive and don't pay". Backend is any Redis with a REST API; credential discovery matches by env-var suffix, so a store connected through the Vercel dashboard (which prefixes the vars it injects) is picked up with no code change. With no store configured it degrades to per-instance in-memory counters and reports "durable": false.
  • src/cli/withdraw.ts β€” sweeps accumulated USDC to the owner's personal wallet, manual CONFIRM required, never automatic.
  • src/wallet/signerAccount.ts β€” resolves the same receiver wallet with signMessage/signTypedData/sendTransaction exposed (createX402Server only exposes the address); used for response signing and EAS attestation.
  • src/attestation/ β€” EAS schema definition and calldata encoding (pure, unit tested); publishAttestation.ts (shared tx-sending logic), queryAttestations.ts (EASScan GraphQL client + decoder), autoAttest.ts (pure decision logic + orchestration for the automatic trigger), trackRecord.ts (then-vs-now comparison), erc8004.ts (ERC-8004 registry addresses/ABI).
  • src/cli/registerSchema.ts / src/cli/attestSignal.ts / src/cli/registerAgent.ts / src/cli/giveFeedback.ts β€” one-time schema registration, manual per-attestation publishing, one-time ERC-8004 identity mint, and buyer-side reputation feedback, same CONFIRM pattern as withdraw.ts. giveFeedback.ts is the one script that deliberately resolves a DIFFERENT wallet than wallet/signerAccount.ts β€” the contract rejects feedback from the service's own address.

Local development

Terminal
npm install
npm test                # automated tests (market-data readers, signal logic, retry, wallet lock, usage funnel)
npm run signal            # live signal, real data, zero credentials needed (`npm run signal -- ETH_STAKING` / `-- WETH` for the other assets)
npm run dev               # local x402 server (reads X402_ENVIRONMENT from .env)
npm run test:paid         # spins up a test buyer wallet, funds it via the CDP faucet, pays for real (testnet only, REST endpoint)
npm run withdraw          # sweep accumulated USDC β€” asks for typed "CONFIRM"
npm run register-schema   # one-time EAS schema registration (mainnet, real gas) β€” asks for typed "CONFIRM"
npm run attest             # publish one on-chain attestation of the current signal (mainnet, real gas) β€” asks for typed "CONFIRM"
npm run register-agent    # one-time ERC-8004 identity mint (mainnet, real gas) β€” asks for typed "CONFIRM"
npm run give-feedback     # a REAL buyer leaves feedback on ReputationRegistry (mainnet, real gas) β€” asks for typed "CONFIRM". Fails with "Self-feedback not allowed" if run from the service's own wallet.

See .env.example for the required variables. Generate your own dedicated CDP project/credentials at portal.cdp.coinbase.com β€” never reuse another project's.

Source

github.com/Stakemate369/yieldsignal β€” open source, CI runs typecheck + full test suite on every push/PR.

Why Spark, Seamless and Silo aren't in the protocol list

Checked against yields.llama.fi/pools on 2026-07-16, filtering chain=Base + symbol=USDC: Spark only has a USDS pool (not USDC) on Base; Seamless and Silo have no indexed Base pool at all right now. Rather than fabricate a number, these three are left out until a real USDC market exists for them on Base β€” see the comment in src/market-data/types.ts.

Why WETH but not WBTC/cbBTC

Checked live against yields.llama.fi/pools on 2026-07-17: there's no canonical "WBTC" market on Base, only Coinbase's cbBTC (a different asset), and where it does have a market its supply APY sits at ~0-0.2% across all six protocols β€” a signal too flat to be worth selling ("which is best" barely matters when everyone's tied near zero). WETH, by contrast, has real, distinct yield across all six protocols (0.66%-3.7%), so it's the asset that got added instead.

Related MCP Servers

View all in Finance & Fintech View all alternatives
  • B
    Blixtworks

    Vision, web and data tools paid per call in USDC on Base via x402. No account, no API key.

    πŸ’° Finance & Fintech0 views
    Compare vs Blixtworks β†’
  • K
    Kerdos X402 Mcp

    Crypto market intelligence MCP β€” pay-per-tool-call in USDC on Base via the x402 protocol.

    πŸ’° Finance & Fintech0 views
    Compare vs Kerdos X402 Mcp β†’
  • P
    Parser

    Parse receipts & invoices into structured JSON. Pay per call in USDC (x402 on Base), no API key.

    πŸ’° Finance & Fintech0 views
    Compare vs Parser β†’
  • M
    Money Engine x402 Research

    Free agent discovery + paid x402 research (outline 0.01 / brief 0.02 USDC Base).

    πŸ’° Finance & Fintech0 views
    Compare vs Money Engine x402 Research β†’

Frequently Asked Questions about YieldSignal

Add the following block to your claude_desktop_config.json under mcpServers: "mcpServers": { "yieldsignal": { "command": "npx", "args": ["-y", "YieldSignal"] } }

AllMCPs Directory Badge

Full Badge Customizer

Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.

Badge Style:
Live Dynamic SVG PreviewYieldSignal AllMCPs Directory Badge
Markdown (GitHub README)
[![AllMCPs](https://allmcps.com/api/badge/yieldsignal?style=directory)](https://allmcps.com/mcp/yieldsignal)
HTML Embed
<a href="https://allmcps.com/mcp/yieldsignal"><img src="https://allmcps.com/api/badge/yieldsignal?style=directory" alt="YieldSignal on AllMCPs" /></a>

Technical Specs & Signals

CategoryπŸ’°Finance & Fintech
More technical detailsExpand β–Ύ
TransportSTDIO
RuntimeNode.js
0/4 checks healthy over the last 6h
Views0
Unique ViewsTotal visits recorded for this listing page on AllMCPs.
Installs0
Installs & Copy ActionsTotal times users copied install commands or configuration snippets for this server.
27Quality signal: Emerging Β· 27/100How this signal is calculated β–Ύ
Server availabilityNot measured

Not scored for repo-hosted servers β€” we can't reach the running server, only its GitHub page. Hosted MCP endpoints are health-checked live.

Verified ownership8/20
Documentation & tools11/30
Adoption & activity1/15
Community engagement0/10

A guidance signal from public completeness & health data β€” not a user rating. New listings start lower and rise as they add docs, get verified, and grow adoption. Signals we can't observe for a listing are skipped, not counted against it.

β˜… FeaturedMoxie Docs MCP logo

Moxie Docs MCP

MCP & Agent Skills for Automated Documentation, and codebase conventions + context

Explore Server β†’

Own this project?

This directory is pre-filled from public sources. Claim via GitHub README, site badge, or DNS TXT to get the verified badge and attach your website.

Free dofollow backlink: after claiming, verify your product site and place a dofollow AllMCPs badge β€” we recheck it stays live.

Claim & get free dofollow

Share & Embed

Add our SVG badge (dark/light directory styles) or embeddable widget to your site.

Explore more

More in πŸ’° Finance & Fintech β†’Best MCP servers for Finance & Fintech β†’Alternatives to YieldSignal β†’Install in Claude DesktopInstall in CursorInstall in VS Code