MCP client

Using this with ChatGPT

Remote MCP endpoint registered as a 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 ChatGPT are in the technical documentation: setting up ChatGPT.

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.

Verify the tools are visible before trusting an answer

The failure mode specific to this client is a connector that appears configured but whose tools are not offered in the surface you are actually using. The conversation then proceeds normally, the model answers from training data, and nothing indicates that no news was retrieved. Because the answer looks fine, this can go unnoticed for a long time. Before relying on it, ask a question whose answer requires reporting from the last few days and confirm a tool call actually happened.

No local runtime, and what that buys you

Because the connector is remote, there is nothing to install, nothing to keep updated, and no egress from your network to manage. For a rollout across people who are not developers, that removes essentially all of the support burden — the setup is entering a URL and authenticating. The trade is less visibility when something is wrong: there is no local process to inspect, so debugging means reading what the client reports rather than watching the server.

Prompting it towards bounded queries

This client tends to issue broad queries when a question is open-ended, and an unbounded news query returns confident results anchored to nothing in particular. A sentence in your instructions asking it to bound requests by time and prefer clustered stories measurably improves what comes back, and costs nothing. This is the single highest-leverage adjustment available on this client.

Where ChatGPT is the wrong place for this

The connector is the wrong choice anywhere the answer must be traceable back to specific sources. Results are summarised into the reply, and while the underlying tool call returned links, what a reader sees is prose that may or may not carry them — which is a problem if someone downstream has to check a claim. For that, call the API directly and render the results yourself. It is also poorly suited to a rollout where different people are on different plans or different surfaces, because the connector may simply not be offered in some of them and the failure is silent: the conversation proceeds, the model answers from what it already knows, and nobody sees an error. Verify visibility per surface before telling a team the tool is available to them.

Notes and the usual pitfall

Because the connector is remote, there is no local runtime to install or keep updated — which also means network egress from your side is not involved.
Connector support differs across surfaces and plans, so verify the tools are visible in the specific surface you intend to use rather than assuming parity.

Watch for: Connector availability varies by plan and by surface. A configuration that works in one place may simply not be offered in another, and the failure looks like the tools silently not existing.