MCP Connections: Turn Your Live Data into a Conversational Experience

Publishers sitting on live data can now connect it directly to their on-site AI agent through MCP, the Model Context Protocol. Instead of answering only from published articles, the agent calls your systems in real time and answers with the actual number: the current score, the shot map, the last traded price, the fixture that hasn't been written up yet. For a sports site, that means a reader can ask "what's the score?" mid-match and get it. For a financial publisher, it means "how has this stock moved since the results?" is answered from the price feed, not from a story filed three hours ago. The data you already license or produce becomes an interactive product surface rather than a widget the reader scrolls past. And if you do not have an MCP server yet, you do not need to build one first: GenDiscover will expose your existing feeds, APIs and databases as an MCP service for you.

The Data Most Publishers Are Already Paying For

Data-rich publishers are unusual among media businesses: they spend real money on information that never appears in an article. A sports network licenses a full Opta or Sportradar feed and publishes a fraction of it. A financial title pays for market data, fundamentals and filings, and surfaces a price ticker. A property portal holds every listing, every sold price, every price change. A B2B publisher maintains a database of companies, deals or regulatory filings that took a decade to build.

That data usually reaches the reader in one of two shapes. Either it sits inside a static page, a league table, a quote page, a stats tab, where the reader has to know what they're looking for and how to navigate to it. Or it is compressed into prose by a journalist, which means it is accurate at the moment of publication and stale shortly afterwards.

Neither shape matches how readers actually ask questions. A reader does not think "I need the expected goals tab." They think "was that a deserved win?" They do not think "open the fundamentals page." They think "is this expensive compared to the rest of the sector?" The gap between how the data is organised and how the question is asked is where the reader leaves and asks something else instead.

What MCP Is, in Publisher Terms

The Model Context Protocol is an open standard for connecting AI systems to external data and tools. Rather than each AI product inventing a bespoke integration for each data source, MCP defines a common way for a data provider to expose a set of callable tools, such as get_live_match, get_player_stats, get_quote, search_listings, and for an AI agent to discover those tools and call them with arguments.

For a publisher, the practical consequence is that your data no longer needs to be pre-rendered into a page for the agent to use. You expose an MCP server, the GenDiscover agent connects to it, and during a conversation the agent decides when a question requires live data, calls the right tool, and answers using what comes back.

This is a different mechanism from retrieval over your archive, and it is worth being precise about the difference. Retrieval is good at "what has this publisher written about the manager's tactical setup?" It is structurally incapable of answering "what's the score right now?", because the answer does not exist in any document. MCP covers the second case. Most good publisher agents end up doing both in the same answer: the live number from the feed, the context and analysis from the archive, with links back into the site.

Why Not Just Let the Agent Read the Page?

The common workaround is to point the AI at the rendered page, or at a JSON endpoint someone exposed years ago, and hope it parses correctly. This breaks in the ways you would expect. Pages change, the scraper silently starts returning the wrong element, numbers get misread, and the agent has no way to know it is wrong. It is also limited to whatever is on the page the reader happens to be on.

An MCP tool is a contract. It has a name, a description, typed parameters and a defined response. The agent knows what it can ask for and what it will get back. When a tool call fails or returns nothing, that is an explicit result the agent can handle, by saying it doesn't have the data, rather than by inventing a plausible-looking number. For any publisher whose credibility rests on accuracy, that distinction is the whole argument.

What This Looks Like for Readers

Sports Media: Live Scores and Match Stats

A reader lands on a match preview twenty minutes after kick-off. Today, that page is already wrong, and the reader bounces to a scores app.

With an MCP connection to the match feed, the conversation goes differently. "What's the score?" returns the live score and the minute. "Who scored?" returns the goalscorers and assists. "Has he been that good all season?" pulls season-to-date numbers from the stats tool and pairs them with the profile piece your writer filed in August. "How does this compare to last season's run-in?" combines historical data with your own archive coverage.

The reader gets the score and stays on the site for the analysis, which is the part a scores app cannot provide. The commercially important detail is that each answer is an opportunity to link to your reporting, not away from it.

Financial Media: Prices, Filings and Fundamentals

A reader finishes an earnings story. The obvious next questions are quantitative: where is the price now, how does that compare to the last four quarters, what is the sector doing, what did the filing actually say on margins.

With quote, fundamentals and filings tools connected, all of those are answerable in the flow of the conversation, with the article the reader just finished providing the interpretation. "Is this cheap?" becomes a real answer, a live multiple against sector and historical ranges, rather than a link to a pricing page. Compliance-sensitive publishers can constrain the agent to factual retrieval and explicitly refuse anything that looks like advice; the tool boundary is where that rule is enforced.

Everything Else

The pattern generalises to any publisher whose value is partly in structured data:

• Weather and environment: current conditions, forecasts and historical comparisons alongside the story.
• Property: live listings, sold prices and local price trends in response to "what does a three-bed go for in this postcode?"
• Travel: live availability, routes and prices attached to destination coverage.
• Automotive: specs, trims, running costs and valuations attached to reviews.
• B2B and trade: your proprietary deal, company or regulatory database, which is usually the single most valuable asset the business owns and the one most tightly locked behind a navigation menu.
• Local news: council data, school results, crime and transport figures for the reader's own area.

In every case the reader is asking a question your organisation can answer better than a general-purpose chatbot, because the general-purpose chatbot does not have your feed.

How the Connection Works

The flow for a single question is short:

1. The reader asks a question in the agent embedded on your page.
2. The agent determines whether the question needs live data, archive content, or both.
3. If it needs live data, it calls the relevant tool on your MCP server with the arguments it inferred from the question and the page context, for example the match ID or ticker from the article.
4. Your server responds with structured data.
5. The agent composes the answer, combining the live values with archive context, and cites the articles it used.

Setup is a configuration task rather than an engineering project, assuming your data is already behind an API. In the publisher dashboard you register your MCP server endpoint and its credentials, choose which tools the agent is allowed to call, and describe each one in plain language so the agent knows when it is appropriate. Descriptions matter more than people expect: "returns the live score, minute and goalscorers for an in-progress match" produces better tool selection than "match endpoint."

If You Don't Have an MCP Server, We'll Build It

Most publishers do not have an MCP server today. That is not a blocker, and it is not a project you need to put on next year's engineering roadmap. Exposing your data as an MCP service is something GenDiscover does for you as part of onboarding.

What that involves in practice:

• We start from what you already have. A REST API, a GraphQL endpoint, a data warehouse table, a nightly export, a licensed vendor feed such as Opta, Sportradar, Stats Perform or a market data provider. Any of these can sit behind an MCP service without changing the underlying system.
• We design the tool surface with your team. This is the part that decides whether the experience is good. We work out which questions readers actually ask, map those to three or four well-scoped tools, and write the descriptions and parameter schemas the agent uses to choose between them. A well-designed tool surface beats a complete one every time.
• We handle hosting, caching and auth. The service can run on GenDiscover infrastructure or in your own environment, whichever your security and data licensing position requires. Credentials to your upstream systems stay scoped to the service, and caching policy is set per tool so a live score and a reference table are not treated the same way.
• We test it against real reader questions before it goes live, using the question data your agent has already collected, so you can see what the agent will say before readers can.

The output is a standard MCP service, not a proprietary integration. It is yours. The same service that powers your on-site agent can be pointed at your apps, your newsroom's internal tools, your customer support agent, or, if you choose to, external AI assistants and partners under your own terms and rate limits. Publishers increasingly want a single, governed way to expose their data to AI systems rather than a different one-off integration per partner. That is precisely what an MCP service is, and building yours to serve the on-site agent gives you that asset as a by-product.

If your team would rather build it in-house, that works too: wrapping an existing API in an MCP server is typically a small amount of work, off-the-shelf MCP servers already exist for several common sports and market data providers, and we will review your tool design and test against it either way.

Guardrails Worth Setting Before You Launch

Licensing. Most data contracts specify where and how the data may be displayed. Conversational delivery on your own site is usually covered by the same terms as on-page display, but it is worth confirming with your provider before launch, particularly for real-time feeds and for anything the agent might restate in aggregate.

Rate limits and cost. Conversational traffic is spikier than page traffic, and a big match or a market event will concentrate it. Cache tool responses on your side with a TTL that matches how fast the data actually moves: seconds for a live score, minutes for a quote, hours for standings, a day for reference data.

Scope. Expose a small number of well-described tools rather than your entire API surface. Every additional tool makes selection harder and widens what the agent can reach. Start with the three or four questions readers actually ask most.

Honesty when data is missing. Configure the agent to say it does not have a figure rather than to approximate one. A reader who is told "I don't have that" trusts the next answer. A reader who catches one invented number stops trusting all of them.

Personalisation and privacy. Tools that return reader-specific data, such as a saved portfolio or followed teams, should authenticate the reader rather than accept an identifier from the conversation. Keep that boundary on your server.

The Business Case

The engagement argument is the same one that applies to on-site AI generally, and which we covered in detail in our piece on reducing bounce rate on news websites: readers who ask a question stay longer, read more articles per session and convert at higher rates than readers who are handed a row of related links. Live data sharpens it, because data questions are the ones readers most reliably leave the site to answer elsewhere. Every score check that happens in your agent instead of in a scores app is a session you kept.

There are three further effects specific to data:

It differentiates you from general AI assistants. As search referrals continue to decline, the publishers with the strongest position are the ones holding something a general model cannot synthesise. Proprietary live data is exactly that. An assistant trained on the open web cannot tell a reader what your feed says right now.

It creates a reason to come back directly. A reader who learns that your site answers their stats questions returns to your site to ask them, rather than arriving sideways from a platform.

It produces demand signals you cannot get anywhere else. The questions readers ask of your data tell you which players, tickers, postcodes or companies your audience cares about this week, in their own words. That is editorial planning input, product input, and, for AI-native advertising, targeting input that no third party holds.

Where GenDiscover Fits In

MCP connections are available now for publishers running the GenDiscover Discovery Agent. If you already have an MCP server, adding a connection is a dashboard configuration: register the server, select and describe the tools, set caching and fallback behaviour, and test against live questions before enabling it for readers.

If you don't, we build it with you. Tell us what data you hold and how it is currently accessed, and we will design the tool surface, stand up the MCP service, and connect it to your agent. Publishers typically go from first conversation to readers asking live data questions in a matter of weeks, not quarters.

If you are not running the agent yet, the free tier gets it embedded on your site with a JavaScript snippet, giving you AI Ask, AI Chat, contextual recommendations and a real-time view of what readers are asking. MCP connections sit on top of that, turning the data you already license or produce into something readers can talk to.

Explore GenDiscover for Publishers to see how the Discovery Agent, MCP data connections and AI-native advertising work together, or get in touch at [email protected] to talk through your data sources.

Frequently Asked Questions

What is MCP and why does it matter for publishers?

MCP, the Model Context Protocol, is an open standard for connecting AI systems to external data and tools. For publishers it matters because it lets an on-site AI agent answer from live systems, not just from published articles, so readers can ask for current scores, prices, listings or statistics and get real values rather than whatever was true when the last story was filed.

How is an MCP connection different from the AI agent reading my articles?

Reading your articles is retrieval: the agent finds relevant published content and answers from it. An MCP connection is a live call into your systems for data that exists in a database or feed rather than in a document. Most answers end up combining both, with the live number from the feed and the interpretation and links from your archive.

What kind of publisher benefits most from MCP connections?

Any publisher whose value depends partly on structured data. Sports media with live scores and match statistics, financial publishers with prices, fundamentals and filings, property and travel sites with live inventory, automotive titles with specs and valuations, and B2B publishers with proprietary company, deal or regulatory databases.

Do I need to build an MCP server to use this?

No. GenDiscover will expose your existing feeds, APIs or databases as an MCP service for you, including designing the tool surface, hosting, caching and authentication. If your engineering team would rather build it in-house, wrapping an existing API in an MCP server is usually a small piece of work and off-the-shelf MCP servers already exist for several common sports and market data providers; we will review the tool design either way.

Who owns the MCP service GenDiscover builds?

You do. It is a standard MCP service, not a proprietary integration, and it can run in your environment or on GenDiscover infrastructure depending on your security and licensing requirements. The same service can serve your on-site agent, your apps, your internal newsroom tools, and any external AI partners you choose to expose it to under your own terms.

Will the AI make up numbers if the data is unavailable?

That is the behaviour to configure against, and it is why tool calls are preferable to scraping a page. When a tool call fails or returns nothing, the agent is instructed to tell the reader it does not have that figure rather than estimate one. Restricting the agent to a small set of well-described tools also reduces the chance of it answering from general knowledge when it should be calling your feed.

Does connecting live data affect my data licensing agreements?

It can, so check before launch. Most agreements govern where and how licensed data may be displayed, and conversational delivery on your own site is usually treated the same way as on-page display, but real-time feeds and aggregate restatements are worth confirming with your provider explicitly.