A news MCP server, built by the people who run the index

Six tools covering search, story grouping, headlines, article lookup and related-article discovery. Same filters and same authentication as the REST API, so behaviour does not diverge between the path your backend takes and the path an agent takes.

Why this is worth having as a first-party thing

Search the web for a news MCP server today and you will find community wrappers around other vendors' REST APIs — GitHub projects, a package on PyPI, a tutorial or two. Several are well made. All of them share the same structural problem: they are a translation layer maintained by someone who does not control either side of it. When the upstream API adds a filter, the wrapper does not have it. When the wrapper's author moves on, you inherit it.

A first-party server does not have that seam. The tool definitions are generated from the same query surface the REST API exposes, so a filter that exists in one exists in the other, and a query you debugged with curl behaves identically when a model issues it. There is no version of this where the tool layer drifts from the API it describes, because there is no separate tool layer to drift.

One tool call, one round trip, grouped results back.

The tools

Tool	What it does	When to reach for it
`search_news`	Search articles by keyword, meaning or both, with time-range, language and outlet filters.	The default tool. Hybrid mode is usually the right choice when a model wrote the query, because models paraphrase.
`list_stories`	The same search, collapsed so one event returns once with the outlets that covered it.	Use this whenever results go into a context window. It is the single biggest token saving available here.
`top_headlines`	The most recent articles, optionally narrowed to a language or an outlet.	For "what is happening right now" questions, where recency matters more than relevance.
`get_article`	Fetch one article record by id.	For following up on a specific result the model has already seen, without re-running a search.
`find_related`	Find articles similar to a given one.	For "what else has been written about this" without the model having to invent a new query.
`account_status`	Report the current plan, rate limit and usage.	Lets an agent check its own remaining budget instead of discovering the limit by hitting it.

Connecting it

The server is hosted, and every MCP client connects to it the same way: a URL and your API key. Nothing to install, and the same key works for the REST API.

{
  "mcpServers": {
    "unzoi": {
      "url": "https://api.unzoi.com/mcp/sse",
      "headers": { "x-api-key": "your-key" }
    }
  }
}

Client-specific walkthroughs live under integrations. Clients that only speak stdio can bridge to this URL with any standard MCP HTTP proxy.

Get a free API key

MCP access is on every plan, including the free one.

Designing tool calls that do not waste context

The most common mistake when wiring news into an agent is reaching for article search when you wanted story grouping. A busy news day means one event has been covered by dozens of outlets, and article search will faithfully return all of them. The model then reads the same fact many times, and — because repetition reads as importance — weights it accordingly.

Prefer list_stories whenever the output is going into a context window and search_news when a human will scan the results. Bound every call with a time range, because "recent" means something different to a model than it does to you, and an unbounded query over a deep archive is both slower and less useful than a bounded one.

If the agent is doing research rather than answering a single question, let it call find_related on the best result instead of issuing another search. Models reformulate queries badly under uncertainty, and each reformulation costs a request; a similarity lookup from a result it already trusts is cheaper and usually better.

What the tools return

Metadata, a snippet and a link: headline, outlet, timestamp, language, and a story identifier where one applies. Article bodies are not redistributed, which keeps the publishers who did the reporting in the loop and keeps you clear of the licensing questions that arrive the moment a pipeline starts storing full text it does not own.

In practice this suits agent workloads well. A model deciding what to read next needs to compare candidates, not consume all of them, and a compact result set lets it consider far more options within the same budget. When it does need the full text, the link is right there and the publisher gets the visit.