Researchers and students increasingly begin their work in AI assistants, and scholarly publishers are starting to meet them there. On October 5, Silverchair announced a six-month pilot of Research Bridge, a shared Model Context Protocol (MCP) channel through which assistants can reach content from several independent publishers, including Royal Society Publishing, the American Association for Cancer Research, and the Royal Society of Chemistry. It follows announcements of Silverchair’s Discovery Bridge in February, Research Solutions’ Article Galaxy MCP in April, Clarivate’s Nexus Connect later in April, and earlier publisher-built servers such as Wiley’s.

I am excited by what this could make possible. A student or researcher asking an AI assistant a question could be pointed to authoritative content, linked to the publisher’s version of record, with the library’s entitlements enabling access. That moves us toward the goal I care most about with AI tools, shifting the focus from access to information toward comprehension of it.

Getting there requires infrastructure that doesn’t yet exist, including a way for each library to track and organize connectors, help users find them, and tie them to institutional entitlements, plus an automated data feed that keeps library registers current. This problem will not get easier as it grows, because every new connector adds to what someone needs to track. I expect that someone to be the library, since publishers and platforms are not likely to be the place of institutional aggregation and entitlement. 

In this essay, I propose that a library treat MCP connectors (as well as APIs and other endpoints) as a collection, keep a register of them, and expect providers to describe their connectors and metadata in machine-readable form. Libraries and their vendor partners have built the kind of infrastructure this will require before, and I believe we can do it again.

What is MCP?

Clarissa Ihssen, a science librarian at American University, introduces MCP for librarians as “an open-source standard for connecting AI applications to external systems,” a description she takes from the protocol’s documentation. Her essay notes the common comparison to a USB-C port: one standard way to plug AI applications into outside systems. Anthropic released MCP as an open standard in 2024, and by 2025 OpenAI and Google had announced support, effectively making it the common standard for connecting AI applications to external tools.

The impact for scholarly searching is easy to see. Without MCP, a researcher who wanted an AI assistant’s help with a PubMed or Wiley search would typically have had to ask it to draft a search string and then paste that into the database, or write custom code linking that assistant to that database. With an MCP connector, the assistant can query the resource directly. I expect MCP’s effects on scholarly search and discovery to run much deeper than this, but for the purposes of this essay the simplified version is enough to show why libraries need to track MCP connectors and related tools. 

In library terms, a connector is a server that implements MCP. A publisher or vendor runs an endpoint, and a user adds it to an AI assistant. Where content is licensed, the user also authenticates so the endpoint knows what that person may access and read. This analysis extends to any other approaches connecting AI services with scholarly resources, such as application programming interfaces (APIs) and browser-integrated utilities.

The appeal for providers is that one connector can serve any compatible AI assistant, so they don’t need to build a separate integration for each. What is new for libraries is who does the connecting. A database is something the library licenses, configures, and lists. A connector is something a student or researcher can install without the library knowing it exists (unless it requires formal licensing or payment from the library, of course). But how can a library ensure that its users know what they are entitled to use and configure their connectors correctly for that access? 

A Promising, Uneven Landscape

It seems that connectors are appearing in at least four forms, though any attempt at a taxonomy is provisional because the tools are still emerging. 

Perhaps the most familiar approach will be the single-publisher connector, of which Wiley’s AI Gateway was an early example. The Elsevier dataset connectors would be another. 

A second form places several publishers behind one endpoint. Research Bridge does this for its participating publishers. Silverchair’s stated rationale is that a shared channel lowers the effort and cost of participating for independent publishers while raising the value of the channel collectively. What is not yet clear to me is how a library would be able to confirm which of its institutional entitlements such a channel recognizes.

Third are the tool and service providers, whose connectors let an AI assistant search scholarly literature and related research data. Scite’s MCP, Research Solutions’ Article Galaxy MCP, Consensus MCP, and Dimensions MCPs are just some of the possible examples here. They differ in what they add beyond discovery. Services include citation context, article requests, structured outputs such as reading lists, and linking publications with grants and other research outputs for analytics. I anticipate many more will be developed.

Fourth are institutionally based connectors, of which Nexus Connect is an example. Clarivate describes it as an institutional AI gateway, a university-branded layer that applies institutional entitlements and can bring in other providers’ MCP services. This comes closest to the kind of registry I am imagining. Librarians who maintain knowledge bases in their discovery systems will recognize how much this depends on accurate metadata. As these layers emerge, libraries will want to know how they will stay current as providers add new connectors and update existing ones: who supplies the records and metadata, how often, and with what verification?

There are also connectors, such as the Semantic Scholar server whose author states it is not affiliated with Semantic Scholar or this Scopus MCP, that sit in public directories but are not from the content provider or platform itself.

The Missing Infrastructure

With rapidly growing adoption of MCP, I anticipate libraries and their partners will need several infrastructure components.

The first is a way to find the right connectors. A third-party analysis counted more than 30,000 unique servers in the official MCP registry as of September 10, roughly triple the May figure, but the registry’s working group describes it as a metadata catalog that does not rank servers. A catalog that size calls for curation based on entitlement connections and quality evaluation, and libraries are well-versed in that work. AI platforms can build these directories, but they will not know a specific library’s license portfolio, how a user must configure the MCP for access, or which ones update for retractions or show provenance.

The second is a way to tie access to the user’s institutional entitlements. Scite’s guidance for librarians is instructive because it states plainly that institutional access comes through a Scite account rather than the user’s Claude or ChatGPT account. A student who connects without the right account gets the tool, but not the licensed content, and the guidance also notes that ChatGPT connections can silently disconnect. I give Scite a lot of credit for highlighting these issues. Librarians will need to be prepared to assist users with troubleshooting access, and such disclosures make doing so easier. 

The third is usage reporting. COUNTER’s Best Practice on Generative and Agentic AI usage metrics offers the method for providers to report AI-driven usage separately from human use. That is encouraging, but because the method is optional, libraries will need to ask providers to adopt it.

Lessons from the Link Resolver

Libraries and their vendor partners have built this kind of infrastructure before. The link resolver is a useful precedent. Link resolvers depend on knowledge bases, and knowledge bases depend on providers sending accurate holdings data. KBART standardized that exchange, and KBART Automation lets providers send institution-specific holdings via API, aiming to reduce maintenance effort and errors and enable more timely updates than manual processes.

Connectors need the same. 

Here is a starting list that reflects my thinking on the needed elements. I imagine each entry including:

• the provider and the operator, which may differ
• the endpoint and version
• the authentication method
• the entitlements covered
• licensed versus open content
• terms on AI use and training
• privacy and data retention
• usage reporting
• the date last verified

Providers should supply these fields as a feed where possible, as they do for KBART holdings, and the library should be able to verify the data. It’s also worth noting that a single provider may offer more than one connector, so a registry needs to accommodate that. 

And, of course, libraries will also need a way to communicate this information to users – whether through the library catalog, as a stand-alone database, via LibGuides, or some other way. 

Implications

The need for MCP cataloging and discovery has implications across the industry, and each party has a part to play. Libraries are the natural owners of this layer. Librarians will need to decide where responsibility for a register lives, whether in collections, e-resources, discovery, or user services, and to add connector terms to their checklists for license review. They will also publish user-facing documentation that tells students and faculty how to sign in with their institutional account to ensure they are recognized as being entitled to the MCP connector and/or content.

Campus IT will be a necessary partner. Campuses will also have MCP connectors for other kinds of resources and tools, and I expect IT to be involved in how connectors are approved, authenticated, and secured. As is typical, scholarly sources bring particular challenges, including licensed entitlements, publisher terms on AI use, and reader privacy, and these are areas in which librarian expertise is valuable. The library can reinforce its expertise in metadata by stepping up to this registry role for the campus, working with IT so that other scholarly connectors fit the same framework.

Publishers and platforms can make their connectors easy to track by supplying machine-readable metadata and entitlement scope statements, documenting which institutions or users a connector serves, and supporting COUNTER’s Best Practice on Generative and Agentic AI usage metrics. 

AI platforms, for their part, could also create ways for institutions to review and recommend connectors, rather than leaving the choice entirely to individual users.

Where Next?

The approach I sketched above is a starting point and not a finished design. It needs more minds than mine and thorough vetting through a community-engaged process like the ones NISO runs, where libraries, publishers, and technology providers test an idea and refine it together. Others may have additional ideas, and I hope they will share them in the comments. Together we can inform and strengthen the infrastructure this moment needs.

Acknowledgments and Disclosures: I am grateful to colleagues and friends who reviewed drafts of this essay, provided feedback, and helped me clarify my thinking. I used Claude as a conversational interlocutor in developing this essay and Grammarly to polish the writing.