Glitch MCP
Everything Glitch can do, available where you work. Connect an AI assistant over MCP, or call the REST API from your own code. The same permissions as the web app, the same audit trail, and server side limits on budgets and launches.
https://mcp.glitchads.ai/mcp
https://api.glitchads.ai/v1
MCP requests use streamable HTTP and REST requests are plain HTTPS. Both take an OAuth 2.1 bearer token or an API key.
Both cover Google Ads campaigns. Meta campaigns are not available through the API or the MCP server.
You do not need to be a developer. If you can paste a URL into the settings of your assistant, you can connect Glitch, and the quickstart and the client guides assume nothing more. The reference pages are there for when you or your team want to script things.
API and MCP access are included with your plan. There is no separate fee.
| Area | Tools |
|---|---|
| Discover | Organizations, account overview, business profile. |
| Read | Performance, campaigns, keywords, search terms, reports, strategy documents, recommendations, and for Owners the action log. |
| Detect | Ten waste and opportunity detectors. They propose, they do not act. |
| Act | Apply recommendations and undo changes, budgets, names and target CPA, pause, resume, launch, negative keywords, draft campaigns, new ads, report and strategy generation. |
| System | Polling for work that runs in the background, and for writes waiting on approval. |
The full list is on the tool reference.
A connection covers every organization the authorising user belongs to, and each request names the organization it acts in. Membership and role are checked live on every request: an organization the user does not belong to is refused, and in each organization the connection can never exceed the role the user holds there. The one addition is for Glitch AdOps staff, who can also read, and only read, the client organizations assigned to their team; glitch_list_organizations marks those rows access adops_team and names the team. glitch_list_organizations shows the organizations a connection covers, with the role in each; an assistant is expected to ask which organization to work in before its first call and stay in it for the session.
Your role in each organization caps what can happen there: a Member reads and can generate reports, an Admin also writes and manages everyone's keys, and an Owner also reads the action log and exports the audit trail.
API keys stay bound to a single organization. For scripted client work, create one key per client organization, so access and audit stay separated per client and a wrong-client write is impossible with a given key.
Removing somebody in Glitch cuts their API and MCP access on their next request.
dry_run: true and return exactly what would change. Executing is a second, explicit call. The other write tools build draft campaigns, add ads, generate reports and strategies or reverse an earlier change, and run without a preview. An ad added to a live campaign starts serving.action_id when executed, and glitch_undo_action reverses it. A recommendation that changes many keywords at once reverses one change per handle, and action_ids carries them all. An executed state change finishes in the background and still carries its action_id. Draft campaigns, reports and strategies change nothing live; a new ad is removed in Glitch.An Owner or an Admin can require a person to approve every API and MCP write before it runs, under Account, API Keys. It is off by default, and while it is off a credential carrying campaigns:write or recommendations:apply can change a live account itself, so grant them deliberately.
| Scope group | Data it can touch |
|---|---|
*:read |
Campaign structures, performance metrics, search terms, reports, strategy documents, recommendations, your business profile, and with the Owner-only audit:read, the action log and audit export. Nothing changes. |
reports:generate |
Triggers report and strategy generation. Reads nothing new. |
campaigns:write, keywords:write, recommendations:apply |
Campaign settings, states, budgets within their limits, new campaigns and ads, negative keywords, and applying recommendations or undoing changes. Each is a separate grant. |
Tokens are short lived and audience bound to Glitch, and are never forwarded to Google Ads or anywhere else. API keys are hashed at rest, shown once, expire by default and can be revoked at any time. Glitch keys are being registered with GitHub secret scanning; once that is active, a key that reaches a public repository is revoked automatically.
Organization isolation is enforced on every request and every object lookup, and it is tested in CI on every release.
GDPR: a Data Processing Agreement is available on every plan; API data is covered by the same deletion and access-request flows as the rest of the product. SOC 2 Type II controls are designed in, with the audit programme underway; a security review pack is available to enterprise customers.
Tool names, parameters and REST paths are stable. Changes within v1 are additive: new tools, new optional parameters, new response fields. Read responses so that an unfamiliar field is ignored rather than fatal.
Anything that would break a working client means a new major version alongside this one, not a change inside v1.
payment_required (402), a dry run reports it as blocked_by, and a go-live reached another way, such as undoing a pause, fails with the reason payment_required. Pausing is never refused.google_ads_connection_broken: the Google login behind the organization's Google Ads account was revoked or deleted, and the account's owner reconnecting Google Ads in Glitch is the fix.google_ads_refused, carrying Google's own explanation, and leaves nothing behind to undo. A name you give a new campaign is kept.