Agencies feel the cost of small changes more than anyone. One client wants the holiday bar up today, another wants the pricing page widget paused during a redesign, a third wants last month's numbers for a report. In a dashboard that is three logins and a lot of clicking. With Provedly's MCP server, it can be three sentences in the editor you already have open.
This post covers how to set that up so it stays tidy as the client list grows. For the broader agency case, including how to talk to clients about honest proof, see social proof for agencies.
Two ways to structure accounts
How you connect depends on how your clients' Provedly setups are organised.
One account, many sites. If you manage a client roster from a single Provedly account, each client is a site on that account. One key covers all of them, and the assistant sees every site. This is simplest to connect, and it means you must name things carefully, because "pause the homepage widget" is ambiguous when twelve sites have one.
One account per client. If each client owns their own Provedly account and has given you access, each account needs its own key. That is more setup and gives you cleaner boundaries: a key for client A cannot touch client B, and when an engagement ends, the client revokes your key and that is the end of it.
Plan limits follow the account. In the first setup, your plan's site, widget and bar limits are shared across all clients. In the second, each client's plan applies to their own account.
Connecting several accounts
MCP clients let you add more than one server. Give each a name that says which client it belongs to:
claude mcp add --transport http provedly-northwind https://provedly.app/mcp \
--header "Authorization: Bearer provedly_NORTHWIND_KEY"
claude mcp add --transport http provedly-harbor https://provedly.app/mcp \
--header "Authorization: Bearer provedly_HARBOR_KEY"
The assistant then sees two sets of the same tools, one per server, and you say which client you mean. In Cursor, the equivalent is two entries in mcp.json, as shown in the Cursor guide.
Keep these at user scope rather than in a project config that might be committed. A repository that holds several clients' keys is a bad day waiting to happen.
Naming that survives a busy week
The assistant finds widgets and bars by name. Generic names cause mix-ups, so adopt a convention and stick to it:
- Start bar names with the campaign and end with the client or site: "BF 2026 main sale, Northwind".
- Name widgets by placement: "Product pages", "Pricing page", "Checkout".
- Name keys after the person and the client: "Maria, Harbor, read and write".
Items can also be referenced by id (a UUID) or by token, so when a name is genuinely ambiguous, ask the assistant to list items with their ids and act on the id.
A day in practice
A realistic morning might go like this.
For Northwind, create a countdown bar called "Winter launch, Northwind" ending Dec 1 at 9am with the message "The winter collection opens in {timer}".
The bar is created paused. Send the client a screenshot of the preview from the dashboard, or read the message back to them. When they approve:
For Northwind, turn on the winter launch bar.
Then:
For Harbor, pause the widget on the pricing page. They are redesigning it this week.
And for reporting:
For each client, give me impressions, clicks, verified orders and proof-assisted orders with revenue for October.
The assistant calls get_stats once per account. Paste the numbers into your report, with a line explaining what proof-assisted means; measuring proof-assisted orders has wording you can borrow.
Access levels for an agency
Not everyone on the team needs to change things. A reasonable split:
| Role | Key level |
|---|---|
| Account manager, reports | Read only |
| Campaign manager | Read and write |
| Developer, installs | Read only, plus the install snippet |
| Backend posting records | Read and write, its own key |
Read-only keys can still call get_install_snippet, so a developer installing the script does not need write access. The reasoning behind each level is in read-only vs write keys.
What stays the same for clients
Clients sometimes worry that an agency with AI tools could inflate their numbers. It cannot. Records added through the API or by an assistant carry a visible "Imported" label in the widget and never the Verified mark, and the client's verification page lists them under "Site owner's backend (API)". Only signed store webhooks produce verified ones. The client's public verification page shows the sources. That is a good thing to say out loud in a pitch, and the verification boundary explains it in more detail.
Frequently asked questions
Can one key access several Provedly accounts?
No. A key belongs to one account. Connect one MCP server per account, each with its own key and a clear name.
What happens to my keys when a client leaves?
If the client owns the account, they revoke your key in their Settings and access ends immediately. If the site lives on your account, deal with it as agreed with the client, and revoke any key that only existed for their work.
Is there extra cost per client?
Keys, the API and the MCP server are included on every plan. Each account's plan sets its own limits.
See plan limits for sites, widgets and bars on the pricing page.