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.
{
"mcpServers": {
"cleaton": {
"command": "npx",
"args": ["-y", "@cleatonxyz/mcp-server"],
"env": { "CLEATON_API_KEY": "..." }
}
}
}Tools#
| Tool | What it answers |
|---|---|
get_attestation | Horizon, confidence and flags for one pool, with the signature |
pre_deploy_check | Go / no-go for an intended action, with the binding constraint named |
portfolio_scan | Positions ranked by breach risk, with n_eff and the earliest binding horizon |
survival_curve | The full S(t) when the agent runs its own threshold |
counterfactual | Horizon under a hypothetical schedule, lock or depositor exit |
expiry_calendar | Every tracked campaign and unlock on one forward timeline |
Pre-deploy check#
The distinction from a raw query is that the verdict names the constraint that binds, so the agent can act on it instead of re-deriving it:
{
"verdict": "no-go",
"binding": "horizon",
"detail": "horizon 6d < requested lock 30d",
"alternatives": [
{ "action": "shorten_lock", "to": 5, "note": "fits inside the horizon at 0.74 confidence" },
{ "action": "substitute", "pool": "0x4200...", "horizon": 62, "apyDelta": -0.031 }
]
}Portfolio scan#
The result worth reading is not the ranking, it is n_eff. In the paper’s worked case an agent allocating $50M across eleven candidate pools finds four of them 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.