Your AI agent can read the workspace, but it can never create a listener — Open Pulse

At a glance

Published

2026-10-01

Written for

Anyone evaluating an MCP connector, and engineers designing one

Category

informative

Reading time

6 minutes

Keywords

read-only MCP server, MCP connector security, AI agent permissions, MCP tool design, agent write access

Overview

Something changed this September. The Model Context Protocol stopped being a developer curiosity and started being a distribution channel. On September 10, RingCentral announced a ChatGPT plugin and MCP connectors for Claude that bring voice, SMS, and team chat data into the LLMs businesses already use. On September 15, Potloc shipped an MCP connector that puts its survey platform inside Claude, ChatGPT, Microsoft 365 Copilot, and Gemini Enterprise. On September 25, Jobber followed with MCP integrations for ChatGPT and Claude aimed at service business workflows. Three companies in fifteen days, all selling the same promise: your AI agent can now reach into your business software and do the work there.

That promise is real, and it is the reason every MCP server should be designed with one question in mind: what is the most expensive thing this agent can be tricked into doing?

The answer is rarely the read. It is the write.

The September launch wave is a permission story

Read the three announcements closely and a pattern appears. Each vendor describes the read access, and each then spends a paragraph on the permission story, because they have to. Potloc says every action runs through its own authorization system, scoped to that user's permissions: the AI can only ever do what the person would be allowed to do themselves. RingCentral enforces identity-aware role-based access controls, with admins able to restrict data access by role or specific prompt conditions. Jobber's integration lets users query accounts and update records by dictation, inside the AI.

These are vendor press releases, so read the shape of the claims rather than the numbers. But the shape is consistent: the read is the feature, the permission model is the product. Nobody launches an MCP connector on governance alone, but nobody launches one without governance either. The market has learned what the browser learned a decade ago: the moment your software accepts commands from an agent, the authorization boundary becomes the most important part of the design.

There is a reason these companies all anchored on "the AI can only do what the user can do." It is the obvious principle, and it is worth stating, because it is the minimum. The interesting design work starts one step further out: which of the things the user can do should the agent be allowed to do at all?

Reads are safe, writes are where the money lives

Consider what the two sides of an MCP server cost when they go wrong.

A bad read leaks information. That is serious, and it is why the OAuth scopes and role restrictions in the September launches matter. But a read is bounded by definition: it returns what is already there.

A bad write creates a commitment. It spends money, sends messages, changes records, and starts clocks that keep running after the agent has been told to stop. In Jobber's case, updating records by dictation is the convenience of the integration; it is also the surface where a hallucinated client name or an autocomplete error writes into a real system of record. In Potloc's case, the vendor keeps sampling standards and quality controls on the platform no matter who drives, precisely because the write side of a survey tool is where a mistake has a cost.

This asymmetry is the whole argument for read-first MCP design. An agent that can read your workspace can be wrong in a conversation. An agent that can write to your workspace can be wrong in your system of record, and those two failures have different price tags.

What Open Pulse exposes, and what it refuses

The Open Pulse MCP server connects Claude, ChatGPT, Grok, and the Claude Code CLI to your workspace. Once connected, a good first prompt is "List my Open Pulse workspaces," because an assistant that has not asked cannot guess which workspace you mean.

Ten tools are registered, and the split is deliberately lopsided. Eight of them only read: list_workspaces, list_listeners and get_listener, search_signals filtered by listener, classification, source, score and window, get_rollup for one row per rival, account, or place, list_runs with status, get_quality_report for per-query and per-source yield, and get_usage_guide, which hands the assistant the conventions rather than any of your data. Everything an agent needs to brief you, summarize, investigate, or plan outreach is there.

Two tools write, and only one of them writes to anything you own. That one is trigger_run, which queues a run now, and it is admin-only. Every other form of writing does not exist. There is no create, update, or delete for listeners, and that absence is asserted by a test rather than left to habit. An agent that can create listeners can commit you to recurring spend on every schedule tick, and no amount of OAuth scoping fixes that, because the permission would be legitimate: the user is allowed to create listeners. The refusal has to live deeper than the permission model. It lives in the tool list.

This is the same philosophy as the no-send-button rule. The product's claim is that it finds people worth talking to, not that it talks to them. The MCP server's claim is that your agent can see everything about the pipeline, and still cannot spend a dollar of your schedule on its own.

The most powerful write we allow is a thumbs

Notice what rate_signal is. It is the second write, the only one available to an ordinary member rather than an admin, and it does not change any data. It feeds your rating back into the next classification pass as a worked example, the same mechanism described in the piece on relevance feedback. A thumbs up becomes part of the definition of "relevant" for your listener. It is a write that changes the machine's behavior rather than your system's state.

That distinction matters for agent security. The dangerous writes are the ones that change state on someone else's behalf: create the listener, launch the run, mint the API key, move the deal. A calibration signal changes the filter's future judgments, and it does so in a way that is visible, attributable, and reversible. If you can design an MCP server where the most powerful write available to most users is "remember that I liked this," you have shrunk the blast radius of a compromised agent to nearly nothing.

There is a second boundary worth naming. An AI assistant connected over MCP cannot see what a run costs us. Pricing and spend are our problem, and our problem stays on our side of the glass. The agent sees signals, scores, quality reports, and rejections. It never sees the meter. That is not a security measure so much as a design principle: an assistant that cannot see the meter cannot be manipulated into optimizing against it.

The checklist for the demo

If you are evaluating an MCP connector, from anyone, ask these five questions before the agent gets write access to anything you own:

• Can the agent do something I am allowed to do, but should not do unsupervised? Scoping to user permissions is the minimum, not the answer.
• Which tools create recurring cost? Scheduled work is a subscription the agent can sign you up for.
• Is there a write that changes state versus one that changes judgment? Calibration is safe; configuration is not.
• What is kept off the agent's screen? Cost data, billing, and admin functions should never cross the boundary.
• What happens when the agent is wrong? Reads fail in conversation. Writes fail in your system of record.

You can run all five against ours in a couple of minutes. Connect a client and ask it to summarize your strongest signals.

The September launches show the industry converging on MCP as the standard way agents touch business software. That is good news. It means the permission conversation is about to happen everywhere, not just in security reviews. The servers that get it right will be the ones where the tool list is short, the writes are few, and the most dangerous thing an agent can do is ask to be heard.

Read-only is not a limitation. It is the whole point.

References

• Potloc launches MCP connector, putting its survey platform inside Claude, ChatGPT and Copilot, GlobeNewswire via FinancialContent, 15 September 2026.
• RingCentral announces plugin for ChatGPT and MCP connectors for Claude, Business Wire, 10 September 2026.
• Jobber integrates its Model Context Protocol with ChatGPT and Claude for enhanced service workflows, Third News, 25 September 2026.

Next

• Start the free trial — Creates a workspace. A card is taken up front and nothing is charged during the trial.
• Pricing — What it costs after the trial.
• All posts — The comparisons and the guides, grouped.

See also

• What Open Pulse is and what it watches
• llms.txt — the index of this site, written for agents
• api.md — the MCP server and the REST API, with scopes
• auth.md — how to authenticate
• openapi.json — the REST API as OpenAPI 3.1
• sitemap.xml — every indexable page