What Changes When an LLM agent Searches Your Library Catalogue?

Part one of a three-part series on home-brew agentic search built with Claude Code and Codex.

Buy me coffee via ko-fi!

Database discovery is one of the areas where library search still often fails students badly.

While discovery layers such as Primo, Summon and EDS have made article discovery more forgiving because users can search across huge article indexes, database discovery remains trickier, especially for novice users. The user has to do more than match a short database description; they often have to guess the right level of description. Search for "autism" and there may be no database with autism in the title or description, even though PsycINFO, MEDLINE, Embase, CINAHL and education databases may be exactly the right places to search. Search for "Rolex watches" and the useful sources are not tagged with descriptions as Rolex databases; they are described as consumer, luxury-goods or market-research databases.

This post is about a small home-brew Primo MCP server I adapted for my institution, and what happened when I tested it against selected zero-result database searches from Primo logs.

The MCP itself is not magic. The useful part is the combination of model knowledge, an iterative recovery loop when no results are found and live institutional grounding, which solves many of the traditional problems less experienced users face when trying to find the right database.

I also ran the same queries through Primo NDE's native Natural Language Search, which converts a query into a single Boolean string, to see how far one-shot query expansion gets without a loop. The answer is: not far.

One thing also worried me, would users using models of differing quality but the same MCP/Skill get exactly the same quality of results? If yes, this might signal a new type of digitail inequality…

Introduction

Over the next three posts I want to work through what happens when you stop treating agentic search as a finished product and start building the pipeline yourself.

If you are unfamiliar with the idea of a MCP server, or the concept of LLMs using tools to search also known as agentic search, refer to the following two articles on MCP servers and the combination of skills and earlier adopter academic search based MCP servers like Scite, Consensus and Pubmed as well as the appendix.

This first post is about a Primo MCP server I vibe-coded for my own institution, and the one problem it solves that article-based MCP servers such as Consensus and Scite cannot touch.

The second is a more personal account of building a PubMed Boolean pilot-testing skill from scratch. The skill is built for high-sensitivity evidence synthesis and runs a tool-assisted loop where it queries PubMed and the MeSH vocabulary iteratively to check controlled-vocabulary headings, harvest their entry terms and synonyms, and generate text-word, proximity and wildcard candidates, then tests each concept block against real hit counts rather than guessing. If you give it known-relevant papers as seeds it checks whether the draft strategy actually retrieves them and diagnoses the misses. It is also wrapped around a very comprehensive set of code-based audit checks and logs that record every "decision" made.

My experience building that skill gave me a rude awakening on the limits of both my knowledge and understanding of coding/agentic flows and my evidence-synthesis knowledge.

The third looks at NUS Researcher - Kenneth Khoo's open-source lit-review-orchestrator skill , which blends Undermind, Google Scholar, Scholar Labs, SSRN, NBER and others with deduplication and validation checks against hallucination.

I have put my own code on GitHub: a Primo MCP server (a fork of geheharidas/primo-mcp-server) and a PubMed search-builder skill for Codex.

Disclaimer, I do not identify as a coder and did not write these for release. The PubMed builder in particular is over-engineered and will burn a lot of tokens. Use them at your own risk, and assume anyone with real coding or evidence-synthesis expertise could do better. Expect non-trivial token use particularly for the PubMed search-builder skill for Codex or the lit-review-orchestrator skill , and it will be taxing on token limits if you are on the lower paid tiers e.g. GPT Plus or Claude Pro.

The problem: database discovery and the zero-result search

Selecting the appropriate database has always been a challenge for inexperienced users. This difficulty stems partly from users having varying expectations of what a database entails and using inconsistent terminology to describe them1.

Furthermore, a user's search terms must align precisely with brief database descriptions. Even when these descriptions are carefully curated, rather than relying on promotional vendor language, users must still formulate the exact matching keywords.

Then there is the granularity problem. A user searches "autism", expecting a dedicated database, and gets nothing, because the right targets sit a level up: MEDLINE, Embase, CINAHL, PsycINFO. The only reliable way to know that mapping has been experience.

Discovery layers such as Summon, Primo and EDS largely solved this for articles by letting users search across every article at once. But they did not solve it for data series and datasets, which in my institution means business, finance and economic sources.

The granularity problem bites harder there, because a description for something like MarketLine or Capital IQ is necessarily generic. MarketLine might be described as having coverage of fast-moving consumer goods including brand share and company share, which is no help to a user who searches directly by name for one specific product (e.g. Watches).

The fallback is to filter the A-Z list by subject and read each description, or to ask someone with experience. Neither is ideal.

A dedicated sub-genre within Library and Information Science literature has investigated this issue for nearly twenty years. As of 2026, the most recent contribution to this discourse is the article Improving Database Discovery and Understandability by Identifying and Reducing A–Z List Jargon

Can this problem be reduced? My exploratory tests suggest yes, and more than I expected. A capable Large Language Model integrated with a library catalogue search or "agentic search" may have the potential to resolve the majority of database discovery issues!

Why I almost did not build this

When Claude Code use went viral last year, early-adopter librarians told me they had built MCP (model context protocol) servers against their catalogues. MCP has rapidly become a widely supported connector standard, including support in major AI applications such as Claude and ChatGPT.

I use catalogue and discovery layer interchangeably here, because like most academic libraries we run a system with local records (Alma) alongside a central index of content (Primo), and the MCP server is capable of searching both.

I almost did not bother. Clarivate has an official Primo MCP on the way2, and I assumed that made a home-brew version pointless.

(Disclosure: I sit on Clarivate's Academia AI Advisory Council. Ex Libris, which makes Primo and Alma, is a Clarivate company, so that disclosure covers the Primo discussion throughout this post.)

I had also the idea that, without much in the way of special collections, my institution would not get the kind of useful results the University of Toronto Libraries reported when they connected their Primo and special collections.

A colleague in our Campus IT group, who works on integrating academic MCP servers (e.g. Consensus, Scite MCP) into our internal secure LLM sandbox, sent me a link to this open-source Primo MCP repo.

Out of curiosity, I cloned it, asked Codex to adapt it for our institution, and it did so easily.

One thing I realised quickly, I had assumed you would need a Primo API key3 for most of what I wanted (and I was lazy to go get access), but this was not true for most functions4.

I was dissatisfied with the original functionality while the initial version returned a title and an Alma record ID, requiring the user to manually request a lookup of the Alma record. This workflow was highly unintuitive. My revised iteration automatically constructs a direct link to the Primo record instead.

I also hardened it to handle non-English characters and to stop the more eager and more powerful models from trying to re-confirm holdings against our LibGuides, which are often out of date. I was vibe coding almost the whole way: run it, look at what broke, ask Codex or Claude to fix it. My next post goes into that experience properly.

Testing against Primo Zero Search Results

Primo logs the search strings that return zero results, usually because a user has too many filters on, or has pasted a long string from a website.

I ran LLM+ Primo MCP or the agentic setup against our institution's 2023 zero-result database searches. To simulate database-finding, my query template was "search for a database in Primo for X".

These tests should of course be taken with a pinch of salt. I used selected, non-random examples from 2023 zero-result database searches, and I tested them with 2026 models. Using modern models with up-to-date pretrained knowledge usually doesn't make a difference but sometimes it does. In the "Refinitiv" example especially, a current model may know the LSEG rebrand in a way a 2023 user, and perhaps a 2023 model, would not. The results are therefore best understood as exploratory demonstrations of failure recovery when searching for databases.

First, I observed a surprising number of queries from users mistakenly searching for journal articles rather than databases.

In the example below, a user searched for the Harvard Business Review article "Why It's So Hard to Be Fair" in the database search! Because my custom MCP is instructed to automatically pivot to an article search when necessary, it located the item seamlessly. Furthermore, even if the system had strictly adhered to the instruction to search only for databases, it would have iteratively adjusted its strategy upon receiving zero initial results.

While one might argue that a human user could independently recover and adjust the search scopes, the system also manages misspellings effectively. In the example below, the Large Language Model, equipped with the Primo MCP, correctly determined that the query "statis" was intended to retrieve the database "Statista".

Consider a more complex example: a search query for the misspelled term "refinituv". A finance or business librarian would easily recognise that the user intends to search for Refinitiv.

However, even when the intended term is successfully identified, an additional challenge remains. The Refinitiv brand in 2026 no longer exists following an acquisition in 2021 and rebrand in 2023, and the service is now known as LSEG.

The previous example is notable; without such intervention, many users would likely abandon their search upon encountering a zero-result screen. (This is the clearest case of the 2023-query, 2026-model problem I flagged earlier, so treat the Refinitiv win with that caveat.)

Returning to the earlier scenario of a user seeking databases for articles on "autism", the initial direct search for that specific term yields no database results.

Although not depicted in the screenshot below, the system subsequently broadens the search scope. It automatically executes queries using wider disciplinary terms such as "psychology", "medicine", "disabilities education", and "special education". This iterative process successfully retrieves relevant scholarly databases, including PsycINFO, Education Research Complete, and SocINDEX with Full Text.

Next, consider a search for statistical databases. An initial query for the specific phrase "cost of living" databases yields zero results, as the Large Language Model found out. However, the system successfully retrieved relevant resources by iteratively searching for related economic terms, such as "inflation", "household expenditure", and "consumer prices".

Now consider a query for a "top music service platform in SEA". The system makes an informed deduction that databases such as Statista or Euromonitor Passport are likely to hold relevant data and avoid zero results.

Similarly, if a user requests databases concerning "Rolex watches", the system recognises this topic falls under consumer and luxury goods. Rather than returning zero results, it recommends suitable platforms such as Statista or Passport.

As demonstrated previously, when direct queries fail, the system automatically broadens the search scope to wider categories such as "luxury goods" or "consumer statistics".

An interesting observation is that in addition to expanding query terms using synonyms or shifting to less granular concepts, the Large Language Model sometimes directly searches for a known, relevant database. In the example below regarding CEO compensation, it explicitly searches for ExecuComp (a well known database with compensation data) alongside the standard keywords.

Finally, if a user queries a database to which the library lacks access, the Large Language Model replicates standard reference practices by suggesting viable alternatives. For example, a search for Hoover's prompts the system to recommend comparable databases such as Orbis or S&P Capital IQ.

So far, hooking an LLM up to catalogue search looks very promising for database discovery.

In fact, you don't necessarily need to even have a Primo MCP server. Our current, test library chatbot was fixed up with a csv file of subscribed databases, including titles, descriptions and when given access, the LLM was able to duplicate most of the results above!

This tells you something interesting. The intelligence is not mainly in Primo, nor even in MCP (since I did not put in the knowledge in the prompt). It is in the combination of model prior knowledge, an iterative search loop, and local grounding. The model supplies the likely mapping from topic to database category. The loop tests and recovers from failed searches. Primo or a CSV confirms what the institution actually licenses and provides grounded titles and links.

So what does the MCP (or even access via command line API) buy you over a CSV of database holdings?

Firstly, the CSV of database holdings cannot fall back to an article search when the user is really after a paper. Secondly, only the Primo MCP server can check live against what is currently in Primo rather than a static export.

How it compares with Primo NDE Natural Language Search (NLS)

In "The Horseless Carriage of AI Search" I argued that using an LLM only to generate nested Boolean is of little benefit on its own. I did allow that it helps novices who would otherwise get zero results, but I assumed that was rare for article searches, given we now search hundreds of millions of articles with full text. For database-scoped searches it is not rare at all to get zero results with the wrong query terms, so this is a fair place to test the Boolean-generation approach directly.

For those not familiar, Primo NDE's Natural Language Search (NLS) converts a natural-language query into a nested Boolean search, like Primo Research Assistant5 though unlike the latter, it does not generate direct answers using retrieval augmented generation.

Compared to hooking up a LLM with Primo MCP server or agentic search, Primo NDE's NLS cannot iterate, but it can add synonyms (aka do query expansion with synonyms) and I was curious how far (if at all) it would fall short from the performance of agentic search which could iterate queries.

To make it fair, I set Primo NDE NLS to "show results from databases"6.

As you will see, unfortunately Primo NDE's natural language search performs far worse than LLM + Primo MCP because it is just a one-shot static mechanism that is unable to iterate, pivot to broader terms or "read the room".

1. Article title in database scope: fails.

When users type in article queries and filter to databases, Primo NDE NLS will give zero results, this is unlike an LLM equipped with a Primo MCP as seen earlier. This is expected I guess.

2. Misspellings such as "Statis" and "refinituv": mostly succeed.

In general, the natural language search within Primo NDE successfully processed the misspelled queries I tested, such as "statis" and "refinituv".

The screenshot below shows the expanded search query.

While this looks promising, more complex errors may require iterative attempts by a Large Language Model to resolve correctly; in such instances, the single-shot natural language query expansion within Primo NDE may prove insufficient.

3. Over-specific or wrong terms such as "autism", "cost of living", "Rolex watch": mostly fail.

Consider scenarios where users employ overly specific terms to search for databases, such as "autism", "cost of living", or "Rolex watches". The natural language search feature within Primo NDE largely failed to resolve this issue through query expansion of synonyms.

Below are the expanded queries generated by Primo NDE NLS:

For the query "autism", the expansion was:

(autism) OR (autistic disorder) OR (ASD) OR (autism spectrum) OR (neurodevelopmental disorder) OR (pervasive developmental disorder).

This expansion retrieved zero results. In contrast, the agentic search combining a Large Language Model with the Primo MCP successfully identified the need to use broader disciplinary terms. The Primo NDE natural language search appears constrained to strict synonym expansion, which is ineffective for this retrieval problem.

Similarly, the query for "Rolex watches" generated this expansion:

(Rolex) OR (Rolex watch) OR (luxury watch) OR (Swiss watch) OR (wristwatch) OR (timepiece).

This search was also unsuccessful. Without a Large Language Model to shift the search to broader categories such as "consumer goods" or "luxury goods", the system could not identify relevant databases.

Other queries avoided zero-result outcomes, but the retrieved databases lacked relevance. For example, the "cost of living" query expanded to:

(cost of living) OR (living costs) OR (costs of living) OR (living expenses) OR (household expenses) OR (cost of life).

Although this prevented an empty results page, the only database surfaced was Gartner, which is inappropriate for this topic.

Finally, the query for a "top music service platform" resulted in a similarly limited synonym expansion:

(music service) OR (music platform) OR (streaming service) OR (digital music) OR (music app) OR (online music).

While the results were non-zero, they did not seem as relevant as when a LLM equipped with a Primo MCP search could do.

Finally, for the query "CEO compensation", the expansion generated was:

(CEO Compensation) OR (Executive Pay) OR (Chief Executive Officer Salary) OR (Executive Remuneration) OR (Corporate Leadership Compensation) OR (Top Management Pay).

In this specific instance, the expanded keywords were sufficient to retrieve several relevant databases directly. Nevertheless, the overall results remained inferior to those obtained when a Large Language Model actively directed the search strategy.

4. Databases we do not license, such as Hoover's: fails

Lastly queries for databases the library does not license, such as Hoover's, were of course unsuccessful when using Primo NDE NLS. In contrast, the combination of a Large Language Model and the Primo MCP successfully suggested viable alternatives.

Primo MCP (Agentic Search) vs Primo NDE Natural language search (Simple Query expansion)

Evidently, the only scenario where the natural language search within Primo NDE performs comparably well is in resolving misspellings, for example, correcting "statis" to "Statista". It achieved only partial success when incorrect keywords were used, provided the query did not require a significantly broader search scope.

There are three primary reasons why the Primo natural language search underperforms compared to a fully agentic search strategy:

1. The Large Language Model deployed within the Primo NDE NLS system is less capable, than the LLM I was using in Codex (as I was using the frontier GPT-5.5 at extra-high effort).

2. The system does not permit iterative searching; it is restricted to executing a single Boolean query.

3. The embedded Large Language Model is highly constrained, likely programmed strictly to construct Boolean strings. Conversely, an agentic model possesses the flexibility to react contextually, for example, by recommending alternative databases when the requested resource is unavailable or searching at a broader level when necessarily (e.g. "Consumer goods" vs "Rolex watches")

A weaker model may contribute, particularly as Ex Libris tends to deploy more economical models under an "environmentally friendly" banner, but I think the second and third reasons do most of the work, and I have evidence for that below.

How much does the capability of the Large Language Model using the Primo MCP affect the quality of the results?

Although the library can provide access to the MCP server or skill to all users, individuals may not be utilising the same Large Language Model. Users with access to premium models, which possess larger context windows, more extensive pre-training knowledge, and longer inference times, might obtain better search results than those relying on free models, despite using identical MCPs or skills.

You might expect that users on premium models, would get materially better results than users on a free model, even with the same MCP. I expected that too. It is not what I found.

I reran the queries in this post with GPT-5.4-mini-low-effort in place of my usual GPT-5.5-extra-high, a far cheaper and weaker configuration. The difference in output quality was usually negligible. My first instinct was to wave this away as my queries being too easy, and that may be part of it.

But this is some evidence that model tier is not what matters - where instead the work is being done by the loop, by the model's freedom to broaden a concept, shift granularity and suggest alternatives, even for the weaker models!

It also sharpens the earlier Primo NDE NLS comparison. If a low-effort model does fine inside the agentic setup, then the gap against Primo NDE NLS is less likely to be about NDE NLS running a weaker model. It is about NDE being unable to iterate and being boxed into Boolean7.

Caution needed

So far, I have been very optimistic on the impact of agentic search by hooking up LLMs to Primo MCP.

But what about hallucinations or ghost references? The MCP server uses code, not an LLM, to fetch record metadata from the Primo API. Titles are taken from Primo's display fields, descriptions are taken from Primo description or abstract fields, and record links are deterministically constructed from the Primo record ID and configuration. So the data handed to the model is strongly grounded, and the risk of a completely invented database or citation is much lower than in an unguided LLM answer.

But grounded retrieval is not an end-to-end guarantee. The grounding holds at the point of retrieval and formatting. After that, the model still has to read the tool output and write the final answer, and nothing in my current setup forces the final answer to contain only fields returned by Primo. The constructed links are useful for checking, but I do not currently live-validate each generated Primo UI link before returning it. Nor do I currently enforce fidelity through validation hooks or a structured-output pipeline. '

Holes in LLM knowledge

Also LLM + Primo MCP works so well because it is like asking a experienced librarian or researcher who has read a lot of libguides and is knowledgeable about the different types of databases.

This is partly a function of the model's pretraining. LLMs can often map autism to PsycINFO, Refinitiv to LSEG, or Rolex watches to consumer, market-research, and luxury-goods databases because these associations are well represented in public web data, vendor pages, library guides, and other documentation likely to have appeared in training data. Famous, well-documented databases therefore benefit from a kind of ambient public knowledge.

The limits show up when the relevant knowledge is not public, even for well-known platforms. Finance databases are a good example, where a lot of information is behind paywalls. An LLM may know, at a general level, what Bloomberg, WRDS, Fitch Connect, LSEG Workspace, or similar platforms are for which supplements the brief database description record. But it will usually not know the precise coverage, field names, dataset quirks, historical availability, entitlements, or institutional configurations unless that information is publicly documented or exposed through the local system.

This matters for highly specific questions: for example, "Where can I find variable Y for 2005–2020 for this set of companies, equities, or countries?" is still a question beyond what a Primo MCP server can answer reliably from discovery-layer metadata alone and where a specialist finance librarian will be superior.

The model may make an intelligent guess on potential places to try, and often that guess will be useful8, but it is not the same as querying WRDS, Bloomberg, or another specialist platform directly. (Also see how finance databases and platforms like Bloomberg, WRDS, Fitch Connect are adding AI)

It is also why I worry if the approach will be biased against niche, regional, newly-licensed or even unique databases that are thinly represented online.

A CSV of database holdings or a well-grounded MCP can put an obscure database in front of the model, but if the model has no pretrained sense of what that database is for, it will not know to reach for it as often. Prompt and instruction tweaks in the MCP or skill help, and fine-tuning would help more, but I would not assume the autism-to-PsycINFO magic transfers to a database the open web has barely heard of.

[Optional] With Agentic Search is lexical keyword search all you need?

One thing I noticed in testing the LLM + Primo MCP server is that it can get surprisingly good results through iterative keyword searching. The model searches, inspects the returned records, reformulates the query, broadens or narrows the topic, and tries again.

Does that mean semantic search, in the form of dense embeddings, or hybrid search combining lexical and semantic retrieval, is unnecessary?

I do not think so. We have learnt that lexical search can be much more powerful when placed inside an agentic loop than when exposed directly to a novice user.

This matters for library database discovery. A student searching for "Rolex watches" may not know to search for luxury goods, consumer behaviour, market research, retail, Euromonitor, Mintel, or Passport. A simple Primo search box may fail because the user does not know the right vocabulary. But an agent can supply some of that missing vocabulary, try related terms, inspect live institutional records, and recover from zero-result searches.

But that does not mean the agent could not do even better if given richer retrieval tools.

This question echoes a wider debate in the agentic-search world. In discussions of Claude Code, Anthropic's coding agent, Boris Cherny and others have described its agentic search as relying heavily on simple tools such as glob and grep rather than a local vector database. The argument is that for code, grep is fast, exact, deterministic, works on the current state of changed files (no indexing needed), and fails visibly when there is no match. Vector retrieval, by contrast, can suffer from the need to constantly index content, chunking problems, and plausible but wrong matches.

But that does not prove that grep, or lexical search methods like BM25, are always enough. It proves that the retrieval method cannot be judged apart from the harness around it. A model that can search, read, retry, and validate results is using search differently from a human typing one or two keywords into a box.

In fact, the industry debate has not settled on "lexical beats semantic" even for agentic search. Cursor, for example, argues that semantic search significantly improves coding-agent performance, especially over large codebases.

In non-code areas, BrowseComp-Plus (a very difficult search benchmark) shows that GPT-5 with BM25 already performs surprisingly well, but that stronger retrievers can substantially improve performance.

With GPT-5, BM25 already performs surprisingly well, but replacing BM25 with Qwen3-Embedding-8B improves accuracy from 55.9% to 70.1%, while also improving recall and slightly reducing search calls. Later reported results suggest further gains from multi-vector retrievers and better harnesses, with some GPT-5-based systems reported in the high 80s and some social/leaderboard reports claiming around 90%.

More modern thinking goes beyond simplistic lexical vs semantic search debates and argues that agents are a new kind of search user and require a rethinking of the interface offered. Human search infrastructure was designed around short keyword queries and top-ten snippets. Agents issue long, structured, multi-turn queries and may need retrieval systems that expose exact matching, semantic matching, filtering, scoring, and structured result handling.

Doug Turnbull another industry retrieval expert also argues for less emphasis on vector embeddings as similarity is not always the same as relevance and argues that semantic search can also come from taxonomies, managed vocabularies, structured attributes, synonym systems, classification, and domain-specific representations.

Doug Turnbull's likes to argue that RAG and agentic search are better understood as query-understanding and corpus-manipulation problems. Embeddings are useful, but users often need systems that translate natural language into domain-specific selectors, taxonomies, filters and ranking signals. In that sense, agentic search is a fat pipeline problem: the agent needs search tools, structured metadata, query reformulation, result evaluation, fallbacks and feedback loops, not just a vector database.

Turnbull's more recent framing is especially helpful. He suggests that improving "agentic search" can mean three different engineering strategies:

Retrieval-centric: build better search so the agent gets better context. This includes BM25, vector search, hybrid search, reranking, metadata, diversity and query understanding.

Harness-centric: keep the retriever relatively simple, but improve the agent loop around it. The harness makes the agent search, inspect, judge, retry, use feedback, follow query plans and recover from bad initial results.

Model-centric: train or fine-tune a model to become better at searching a specific corpus and using specific retrieval tools, so that efficient search behaviour is learned rather than repeatedly rediscovered.

The lesson is not "keyword search is all you need". The lesson is:

A keyword-oriented Primo search endpoint can become much more useful when wrapped in an agentic loop that performs query reformulation, subject broadening, result inspection, grounding and failure recovery.

For academic database discovery, that is an important result. It suggests that some failures of library discovery are not only retrieval-engine failures. They are also interaction failures: the user has to know the right vocabulary, the right subject level, and the right kind of source before the search system can help them.

Agentic search changes that interaction, but it does not remove the need for better retrieval. The serious design question is where to invest next: improve the retrieval layer, improve the agent harness, or eventually train models that are better at searching local institutional systems.

Buy me coffee via ko-fi!

Appendix

Connecting a Large Language Model to Your Library Catalogue or Discovery Layer

When I first wrote about Model Context Protocol servers in December 2025, I focused on connectors that allowed Large Language Models to search article sources, including PubMed and the Wiley AI gateway. For those unfamiliar with the concept, a Model Context Protocol acts as a bridge that a Large Language Model uses as a tool to access external data sources. This protocol has now become a standard supported by all major artificial intelligence laboratories.

My February 2026 article provided an update, discussing the importance of combining custom skills with these protocols and outlining the common academic servers available at the time. Currently, institutional support for these servers is rapidly accelerating. Below are examples of official connectors that have been released or announced:

Startups

• Consensus

• Scite.ai

• SciSpace

• Elicit

Publishers and Legacy Vendors

• Statista

• Wiley

• Clarivate (announced)

• EBSCO (announced)

With the exception of Statista and Clarivate, nearly all the listed servers connect specifically to journal articles.

Disclosure: I am currently a member of the Clarivate Academia AI Advisory Council.

Clarivate has a complex strategy for supporting Large Language Models. Their first initiative is Nexus Extend, a browser extension that activates when users visit specific domains associated with tools such as ChatGPT and Claude. Clarivate describes the tool as follows:

Nexus Extend is a browser extension that operates across AI chat tools and web pages. It detects scholarly context, verifies citations and connects users to library resources — working at the browser level, regardless of the underlying platform. It is primarily designed for access, verification and surface-level discovery.

At its most basic level, the extension scans for DOIs within the outputs of Large Language Models and overlays them with links to full-text access. This is a feature that Third Iron's LibKey Nomad also supports. However, Nexus Extend appears to offer additional functionality. It suggests alternative scholarly resources, draws information from platforms such as LibGuides, and allows users to validate whether the cited references genuinely support the generated text.

Regarding protocol support, Clarivate appears to have broader ambitions with their "Nexus Connect" concept. My understanding is that they are positioning Nexus Connect as a unified gateway to multiple academic sources. Instead of users installing individual connectors for publishers such as Wiley, SAGE, or Taylor & Francis, librarians would configure a single institutional connector. The user would then select this unified connector to search across various publisher platforms simultaneously.

It remains unclear whether other publishers will support this unified approach. At a minimum, we expect Clarivate to release dedicated Model Context Protocol servers for Primo and Web of Science.

A note on MCP versus direct API

One technical point, there has been steady pushback on use of MCP servers as inefficient connectors, with the argument that connecting to sources via a command-line interface or API directly is often simpler and uses fewer tokens. I have found that to be true in practice, and my PubMed search-builder is a skill that calls the NCBI API directly rather than using the MCP protocol at all to access Pubmed as I have found such MCP servers to be often buggy and are not designed for my use case in mind. In any case, many of the unofficial "MCPs" floating around, e.g. for OpenAlex or Semantic Scholar, are really just API wrappers, and with current coding models they are trivial to produce to support your own use case.