Connect Openpulse to ChatGPT, Claude and Claude Code

Openpulse is a remote MCP server, which means an AI assistant can read your workspace directly rather than you pasting results into a chat. Ask for this week's high-intent signals and get them, in the tool you already work in.

This is the setup for each client, the requirements that will waste your afternoon if nobody tells you about them, and what the authorisation flow is actually doing.

Before you start: the requirement that blocks people

Every client below supports custom MCP connectors on paid plans only. This is the single most common failure, and it fails invisibly: you follow every step correctly and the option is simply not there, with nothing on screen explaining why.

You also need your workspace's server URL, which is shown in Openpulse under the MCP connector settings. It is the same URL for every client.

Claude

1. Open Settings → Connectors.
2. Choose Add custom connector.
3. Name it openpulse and paste the server URL.
4. Press Connect, then approve the Openpulse consent screen.
5. The tools appear under the connector in any new chat.

Existing chats will not pick up a newly added connector. Start a new one.

ChatGPT

1. Open Settings → Apps → Advanced settings and turn on Developer mode.
2. Choose Add custom connector.
3. Paste the server URL.
4. Complete the sign-in step, then enable the connector for your chats.

Developer mode is the step people miss: without it there is no "add custom connector" option at all, and the settings screen gives no hint that one exists.

Grok

1. Open grok.com/connectors.
2. Choose New connector, then Custom.
3. Paste the server URL and complete authentication.
4. Grok reads the tool list and offers the tools in conversation.

Claude Code

One command:

claude mcp add --transport http openpulse <your-server-url>

Then run /mcp inside a session to complete the sign-in. The tools are then available to the agent in that project.

This is the setup worth having if you want an agent to act on signals rather than report them: pulling the week's signals, cross-referencing them against a local file of target accounts, and writing a summary is a single prompt once the server is connected.

What the consent screen is actually doing

Worth understanding, because "paste a URL and click approve" hides a genuinely well-designed flow, and because it explains why the setup is this short.

MCP authorisation builds on the OAuth 2.1 draft plus four RFCs, and the discovery is entirely automatic:

1. The client makes a request with no token. The server answers 401 with a WWW-Authenticate header pointing at its resource metadata.
2. The client fetches /.well-known/oauth-protected-resource (RFC 9728), which names the authorisation server.
3. It fetches /.well-known/oauth-authorization-server (RFC 8414) for the endpoints.
4. If it has no client ID, it registers itself dynamically (RFC 7591). This is why you never create an app or paste a client secret.
5. It generates PKCE parameters (required, not optional) and includes a resource parameter (RFC 8707) naming the exact server the token is for.
6. You approve in the browser, the code comes back, and the token is exchanged.

The resource parameter is the security-relevant part: it binds the token to this server specifically, so a token issued for one MCP server cannot be replayed against another. Our server validates that every token presented was issued for it, and refuses anything else.

One implementation note that cost us an outage class: our /.well-known/oauth-authorization-server document never fails. When the identity provider is unreachable it is derived from the publishable key, which encodes the issuer. It used to return a 502, and since that route is the only place part of the metadata ships, one blip made the whole server scan as though it had never implemented the convention.

What the tools actually do

Reads first, writes last. The agent gets:

There is no create-listener tool, and that is deliberate. A listener is a standing commitment to spend money on every run. An agent that misreads a sentence and creates six of them has not made a formatting error, it has made a billing decision. Creating and deleting listeners stays in the interface where somebody can see the plan limits.

The prompts that actually work

The most common disappointment is a vague question producing a tool-call loop and a mediocre summary. Two rules fix most of it.

Prefer roll-ups to searches for sales questions. Anything shaped like "who should we contact" or "which competitor is vulnerable" wants get_rollup, which returns the row a salesperson acts on. search_signals returns the evidence underneath it, which is what you want after you have picked a row.

Constrain the window and the class. "Show me signals" is an unbounded request. "People actively leaving a named competitor in the last fortnight" maps cleanly onto a classification and a window and returns something useful.

Prompts that work well in practice:

• "Which of our competitors lost the most users this month, and what were the top three complaint themes for each?"
• "Show me high-intent signals from the last seven days, with the reasoning, and group them by source."
• "Has the quality report got any queries that have never produced a kept signal? List them so I can prune them."
• "Rate the signals I mark as good, then tell me what they have in common."

That last one is worth trying. Ratings feed the next pass, so an agent that helps you rate consistently is improving the filter, not just reading it.

Security boundaries, stated plainly

• The tools are read-only apart from rating a signal and queueing a run.
• An agent can never create or delete a listener, or change billing.
• Tokens are bound to this server by audience validation and the resource parameter, and tokens issued for anything else are rejected.
• Openpulse asks for no credentials to anything you own. It reads public sources and sends results outward. It does not connect to your CRM or your inbox.

The broader argument for reading signals through an agent rather than a dashboard is in give your AI agent a research tool, and the rest of the machine-readable surface is described in how we made a marketing site that agents can read.