How do I use adwhiz-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@adwhiz-mcp What's the AI recommending I do right now?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

adwhiz-mcp

by DEXUN-inc

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

DEXUN AdWhiz MCP Server

Let Claude Desktop / Cursor / any MCP-aware client talk to your DEXUN AdWhiz account. Ask Claude things like:

"List my connected ad accounts." "What's the AI recommending I do right now?" "Have there been any sign-ins from new IPs this week?" "How close am I to my API rate limit?"

Read-only for now (v0.1) — Claude can see your AdWhiz state but can't apply changes or pause campaigns. Mutation tools land in a later version once the optimizer exits shadow mode.

What you need

Node.js 18 or newer (node --version)
A DEXUN AdWhiz account (sign up free)
A DEXUN AdWhiz API key — generate one at /settings#api-keys
Either:
- Claude Desktop (recommended)
- Cursor with MCP enabled
- Any other MCP-aware client

No npm install required. The server is a single Node script with zero runtime dependencies.

Related MCP server: Google Ads MCP Server

Install

Claude Desktop

Clone or download this repo somewhere stable on your machine:

git clone https://github.com/dexun-inc/adwhiz-mcp.git ~/.adwhiz-mcp

Open Claude Desktop's MCP config file. On macOS:

~/Library/Application Support/Claude/claude_desktop_config.json

On Windows:

%APPDATA%\Claude\claude_desktop_config.json

Add the adwhiz entry to mcpServers:

{
  "mcpServers": {
    "adwhiz": {
      "command": "node",
      "args": ["/absolute/path/to/.adwhiz-mcp/src/index.mjs"],
      "env": {
        "ADWHIZ_API_KEY": "dxk_live_PUT_YOUR_KEY_HERE"
      }
    }
  }
}

Replace the path with where you cloned the repo, and the API key with one from /settings#api-keys.

Quit Claude Desktop completely and reopen. The 5 AdWhiz tools should now show up when you start a new conversation.

Cursor

Same git clone step.
Open Cursor → Settings → Features → Model Context Protocol → Add server.
Use the same command + args + env shape as Claude Desktop.

Other MCP clients

Any client that follows the MCP spec can use this. The server speaks plain JSON-RPC 2.0 over stdio. Tell the client to run node /path/to/src/index.mjs and set ADWHIZ_API_KEY in the spawn environment.

What Claude can do

Tool	Use when the user asks
`list_ad_accounts`	"What accounts do I have connected?" / "Show me my Meta accounts"
`list_recommendations`	"What does the AI recommend right now?" / "Anything to do today?"
`get_savings_summary`	"How much has AdWhiz saved me?" / "Is the AI actually working?"
`get_recent_activity`	"What happened this week?" / "Any sign-ins I didn't make?"
`get_quota`	"Am I close to my rate limit?" / "How much API quota do I have?"

All five are read-only. They never apply budget changes, pause campaigns, or revoke keys. To do those things use the dashboard.

Environment

Variable	Default	Notes
`ADWHIZ_API_KEY`	(required)	`dxk_live_` or `dxk_test_`. Generate at /settings#api-keys.
`ADWHIZ_BASE_URL`	`https://app.7275.com`	Override for self-hosted / staging environments.

Troubleshooting

Claude says "Server adwhiz is not responding" or the tools don't appear. Run the script manually to see stderr output:

ADWHIZ_API_KEY=dxk_live_... node /path/to/src/index.mjs

It should sit idle waiting for stdin. If it errors immediately, the message tells you what's wrong (most commonly: API key missing or node is too old).

Tools error with "Unauthorized". Your API key was revoked or you copied it wrong. Generate a fresh one at https://app.7275.com/settings#api-keys.

Rate limited. You're hitting your plan's per-key RPM cap (60/120/600/3000 RPM by tier). Either wait for the window to reset (get_quota tells you when) or upgrade.

Security model

The MCP server runs locally on YOUR machine. Your API key never leaves your machine.
All HTTP requests go directly to app.7275.com over HTTPS.
Claude sees only the data the tools return — same data your dashboard shows you.
This server is open source. Audit it before installing on a sensitive machine.

Versioning

v0.1 — Read-only tools: list accounts / recommendations / activity / quota / identity.
v0.2 (planned) — apply_recommendation once auto-apply is calibration-gated.
v0.3 (planned) — pause_campaign + change_budget direct mutations.

License

MIT — see LICENSE.

Issues / questions

Bug reports + feature requests: open an issue on the main repo or email service@7275.com.

Privacy Policy

This extension talks only to the DEXUN AdWhiz API (https://app.7275.com/api/v1) using the API key you configure. It reads your ad-account metadata, AI recommendations, savings summary, and audit events — it never modifies campaigns or spends money, and it sends no data to any third party.

Full policy: https://www.7275.com/en/legal/privacy

Available Tools

5 tools

get_quotaGet API quota statusA

Read-only

Get the current rate-limit window for this API key — how many requests/min you're allowed (tier-dependent), how many you have left, and when the window resets. Use this to budget batch operations or diagnose why a previous tool call got rate-limited.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds no conflicting information and reinforces the non-destructive nature by describing it as a status query.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, two sentences, and front-loads the key action (getting rate-limit window). No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description states what information is returned (window, remaining requests, reset time). This is sufficient for the tool's simple purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so there is nothing to describe. The description correctly omits parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: retrieving the current rate-limit window, tier allowance, remaining requests, and reset time. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly mentions when to use the tool (to budget batch operations or diagnose rate-limiting) and implies it is a diagnostic read operation. This gives clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recent_activityGet recent account activityA

Read-only

List the user's most recent security + system audit events (sign-ins, API key changes, OAuth connections, subscription changes, AI changes applied). Use this when the user asks 'what happened recently' or 'did anything change'. Optional kind filter restricts to one event type (e.g. 'sign_in').

ParametersJSON Schema

Name	Required	Description	Default
`kind`	No	Filter to one event kind. Valid values: 'sign_in', 'sign_out', 'password_changed', 'api_key_created', 'api_key_revoked', 'ad_account_connected', 'ad_account_disconnected', 'ad_account_token_expired', 'subscription_changed', 'subscription_canceled'.
`limit`	No	How many events to return (default 20, max 200).

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint: true, and the description's verb 'List' is consistent. No further behavioral details (e.g., rate limits, side effects) are needed given the read-only annotation. The description adds context about event types but does not go beyond annotation-covered behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and followed by usage and filter explanation. Very compact without missing key information; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with two optional parameters and no output schema, the description covers purpose, usage, and filter semantics. No output format is described, but that is unnecessary given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters have full descriptions in the schema (kind with valid values, limit with default and max). The description's mention of 'kind filter' and example 'sign_in' is redundant with the schema, adding no new semantic information beyond what is already provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states a specific action: 'List the user's most recent security + system audit events' and provides a clear usage trigger: 'Use this when the user asks "what happened recently" or "did anything change"'. This differentiates it from sibling tools like list_recommendations and get_savings_summary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly provides a when-to-use condition: 'Use this when the user asks...' but does not mention when to avoid or name alternative tools. The condition is clear and actionable, though it lacks explicit alternatives or negative guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_savings_summaryGet savings summaryA

Read-only

Get the user's bottom-line: how much money the AI has saved them across all campaigns, broken down by time window (this month, last 7 days, lifetime). This is the headline number on their dashboard. Use this when the user asks 'is this working' / 'how much has it saved me' / 'what's the ROI'.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnlyHint and destructiveHint. Description adds the time-window breakdown and headline context, but does not describe return format or potential edge cases, so 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that are direct and front-loaded. Immediately states purpose, then adds usage examples. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description clearly explains what is returned (savings amount, broken down by time window) and gives context for when the agent should use it. Sufficient for a simple read-only summary tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has zero parameters, so baseline is 4. No parameter details needed, and description adds no conflicting info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool gets the user's total savings across campaigns, with breakdown by time window. Distinct from sibling tools like list_ad_accounts and get_quota.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly gives example user queries that should trigger this tool ('is this working', 'how much has it saved me', 'what's the ROI'), making when-to-use unmistakable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_ad_accountsList connected ad accountsA

Read-only

List every advertising account the user has connected to DEXUN AdWhiz. Returns one row per account with platform (google_ads / meta_ads / tiktok_ads), human-readable name, and connection status. Use this when the user asks 'what accounts do I have' or wants to refer to one of their accounts by name in a follow-up question.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces the read-only nature by stating it only lists accounts, adding no contradictory behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and direct, using two sentences to convey purpose, output fields, and usage triggers without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While there is no output schema, the description enumerates the returned fields (platform, name, status). This is sufficient for an agent to understand what the tool returns, though a formal schema would be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so no parameter-specific documentation is needed. The description correctly implies that no arguments are required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists connected ad accounts, specifying the returned fields (platform, name, status). It is distinct from sibling tools like list_recommendations or get_savings_summary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly indicates when to use it: when the user asks 'what accounts do I have' or wants to refer to an account by name. This provides clear usage context and differentiation from the other listed tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_recommendationsList AI optimization recommendationsA

Read-only

List the AI's current open optimization recommendations across all the user's connected accounts. Each recommendation is one campaign-level action (increase budget / decrease budget / pause) with the predicted ROAS, confidence, and reason. Use this when the user asks 'what should I do' or 'what does the AI recommend'. Recommendations refresh daily.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly and non-destructive behavior. The description adds useful context by noting recommendations are 'current open' and 'refresh daily', which helps set expectations without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: it states the purpose, the content of each recommendation, when to use it, and the refresh cadence in three sentences without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even though there is no output schema, the description fully specifies the return shape: each recommendation includes action, predicted ROAS, confidence, and reason. It also defines the scope as all connected accounts, making the tool self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters in the input schema, so there is nothing to explain. The description correctly omits parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' and clearly identifies the resource as 'AI optimization recommendations' across all connected accounts. It clearly differentiates from siblings like list_ad_accounts and get_recent_activity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use the tool with trigger phrases like 'what should I do' or 'what does the AI recommend'. It does not explicitly mention when not to use it or compare with alternatives, but the guidance is still clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.2.0Sep 8, 2026
- First observedget_quota
- First observedget_recent_activity
- First observedget_savings_summary
- First observedlist_ad_accounts
- First observedlist_recommendations

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored 2026-09-08 07:25 across 5 tools

Disambiguation5/5

Each tool addresses a distinct aspect: accounts, recommendations, savings, activity, and quota. There is no ambiguity or overlapping purpose, making it clear which tool to select for a given query.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (list_* and get_*), with clear object names. The naming is uniform and predictable, aiding agent selection.

Tool Count5/5

With only 5 tools, the server is tightly scoped to its core purpose of providing AI-driven ad optimization insights. Each tool is necessary and none feel superfluous.

Completeness4/5

The tool surface covers the main read-only workflows: listing accounts, getting recommendations, savings summary, activity, and quota. A potential gap is the lack of an 'apply recommendation' tool, but that likely falls outside the server's advisory role.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

adwhizOAuth
com.7275
Read-only MCP access to your DEXUN AdWhiz account: ad accounts, AI recommendations, savings.
Marketing AI & Machine Learning
1
onelens-mcpOAuth
io.github.astuto-ai
Query OneLens cloud-cost data in natural language: breakdowns, trends, cost centers. Read-only.
Search Cloud Platforms Finance
2
coralquery-mcp
com.clauxel.coralquery
A paid remote MCP for AI SDK data query MCP, built to return verdicts, receipts, usage logs, and aud
Observability AI & Machine Learning Payments & Billing
2
mcp-serverOAuth
io.github.adlane-app
Read-only MCP connector for Adlane workspaces, Google and Meta ad accounts and campaign reports.
Marketing Social Media Finance
1

Related MCP Servers

flin-google-ads-mcp
Marketing Search
flin-agency
A
license
B
quality
C
maintenance
Read-only MCP server for Google Ads, enabling querying campaigns, ad groups, ads, insights, and keywords without create/update/delete operations.
Updated 2 months ago (2026-08-04 08:31 UTC)
9
MIT
Google Ads MCP Server
Marketing Search
RustamFaskhutdzinau
A
license
Not graded
quality
C
maintenance
Provides read-only access to Google Ads account data including campaigns, ad groups, keywords, and performance reports. Enables querying via GAQL through an MCP interface.
Updated 3 months ago (2026-06-29 22:53 UTC)
MIT
Google Ads MCP Server
Marketing Search Finance
administrator-prog
F
license
Not graded
quality
C
maintenance
A read-only MCP server for the Google Ads API, exposing reporting tools for account summaries, campaigns, performance, search terms, and conversion actions. Enables natural-language queries to Google Ads data without write access.
Updated 2 months ago (2026-08-06 13:18 UTC)
-
HBCA Meta Ads MCP
Marketing Social Media
jmbrader
F
license
Not graded
quality
B
maintenance
A read-only MCP server for querying Meta Ads accounts through Meta's Marketing API. It provides tools to retrieve ad accounts, campaigns, ad sets, ads, and performance insights.
Updated a month ago (2026-08-09 20:33 UTC)
-