Why the Leadstore MCP Connector Is Read-Only, and What That Protects

Seven tools, all lookups: visibility score, competitors, content calendar, blog drafts, mentions, share of voice, connected sites. Every one answers a question. None of them changes a row in an account. Asking an assistant to draft a post or launch an audit today will not work, because that tool does not exist yet, not because a permission check silently blocked it.

A few things are excluded entirely, not just from writes, from reads too. Plan name, subscription status, prices, renewal dates, and remaining AI credit balance never appear in a connector response. Asked what plan an account is on, the answer is to check the app.

A connector's output lands inside a conversation with a third-party assistant, and depending on how that assistant is set up, that conversation can be logged, reviewed, or surfaced somewhere outside anyone's control. A visibility score sitting in a ChatGPT transcript is low-stakes. Billing details sitting there are not. Billing is excluded, with one narrow exception: bare quota counts, like drafts remaining this month, so an assistant can warn before a request fails instead of after. Those numbers go through an explicit allow-list, not a blanket pass-through, so a new billing field added later cannot leak just because nobody updated a filter.

Every connection uses the account's own Leadstore login, through a standard OAuth flow. There is no shared account behind the scenes and no cached token serving every user. Each request is checked against that specific account, and access can be revoked at any point without affecting anyone else's connection.

Read-only does not mean low-stakes in every direction. A read tool can still leak the wrong thing if nobody thought carefully about what it returns, which is why billing is excluded at the source instead of being trusted to a do-not-mention instruction in a prompt. A field that was never included in a response cannot leak, no matter what an assistant is asked to do with it. The same logic applies to error handling: when a request to an underlying provider fails, whatever error comes back is checked for anything that looks like a credential before it reaches the assistant, since a failed request can sometimes echo an API key back in its error message.

An AI assistant that can take actions on someone's behalf is genuinely useful to build toward, and it is also the kind of feature that is easy to get wrong once and regret. A read tool returning the wrong number is an annoyance. A write tool doing the wrong thing to a live content calendar, or publishing something nobody approved, is a different category of mistake. Starting read-only means the current server has had time to prove out the authentication and access boundaries without that risk sitting on the table from day one.