Adcopilot Claude Plugin MCP Server

AdCopilot for Claude Code

The AI agent that runs your Google Ads, with Google Analytics, Google Search Console and Google Tag Manager in the same chat. Audit wasted spend, mine search terms, build campaigns and fix conversion tracking from Claude Code. AdCopilot proposes each change first. For a hard stop, set your AI client to ask before AdCopilot's write tools: Needs approval in Claude; in Cursor, use the Allowlist run mode and keep them off the allowlist (Cursor's cloud agents never ask). AdCopilot never deletes anything but a negative keyword. This plugin bundles the hosted AdCopilot connector and carries the steps the connector cannot take for you: what to click in Google's own screens, and the traps that are easy to fall into.

AdCopilot is made by Atromx Intelligence (https://adcopilot.cloud) and is not related to other products named AdCopilot.

The plugin is free (MIT). The connector is a hosted service — plans at https://adcopilot.cloud/pricing.

Install

Two steps on every surface: add the plugin, then sign in to the connector it brings with it. The second step is the one people miss, and nothing works until it is done.

AdCopilot connects to Google Ads through its own Google Cloud project, with your Google sign-in. If you want programmatic access to Google Ads for your own software, get your own Google Cloud account and apply for Google Ads API access there.

claude.ai, Cowork and the desktop app

1. Add the plugin: open AdCopilot in the plugin directory, or go to Customize, then Plugins, and search for AdCopilot. Click Add.
2. In the plugin, open its Connectors tab, click Connect beside adcopilot, and sign in.

The connector is already listed — there is nothing to add, and no need for "Add custom connector" or the connector URL: the plugin registers it for you. If you added AdCopilot by hand before installing the plugin, nothing breaks: Claude links a connector by its URL, so you still have one AdCopilot connector, the same one.

If you clicked Try in Cowork straight from the listing, you landed in a chat before step 2 — the connector will report as missing. Do step 2 and say "get me started" again.

Claude Code

/plugin marketplace add AtromxIntelligence/adcopilot-claude-plugin
/plugin install adcopilot@adcopilot-claude-plugin
/mcp

The last step opens the connector list. Choose adcopilot and sign in with your own Google account. There is no claude mcp add step: the plugin registers the connector at https://mcp.adcopilot.cloud/mcp for you. Signing in links your AdCopilot workspace, so you need an AdCopilot account; your Google products are connected once, in AdCopilot at https://app.adcopilot.cloud, not in Claude Code — /adcopilot:setup tells you which are missing and sends you to the right page.

Cursor

Cursor takes AdCopilot's connector on its own; this plugin does not install there as a whole. Its skills are written for Claude, and Cursor reads them too when they are copied into .cursor/skills or .claude/skills. Wherever they work out which client they are in (/adcopilot:setup, adcopilot-connect, the daily-habit offer), they check for Cursor first: there they never run claude mcp, look for the connector in Cursor's MCP settings and make no schedule offer of their own; a check-in offer AdCopilot's answer asks for is made as it asks.

1. Add the connector: Add AdCopilot to Cursor opens Cursor with the connector named adcopilot. From inside Cursor the same link is cursor://anysphere.cursor-deeplink/mcp/install?name=adcopilot&config=eyJ0eXBlIjoiaHR0cCIsInVybCI6Imh0dHBzOi8vbWNwLmFkY29waWxvdC5jbG91ZC9tY3AifQ%3D%3D. Or put it in ~/.cursor/mcp.json (every project) or .cursor/mcp.json (one project):

   {
     "mcpServers": {
       "adcopilot": {
         "url": "https://mcp.adcopilot.cloud/mcp"
       }
     }
   }
   

2. Sign in: Cursor opens AdCopilot's page, Let Cursor use your AdCopilot?, in your browser. Press Approve; there is no API key to paste. If Approve did nothing on an earlier try, remove AdCopilot in Cursor's MCP settings, add it again and press Approve once; see Approve does nothing.

3. Ask: "Get me started with AdCopilot".

Added from cursor.directory? Its Add to Cursor button can name the connector server instead of adcopilot, so Cursor's MCP list and its approval questions show server. It is the same connector. The link above names it adcopilot.

Approvals in Cursor. Cursor has no Needs approval setting; its run modes decide, in Settings, then Agents, then Approvals & Execution (at the time of writing). In Allowlist, a tool on the allowlist runs without asking and any other asks first, so keep AdCopilot's write tools off the allowlist. In Auto-review, Cursor's recommended default, allowlisted calls also run at once, and every other MCP call goes to a classifier that can let a change through without asking. Run Everything asks before nothing, and a Cursor cloud agent never asks you to approve an action. Whatever the mode, AdCopilot proposes each change first, never deletes anything but a negative keyword, and builds every campaign paused.

Then, on every surface

Signing in to the connector links your AdCopilot workspace, so you need an AdCopilot account. Your Google products — Google Ads, Analytics, Search Console, Tag Manager — are connected once, inside AdCopilot at https://app.adcopilot.cloud, not in Claude. So a fresh sign-in can report nothing connected: that is the server answering correctly, not a fault.

Run /adcopilot:setup first. It says what is connected, what is not, and sends you to the right page for each.

If you had already added the connector by hand before installing (Claude Code only — the web has no such command), Claude Code keeps yours and silently ignores the plugin's: claude mcp list then shows a bare adcopilot: line and no plugin:adcopilot:adcopilot line. Remove yours from every scope it is in — claude mcp remove adcopilot -s user, and claude mcp remove adcopilot -s local run from the directory you added it in, because a local registration belongs to that directory — and the plugin's line appears and asks you to sign in.

What you get

Seven commands, which you type:

• /adcopilot:setup — checks the connector is connected and signed in, says what each connected product unlocks, and catches the two ways a fresh install goes wrong: a lapsed sign-in, and, in Claude Code, a copy of the connector you added by hand before installing.
• /adcopilot:launch — a first Search campaign, through the adcopilot-launch skill below.
• /adcopilot:measure — conversion tracking, through the adcopilot-measure skill below.
• /adcopilot:daily — the daily check-in: this month's budget pacing, the last seven days' searches that cost money and brought nothing, any ad Google has disapproved or limited, and what changed in the account since yesterday and who changed it — in that order, as far as the reads AdCopilot sizes for one answer allow.
• /adcopilot:weekly — last Monday to Sunday against the week before: spend, conversions and cost per conversion, the three biggest changes, and three things to do this week, written to be forwarded.
• /adcopilot:negatives — the last seven days' searches that cost money and brought nothing, grouped by theme, with the never-show-for words (negative keywords) that would block them, proposed first (the command asks which themes to block) and read back once added.
• /adcopilot:audit — the connector's full audit and this month's budget pacing, with the findings that are only a symptom of a brand-new account kept separate, and the first fix proposed with what it costs to act and to leave it, read back once made, then the next one proposed.

Nine skills, which Claude draws on when the conversation calls for them:

• adcopilot-connect — sets up AdCopilot, connects your Google products and links them to each other in the order that works, saying what each step bought you as it happens.
• adcopilot-measure — sets up conversion tracking end to end: the Analytics property and data stream, the Tag Manager tags, the key event, the Analytics-to-Ads link and the import, and ends with exactly one Primary conversion, proven by a real click.
• adcopilot-launch — builds a first Search campaign switched off, on the budget and bid you name: locations, never-show-for words, ad groups, keywords with their match types, ads and assets; verifies the settings that leak money by reading the campaign back; hands you the go-live switch, and asks you to say when it is on so it can read the first day's delivery; and runs the first week's checks, reading why a switched-on campaign is not delivering before it sends you to any screen.
• adcopilot-daily — the morning check a Claude scheduled task or a Claude Code routine runs while nobody is there: it is written to read only and never ask a question, opens with "All clear" or "Needs a look" and ends with the one fix worth doing, as a yes/no question for when you open it. When you answer yes, it re-reads what the fix touches and states the change again before making it, because the report is hours old by then. It also holds the steps for setting that schedule up.
• adcopilot-review — the everyday one: reads the account and says what happened, what it cost, what is wasting money and what to change, then proposes the change and applies it when you say yes, reads back what the change's own result does not show, and proposes the next fix the same way. It opens with full_audit, because one lens is one read and answers what a dozen hand-written queries would, and it treats the number of reads AdCopilot sizes for one answer as something to spend rather than stay under, never as a daily limit.
• adcopilot-fix-checks — the fixes for the checks an AdCopilot audit flagged, when you send the question from the audit page's or an email's "Fix all three" or "Fix this" button. It says first what the fixes cost and what today's operations cover, takes the checks foundation first (counting results before anything judged by them), reads only what each fix needs rather than running the audit again, and puts each fix to you as one yes/no, with at most five rows of any list. A search-term check goes to the never-show-for words, zero-conversion keywords to a pause, and a conversion-tracking check to the steps AdCopilot can take or the clicks in Google Ads it cannot. Each change is read back, with how to undo it, before the next check.
• adcopilot-docs — answers questions about AdCopilot itself from your live workspace rather than from memory: which products it reaches, how many look-ups are left today and what happens when they run out, which plan you are on, what it is allowed to change, where data goes, and what to do when a call fails. Plans and prices are linked, never quoted. It answers from that one look at your workspace, without reading your accounts or starting another skill, and says what AdCopilot can do as one list. When the question pointed at something a read of your account would answer, it ends on one question offering that read; after a question about look-ups, billing, privacy or safety it offers nothing.
• adcopilot-seo — answers what Google search makes of your site, through Search Console: which pages earn clicks and which earn nothing, what people typed to find you, whether a sitemap is being read, and when a page was last crawled. It is written around the readings that mislead — the sitemap's dead "indexed" column, an average position that is not a rank, impressions that are not demand — and it says plainly what it cannot see: there is no site-wide coverage list and no penalty read, so it asks you for Search Console's Pages export rather than guessing. Once an edit is live it offers to inspect the page again a few days later, and with Google Ads connected it offers to set the searches you pay for beside the ones that already bring you organic clicks.
• adcopilot-meta — for a question about Meta ads (Facebook ads, Instagram ads) or about Meta and Google together. AdCopilot has no Meta integration (one is on the roadmap, with no date), and Meta publishes a connector of its own for Meta ads, so this skill looks for Meta's connector in the conversation first. When it is not there, it says what it is and how to add it, links Meta's help page and AdCopilot's guide, and states nothing about Meta's terms that Meta has not published. When it is there, Meta's figures come from Meta's connector and Google's from AdCopilot, each labelled with where it came from; nothing read from one is sent to the other; and any change through either connector is proposed first, one platform at a time (for a hard stop, set both connectors' write tools to ask, as at the top of this page). AdCopilot never writes to Meta.

One agent, which Claude hands a job to when it is too big for the conversation:

• adcopilot-auditor — a full account audit end to end, returning findings with the numbers behind them and the changes worth making. It reads and proposes only: it holds no write tool, so it cannot apply anything, and the conversation that asked for it takes your yes.

Together with the connector registration above, the commands, skills and agent above are what the plugin ships at this version.

Every morning, without asking

Every command above, and the connect, launch, measure and fix-checks skills, make one short offer to turn a morning check of the account into a daily habit when AdCopilot's own answer hands them the recipe for your AI client (routine.schedule): an account with a campaign switched on, no schedule reported yet, and a client AdCopilot gives scheduling steps for, which today means Claude. AdCopilot gives none for Cursor, ChatGPT or another client, and there the plugin makes no schedule offer of its own; in Cursor, when AdCopilot's answer asks for an offer of a check-in or a summary, the plugin makes that one as AdCopilot words it. The offer comes, as a paragraph of its own, only in a reply that asks you no yes/no on a fix: the reply that reads back the first fix you approved, where it stands in for the next fix's yes/no (the next fix is named, and proposed in the reply after), or at the close of a reply that proposes none. When that fix was for a finding the morning check also reads (the searches that spent with no sale, a campaign out of budget, a disapproved ad, a drop against the 7-day average, a change nobody asked for, except on Free's 10 a day, where the check leaves what changed for the chat), it is tied to it: a check that runs by itself every weekday at 8:07 would have caught it on its first morning. With any other finding, or none, the offer closes the reply instead, without that claim. In claude.ai, Cowork or the desktop app it is a Claude scheduled task; in Claude Code, a routine made with /schedule, which it offers to create for you. Say "schedule it" and it walks you through the steps; say no and it does not offer again in that conversation, asks once whether your Claude has scheduled tasks, and records the answer, so a no pauses the offer for a week and a Claude with no scheduled tasks ends it. It records that answer only from Claude, because AdCopilot keeps it for the whole workspace. The offer stops for good once AdCopilot reports a schedule — one you recorded with it, or a scheduled run that has checked in on two different days.

The instructions you save are AdCopilot's own morning-check recipe, word for word, filled in with your account. A run reads about six or seven times, and each read counts toward your workspace's daily operations; on a Monday, the daily check and the weekly summary together can use all of a Free workspace's 10. On Free, and on a trial held to Free's 10 a day, an analysis such as budget pacing counts 2 operations and a single read 1, so all five reads would come to about 8 to 10 of Free's 10, some days all of them; there the run makes its first four reads only, about 6, leaving what changed for the chat, so the fix it ends on still fits the same day. On a paid plan or a running trial every read counts 1. If AdCopilot already emails you its daily check-in, that keeps coming as well; the Routine card on AdCopilot's Home page pauses it if you want only one. Scheduled tasks need a Claude plan that has them; on Claude's Free plan, and in Cursor, AdCopilot's emailed daily check-in, when it is on, is the morning check.

A scheduled run is told not to change anything. The instructions adcopilot-daily gives you are read-only and ask no questions; a fix it finds is a question for when you open the report. AdCopilot holds a scheduled run to reads as well: once a run's first call is get_org_context with source: "claude-scheduled", AdCopilot refuses every tool that changes Google Ads, Analytics, Tag Manager or Search Console on that connection for the rest of the run, up to 20 minutes, whatever Claude allows (AdCopilot's own notes aside). It knows a run is scheduled only from that first call, so a run that skips it or sends another source is not held, and a yes typed in the run's own conversation can be refused while the run is on; say it again in a new conversation. Claude Code adds one more hold: AdCopilot marks set_campaign_status, the tool that pauses a campaign or switches one on, as needing a person, so Claude Code (version 2.1.214 or later) will not use it in a run on your computer with nobody there to answer, such as claude -p. The plugin's skills pause or switch on a campaign only with that tool, never with a status in a change to the campaign's settings (update_campaign), and the mark does not hold that change. A Claude Code routine runs its tools without asking, and so does a scheduled task switched to Automatically approve; in those, the first call and the instructions are what keep the run to reads, so keep them as written. In claude.ai, Cowork and the desktop app, setting AdCopilot's other Write/delete tools to Blocked, every one but the two AdCopilot tools below, stops a change outright, in every chat as well as in the run.

The one setting a scheduled task needs in Claude. In claude.ai, Cowork and the desktop app, a run with nobody there stops at the first tool Claude asks about. So the set-up's first step is in AdCopilot's Tool permissions (Customize, then Connectors, then AdCopilot): the Read-only tools on Always allow, and under Write/delete tools two of AdCopilot's own, “AdCopilot: what is connected and where you are” and “AdCopilot: save business notes and progress”, on Always allow too. They keep AdCopilot's own notes and never change Google Ads; every other Write/delete tool stays on Needs approval, so Claude asks before each change (Cursor has no such screen; see Approvals in Cursor above). Claude has listed the first of the two under Write/delete tools since AdCopilot v2.42.3, and it is every run's first call, so a task set up with only the read-only tools on Always allow, as the plugin's steps said up to 0.2.13, stops there; setting those two tools to Always allow is the whole fix.

What it will not do

• Switch on a campaign it built. Every campaign it builds is created paused. You switch it on in Google Ads yourself.
• Delete anything but a negative keyword. The connector refuses a REMOVED status server-side: the campaign, ad group, ad and keyword tools accept only ENABLED or PAUSED, and the asset tools refuse a remove outright. Pausing is as far as it goes for all of those, and it is the server that enforces that rather than the assistant's good manners. The one exception is deliberate: each of the three ways to add a negative keyword has a removal behind it, so a negative can be taken back out — which is what makes "you can undo this" true when AdCopilot says it. Attaching a shared negative-keyword list is the genuinely one-way action; there is no detach tool, and a list is detached in Google Ads under Tools, Shared library, Exclusion lists.
• Change your account unasked, while your AI client asks before AdCopilot's write tools. Reads run freely, and AdCopilot proposes each change first. For a hard stop, set your AI client to ask before AdCopilot's write tools: Needs approval in claude.ai, Cowork and the desktop app; in Claude Code, leave them off the allowlist and the session out of auto and bypassPermissions mode; in Cursor, use the Allowlist run mode and keep them off the allowlist (see Approvals in Cursor above; Cursor's cloud agents never ask). Take the question away and changes to what already exists, a budget or a switched-on campaign among them, apply without it; only a new campaign is still built paused. The one exception is set_campaign_status, the tool that pauses a campaign or switches one on: Claude Code (version 2.1.214 or later) asks before every use of it, whatever its settings, and a run with nobody there to answer cannot use it; the Claude desktop app may also ask every time for it. The plugin's skills pause or switch on a campaign only with that tool, never with a status in a change to the campaign's settings (update_campaign), which follows your settings like any other change.

Support

• Something wrong with the plugin (a command, a skill, this README): open an issue here.
• Something wrong with the connector (sign-in, a tool call, your account): support@adcopilot.cloud.

AdCopilot version

0.2.16 (2026-10-23, written against AdCopilot v2.44.1, which must be live before this version is published; v2.44.0 was the release in production when this text was written): the release checklist below must be run before this version is tagged, and none of its steps had been run when this text was written, the structural tests and claude plugin validate --strict aside. The listing's name and description now name every Google product people search for. No change to what a customer or the model reads: no skill, command, agent, tool or .mcp.json says or does anything different. In the manifest, the display name becomes "AdCopilot for Google Ads, Google Analytics (GA4), Google Search Console & Google Tag Manager". The description leads with what the agent does, and each claim in it was read against AdCopilot v2.44.1's tools: Keyword Planner data (get_keyword_ideas, get_keyword_metrics, get_keyword_forecast), Search and Performance Max builds (create_campaign, create_performance_max_campaign), the Merchant Center products that cannot show in Shopping (shopping_product_issues, new in v2.44.1), and negative keywords as the only thing AdCopilot removes. It keeps the approval sentence, with its Cursor clause, and the negative-keyword sentence, word for word, because the structural tests require both. The keywords grow from twenty to twenty-eight: keyword-planner, keyword-research, merchant-center, google-shopping, shopping-ads, seo, local-services-ads (lsa_leads and lsa_rate_lead, new in v2.44.1 and on by default) and google-ads-reports. The marker in every file moves to claude-plugin/0.2.16, and so does the plugin.version the eval fixtures' get_org_context answers carry, because the structural tests hold both to the manifest's version; those are the only changes to a skill, command, agent or eval file. No eval case was run for this text: what the model reads is 0.2.15's with the version number moved.

0.2.15 (2026-10-23, written against AdCopilot v2.44.0, deployed 2026-10-22): the release checklist below must be run before this version is tagged, and none of its steps had been run when this text was written, the structural tests and claude plugin validate --strict aside. No change to what a customer or the model reads: no skill, command, agent, tool or .mcp.json says or does anything different, and nothing in the manifest changes but the version. The plugin directory's pre-submission checklist says to keep every file that is not an image or a font under 256 KiB, or the version is held for a reviewer, and to keep the plugin to 512 files or fewer. At 0.2.14 the structural tests were one file, tests/test_structure.py, of 273,469 bytes, 11,325 over that line; the next largest file, the README at 93,719 bytes, was well under it, and the plugin had 242 files. That file is now six files by topic, tests/test_daily_habit.py, test_unattended_run.py, test_manifest_and_marker.py, test_review_and_audit.py, test_handoff_and_approval.py and test_eval_cases.py, the largest 66,136 bytes, with the helpers they share in tests/structure_helpers.py. The tests moved verbatim, the same classes, test names and assertions: 252 tests before and 252 after. The one edit inside them is that the three tests that pin this README's 0.2.14 note now look that note up by its own version, not the manifest's, so a release that changes none of what it pins does not have to repeat it. A new tests/test_plugin_size.py fails, naming the file, on any file that is not an image or a font and is over 250 KiB, or on a plugin of more than 480 files, so this repository now measures the limit itself; the plugin has 249 files. The marker in every file moves to claude-plugin/0.2.15, and so does the plugin.version the eval fixtures' get_org_context answers carry, because the structural tests hold both to the manifest's version; those are the only changes to a skill, command, agent or eval file. No eval case was run for this text: what the model reads is 0.2.14's with the version number moved.

0.2.14 (2026-10-23, written against AdCopilot v2.44.0, deployed 2026-10-22): the release checklist below must be run before this version is tagged, and none of its steps had been run when this text was written. Changes to what the plugin tells the model, one new skill and two new cases, and nothing to the manifest but the version. First, and the reason this version goes out first: a morning check scheduled from the plugin no longer stops at its first call. Since AdCopilot v2.42.3, Claude lists get_org_context, titled “AdCopilot: what is connected and where you are”, under Write/delete tools, and up to 0.2.13 the set-up put only the read-only tools on Always allow, so a run set up that way waited at its first call for an approval nobody was there to give. The daily skill's first set-up step for Claude now says what AdCopilot's own step says (schedule_recipe.ALWAYS_ALLOW_STEP): in Customize, Connectors, AdCopilot, Tool permissions, the Read-only tools on Always allow, and under Write/delete tools “AdCopilot: what is connected and where you are” and “AdCopilot: save business notes and progress” on Always allow too, because they keep AdCopilot's own notes and never change Google Ads; every other Write/delete tool stays on Needs approval, so Claude still asks before each change (Cursor has no such screen; see Approvals in Cursor above). This README's morning section says the same, and the advice to set the other write tools to Blocked leaves those two out, since blocking them would stop every run. The instructions the set-up hands over are AdCopilot v2.44.0's morning-check recipe word for word, and their first call is now: Call get_org_context first, with source "claude-scheduled" and task "AdCopilot morning check". AdCopilot counts only a run whose first call also names that task as its morning check, so a customer's own scheduled task is a scheduled run, not the morning check, and no longer ends the morning-check offer; the daily skill's run sends the task whenever the instructions open with "AdCopilot morning check", even when an older saved copy of the recipe does not name it, and never for a scheduled task worded any other way, and daily-scheduled-run now fails a first call without it. Second (#22), every file that sends the plugin's marker, source set to claude-plugin/0.2.14, now also says, in one sentence that is the same in each, that a scheduled run, started by a Claude scheduled task or a Claude Code routine with nobody there to answer, sends source: "claude-scheduled" instead, never claude-plugin. Before, only the daily skill's run said so, and a scheduled task in the customer's own words, answered by the review skill, reached AdCopilot as a conversation with a person in it. A new case, review-scheduled-unmarked, owned by adcopilot-review, is that run. What this version does not change: the daily skill's run still calls no save_org_context. Every schedule set up before 0.2.14 keeps that tool asking first, and a scheduled run cannot answer an approval prompt, so a run that kept a note would stop there and never finish. The ban lifts only once AdCopilot has told the people who already schedule the check to set the two tools to Always allow, and that notice has been measured. The third to eighth changes (#24) come from one conversation on 2026-10-20, on a workspace with 10 operations a day: the audit page's "Fix all three in Claude" question was answered with three menus of numbered options and up to three related reads per check, the daily-habit offer came after the first of the three checks, and the day's operations ran out before the fix the customer had agreed to could run. Third, a new skill, adcopilot-fix-checks, for the questions AdCopilot's audit page and emails send: "My AdCopilot audit of Google Ads account … flagged three checks to fix first", or one that "failed" or "warned on" a check, each named with its ID in brackets. It says first what the fixes cost in operations (each check's read, plus one call per keyword a change pauses or per campaign or list it adds never-show-for words to, plus a read-back) and what today covers, recommends the order itself, foundation first (counting results before anything judged by them), reads each check with its own lens and runs no new audit, puts each fix to the customer as one yes/no with at most five rows of any list, reads back every change with how to undo it, and makes the daily-habit offer only once a fix has been applied and read back. A search-term check (G18 and its family) goes to the never-show-for words, zero-conversion keywords (G-WS1) to a pause, and a conversion-tracking check (G43 and its family) to the steps AdCopilot can take, or to the clicks in Google Ads where it cannot make the change. Before a call that would use the last of today's operations, it says what that call covers and asks first. Its case, fix-checks-three-checks, is new and had not run when this text was written. Fourth, the daily-habit offer, in all eight files that carry it (fix-checks carries the block itself) and in adcopilot-review, is made in a reply that asks the customer no yes/no on a fix: the reply that reads back the first fix they approved, where the offer stands in for the next fix's yes/no (the next fix is named in one line and proposed in the reply after), or the close of a reply that proposes none. A fix for a finding the morning check also reads is still what lets the offer say the check would have caught it; on a workspace with 10 operations a day, whose morning check leaves what changed for the chat, a change nobody asked for gets the close instead. Fifth, one decision per reply. adcopilot-review and /adcopilot:negatives end on one yes/no on the step they recommend, never a numbered menu or a request to pick the order; they show at most five rows of any list, costliest first, then "and N more"; and in Claude Code they put that yes/no with the AskUserQuestion tool. adcopilot-review also says what a call covers and asks first before the one that would use the last of a short day's operations. Sixth, related_reads: every surface now runs at most one that bears on the question (it was three), as AdCopilot's own instructions say from v2.43.3. Seventh, /adcopilot:negatives no longer carries disable-model-invocation, so the model can start it when the customer asks to block searches; its description now says checks from an AdCopilot audit are the fix-checks skill's and a question about how the ads are doing is the review's, which is what 0.2.12's flag was for. The fix-checks steps apply its write steps with the search-term read they already hold and do not start it, which would read the last seven days again. Eighth, the unattended morning check, on a workspace with 10 operations a day, makes its first four reads only, leaving what changed for the chat, so the fix its report ends on still fits the same day: at 0.2.13's weights the four count 6 of Free's 10, where the five count 7 and a run about 8 to 10, and the daily skill's run and set-up and this README say so. Ninth (#25, #28), the audit's count. AdCopilot v2.44.0's audit has seventy checks, each listed, and grades its score over the checks that apply to the account. The review skill and the auditor say seventy where they said seventy-three, and give coverage as the count the result gives, "from N of the M checks that apply", still never as a percentage. The eval mocks' audit results carry v2.44.0's counts, and tests/test_check_count.py fails on any count of the checks above seventy, except in the eval tool snapshots (_tools.json), which stay as they were taken until they are refreshed whole from the server (issue #5). Tenth (#26), an audit finding's fix. From v2.44.0 a finding can carry its fix in recommended_actions: a ready call (kind tool), its IDs read from the account and an audit's negatives Exact, or a draft (kind skeleton) whose needs says what only the customer can give, such as the searches to block or the campaign to take budget from. The fix-checks and review skills propose a ready call as it stands, with the condition its why gives, ask for a draft's needs in their one question and never fill it in themselves; the review skill's own PHRASE rule is now for the negatives it writes itself, so it never rewrites an audit's Exact call. Release order: every server half is live, AdCopilot v2.44.0 included, so nothing on the server waits for this version. From v2.43.3 AdCopilot hands an audit question to the fix-checks steps on a running account and tells a Claude that called with no marker, or with the bare claude-plugin, to load the installed skill first, without handing it the turn; against an older server the skill would still run, but next_step would name only the review steps. The marker in every file moves to claude-plugin/0.2.14, and so does the plugin.version the eval fixtures' get_org_context answers carry. No eval case had been run for this text when it was written.

0.2.13 (2026-10-20, written against AdCopilot v2.43.1, deployed 2026-10-20 17:51 UTC): the release checklist below says its steps must be run before this version is tagged, and 0.2.13 is released by the founder's choice on 2026-10-20 ("do the plugin release") without its real-account steps 1 to 6, as 0.2.10 and 0.2.12 were, and without the eval suite, as 0.2.10 was, because the change is text only. Step 7: both claude plugin validate --strict runs pass, and so do the structure tests in tests/test_structure.py; neither the suite nor the tools-only ablation has been run for this text. One change to what the plugin tells the model (#23), and nothing to the manifest but the version: Free's weighted operations. From v2.43.1 AdCopilot counts a Free workspace's calls in weighted operations: a full audit or an account health score counts 4, an analysis such as budget pacing 2, listing audiences 2, and every other call 1, except the four that never counted (AdCopilot's own get_org_context and save_org_context, get_resource_metadata and list_accessible_customers), which still count 0, while a paid plan and a running trial count every call 1, and a trial held to Free's 10 a day (paused for its card, or waiting for its first charge) counts as Free does. The daily skill keys its cost on get_org_context's org.ops_weighted, which v2.43.1 adds to the org block, because a held trial's plan still reads pro. The daily skill's cost (in its run and in its set-up), this README's, /adcopilot:audit's (6 of Free's 10 for its two calls) and /adcopilot:weekly's (about 5 or 6 for its four reads), each with 1 or 2 more for every related read run, now say so: the morning check's five reads come to 7 operations at that table, and a run to about 8 to 10 of Free's 10. Nothing changes for a paid plan. AdCopilot sends ops_weighted only while its weighting switch is not off (v2.43.1 runs it at free); set back to off, the daily skill says reads again on its own, but this README and the two commands would overstate Free's cost, so this text goes back with the switch. .gitignore now keeps Python's compiled caches out, and tests/test_structure.py holds each sentence and fails on a tracked cache. The marker in every file moves to claude-plugin/0.2.13, and so does the plugin.version the eval fixtures' get_org_context answers carry. AdCopilot reads any version from 0.2.7 on, and v2.43.1 is live, so nothing on the server waits for this version.

Documentation truncated — see the full README on GitHub.