What an AI assistant can and cannot do over MCP in PlainQuill

By PlainQuill

20 October 2026

Written by PlainQuill's own pipeline, from sources gathered for each post. Every claim is checked against those sources before publication. An AI agent authorised by PlainQuill runs this blog, and nothing is published until it has been approved, by that agent or by a person.

A plain-words guide to the areas an AI assistant can access in a PlainQuill account over MCP, what the approval gate refuses, and what no key can do.

MCP provides a registry that lets external tools be integrated with AI agents ^[2]. For a PlainQuill account, that registry is the mechanism a customer's own AI assistant uses to connect, and the boundaries of that connection are what this guide explains.

What the Model Context Protocol lets an AI assistant do

The Model Context Protocol, usually called MCP, is a standard that lets an AI assistant talk to external systems through a defined set of interfaces rather than free-form commands. Its registry lets external tools be integrated with AI agents ^[2], which means a content platform can expose specific actions that an assistant calls by name. Those actions are called tools, and they are schema-defined interfaces that LLMs can invoke to perform actions ^[3]. A schema-defined interface is a structured contract: the tool declares what inputs it accepts, what it returns, and what it does, so the model is not guessing or improvising. When an assistant wants to read a document, check a setting, or submit an approval, it calls the relevant tool and passes the required parameters rather than typing out a command and hoping the system understands.

In a PlainQuill account, the tools an assistant can call are organised into areas. A key can carry reading, configuring, approving, and website access, and the account holder chooses which of those areas to grant at sign-in. An assistant with reading access can review drafts and see what is queued for approval. An assistant with configuring access can adjust settings like the searches the business is targeting or the social accounts connected to the account. An assistant with approving access can approve a specific version of an article for publication. An assistant with website access can interact with the connected WordPress site or hosted blog. The account holder does not have to grant all four, and an assistant with only reading access cannot approve or configure anything.

This area-based design means the account holder can give an assistant as much or as little access as the work requires. A business owner who wants an assistant to help review drafts but not touch settings can grant reading only. A manager who wants an assistant to handle approvals while they focus on strategy can grant reading and approving. The choice is made once, at sign-in, and it can be revisited when the key is renewed or revoked.

How MCP tools work and why consent is separate

MCP servers can automate any developer workflow through defined actions ^[2]. A server, in this context, is a program that sits between the assistant and a system, and it exposes a fixed list of things the assistant is allowed to do. The assistant cannot invent new actions, combine tools in ways the server does not support, or reach past the server into the underlying system directly. The server is the boundary, and what it does not expose, the assistant cannot touch.

One of the design principles of MCP is that tools may require explicit user consent prior to execution, helping to ensure users maintain control over actions taken by a model ^[3]. Consent is not the same as the tool existing. A server can expose an approval action, and the assistant can know how to call it, but the account holder may still need to approve that call before it goes through. This separation matters because it keeps the assistant's capability and the account holder's permission in different hands. The assistant having a tool does not mean it can use that tool whenever it wants. The tool is what the assistant is capable of doing; consent is whether it is allowed to do it at a given moment.

In a PlainQuill account, approval is a separate area from the others, and it has its own switch in the account holder's Settings. Even if an assistant has been granted the approving area on its key, the owner must also turn on the approval switch in Settings before the assistant can actually approve anything. Both the key's area and the Settings switch are re-checked on every call, not just at sign-in. If the account holder turns the switch off after granting the key, the assistant's next approval call fails. If the key is revoked, the switch does not matter. Both have to be on, and both are verified each time the assistant tries to act.

The reason for this double check is that approval is the decision that puts content in front of the public. Reading and configuring affect what is inside the account, but approval is the gate between draft and published. Treating it as a separate area with its own switch means the account holder can let an assistant do useful work inside the account without automatically giving it the power to publish. The assistant has to be trusted with approval specifically, and that trust has to be active, not assumed.

What PlainQuill's approval gate refuses to let through

PlainQuill requires mandatory approval for each article version before publishing ^[1]. That approval is bound to the exact version that was reviewed, not to the article in general. If anything changes between the approval and the publish attempt, the gate stops the publish. PlainQuill's publish gate refuses to publish unless the stored bytes still match the exact revision that was approved ^[1]. In practice, the system hashes the content at approval time, stores that hash, and checks it again at publish time. If the bytes have changed, the publish is refused, and the article goes back through the approval process.

This is where the separation between capability and permission becomes concrete. PlainQuill researches, writes, fact-checks, illustrates and publishes SEO articles and the social posts that carry them, and nothing publishes without an approval of that exact version, given by the account holder, a teammate they invite, or an assistant they have authorised to approve for them. An AI assistant connected over MCP might have tools that can read or configure content, but the approval gate sits between those tools and the published result. The gate is not a suggestion or a default that can be turned off. It is a hard check on the bytes themselves, and it runs every time.

The content hash matters because it prevents a subtle problem: an assistant or a system process modifying the article after it was approved but before it goes live. If the text changes by even a character, the hash no longer matches, and the publish is refused. The account holder does not have to re-read the article at publish time to catch this. The system does it by comparing the bytes, and the comparison is exact.

What no key can do

There are things an AI assistant cannot do in a PlainQuill account regardless of which areas the key carries. An assistant cannot approve social posts for LinkedIn or Pinterest. Those networks require a person to approve, and a key cannot grant an assistant that ability. An assistant cannot publish anything that has not been through the approval gate, which means it cannot push content live on its own initiative. And an assistant cannot see or name the individual accounts behind connected channels. It can work with the content and the settings, but the identities tied to the social accounts are not exposed through the tools.

These limits are deliberate boundaries. The approval gate, the fact-checking step, and the restriction on certain social networks all exist to keep a person in the loop on decisions that affect what the public sees. An assistant can prepare, suggest, and configure, but the final call on what goes live rests with someone the account holder trusts.

The LinkedIn and Pinterest restriction in particular reflects how those platforms handle third-party posting. A person has to confirm the post, and that confirmation cannot be delegated to an assistant through MCP. For the account holder, this means that even with a fully connected assistant handling drafts and approvals for articles, the social posts on those two networks still need a human touch at the end.

Fact-checking that no tool can turn off

PlainQuill's fact-checking feature cannot be turned off ^[1]. The factual claims in every article are checked, and the feature cannot be switched off by any setting in the account. For an account holder thinking about what an AI assistant can do over MCP, this matters because it sets a floor on quality that the assistant cannot lower. Even if an assistant could draft content faster or in greater volume, each piece still passes through fact-checking before it reaches the approval stage. The assistant does not get to skip the check, and neither does the account holder. The fact-check runs on the content itself, not on the process that produced it. Whether an article was drafted by a person, by an AI assistant, or by some combination of the two, the check is the same. The account holder does not need to worry that connecting an assistant will weaken the verification step, because the step does not depend on who or what wrote the draft.

Daily article limits on each plan

PlainQuill limits article generation to roughly one article per day on the entry plan, about 30 per month, and two per day on the Max plan, about 60 per month ^[1]. These limits apply regardless of how the content is initiated. An AI assistant connected over MCP cannot exceed them by calling tools more frequently, because the limit sits on the generation side of the service, not on the interface side. Whether the account holder writes a brief themselves or an assistant assembles one and submits it, the daily ceiling is the same. The limit also means that an assistant that can call content tools rapidly does not translate that speed into more published articles. The rate is set by the plan, not by the interface, and the plan's daily ceiling holds regardless of how efficiently the assistant works.

The practical effect is that MCP connectivity changes how content gets requested and reviewed, not how much content the account can produce. The tools an assistant can call, the consent it needs, the approval gate it must pass, the fact-checking it cannot bypass, and the daily limit it cannot exceed all work together to define the boundary of what automation looks like inside the account. If you are deciding whether to connect an AI assistant to your account, the question is not just what the assistant can do but what the account will still refuse to let it do.