The Retrieval That Lies
The data shows a pipeline that retrieves correctly and reports incorrectly. These are not two states. They are one state observed at two layers of abstraction, and conflating them is the central engineering error of the current AI-data gold rush.
In late 2025, Blockworks activated a Model Context Protocol server. The endpoint exposes 40,000+ crypto assets, 300+ exchanges, and 400+ DeFi protocols to any MCP-compatible client: Claude, ChatGPT, Cursor, and the long tail of agent frameworks that adopted Anthropic's standard after its November 2024 release. The company spent the prior quarter assembling the substrate. A June acquisition of Messari. A September 24 launch of a Unified API that merged both firms' data under a single key. A compliance-monitoring product called Agentic Detection that shipped two weeks before the server went live.
I want to state the retrieval verdict plainly, because everything that follows is not a claim of broken engineering. The retrieval works. The provenance mechanism works. Every response carries a source string. What does not work, and cannot be made to work by appending more source labels, is the translation between a deterministic retrieval and a probabilistic synthesis. The pipeline has a deterministic front half and a stochastic back half. Blockworks has audited the front half to death and left the back half unverified.
Trust is a bug, not a feature. That is not a slogan. It is a design constraint. And this release, for all its data breadth, treats trust as a feature, a label attached to an answer, rather than as a defect to be eliminated at the protocol level.
What MCP Is, Mechanically
Before decomposing the Blockworks implementation, I need to specify what the Model Context Protocol actually is at the wire level, because most coverage describes it at the marketing level and that description hides the exact place where the failure lives.
MCP is a JSON-RPC 2.0 protocol. A client, typically an LLM host application, connects to a server over one of three transports: stdio, server-sent events, or streamable HTTP. The connection begins with an initialize handshake in which both parties exchange capability declarations. The server advertises what it supports: tools, resources, prompts, or a subset. The client advertises its own capabilities. After the handshake, the client can call tools/list to enumerate the available tools, each of which carries a name, a description, and a JSON Schema describing its input arguments. To invoke a tool, the client sends tools/call with a tool name and an arguments object. The server executes, returns a result content block, and the loop continues.
That is the entire surface. MCP is not a model. It is not a retrieval algorithm. It is a structured adapter that converts an external data source into a set of callable functions with typed inputs and typed outputs. Anthropic designed it to be the universal interface between language models and the outside world, a USB port for tools. The analogy is accurate and also limiting: a USB port does not guarantee that the device on the other end returns correct data. It guarantees only that the bytes arrive in a known format.
The important property for this analysis is where the determinism ends. tools/list is deterministic. The schema is fixed. tools/call is deterministic at the server boundary: given a valid arguments object, the server returns a fixed result for a fixed data state. But the client's decision to call a specific tool, with a specific set of arguments, and its interpretation of the returned result, is not deterministic. The model samples tokens. It selects tools from natural-language intent. It reads a JSON result and converts it into prose. Every one of those steps is probabilistic.
The MCP specification does not, and structurally cannot, constrain the probabilistic steps. It defines the pipe. It does not define the water. When a vendor claims that a data source is now AI-accessible, the claim is true and irrelevant at the same time. Accessibility was never the hard problem. Fidelity of interpretation is the hard problem, and MCP is silent on it.
I have spent enough time inside proof systems to recognize the pattern. A constraint system defines the space of valid assignments. It does not guarantee that any particular assignment is the one the prover intended. MCP is a constraint system for tool invocation. It defines valid calls. It does not define correct conclusions.
What Blockworks Actually Shipped
The architecture has three layers, and the release order reveals the strategic logic.
Layer one is the data substrate. The June acquisition of Messari gave Blockworks the asset breadth that a media and research firm accumulates over years of coverage. The September 24 Unified API merged Blockworks' depth with Messari's breadth behind a single key. The engineering claim is that 400+ DeFi protocols' financial data is arranged in an identical format for side-by-side comparison. That sentence, buried in product copy, is the most technically significant statement in the entire release.
Layer two is the protocol adapter. The MCP server wraps the Unified API. Each data endpoint becomes a tool. The client sees a menu of functions: fetch asset metrics, fetch protocol financials, fetch ETF flows, fetch governance proposals, fetch treasury-company holdings. Twenty-plus data types are exposed, spanning structured financials and unstructured media such as podcasts.
Layer three is the compliance extension. Agentic Detection, shipped two weeks before the server, marks anomalies and pushes alerts to compliance teams. It is a separate product line that happens to share the same data pipeline.
The stated target is not the retail user. Blockworks positions the offering for institutions and professional users, the segment that already reads Messari research and monitors protocol fundamentals. The co-founder, Jason Yanowitz, framed the thesis directly: agents will become the largest consumers of financial data. Every number, in his framing, should be retrievable by an agent in a single call.
That is a platform ambition, not a feature. It is the claim that Blockworks intends to become the default data-calling layer for autonomous financial agents. Whether the engineering supports the ambition is a separate question, and it is the question I intend to answer at the constraint level.
Decomposing the Tool Surface
A data MCP server is a set of functions. I evaluate it the way I evaluate any function surface: input validation, output typing, error semantics, and the gap between the natural-language description and the machine contract.
Consider a representative tool. The client sees something like get_protocol_financials with an input schema requiring a protocol identifier and a metric selector, and optionally a timestamp or window. The description, written in natural language, tells the model what the tool does. The schema, written in JSON Schema, tells the model what arguments are valid.
The first failure mode is argument ambiguity. A natural-language intent such as "how much liquidity does the biggest lending protocol have" must be resolved by the model into a protocol identifier and a metric. Which protocol is "biggest"? By total value locked, by revenue, by user count? Which metric is "liquidity"? The model picks. The schema cannot forbid a defensible but wrong pick. The server returns a valid result for a valid call. The answer is internally consistent and externally wrong.
The second failure mode is enum drift. If the schema constrains a metric to a closed enumeration, the model must map free text onto that enumeration. Free-text-to-enum mapping is lossy. "Cash reserves" might map to a metric labeled treasury, which might exclude stablecoin holdings. The model does not know the internal definition. The schema does not carry the definition. The result is precise and mislabeled.
The third failure mode is composition. A single question often requires multiple tool calls, each returning a fragment. The model aggregates fragments in context. Aggregation is arithmetic performed in the token space, where the model does not execute arithmetic reliably. Two correct numbers can be combined into an incorrect ratio. This is the last-mile problem, and I will return to it, but its origin is here, at the tool surface, where the composition step is unconstrained.
The fourth failure mode is silent partial failure. If a tool call fails or returns an empty result, the model may proceed with incomplete data and narrate a conclusion as though the data were complete. MCP has error semantics, but the model's response to an error is a sampled decision, not a protocol guarantee. A pipeline that reports confidently on incomplete data is more dangerous than one that fails loudly, because the failure is invisible to the consumer.
None of these are defects in Blockworks' implementation. They are structural properties of exposing typed data to a probabilistic caller. The vendor cannot fix them at the server. They can only be mitigated at the interpretation layer, which the vendor does not control.
Code doesn't lie; audits do. The retrieval code is honest. The audit that certifies the retrieval as trustworthy is where the deception enters, because the audit stops at the server boundary.
The Schema Normalization Problem
The genuine engineering achievement of this release is not the MCP server. It is the normalization layer beneath it. I want to give credit precisely where it is due, because the difficulty is underappreciated.
Aggregating 400+ DeFi protocols' financial data into a comparable format is a schema reconciliation problem of significant scale. Every protocol reports differently. Some report total value locked as a single number. Some decompose it into collateral and debt. Some report revenue gross, some net of incentives. Some report in native tokens, some in USD at a timestamp, some in USD at a rolling average. To arrange these into an identical format for side-by-side comparison, an engineering team must define a canonical schema, write adapters for every source, and resolve conflicts where sources disagree.
The canonical schema is the moat. Not the data, which is public. Not the MCP server, which is a standard. The schema, and the thousands of adapter decisions encoded inside it, is the durable asset. Anyone can scrape on-chain data. Almost no one will invest the labor to reconcile 400 heterogeneous reporting conventions into one comparable surface.
But the moat has a property that the marketing does not disclose. Normalization is lossy and opinionated. To force heterogeneity into a single schema, the engineers must make definitional choices: what counts as revenue, how to treat double-counted value, which timestamp to trust when sources conflict. Those choices are correct or incorrect relative to a definition, and the definition is not exposed at the tool surface. The model receives a normalized number with a source label. It does not receive the definitional assumptions that produced the number.
This is the second provenance gap. The first gap is that provenance labels the source. The second gap is that provenance does not label the transformation. A number labeled with its origin but stripped of its normalization assumptions is a number that cannot be independently verified from the label alone. The consumer must trust the adapter. Trust, again, is a bug.
I have encountered this exact pattern in circuit audits. When I verified the Groth16 circuits for a privacy lending protocol in 2020, the public inputs were a small, visible subset of the computation. The bulk of the logic lived in the witness, hidden from the verifier. A mismatch in the public input encoding could have allowed a false proof to verify, because the visible surface did not constrain the hidden computation. Normalized data has the same shape: the visible number is the public input, the adapter logic is the witness, and the consumer verifies nothing about the witness.
The Provenance Object and Its Limits
Blockworks returns raw numbers and sources. The answer carries attribution. This is presented as the solution to AI hallucination. It is not a solution. It is a mitigation, and a partial one.
A provenance label is a string. It says where a number came from. It does not commit to the number. There is no cryptographic binding between the label and the value. If the number is wrong, the label is still there, pointing at the source, conferring legitimacy on an incorrect result. The label does not falsify the claim. It decorates it.
Compare this to a cryptographic commitment. A hash commitment binds a prover to a value. The prover cannot later present a different value without breaking the commitment. A Merkle root over a dataset binds the dataset. A verifier can recompute the root and confirm that the data is the committed data. A provenance string binds nothing. It is an assertion, not a proof.
The distinction matters because the consumer's behavior changes. When a user sees a source label, the user relaxes scrutiny. The label is a trust signal. It reduces the perceived need to verify. This is the inverse of what a security mechanism should do. A real verification mechanism demands work from the verifier and returns certainty. A provenance label demands nothing and returns the feeling of certainty. The feeling is not the fact.
The vendor's own framing acknowledges the risk. The published commentary notes that a model can retrieve an accurate number and still report an incorrect result. That admission is the honest core of the release, and it undercuts the marketing. If accurate retrieval does not guarantee accurate reporting, then provenance, which operates at the retrieval layer, does not guarantee accuracy at the reporting layer. The label certifies the input. The output is unlabeled.
A provenance mechanism that does not bind the value, that does not expose the transformation, and that does not constrain the interpretation is not a verification layer. It is a citation layer. Citations are useful. They are not proofs. Zero knowledge, maximum proof: the discipline is to demand proof where the claim is made. Here the claim is made at the output, and the proof is offered at the input.
The Last Mile: Deterministic Retrieval, Probabilistic Synthesis
This is the finding. Everything before is context for it.
A data pipeline has two halves. The front half is deterministic: query in, data out, byte-identical for identical inputs. The back half is probabilistic: data in, language out, sampled and non-reproducible. Blockworks has engineered the front half to a high standard and has no control over the back half. The vulnerability lives exactly at the seam.
I will model the seam as a function composition. Let R be the retrieval function, mapping a query q to a dataset d. R is deterministic and, per the vendor's testing, accurate. Let S be the synthesis function, mapping a dataset d and a question to a natural-language answer a. S is a language model. S is stochastic: the same d and the same question can produce different a across runs. The observable output is S(R(q)).
Provenance attaches to d, the intermediate value. The consumer observes a, the final value. The chain of custody from d to a is a single, opaque, sampled transformation. The consumer cannot audit it. The vendor cannot audit it, because the vendor does not own the model. The model provider cannot audit it in any per-query sense, because the transformation is emergent from weights, not specified in code.
The failure modes inside S are well documented and reproducible. I enumerate the ones that matter for financial data, because financial data has the property that small numerical errors become large decision errors.
One: unit confusion. A dataset reports a value in millions. The model narrates it in billions. The number in the dataset is correct. The number in the answer is wrong by three orders of magnitude. Provenance still cites the source.
Two: temporal drift. A dataset reports a value at timestamp t. The question implies the present. The model answers as though t were now. The retrieval was correct for t. The answer is stale and presented as current.
Three: aggregation error. The model sums, divides, or averages retrieved values in token space. Token-space arithmetic is unreliable, especially across many terms. The inputs are correct. The arithmetic is wrong.
Four: definitional substitution. The model interprets a metric by its common meaning rather than the schema's defined meaning. The number is correct for the schema's definition. The answer is wrong for the user's definition.
Five: selection error. The model chooses among candidate protocols or metrics by a heuristic that does not match the user's intent. The retrieval is correct for the chosen entity. The entity is the wrong one.
Six: confident completion. When retrieval is partial, the model fills the gap from its prior. The prior is not data. The answer blends data and parametric memory with no marker separating them. Provenance cites the data portion. The blended portion is unlabeled.
Each of these is a last-mile failure. Each occurs after the provenance label is attached. Each is invisible to the provenance mechanism. The vendor's mitigation, human review across research analysts, data analysts, and data engineers, addresses the data layer. It does not address the synthesis layer, because the synthesis layer runs on the consumer's model, at the consumer's query time, outside the vendor's perimeter.
I want to be precise about the economic security implication, because this is where the analysis becomes consequential. In a system with a bond, a slashing condition, or a challenge window, the cost of an error is internalized by the actor who causes it. Here, the cost of a synthesis error is externalized onto the consumer, who makes a financial decision on a wrong number, and onto the vendor, whose brand is cited as the source of the wrong number. The vendor bears reputational liability for a failure it cannot prevent. That is a mispriced risk, and mispriced risks are the ones that detonate.
Provenance Without Proof: The ZK Analogy
I have spent the last several years inside proof systems, and the analogy here is exact enough to be diagnostic.
A zero-knowledge proof establishes that a statement is true without revealing the witness. The prover computes a proof. The verifier checks it. The proof is binding and sound: a false statement cannot produce a passing proof, and a prover cannot change the statement after the fact. The verifier does work, small work, and receives certainty.
The Blockworks provenance mechanism establishes that a statement has a source. It does not establish that the statement is true. The prover, here the pipeline, emits a label. The verifier, here the consumer, checks nothing. There is no soundness. A false statement with a valid source label passes. There is no binding. The pipeline can attach a source to any value. The consumer does no work and receives the feeling of certainty.
So the release is a proof system with the soundness removed and the verification removed, leaving only the aesthetic. It looks like verification. It functions as decoration.
This is not a criticism unique to Blockworks. It is the dominant pattern of the AI-data industry. Every vendor adds citations. Almost no vendor adds verification. The reason is economic: verification is expensive and the market has not demanded it. The reason it will be demanded is that the market will eventually price the errors, and when it does, the vendors with real verification will be worth more than the vendors with pretty citations.
What would real verification look like? It would require that the final answer carry a commitment to the data that produced it, that the transformation be reproducible or provable, and that the consumer be able to check the commitment without trusting the pipeline. Concretely: a Merkle commitment over the normalized dataset, a signed attestation over the transformation, and a consumer-side check that the cited number recomputes to the committed value. The technology exists. Merkle trees, signatures, and, increasingly, verifiable computation. The cost is real but bounded. The obstacle is not technical. It is that citations are cheaper and, for now, sufficient.
The DAO was a warning we ignored. In 2016, the contract did what the code said, and the code did not do what the humans meant. The gap between specification and implementation was the vulnerability. Here the gap is between retrieval and reporting, and the industry is repeating the error at a higher layer. The code retrieves what it says. The report does not say what the data means. We ignored the first gap and paid for it. The second gap is larger.
The Economics of Agent-Native Data
The business model is a subscription. API keys gate access. Enterprise customers pay recurring revenue for data depth and breadth. This is a healthy model with real revenue and no Ponzi structure. It is also a model with a structural vulnerability that the release does not address.
The competing model is pay-per-call. CoinMarketCap exposes an MCP server where an agent without an API key pays a micro-fee, reported at 0.01 USDC, per call. The difference is not pricing. It is the identity of the payer. Under a subscription, the payer is a human who holds an account. Under pay-per-call, the payer is the agent itself, transacting autonomously in stablecoins.
The distinction is decisive for the agent economy the release is betting on. An autonomous agent cannot hold a human subscription. It cannot sign a contract or manage a billing relationship. It can hold a wallet and pay per call. If agents become the primary consumers of financial data, as the vendor's own thesis asserts, then a subscription model gates the exact customer the thesis predicts. The vendor is building for a customer its billing model cannot serve.
I have seen this pattern before, in a different domain. In 2024, designing a 5-of-9 threshold custody scheme for an institutional client, the constraint was not cryptographic strength. It was regulatory fit. The scheme had to satisfy compliance while remaining usable by humans who did not understand threshold signatures. The lesson generalized: a system that is technically superior but operationally mismatched to its user loses to a system that fits. Here, the operationally matched user is an autonomous agent, and the operationally matched payment is a micro-transaction. The subscription is the mismatch.
The value capture question follows. Blockworks captures value through data breadth, normalization, and provenance. None of these are network effects. Users do not benefit from other users. The moat is data quality plus migration cost, and both are moderate. Data is public. Normalization can be replicated by a funded competitor. Migration cost is real but not high, because the switching cost for a consumer of an API is a config change, not a data migration. The moat is shallower than the marketing implies.
The durable asset is the compliance product, Agentic Detection. Compliance is a genuine need, high-margin, and resistant to commoditization because it is tied to regulation rather than to data. The data business is the wedge. The compliance business is the margin. The release ships both, and the strategic logic is to use the free-flowing data to sell the regulated monitoring. That is a sound business. It is also an admission that data alone is a commodity.
The Dependency Asymmetry
The ecosystem position is the most under-discussed risk in the release, and it is structural.
Blockworks sits in the middle of a three-layer chain. Upstream are data sources: exchanges, DeFi protocols, on-chain data. Downstream are AI platforms: Claude, ChatGPT, Cursor, and other MCP clients. Blockworks aggregates the upstream and distributes to the downstream.
The upstream dependency is benign. Exchange and protocol data is public. Any aggregator can access it. Blockworks does not depend on any single upstream source for survival.
The downstream dependency is not benign. Blockworks needs the AI platforms more than the platforms need Blockworks. An AI platform can switch data providers with a config change. A data provider cannot switch AI platforms, because the platforms are where the users are. The distribution is owned downstream. The data provider is a replaceable supplier to a concentrated set of gatekeepers.
This asymmetry caps the value capture. A supplier with many substitutes and few buyers has weak pricing power. Blockworks can be the best data provider and still be squeezed by platforms that integrate multiple providers and route between them. The platform captures the relationship. The supplier captures the margin the platform allows.
The ChatGPT listing is the release's most valuable asset and also the clearest evidence of the asymmetry. Being listed as an official application is a distribution win, and it is granted, not owned. The grant can be revoked or replicated. CoinGecko and CoinMarketCap are already listed. The listing is a privilege extended by a platform that controls the channel. When your largest distribution channel is a platform you do not own, your strategic position is rented.
The counter-move is the one the vendor is already making: move up the value chain into compliance, where the buyer is the regulated institution, not the AI platform. Compliance buyers are sticky, contract-bound, and numerous. AI platforms are few and fickle. The vendor that recognizes the asymmetry will migrate revenue toward the sticky buyer. The compliance product is that migration. It is the correct response to a correctly diagnosed weakness.
Vulnerability Forecast
The forecast is a three-part judgment.
First, the deterministic layer is sound and will not be the source of a material failure. The retrieval is accurate, the normalization is defensible, and the provenance is correctly implemented for what it claims. The vendor has engineered the front half well. There is no reentrancy-equivalent in the data layer. No single call returns a corrupted result.
Second, the semantic layer is the vulnerability, and it is unavoidable at the protocol level. The failure will not be a wrong number in the API. It will be a right number in a wrong conclusion, cited to Blockworks, and it will surface as a public incident. The provenance label will be present in the incorrect answer. The label will be read as a guarantee. The guarantee will be false. The reputational damage will be disproportionate to the technical cause, because the brand's entire value proposition is data trust, and trust is exactly what the failure erodes.
Third, the economic layer is where the long-term risk concentrates. The subscription model is mismatched to the autonomous-agent payer the thesis predicts. The micro-payment competitor is better aligned with that payer. If agents become the primary consumers, the subscription gates the customer, and the model that gates the customer loses to the model that serves it. The vendor's best defense is the compliance product, which is aligned with a different, stickier buyer.
The forward question is the one the industry has not answered. When an autonomous agent acts on financial data and the action is wrong because the interpretation was wrong, who is liable? The vendor that provided accurate data with a provenance label? The platform that synthesized the answer? The user who did not verify? The current architecture assigns liability to no one and therefore to everyone, and systems that assign liability to no one do not internalize the cost of their errors until the cost becomes catastrophic. The DAO taught that lesson in 2016. The data layer is teaching it again in 2025. The difference is that this time the error is not in the contract. It is in the sentence the contract's data produced.
The pipeline retrieves correctly. The report lies. The label says trust me. The discipline says verify. Until verification replaces provenance, the industry is building citation engines and calling them proofs.