Read-only and two-way
What changes when the MCP connection can write as well as read, which fourteen tools are writes, and why a loop that records itself gets better.
Updated October 20, 2026
Every plan can read over MCP. Two-way adds writing, and the practical difference is larger than the phrasing suggests.
Read-only
The agent sees everything: the overview, prompts, runs, full answers, fan-out searches, sources, retrieval scores, project context, files and the methodology. It can analyse, summarise, draft and advise.
What it cannot do is leave a trace. Every session starts with no knowledge of what the last one decided, so you become the memory: you re-explain the context, the priorities and what was already tried.
The fourteen write tools
These are the ones a read-only connection answers with an upgrade message instead of acting:
| Tool | What it writes |
|---|---|
create_project | A new project on the account |
project_context_update | The brand and voice settings |
project_files_put | A stored project file |
memory_store | A durable fact into project memory |
memory_delete | Removes one |
presence_manage_prompt | Creates, edits, pauses, resumes or deletes a tracked prompt |
presence_manage_asset | Registers a brand or competitor and its spellings |
presence_set_config | The project's presence configuration |
presence_tag | A tag on a prompt, fanout or source |
presence_run_now | Triggers a run |
presence_research_batch | Submits a one-off research batch |
presence_set_optimizing | Flags a fanout as being worked |
presence_source_update | Notes or a claim on a source |
presence_log_optimization | A dated record of live work |
Everything else, including project selection and every read, is open on both modes.
Why writing compounds
A loop that records itself gets better. Session three knows that sessions one and two rewrote the comparison page and claimed two directory listings, that the Visibility Score has not moved yet, and that the control is flat. It can pick the next thing instead of re-deriving the plan.
Three of those writes carry most of the value:
- Flagging a fanout as being optimized stamps the date every before-and-after is drawn from, and puts the query in a work queue a later session can read back.
- Logging an optimization records what actually went live, with the page, so a citation change can be attributed to something specific.
- Memory holds the decisions, so the context survives the end of a chat window.
Without the write path all of that lives in your head, and the quality of each session depends on how much of it you remember to type.
What is never writable
Deletion of a project. A project is paused or cancelled, never destroyed, and that holds on every surface including the agent. Model keys are also not writable: a credential stays a deliberate human action in the app.
A write tool does not mean an unsupervised agent. Logging an optimization is explicitly for work that has already gone live, and claiming a source is for a placement that is actually on the page. The tools are built to record reality, not to let an agent mark its own homework.
Questions about read-only and two-way
- Which plans have two-way?
- Read-only on Starter, two-way from Pro upwards. A trial runs with the write tools available whichever plan you end up on.
- What happens if a read-only connection calls a write tool?
- The tool is present and returns a message saying the connection is read-only and what upgrading would allow. Nothing is half-written.
- Can I make a two-way connection read-only for a session?
- Not as a setting. If you want a session to only look, say so in the conversation; the agent respects an instruction not to write.