adwarp

Start with 1 prompt.

Paste it into Claude Code, Codex or Cursor. Your agent installs Adwarp, walks you through your LinkedIn app and checks the connection.

setup prompt
Set up Adwarp for me. It's the open-source ad agent for LinkedIn Ads and Google Ads: https://github.com/adwarp-dev/adwarp

1. Check that Node.js 20 or newer is installed.
2. Walk me through creating my own LinkedIn developer app with the Advertising API product: https://github.com/adwarp-dev/adwarp/blob/main/docs/linkedin-app.md
3. Save the app's client ID and secret to ~/.adwarp/config.json as clientId and clientSecret.
4. Run "npx -y adwarp auth login" and wait while I approve access in my browser.
5. Add Adwarp to the AI client I'm using right now as an MCP server that runs "npx -y adwarp mcp". In Claude Code that's: claude mcp add adwarp -- npx -y adwarp mcp
6. Check the connection by listing my ad accounts, then save the one I pick as defaultAccountId in ~/.adwarp/config.json.

Don't create or change anything in my ad accounts during setup. LinkedIn campaigns start as drafts, so nothing spends until I turn it on.
Rather run the commands yourself? Read the install guide
adwarp
GitHub

Start with 1 prompt.

Paste it into Claude Code, Codex or Cursor. Your agent installs Adwarp, walks you through your LinkedIn app and checks the connection.

setup prompt
Set up Adwarp for me. It's the open-source ad agent for LinkedIn Ads and Google Ads: https://github.com/adwarp-dev/adwarp

1. Check that Node.js 20 or newer is installed.
2. Walk me through creating my own LinkedIn developer app with the Advertising API product: https://github.com/adwarp-dev/adwarp/blob/main/docs/linkedin-app.md
3. Save the app's client ID and secret to ~/.adwarp/config.json as clientId and clientSecret.
4. Run "npx -y adwarp auth login" and wait while I approve access in my browser.
5. Add Adwarp to the AI client I'm using right now as an MCP server that runs "npx -y adwarp mcp". In Claude Code that's: claude mcp add adwarp -- npx -y adwarp mcp
6. Check the connection by listing my ad accounts, then save the one I pick as defaultAccountId in ~/.adwarp/config.json.

Don't create or change anything in my ad accounts during setup. LinkedIn campaigns start as drafts, so nothing spends until I turn it on.
Rather run the commands yourself? Read the install guide

Privacy policy

Adwarp has no accounts and no database. Your credentials and ad data stay with you, and this page lists what each part of Adwarp records.

Last updated

What this covers

Adwarp is an open-source ad agent for LinkedIn Ads and Google Ads. This policy covers its 3 parts:

  • adwarp.dev, this website.
  • The local tool, the adwarp CLI and MCP server that run on your own computer.
  • The hosted endpoint at mcp.adwarp.dev, an MCP server that calls LinkedIn for whoever connects to it. Its old address, liam-mcp.vercel.app, serves the same endpoint.

Adwarp is operated by its maintainer, Stan Rymkiewicz. There is no sign-up, no user account and no profile, so we don't know who you are unless you contact us.

The website

adwarp.dev counts page views with Vercel Analytics, which uses no cookies. It records the page you visit, the referrer, and your browser, operating system, device type and country.

That is the only analytics on the site. There are no ads, no tracking pixels and nothing that asks for personal information, and the fonts load from adwarp.dev itself. Links to other sites, such as GitHub or the Summarize with AI links in the footer, follow that site's policy once you click them.

The local tool

When you run Adwarp on your computer, it talks straight to the ad platforms: the LinkedIn and Google Ads APIs and their sign-in pages. The CLI and the local MCP server send no telemetry, usage data or crash reports to us or to anyone else. If you set up the optional creative worker for competitor ads, the tool also sends public Ad Library ad ids to that worker, which you host yourself.

Everything it keeps is on your own disk, in ~/.adwarp (an install from before the rename keeps using ~/.liads):

  • Developer app settings for each platform, in config.json and google.json.
  • OAuth tokens, in credentials.json and google-credentials.json, written so only your user account can read them.
  • The change journal, in changelog.jsonl: a log of the changes Adwarp makes and the ones you note, with entity ids, names and the fields that changed. Adwarp reads it to compare performance before and after a change. Set ADWARP_NO_CHANGELOG=1 to turn it off.

To remove all of it, delete that folder, then revoke Adwarp's access in your Google account permissions and in your LinkedIn settings.

Contact lists

When you build a LinkedIn matched audience from a contact list, whether a CSV, a Salesforce query or a HubSpot list or search, Adwarp reads the email addresses on your machine, trims and lowercases them, and hashes every address with SHA-256 before anything is uploaded. Only the hashes go to LinkedIn. The plain addresses are never sent to LinkedIn or to us.

Company lists upload company names and websites as they are. These uploads run in the local tool only, because the hosted endpoint can't read your files, your Salesforce login or your HubSpot token. Either way, you need a lawful basis to use a list for advertising.

The hosted endpoint

The hosted endpoint takes your LinkedIn developer app's client ID, client secret and refresh token as request headers. It uses them in memory to call LinkedIn for that request, and never stores or logs them. It has no database and no change journal: results go back to your MCP client, and the endpoint keeps no copy.

For each MCP request it records a Vercel Analytics custom event with 3 fields: the JSON-RPC method, the tool name on tools/call, and whether the caller brought their own credentials. It never records the credentials or the arguments to a call. As with a page view, the event reaches Vercel with the caller's IP address and user agent.

The endpoint serves no Google Ads tools, so no Google data passes through it. Its own pages on mcp.adwarp.dev count page views with Vercel Analytics, the same way adwarp.dev does.

What Adwarp can access

Adwarp reaches only the ad accounts you connect, with the scopes you approve. On LinkedIn it asks for 4: rw_ads to manage campaigns and audiences, r_ads_reporting for reports, rw_conversions for conversion tracking and w_organization_social to create the posts behind image ads. On Google it asks for 1, the Google Ads scope https://www.googleapis.com/auth/adwords. It never asks for your email, profile, contacts or messages.

Adwarp uses Google Ads data only to do what you ask: create paused campaigns, ad groups, keywords and ads, report on performance and research keywords. That data is never stored on a server we control, sold, shared, used for advertising or used to train AI models. Adwarp's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. LinkedIn data gets the same treatment.

Third parties

  • LinkedIn, for the Marketing API and the Ad Library, called with your credentials.
  • Google, for the Google Ads API and Google sign-in, from the local tool only.
  • Salesforce, only if you build an audience from it. Adwarp runs read-only queries through the sf CLI you have already signed in to, and stores no Salesforce credentials.
  • HubSpot, only if you build an audience from it. Adwarp reads contacts and companies with a private app token you create with read-only scopes, keeps that token on your machine and never writes to HubSpot.
  • Vercel, which hosts adwarp.dev and the hosted endpoint and runs the analytics above.
  • Your MCP client, such as Claude, Codex or Cursor, which receives what each tool returns and handles it under its own terms.

Each of them handles your data under its own privacy policy. Adwarp sells no data and shows no ads.

Changes and contact

For questions or a request about your data, open an issue at github.com/adwarp-dev/adwarp/issues. Issues are public, so never paste credentials or personal data there.

Adwarp holds no accounts and no stored personal data, so most requests come down to deleting your local folder and revoking access, which you can do yourself. When this policy changes, the date at the top changes with it.