Digital Asset Data for AI Agents
An agent cannot see that a number looks wrong. It needs data that carries its own identity, its own timestamp and its own caveats — which is a design constraint on the data layer, not on the agent.
There is no Moonlytics MCP server and no agent tool API today. Nothing on this page is installable. What follows is the reasoning and the intended shape, published because the design constraints are already affecting how the layer is built.
Why agents change the requirements
A human analyst reading a dashboard brings context the data does not carry. They know which BTC the chart means. They notice a stale timestamp. They discount a sentiment reading that sits next to a suspiciously small volume.
An agent brings none of that. It reads what it is given, and it produces a confident sentence either way. Every piece of context that a human supplies implicitly has to be in the payload explicitly, or it is lost.
That inverts the usual API design instinct. Terse responses are good for bandwidth and bad for agents.
{ "BTC": 78135 }
# What is 78135? Which BTC? Observed when? In what currency?
# An agent will answer confidently from this and be wrong.{
"asset": { "id": 1, "symbol": "BTC", "name": "Bitcoin" },
"metric": "price",
"value": 78135,
"unit": "USD",
"observedAt": "2026-08-31T09: 00: 00Z",
"cadence": "hourly",
"note": "Aggregated across venues. Not a settlement price."
}The second response costs a few hundred bytes more and removes four distinct ways for an agent to produce a plausible falsehood. For this use case that is an obviously good trade.
What the layer already does right for agents
Three properties that exist for other reasons happen to be exactly what agent consumption needs:
- Resolved identity. An agent asked about "HYPER" is facing a ticker used by three different assets. Because resolution is deterministic and identity is canonical, the correct behaviour — return candidates, do not guess — is expressible.
- Explicit timestamps. Every stored value carries the time it describes, so no response has to imply currency.
- Documented limits. Every category on this site states what it cannot support. That text is what an agent tool description should carry verbatim, so the model knows the boundary before it calls.
Agent use cases
The patterns below are what this data would plausibly serve. They are worth listing precisely because they are all retrieval problems, not prediction ones.
Assembles market, social and ecosystem context for a named asset, with each figure timestamped and sourced.
Watches the deduplicated news window and the narrative snapshots for events touching a defined asset set.
Compares consecutive topic snapshots to report what is forming, growing or fading, with source counts as evidence.
Resolves a holdings list to canonical identities — the step that silently fails when tickers are used as keys.
Reads volatility, liquidity ratios and coverage gaps, and can state when it does not have enough data to answer.
Checks freshness and completeness of a series before an analysis runs on it.
None of these are trading agents, and the layer will not carry anything shaped like a recommendation. Market, social and sentiment data are descriptive inputs. An agent tool that returned "buy signal" would be manufacturing confidence that the underlying data cannot support.
Planned tool surface
Product planning. Every tool below maps to a data service that already runs internally, which is what makes the list a plan rather than a wish.
| Tool | Status | Purpose | Backed by |
|---|---|---|---|
| search_asset | Planned | Resolve a symbol, name or provider identifier to canonical candidates. | Asset registry |
| get_asset | Planned | Fetch the canonical record: identity, provider mappings, categories, channels. | Asset registry |
| get_market_data | Planned | Current or historical market observations for a canonical asset. | Observation store |
| get_social_activity | Planned | Social volume, interactions and dominance series. | Observation store |
| get_sentiment | Planned | Sentiment series, always returned with its activity volume. | Observation store |
| get_news | Planned | The deduplicated news window, optionally filtered to an asset. | News feed |
| get_narratives | Planned | Current and previous hourly topic snapshots. | Narrative snapshots |
| get_ecosystem_activity | Planned | Daily channel, repository and contributor series. | Ecosystem series |
Machine-readable formats
Where the layer is heading, and where it is today:
- REST + JSON — the base interface. In development.
- MCP — the tool surface above. Not implemented.
- Webhooks — push for event-driven agents. Not implemented.
- Streaming — not planned in the near term; the layer's fastest cadence is hourly, and streaming an hourly value is theatre.
- Structured documentation — live today. This site publishes llms.txt, uses semantic HTML with schema.org typing, and answers the same eight questions on every data page: what it is, where it comes from, how it is processed, how often it updates, which fields exist, how to access it, what its limits are, and which applications use it.
Coverage, for an agent's benefit
7,461 canonical assets, 6.7 million hourly observations since November 2025, daily ecosystem series for 69 assets, hourly news and narrative snapshots. Fastest cadence hourly. No sub-hour data. Measured 2026-08-31.
Related
- Designing APIs for AI agents — the engineering write-up.
- AI developer use case.
- Canonical data model.