Blog
What an MCP server is, and what yours should be allowed to do
MCP lets an AI assistant call your tools directly instead of guessing from a screenshot. The interesting question is not whether to connect one, but what to let it reach.
MCP — the Model Context Protocol — is a standard way for an AI assistant to call software directly. Instead of you copying numbers into a chat window, the assistant asks the tool for them. Instead of describing what you want built, the assistant calls the thing that builds it.
The protocol itself is unremarkable engineering. What is worth thinking about is the part that gets skipped: an assistant with a connection to your accounts can do everything that connection allows, and the permission question is not the boring part. It is the whole decision.
What actually happens when you connect one
Three pieces, and it helps to be able to name them.
- The server is the software exposing a set of tools — named operations with typed inputs. "List my accounts." "Show posts between these dates." "Schedule this."
- The client is the assistant. It reads the tool descriptions, decides which ones to call, and gets structured data back rather than a screenshot to interpret.
- The credential is what ties the two together and scopes what the server will do. Usually a key you generate and can revoke.
The practical difference from pasting a CSV into a chat is that the assistant can follow up. It asks a question, gets an answer, notices something in the answer, and asks a second question you did not think to ask. That is genuinely more useful, and it is also exactly why the permission boundary matters.
The three questions to ask before connecting anything
Not specific to any product. Ask these of any tool offering an AI connection.
1. What can it read?
Read access is where most of the value is, and it is not risk-free. An assistant reading your analytics is reading your business. Ask whether the connection is scoped to your workspace, on the server side, so that a key belonging to you cannot return anyone else's rows even if the assistant asks for them.
The honest way to evaluate this is not the marketing page — it is whether the vendor will state plainly that scoping is enforced where the data is, rather than in the tool descriptions the model reads. A model that is asked nicely not to look at something is not an access control.
2. What can it change?
Reading and writing should not arrive together by default. There is a real difference between:
- reading performance data,
- putting a draft on a calendar,
- and publishing to a live account.
Those are three different levels of trust, and a tool that offers them as one switch is asking you to grant the third to get the first. Look for separate levels, and grant the lowest one that does the job you actually want done.
3. How do you take it back, and can you see what it did?
Two properties, both boring, both the ones you need on a bad day:
- Revocation. A key you can delete, that stops working immediately, without unwinding anything else.
- An audit log. A record of which tool was called and when. Without it, "what did it do yesterday?" has no answer.
If a connection cannot be revoked independently, it is not a connection you can experiment with.
Three levels of access, concretely
The sensible shape is the one used for keys generally: name the levels, and make the narrow one the default.
| Level | What it can do | Sensible default for |
|---|---|---|
| Read | Query analytics, list accounts and posts, search content | Almost everyone, almost always |
| Schedule | The above, plus put drafts and scheduled posts on the calendar | Once you trust the outputs and want the drafting loop |
| Publish | The above, plus send something live | A deliberate, narrow decision, ideally on one account |
The reason to start at read is not fear of a rogue assistant. It is that an assistant that cannot publish gives you a review step for free, and the review step is where you find out whether you agree with what it produced. Most people who jump straight to publish end up adding a review step back in manually within a week.
What it is actually good for
Worth being concrete, because "connect your AI" is a claim that has been made vaguely a lot.
- Questions with a follow-up. "Which posts did best last month?" is a report. "Which posts did best last month, and what do they have in common that the rest do not?" is two queries and a comparison, and the assistant can do the second one without you specifying it.
- Cross-account work. Comparing several accounts you run is tedious by hand and trivial for something that can call the same query per account and line the answers up.
- The drafting loop, if you grant the schedule level — look at what worked, draft the next batch in that shape, put it on the calendar for you to review.
- Work you would not have bothered doing. This is the real one. The cost of asking a question drops far enough that you ask questions you previously could not justify.
And what it is not good for: it does not know anything your data does not contain, and it will answer a badly-defined question confidently. If your metrics are ambiguous — reach against impressions against views — an assistant will happily compare the wrong pair for you, faster than you could have done it yourself.
A note on the tool descriptions
One thing worth knowing if you are choosing between tools, and it is invisible from the outside: the text describing each tool is read by the model, and it determines whether the tool gets used well. A vague description produces an assistant that calls the wrong tool or gives up. A precise one produces an assistant that gets it right on the first try.
That text is, functionally, product copy with an audience of one machine. It is a surface almost nobody treats as a surface, and it is a fair proxy for how seriously a vendor has thought about the integration rather than the announcement.
Where SupahPost sits
Plainly, since the question is fair: SupahPost's AI connection has the three levels of access above, a record of every call, and keys you can revoke one at a time — and a key only ever sees your own workspace. It is one of the two surfaces the product exists for — analytics that answer questions, and the tools that make the next thing.
It is not the only tool in this category with an MCP server, and it should not be. The standard is more useful the more things speak it. What is worth comparing is the second question above: what your assistant can actually reach once connected — a publishing queue, or your numbers.
Checked 2026-08-27. This describes SupahPost's implementation on that date and the general shape of MCP as a standard; the standard is young and moving, so verify anything load-bearing against current documentation.