How to Use Read-Only Promptwatch API Keys for Looker Studio and MCP
How we issue read-only Promptwatch API keys for Looker Studio and MCP chat, and keep write keys on the CMS-connected seat only.
Most people on an account should not be able to create prompts or push Webflow drafts. We issue read-only Promptwatch API keys for Looker Studio and for MCP chat. Write keys stay on the one seat that is connected to the CMS. That is the whole policy.
The policy is short because the threat is specific. A read-only key that leaks exposes visibility data, which is recoverable. A write key that leaks can push a draft to the CMS or grow the prompt list silently, which is not. The cost of the second failure is a published page no human approved, or a prompt list bloated with imports. The control that prevents it is keeping the write key on a single named seat and rotating it when that seat changes hands. Everything else in this piece is the detail of how we apply that control across Looker, MCP, and the CMS seat.
List who needs Looker, who needs MCP, and who publishes. Only the last group gets write. Essential at $95/mo includes MCP and API, but Data Studio is not listed there. Professional at $245/mo is the first brand plan with Data Studio. Business is $579/mo. Kick-off is $199/mo with Data Studio, unlimited projects and prompts, and 10 seats. Explore is free, 10 ChatGPT prompts. G2: 4.7/5.
The tier list matters here because Data Studio is not on every plan. Essential includes MCP and API, which is enough for a small team to wire chat and a custom dashboard. Data Studio, the native Looker Studio connector, starts on Professional for brand plans and on Kick-off for agency plans. A team that wants the native connector on Essential will not find it, which is why the first step is to list who needs what before issuing keys.
Read-only where the key can leak
Looker: the connector takes an API key. Every analyst who can edit the report can see how the connector is set up. Use read-only. A leaked Looker key should not publish a draft. We do not put write keys in the Looker connector "so the report can add prompts." Reports do not add prompts.
The Looker point rests on who can see the connector config. Any analyst with edit access to the report can open the connector and read the key. That is not a leak in the dramatic sense, it is the normal way a shared report works. The control is to make the key in that connector read-only, so the worst case is that an analyst sees visibility data they were already allowed to see. A write key in the same connector is an open door to a draft push, and there is no report that needs that door.
MCP: Claude, Cursor, and ChatGPT store the key or the OAuth grant on a laptop. We use read-only there too. Read-only hides write tools on MCP. The chat can ask for visibility. It cannot bulk-create prompts from a year of GSC imports. Wiring: connect MCP. Confirm MCP hides write tools on the read-only key before you call the setup done.
The MCP point rests on where the key lives. A key pasted into Claude or Cursor sits on a laptop, and laptops change hands, get lost, and run software the security team does not own. Read-only on MCP hides the write tools from the chat, which means the chat can answer questions about visibility but cannot act on the CMS or the prompt list. The confirmation step is the one teams skip: paste the key, then ask the chat to create a prompt. If it can, the key is not read-only, and the setup is not done.
Can we use OAuth for MCP and a key for Looker? Yes. OAuth for a named login in Claude is fine. Looker still wants a key. Both should be read-only unless that login is the CMS seat.
Project vs org: project key for one logo. Org key on Kick-off when the same Looker file or the same Cursor setup spans clients. Still read-only. We do not hand an org write key to a freelancer.
Create the read-only keys first, project or org, matching scope. Paste those into Looker and into Claude, Cursor, and ChatGPT. Slack does not get an API key pasted in the channel. Slack is a separate org-owner connection. See add the agent to Slack.
Write keys, one seat
The CMS-connected seat is the exception. Webflow OAuth and field mapping need someone who can push a draft. That person holds the write key. We still push draft, never live autopublish. Publish to Webflow. Create one write key on the CMS-connected seat. Do not copy it into Slack.
If that person leaves, we rotate the write key the same day. We do not wait for the monthly. Rotate on offboarding. Revoke laptop keys you cannot name. People stall on this because they think rotating will break Looker. It will not, if Looker is on a different key, which it should be.
The rotation stall is the one we hear most. A team knows the write key should rotate on offboarding, and they wait for the monthly review because they fear the dashboard breaks. The fear is misplaced if Looker is on its own read-only key, which is the whole point of the split. Rotate the write key the day the seat changes hands. The dashboard keeps running on its read-only key.
What if someone needs to create prompts from Cursor? Then they are not on a read-only laptop key. We would rather they add prompts in the UI after a human cuts the list. If you insist on write-from-chat, it is a write key on a controlled machine, not in a shared repo.
We do not put write keys in GTM. Visitor analytics is a collector. GTM setup.
What read-only still can do
Pull monitors, citations, prompts, and visibility into Looker (90-day window on the connector). Ask MCP about imported GSC topics. Read persona rows. Enough for the weekly.
What it cannot do: accept a Content Agent slot, publish to Webflow, or silently grow the prompt list. Those stay human and stay on the write seat. Looker can still sit next to Google's generative AI performance reports in the same file. The key type does not change that. The GSC chart uses Google's connector.
No instant alerts either way. Keys do not change that.
The split is the whole policy in one sentence: read-only where the key can leak, write on the one seat that publishes. A Looker connector and an MCP grant both live on machines and accounts you do not fully control. A leaked read-only key exposes visibility data, which is recoverable. A leaked write key can push a draft to the CMS or grow the prompt list silently, which is not. Keeping the write key on a single named seat, and rotating it the day that seat changes hands, is the cheapest control that prevents the expensive failure.
FAQ
Can we use OAuth for MCP and a key for Looker?
Yes. OAuth for a named login in Claude is fine. Looker still wants a key. Both should be read-only unless that login is the CMS seat.
What if someone needs to create prompts from Cursor?
Then they are not on a read-only laptop key. We would rather they add prompts in the UI after a human cuts the list.
Does rotating the write key break Looker?
No, if Looker is on a different key, which it should be. Rotate the write key the day that person leaves. Do not wait for the monthly.
If you want the key split done, hello@1001seomedia.com. Say who edits Looker and who touches Webflow.