MCP client

Using this with Cursor

Remote MCP URL declared in the editor MCP settings.

Setup

A URL and a header, and the configuration differs only in where this client keeps it. The step-by-step, the config block to paste and the mistake people actually hit with Cursor are in the technical documentation: setting up Cursor.

That page is kept current against the API rather than restated here, and it covers seventeen clients — including the bridge for anything that only speaks stdio.

Keep it out of automated runs

An editor agent with a news tool available will sometimes use it during tasks that have nothing to do with news, because a tool that is present is a tool that gets considered. That is harmless interactively and wasteful in any automated or batch context, where nobody is watching and the requests still count. If you run unattended jobs from the same editor configuration, scope the server to the projects that actually need it rather than enabling it globally.

Querying the real index while you build against it

The reason to wire this into an editor is not to read the news — it is that you are writing code which consumes news data and would otherwise be guessing at response shapes. Being able to ask for a real result while writing the parser that handles it removes an entire category of mistake, particularly around fields that are frequently absent. Optional fields are where integrations break, and they are exactly what a hand-written mock will get wrong.

Editor agents burn request budget fast

An agent operating inside a codebase explores. It will issue broad queries to understand the shape of the data, then more queries to check its understanding, and a single question from you can become a dozen requests without anything having gone wrong. On a small plan that is noticeable within an afternoon. Bound queries tightly by time, and keep an eye on usage while you are iterating — this is the client where the request multiplier surprises people most.

The stale process problem

The editor keeps the server process alive across window reloads, which is normally what you want. It becomes a problem after you rotate an API key: the old process keeps running with the old key, requests keep succeeding, and you conclude the new key works when it has never been used. If usage is appearing under an account you did not expect, this is almost always why.

Where Cursor is the wrong place for this

Do not use this as the news integration for anything that ships. The editor connection exists so you can query the real index while writing the code that consumes it; the code you are writing should call the API itself, with its own key, its own error handling and its own request budget. Leaving an editor-scoped connector as the production path means your service depends on a developer's local configuration, which will eventually be changed or removed by someone who has forgotten it mattered. It is also the wrong place for anything expensive or repetitive: an editor agent explores, exploration multiplies requests, and a quota consumed while iterating is a quota not available to whatever you were building.

Notes and the usual pitfall

Useful when the code you are writing consumes news data — you can query the real index while building against it, instead of guessing at response shapes.
Keep queries tightly time-bounded here; editor agents tend to issue broad exploratory calls that burn request budget quickly.

Watch for: The editor keeps the server process alive across reloads. After changing the API key, kill the process or the old key stays in use and requests keep succeeding under the wrong account.