Every MCP-first search tool in the market — Tavily, Brave Search, Exa, Perplexity, Search1API — does the same thing: they take a query and return a list of documents with snippets. The format differs, but the operation is identical. Query in, documents out.
Alexandria is built on a typed knowledge graph, not a document index. That means it can answer three classes of question that no flat-document search tool can touch.
1. Pathfinding: "How is A connected to B?"
A search engine can return documents about momentum investing and documents about CAPM. It cannot tell you how the two are connected — because the connection exists in the graph, not in any single document.
library_pathfind does a bidirectional BFS through the typed graph and returns the shortest path with labeled hops. The path from "momentum investing" to "CAPM" is 4 hops:
Cross-Sectional Momentum Investing --[uses_dataset]--> Ken French Data Library --[hosts]--> Fama-French Three-Factor Model --[derives_from]--> CAPM (Sharpe 1964) --[introduced_by]--> Sharpe, W. F. (1964). Capital asset prices.
Every hop is typed. Every edge has a confidence rating. The agent gets a connection, not a search results page.
No search MCP can do this. They do not have a graph. They have documents.
2. Comparison: "What is the relationship between X and Y?"
Two papers on the same anomaly. One finds a significant premium, the other finds it disappeared after 2000. A human reads both and synthesizes. An agent using web search reads both, guesses at the relationship, and hopes the context window is wide enough to keep both papers in view.
library_compare takes two entity IDs and returns a structured comparison in one call: direct edges between them, shared neighbors in the graph, belief differences (declared contradictions or outperformance claims), provenance overlap, overlapping tags, and a structured summary. No guesswork. No truncated context.
No search MCP can do this. A comparison requires a graph. Web search cannot compare two results because it does not know which results belong to which paper.
3. Trending: "What are agents asking about?"
Every query to the library is recorded — anonymized, aggregated, never payload content. The telemetry is not just for monitoring. It is a product feature.
library_trending returns the demand map: top requested types and tags, query volume, conversion rate, and the routes agents use most. An agent discovers what other agents need. The operator discovers which knowledge gaps to fill next.
No search MCP can do this. Telemetry is not built into the architecture of web search tools. It is built into the architecture of Alexandria — the tracker is wired into every surface operation at the framework level.
Why the graph matters
These three capabilities exist because the data model is a typed graph, not a document index. Every node has a type, a confidence rating, and provenance. Every edge has a type, a direction, and a confidence rating. The schema is enforced at write time and queried at read time.
The graph model creates a combinatorial explosion of query operations that document search cannot match. Traverse, compare, and pathfind are the first three. The next shelf will add more.
library_traverse (one-hop neighborhood), library_compare (two-entity comparison), library_pathfind (shortest path), and library_trending (demand map) are built and live. Agents query them over MCP or the HTTP API. Documentation is at the API reference.