Alpha at the Data Frontier. Send Your Agents.
Brickroad's API and MCP server let agents discover, inspect, and access data from the workflows where research already happens.
Brickroad already helps people find and access data that traditional catalogs miss. Now our API and MCP server let their agents do the same work inside the tools they already use.
AI models keep getting better at reasoning. But their answers are still limited by the data they can reach.
The most valuable data often isn't in a clean warehouse or a familiar catalog. It's scattered across obscure APIs, government portals, industry tools, public files, vendor sites, and access gates. We call this edge the data frontier: the constantly changing set of data that exists, but isn't yet connected to the computation that needs it.
Brickroad indexes that world. Our discovery agents find suppliers that are difficult to locate through normal search or static catalogs. Our access agents then qualify those suppliers, retrieve samples when possible, and help people start the access process when a human conversation is still required.
The goal is simple: make data access move at the speed of computation.
From months to seconds
The normal path to a new dataset is slow. A researcher finds a vendor, sends an email, schedules a call, signs paperwork, waits for a trial, and only then learns whether the data is useful. Industry guides put that process at about three months.
In one Brickroad reference deployment, 86 of 116 selected open endpoints returned a verified live sample. The median time from drill-down to sample was 38 seconds. The same deployment completed discovery requests in a median of 50 minutes and grew its registry at more than 200 times the pace of the static catalogs we measured.
Those results aren't a promise that every supplier will open in seconds. Some data requires payment, credentials, or a commercial agreement. But they show what becomes possible when discovery and access use machine-readable rails instead of a manual procurement queue.
People want the frontier inside their workflow
People who use an agent as their interface to the computer don't want to move their research process into another interface. They want their agent to search for data, inspect the evidence, request samples, and pass useful candidates into the research systems they already use.
That was the useful lesson: a good UI isn't enough. Different people want to inspect data in different ways. Quants, researchers, and engineers increasingly want services that their own agents can call directly.
Many teams already have their own processing and assessment pipelines. They don't need us to replace them. They need the right tools and enough flexibility to plug Brickroad into the way they already work. The same tools power our UI, so teams can compose them into their own systems while people who want a ready-made workflow can still get the result by clicking a button.
That's why we built the Brickroad API and Model Context Protocol (MCP) server.
One system, three ways in
The UI, REST API, and MCP server expose the same discovery and access workflows through different interfaces.
The REST API is useful for deterministic applications and data pipelines. MCP lets an agent such as Claude use Brickroad as a native tool. Both use the same organization API key and the same organization-scoped data.
We also publish the complete API contract as a Markdown file. You can give docs.md to an agent and let it learn the interface without converting a documentation site into model context.
Agent Access. One key connects the REST API or MCP server.
The current interface can:
- Submit a one-time data discovery query, check its status, read its suppliers, or cancel it.
- Create a Stream that repeats a query on a schedule, then list, pause, resume, edit, run, or delete that Stream.
- Read compact supplier results or inspect the full evidence behind one supplier.
- Retrieve coverage tags such as geography, exchange, instrument, industry, and sample tickers.
- Retrieve available supplier contacts and access evidence.
- Add prompt rules and task profiles that control what agents collect and how results are ranked.
Streams repeat the same discovery request on a set cadence.
Example: finding data for public-equity research
Suppose an industrials quant wants new data that may help explain weekly demand for Caterpillar, Deere, and AGCO. The useful research question isn't “What should I buy?” It's:
Find non-obvious data suppliers that could improve a weekly demand signal for CAT, DE, and AGCO. Focus on machinery utilization, dealer inventory, replacement parts, freight, and construction activity in North America. Prefer at least three years of history, weekly or better cadence, point-in-time availability, and sample access.
An agent could submit that query once or turn it into a weekly Stream. Here's an illustrative request:
POST /api/v1/ifa/queries Authorization: Bearer $BRICKROAD_API_TOKEN Content-Type: application/json
{
"query": "Find non-obvious North American data suppliers that could improve a weekly demand signal for CAT, DE, and AGCO, with at least three years of history, weekly or better cadence, point-in-time availability, and sample access.",
"preset": "thorough",
"fastVerify": true,
"steering": {
"max_sources_to_enrich": 20
},
"taskProfileIds": ["industrial-demand-profile"],
"stream": {
"intervalDays": 7
}
}
The saved task profile can ask Brickroad to collect the fields that matter to this workflow—history length, update cadence, ticker coverage, point-in-time support, delivery format, and sample availability—and weight them for ranking.
With MCP, the same workflow can start as a plain request to an agent: “Run this search every Monday. Check each run when it completes, show me new final suppliers, and inspect the evidence for anything that covers all three tickers.” The agent can map that instruction to ifa_submit_query, ifa_get_query, ifa_list_sources, and ifa_get_source without a person wiring each request by hand.
The response is asynchronous, so the calling system doesn't need to hold an agent session open while discovery runs:
{
"queryId": "qry_industrials_weekly_01",
"streamId": "str_industrials_weekly_01",
"query": "Find non-obvious North American data suppliers that could improve a weekly demand signal for CAT, DE, and AGCO, with at least three years of history, weekly or better cadence, point-in-time availability, and sample access.",
"status": "queued",
"createdAt": "2026-09-11T16:00:00.000Z",
"updatedAt": null,
"nextPollAfterSeconds": 300,
"links": {
"self": "/api/v1/ifa/queries/qry_industrials_weekly_01",
"sources": "/api/v1/ifa/queries/qry_industrials_weekly_01/sources",
"stream": "/api/v1/ifa/streams/str_industrials_weekly_01"
},
"stream": {
"streamId": "str_industrials_weekly_01",
"query": "Find non-obvious North American data suppliers that could improve a weekly demand signal for CAT, DE, and AGCO, with at least three years of history, weekly or better cadence, point-in-time availability, and sample access.",
"intervalDays": 7,
"status": "active",
"nextRunAt": "2026-09-18T16:00:00.000Z",
"lastRunAt": null,
"createdAt": "2026-09-11T16:00:00.000Z",
"links": {
"self": "/api/v1/ifa/streams/str_industrials_weekly_01",
"queries": "/api/v1/ifa/streams/str_industrials_weekly_01/queries",
"run": "/api/v1/ifa/streams/str_industrials_weekly_01/run"
}
}
}
When the run completes, the agent can retrieve ranked supplier summaries:
{
"sources": [
{
"id": "src_machinery_activity_01",
"name": "Example Machinery Activity Supplier",
"description": "Illustrative weekly equipment activity for North America",
"url": "https://example.com/machinery-activity",
"whyMatched": "Weekly equipment activity with North American coverage",
"scores": {
"ranking": 0.91,
"novelty": 0.76,
"relevance": 0.94,
"accessibility": 0.82,
"alpha": 0.71
},
"tags": {
"geography": ["US", "CA"],
"gics": [
{
"sector": "Industrials",
"industryGroup": "Capital Goods",
"industry": "Machinery",
"subIndustry": "Construction Machinery and Heavy Transportation Equipment"
}
],
"exchanges": ["NYSE"],
"instruments": ["equities"],
"sampleTickers": ["CAT", "DE", "AGCO"],
"tickers": ["CAT", "DE", "AGCO"],
"categories": ["alternative", "industrial_activity"]
},
"contactAvailable": true
}
]
}
The agent can then inspect the evidence, request available samples, and pass the candidates into the firm's own research and backtesting workflow. If a dataset survives that process, the firm can connect it to its existing trading stack.
The point is to shorten the path between a good research question and the data needed to test it.
The IDs, supplier names, and result values in this example are mocked. The request and response shapes follow the Brickroad API contract.
The interface for the next user is an agent
Software used to be designed around pages and buttons. Those still matter. But more work now starts with a person telling an agent what outcome they want.
For data infrastructure, this shift is especially important. The data frontier is too large and changes too quickly for a person to browse it one vendor at a time. An agent needs a way to discover, qualify, access, and monitor suppliers as part of a larger workflow.
That's the direction we're building toward: not another closed catalog, but a programmable path to the data frontier.
If you want to try it, create a Brickroad account, generate an API key, and give the Markdown docs to your agent. Start with one research question you already care about.
Then tell us what worked, what broke, and what you want your agent to do next. We're early, and the feedback will shape the interface.