MCP server

Native tool exposure so an agent can query durability the same way it queries anything else.

Argued in full in the whitepaper at §11, surfaces 28–32.

Why agents are the point#

A human analyst can separate a rented pool from an owned one in ten minutes with a browser. An agent cannot, because the distinguishing information is not in any state it reads. The MCP surface is what puts it there.

Connect#

Streamable HTTP, at https://dapp.cleaton.xyz/mcp. No key: every tool reads the same public record the website shows, and nothing exposed here can move funds, sign an attestation, or change what Cleaton publishes.

claude_desktop_config.json

{
  "mcpServers": {
    "cleaton": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://dapp.cleaton.xyz/mcp"]
    }
  }
}

terminal

claude mcp add --transport http cleaton https://dapp.cleaton.xyz/mcp

Tools#

Nine, all read-only. Nothing here can move funds, sign, or change what Cleaton publishes. They are listed in the order the server registers them.

Tool	What it answers
`get_pool_attestation`	Horizon, confidence and signature for one pool
`list_pools`	The tracked universe, with what is known about each
`pre_deploy_check`	Go / no-go against an intended lock, with the reason named
`get_accuracy_record`	The public record: totals, outcomes, and when the first claim comes due
`get_liquidity_profile`	One pool's depth, durability and movement, with no combined score — exitability is reported inside depth
`get_dtvl`	Durability-weighted TVL per pool and per chain
`get_expiry_calendar`	Every observed campaign expiry on one forward timeline
`compare_pools`	Up to four pools side by side on the same stored fields
`verify_attestation`	Recovers the signer from a signed attestation

Pre-deploy check#

The distinction from a raw query is that the verdict carries the comparison, so the agent can act on it instead of re-deriving it:

response.json

{
  "verdict":    "go",
  "lockDays":   30,
  "marginDays": 60,
  "reason":     "The horizon covers the lock with 60 day(s) to spare.",
  "pool":       "0xbeeff033f34c046626b8d0a041844c5d1a5409dd",
  "horizon":    90,
  "confidence": "0.65"
}

Not built yet#

Surfaces 30–32 are in the paper and are not exposed here. A portfolio can be scanned today over POST /api/v1/batch, but without n_eff, which is the number worth reading and the reason the surface exists.

Surface	What it would add	Blocked on
30 — Portfolio scan	Ranking a book by breach risk, with `n_eff`	Copula-adjusted joint survival across correlated expiries
31 — Constraint negotiation	The nearest feasible alternative to a rejected allocation	Needs the survival ensemble to price substitutes
32 — Attestation receipt	A signed record that an agent acted consistently with a claim	Registry not deployed

The paper’s worked case for n_effis why it is not faked in the meantime: an agent allocating $50M across eleven candidate pools finds four drawing incentives from the same treasury with expiries inside a nine-day band — an effective exposure count of 4.2 against a nominal eleven. It had constructed what it believed was a diversified book. What it held was a concentrated bet on one treasury’s emission policy, and no single-pool query would have surfaced it. A ranking without that number would look like the answer and not be one.