Autonomous agents executing on-chain strategies are not dashboard users. They do not read charts, hover over tooltips, or pause to judge whether a number looks reasonable in context. They call an API, receive a structured response, and act. The data format, the completeness of the response, and the latency between query and answer directly affect the quality of the decisions they make.
Most risk data products were designed for human analysts. The field of agentic DeFi is moving faster than those products have adapted. This article describes what a purpose-built agentic risk API requires and why it differs from existing tooling.
What agents need from risk data
Human analysts can fill in gaps. They can see that a number is from six hours ago and decide whether that matters. They can cross-reference two sources when the first seems unreliable. They can intuit that a market “looks thin” from a chart without requiring an exact liquidity depth figure.
Agents cannot do any of this. They require:
Complete, structured responses per query. Every data point an agent needs to make a decision must arrive in a single response, with clear field names and types. Partial responses that require follow-up queries, or responses that require the agent to join data across multiple endpoints, increase latency and create failure surfaces.
Timestamp provenance on every field. When an agent reads a collateralisation ratio or a liquidity depth figure, it needs to know when that value was computed. An undated field is not usable for time-sensitive decisions. Every field in a risk response should carry the timestamp of the observation it reflects.
Explicit uncertainty and confidence signals. Where data is estimated rather than observed, or where a computation depends on assumptions, the agent should receive that signal explicitly rather than receive a best-guess figure with no indication of its reliability.
Sub-second response latency for position-critical queries. An agent deciding whether to enter, hold, or exit a position on a fast-moving market cannot wait 2-3 seconds for a dashboard-grade API call. The latency budget for position-critical queries is measured in hundreds of milliseconds on most execution paths.
The structural gap in existing data APIs
Most on-chain data APIs today provide raw chain state or pre-computed analytics endpoints designed for front-end rendering. Two structural characteristics limit their usefulness for agents.
Pagination and multi-call requirements. APIs designed for dashboard pagination require multiple calls to assemble a complete market risk picture. An agent checking collateralisation, oracle freshness, liquidity depth, and large position distribution for a single market may need four or five separate API calls. Each call adds latency and a new failure point.
Human-readable formatting instead of machine-readable types. Fields returned as formatted strings (“$4.2M TVL”) rather than typed numerics require parsing. Fields that are percentages in some contexts and basis points in others require the agent to apply contextual logic. Both patterns are common in dashboard-oriented APIs and both are problematic for agent consumers.
What an agentic-first design looks like
A purpose-built agentic risk API returns a complete risk envelope per market per query. The risk envelope for a lending market includes at minimum:
- Collateral composition with per-asset concentration and volatility history.
- Oracle feed addresses and freshness timestamps for each feed the market uses.
- Liquidity depth at specified position sizes and a recent history of depth changes.
- Large position distribution and the proximity of the nearest large liquidatable position to current price.
- A cascade breakpoint estimate with the stress level at which that estimate was derived.
All fields carry ISO 8601 timestamps of the last observation. Typed numerics throughout, no formatted strings. The response schema is versioned and stable. Unknown fields are additive, not breaking.
For agents operating at high frequency, a WebSocket subscription model that pushes risk envelope updates on state change is more efficient than polling. The subscription surface for a risk API is structurally simpler than for raw chain state: agents subscribe to markets, not to all contract events.
The MCP interface pattern
The Model Context Protocol (MCP) is an emerging standard for exposing structured data to AI agents and language model pipelines. An MCP-native risk API exposes tools that an agent can call to query market risk state, with schemas that match the tool descriptions the model uses for reasoning.
This pattern has a practical advantage over custom SDK integrations: it allows agents built on language model backends to use risk data as a first-class reasoning input without requiring custom tool-calling infrastructure on the model side.
Alterscope’s MCP server exposes risk tools for the markets we cover on Ethereum and Stellar. The server is under active development; tool coverage and capability expand with each protocol connector we ship.
Honest limits of agentic risk data
Structured, low-latency risk data improves agent decision quality, but it does not eliminate the risks of operating on-chain autonomously. Several important limits apply.
Risk data reflects observed state. It does not predict future state. An oracle that is fresh now may go stale. Liquidity that is deep now may withdraw in the next block. Data freshness and decision latency together determine how much real-world state can change between the moment the agent reads and the moment it acts.
Agents acting on risk data still require appropriate position sizing, stop-loss logic, and access to override mechanisms. Data quality is one input into a broader system that includes execution controls, governance, and human oversight for edge cases. Neither the data nor the agent alone is sufficient.
FAQ
What protocols does the Alterscope API currently cover? The Alterscope API covers lending and yield markets on Ethereum and Stellar, including Blend on Stellar and a growing set of Ethereum lending markets. Current coverage is listed on the connectors page. Coverage is live data, not modelled estimates, for listed protocols.
Is the MCP server available now? The MCP server is available in early access for protocol integrations. It exposes a subset of risk tools covering oracle freshness, liquidity depth, and market health signals. Broader tool coverage, including full cascade breakpoint queries, is on the development roadmap. Contact us via the developer portal to request early access.
What is the typical response latency for a risk envelope query? For markets covered at full integration depth, the typical p50 response latency for a complete market risk envelope is under 200 milliseconds. Latency varies by chain and market complexity. The developer portal includes per-connector latency benchmarks updated weekly.
Does the API support batch queries across multiple markets? Yes. The batch endpoint accepts a list of market identifiers and returns risk envelopes for each in a single response. This is the recommended pattern for agents monitoring a portfolio of positions. Batch queries carry higher latency than single-market queries; the current p95 for a 10-market batch is under 800 milliseconds.