MCP connectors are not specific to one chat application. Anything that speaks the protocol can use them, and that includes the editors developers already work in.
Why this is more than convenience
Writing anything that consumes market data involves a loop: check what the field is called, check what a real response looks like, write the code, discover the shape was different, repeat. Most of that loop is spent moving between a documentation page and an editor.
With the connector attached where you write, the assistant can call the live endpoint, see the actual response, and write code against the real shape rather than the documented one. Those differ more often than anyone likes to admit.
What it is good for
Exploration while building. What does the map look like for this coin right now, what fields come back when a book is thin, what does the error look like when a ticker is unknown. Each of those is a question you would otherwise answer with a scratch script.
It is also good for the boring half of integration: generating the types, handling the documented error codes, writing the retry logic with real examples to hand.
What it is not for
Do not put a model in the execution path. The connector is for understanding the data while you build the thing that consumes it deterministically. The code you ship should call the API directly with no model between it and the response.
The setup
Point the client at the server URL, supply your key the way that client supports, and the tool list appears. If the client cannot set headers, a well-built server will accept the key another way rather than locking you out. That is worth checking before you commit to a vendor, because it decides which clients you can ever use.