The platform speaks the Model Context Protocol, so an assistant can query it
directly instead of you copying numbers into a chat window.
Connect
{
"mcpServers": {
"dfrds": {
"type": "http",
"url": "https://dfrds.com/mcp",
"headers": { "Authorization": "Bearer YOUR_API_KEY" }
}
}
}
Same key and the same plan entitlements as the REST API, but its own daily
budget rather than the REST hourly one. An agent answering a single research
question can make a dozen tool calls, so sharing the REST allowance meant one
MCP session could exhaust a whole hour of scripted access. The refusal is the
same shape either way: a 429 with X-RateLimit-Limit and
X-RateLimit-Remaining, and the MCP window resets at midnight UTC.
Your organization page shows API calls and MCP calls per key separately, so
you can see which of the two a key is actually being used for.
Tools
| Tool | What it answers |
|---|---|
search_markets |
symbol or pair → pool addresses, ranked by activity; source narrows to one DEX |
get_price_bars |
OHLC bars for a pool, decimals already applied |
get_canonical_series |
the citable series plus its SHA-256 hash |
get_health_factors |
Aave-style panel summary, distribution, or one account; protocol is aave_v3 or spark |
get_liquidations |
liquidations with realized versus configured bonus; same protocol argument |
get_events |
the sourced event registry |
list_research_pages |
your research pages, newest first |
get_research_page |
one page: blocks in order, plus cited values and their verification state |
append_research_block |
record a finding into a page |
cite_query |
compute an aggregate over a dataset and get a {{derived:N}} token for it |
get_entitlements |
what this key’s plan allows |
platform_status |
warehouse reachability and ingest freshness |
Every tool has a REST twin (the API reference lists the pairs), and
both run the same service, so a number from a tool call and the same number
from a script agree.
Scopes
A key’s scopes apply to tools exactly as they apply to endpoints. Reads need
read, which every key has unless it was minted without it. The tools that
record something, append_research_block, cite_query and
get_canonical_series (it records a citation), need research:write, and a
key without it gets a tool error naming the scope rather than a silent no-op.
A key with an IP allow list is refused from any other address, before the
JSON-RPC layer, with the same 403 the REST API sends.
Writing findings back
The same tools reach the assistant on a research page, where the three that
write become proposals the author applies: see
the assistant on a page.
append_research_block and cite_query are the tools that write. An assistant
that computes something can record it on a research page rather than leaving
it in a chat log, and pasting a {{cite:N}} or {{derived:N}} token in the
body shows the value with its source instead of a number typed out. A
derived citation belongs to the member who minted the key and lands in their
research space; a key minted without a person (or by someone who has since
left the organization) cannot cite, and says so.
The same reach rule applies as everywhere else: a key belongs to an
organization, research belongs to a space, and the key reaches the spaces its
organization’s members belong to. It cannot read or write a page its holder
couldn’t open in the interface.
What it will not do
There is no SQL passthrough. Every tool runs a bounded query through the same
service objects the web surfaces use, ranges clamp, row counts cap, and anything
larger comes back as a pointer to the CSV path. The warehouse is a small shared
box; it cannot absorb agent-generated queries.
Payloads state their units and never fill a gap: an unpriced liquidation is null
with a reason, a partial health-factor snapshot reports itself incomplete, an
unknown pool is an error rather than an empty series. An assistant relaying “no
data” from these tools is relaying a real absence.