Overview
Understand priority issues and competitive position.
Understand priority issues and competitive position.
See when models recall, find, and choose a measured product before an agent begins the task.
Bars show the share of answers that selected Northwind. Search-on and search-off answers were measured separately; their difference does not establish the effect of search. Open a row for competitors, rank, and exact questions.
Brand-neutral questions tested four Northwind priorities. Web search frequently reached Early Confirmation Signals, Raw Data Stream Delivery, and Transaction Incentives. Transaction Protection was mentioned often but usually lost the final choice to Competitor B or Competitor C.
This fixed-list diagnostic explains the search result; it is not an overall provider ranking.
Implication: keep Northwind's existing mechanism explanation, but make the exact Transaction Protection page easier to find. It was cited in only 1/18 MEV web-search answers.
The earlier five-need search panel often used Northwind by name. The four growth-product tests above use brand-neutral questions and are the cleaner pattern for future discovery checks.
Use this only as evidence that models verified a known option—not as proof that an unbranded search discovered Northwind.
These arms came from their own controlled design, so they are not the routing results above and must not be read as the same measurement improving.
What moved choices: Transaction Submission API name, signed-transaction action, and explicit routing context—described in the controlled message as validator/Competitor B routing.
Full test result →What moved tool routing: Task, transport, replay window, filters, and delivery behavior.
Full test result →What moved tool routing: Complete transaction objects, pagination, and filters—not only the method name.
Full test result →The tests showed that complete product context can change routing. A fresh source review found the same details already present in current Northwind docs, so the next work is discovery, tool routing, and execution—not adding duplicate copy.
What moved choices: Transaction Submission API name, signed-transaction action, and explicit routing context—described in the controlled message as validator/Competitor B routing.
Current decision: Current docs now describe multi-path routing. Keep that public explanation, then test an unbranded entry path or a bounded non-value-bearing Transaction Submission API action.
What moved tool routing: Task, transport, replay window, filters, and delivery behavior.
Current decision: The docs already contain these facts. Apply them to tool metadata, then test one bounded live subscription and recovery path.
What moved tool routing: Complete transaction objects, pagination, and filters—not only the method name.
Current decision: The method page already has these facts. Test whether entry-page and tool metadata distinguish complete history from signatures-only and transfers-only routes.
These are bounded capability checks. Transaction Submission API broadcasts and Streaming API subscriptions were not included.
Transaction Submission API broadcasts and Streaming API subscriptions were not executed.
Terra and Sonnet completed native-balance and account-inspection actions.