MCP client

Using this with Claude

Remote MCP URL — a hosted server, added as a custom connector.

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 Claude are in the technical documentation: setting up Claude.

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.

Tool selection is unusually reliable here

This client reads tool descriptions carefully and picks between similar tools better than most. In practice that means it will reach for story grouping when the question is about an event and article search when the question is about coverage, without being told to. That changes what you should put in your system prompt: you generally do not need to script which tool to use, and over-specifying tends to make things worse by overriding a judgement that was already correct.

Summarised results change what you should request

Long tool results get summarised rather than pasted wholesale into the reply, which interacts well with clustered stories and badly with raw article lists. A clustered result carries one item per event with its outlet list, so a summary of it preserves the useful structure. A list of forty near-identical articles summarises to a single sentence that throws away everything except the fact that there were forty of them.

Local versus remote

The server is hosted, so there is nothing to install and no local process to keep alive — you point the client at a URL and give it your key. That also means a team rollout is a config file rather than a deployment, and revoking access is revoking a key rather than chasing down machines. If your client only speaks stdio, any standard MCP HTTP proxy will bridge it.

Where Claude is the wrong place for this

This is a good place to ask news questions and a poor place to run them on a schedule. The connector is attached to a conversation, so anything that has to happen every morning whether or not someone opens the client belongs in your backend calling the REST API directly, with the client left for the interactive half. It is also the wrong surface when the output has to be reproducible: the same question asked twice can produce different tool calls with different windows, which is fine for exploration and unacceptable for anything that feeds a report. The rule that holds across all of this is that a chat client is where a person investigates and a backend is where a process runs, and the same API sits underneath both, so moving a workflow from one to the other is a change of caller rather than a rewrite.

Notes and the usual pitfall

Tool descriptions are read carefully by this client, so it reliably picks story grouping over article search when the question is about an event rather than about coverage.
Long result sets are summarised rather than dumped, which makes clustered results noticeably more useful than raw articles.

Watch for: Configuration is only read at startup. If the tools do not appear, the cause is almost always that the client was not restarted, not that the config is wrong.