Provides read-only access to Google Ad Manager (the publisher-side Ad Manager API, not Google Ads), exposing tools to list networks and their network codes, list saved reports, run saved reports and fetch their rows, and list orders and line items for context alongside report data. Reporting is asynchronous, so runs block until results are ready.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Google Ad Manager MCP list my saved reports and run the daily revenue one for last week"
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.
Read-only MCP server for Google Ad Manager. Exposes GAM reporting and inventory metadata to Claude Desktop for analytics.
Read-only by design. No tool in this server mutates anything. But that is a property of the code, not of your account — enforce it at the credential layer too by giving the authenticating user a read-only role in Ad Manager. With per-user OAuth (below) each person automatically inherits whatever permissions they already have in GAM.
Google Ad Manager is not Google Ads. This server targets the Ad Manager API (Beta), the publisher-side ad serving product. Google's own
google-ads-mcpis for the advertiser-side Google Ads API and does not work here.
Tool | Purpose |
| List accessible GAM networks and their network codes |
| List saved reports; returns the resource names |
| Run a saved report and return its rows |
| List orders, for context alongside report data |
| List line items, for context alongside report data |
Reporting in Ad Manager is asynchronous — run_report starts a long-running
operation, waits for it, then fetches rows. It blocks for up to 90 seconds; if a
report is slower than that, narrow the date range.
Related MCP server: GAM Seller MCP Node
Enable the Google Ad Manager API in a Google Cloud project.
Create an OAuth 2.0 client of type Desktop app.
Google treats desktop client secrets as non-confidential, because they ship inside distributed applications. That means they are safe to put in a user's local config — it does not mean they are safe to commit. This repository is public; a published client ID and secret would let anyone show a Google consent screen carrying our name. It grants no access to data (users still have to consent, and tokens are per-user) but it is a phishing vector. Keep both values in each machine's environment.
The genuinely sensitive value is the per-user refresh token, which is created on the user's machine and never leaves it.
npm install && npm run build
GAM_OAUTH_CLIENT_ID=... GAM_OAUTH_CLIENT_SECRET=... node dist/index.js authA browser opens for Google sign-in. The refresh token is written to:
macOS — ~/Library/Application Support/bizclik-gam-mcp/token.json
Windows — %APPDATA%\bizclik-gam-mcp\token.json
Linux — ~/.config/bizclik-gam-mcp/token.json
Add to claude_desktop_config.json:
macOS — ~/Library/Application Support/Claude/claude_desktop_config.json
Windows — %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"google-ad-manager": {
"command": "npx",
"args": ["-y", "github:Bizclik-Media/google-ad-manager-mcp"],
"env": {
"GAM_OAUTH_CLIENT_ID": "...",
"GAM_OAUTH_CLIENT_SECRET": "...",
"GAM_NETWORK_CODE": "..."
}
}
}
}GAM_NETWORK_CODE is optional — without it, ask Claude to run list_networks
and pass the code per call.
Claude Desktop bundles a Node runtime, so users do not need Node, Python, or any other runtime installed. There is no Claude Desktop build for Linux; develop and test against Claude Code, then verify on macOS or Windows.
npm run typecheck
npm run buildSmoke-test the MCP protocol without Claude:
printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' '{"jsonrpc":"2.0","method":"notifications/initialized"}' '{"jsonrpc":"2.0","id":2,"method":"tools/list"}' | node dist/index.jsThis repository is public. Two things must never be committed:
OAuth client ID and secret — see above.
Network codes, report names, advertiser names, or real report output.
These describe our commercial structure. The network code is read from
GAM_NETWORK_CODE for exactly this reason. The likeliest way this leaks is a
test fixture captured from a live report — scrub before committing.
Structurally complete and verified against the MCP protocol, but no call has
been made against a live Ad Manager account. Field names come from the
@google-ads/admanager type definitions, not from observed responses. Expect to
adjust the response shaping in src/index.ts once real data is flowing.
List Ad Manager line items, for context alongside report data. Supports a filter expression.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Ad Manager filter expression, e.g. 'status = DELIVERING'. | |
| pageSize | No | Maximum line items to return. | |
| networkCode | No | Ad Manager network code. Defaults to the configured network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. Beyond 'Supports a filter expression' it says nothing about pagination behavior, default network resolution, permission requirements, or whether results are truncated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the verb and resource, with no filler. The second sentence is thin but earns its place by signalling filter support.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description should at least hint at what is returned (line item fields) and how paging works. As written, an agent cannot tell what a response contains or how to page through results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so filter, pageSize, and networkCode are fully documented in the schema itself. The description's single mention of the filter expression adds no syntax or behavior beyond what the schema already states; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb+resource (list Ad Manager line items) and adds a purpose clause that ties it to report data. It does not explicitly distinguish itself from list_orders or list_reports, but the resource noun is specific enough for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'for context alongside report data' implies the intended moment of use (enriching report output), which is more than nothing, but there is no explicit when-not or named alternative among list_reports/run_report/list_orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Google Ad Manager networks this account can access, with their network codes. Use this to discover the network code if it has not been configured.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'List' implies a safe read, and it discloses the returned content (networks plus their codes), but it does not state whether pagination applies, whether results are cached, or any auth requirements. Adequate but shallow for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: purpose first, then the practical reason to call it. Zero filler, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema and no nested data, the description covers what is returned and why to call it. Minor gaps around pagination/volume of results, but nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the schema offers nothing to document and the baseline is 4. The description correctly implies no inputs are needed to perform the listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (Ad Manager networks) with added scope detail (the networks this account can access, with their network codes). Clear what it returns and how it differs from report/order/line-item siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use it 'to discover the network code if it has not been configured,' giving a clear triggering condition. It does not enumerate alternative tools, but none of the siblings overlap in purpose, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Ad Manager orders, for context alongside report data. Supports a filter expression.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Ad Manager filter expression, e.g. 'status = APPROVED'. | |
| pageSize | No | Maximum orders to return. | |
| networkCode | No | Ad Manager network code. Defaults to the configured network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'List' weakly implies read-only, but nothing is said about pagination/truncation behavior, ordering, auth/network requirements, or what happens when filter matches nothing - significant gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action. The trailing 'for context alongside report data' is slightly vague but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter list tool with no output schema and no annotations, the description covers the purpose and filter support but omits return shape, pagination semantics, and the meaning of the default network - gaps the missing output schema leaves unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so filter, pageSize, and networkCode are already fully documented in the schema. The description's mention of 'a filter expression' adds no syntax or constraints beyond that, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (Ad Manager orders) and hints at its role ('for context alongside report data'). However, it does not differentiate itself from siblings like list_reports, run_report, or list_line_items, so an agent cannot route between them from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'For context alongside report data' implicitly suggests using this to enrich report results, but there is no explicit when-to-use, when-not, or named alternative among the sibling list tools. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved reports in Ad Manager. Returns each report's resource name, which is what run_report takes. Use this first to find the report to run.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Maximum reports to return. | |
| networkCode | No | Ad Manager network code. Defaults to the configured network. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the return includes a resource name that run_report consumes, but says nothing about pagination behavior, result limits (pageSize max 200), or whether listing requires specific permissions. Adequate for a simple read but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, with the core action and the downstream dependency front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by stating what is returned (the resource name) and how it is used next. Pagination behavior is left implicit and not spelled out, keeping it just short of complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so pageSize and networkCode are already fully documented in the schema and the baseline is 3. The description adds no syntax or format detail beyond what the schema provides, though it does clarify what the returned resource name is for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("List saved reports in Ad Manager") and immediately ties the output to a sibling by naming run_report and the resource name it consumes. An agent can separate this from run_report without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this first to find the report to run" gives explicit sequencing relative to run_report, which is the one alternative that matters here. It stops short of naming exclusions or stating what to do when no reports exist, so it is clear context rather than full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a saved Ad Manager report and return its rows. Takes the report resource name from list_reports (e.g. 'networks/12345678/reports/42'). Reporting is asynchronous in Ad Manager; this waits for completion. Read-only — it runs an existing report definition and never modifies it.
| Name | Required | Description | Default |
|---|---|---|---|
| maxRows | No | Maximum rows to return. | |
| reportName | Yes | Report resource name, e.g. 'networks/12345678/reports/42'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description does the heavy lifting: it discloses that reporting is asynchronous, that this call waits for completion, and that the operation is read-only and never mutates the report definition. It stops short of disclosing rate limits, timeout behavior, or how results are truncated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with purpose and followed by the resource-name source, async behavior, and safety note. Slightly more than strictly necessary, but each sentence adds usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by stating that rows are returned and that the call blocks until the async job finishes. It does not describe row shape or result-size behavior beyond the schema's maxRows, but is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented, and the description merely repeats the reportName example format. The maxRows cap (1-5000, default 500) is left entirely to the schema. Baseline 3 is appropriate when structured data carries the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run a saved Ad Manager report and return its rows') and differentiates itself from the list_* siblings by making clear it executes an existing definition rather than enumerating resources. An agent can tell this apart from list_reports without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to list_reports as the source of the required reportName, which is the key precondition. It does not state when not to use it or what to do on failure/timeouts, but the practical entry condition is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0list_line_itemslist_networkslist_orderslist_reportsrun_reportScored across 5 tools
Each tool targets a distinct resource and action: list_networks, list_reports, run_report, list_orders, and list_line_items have no overlapping purpose. The descriptions explicitly cross-reference each other (list_reports -> run_report, list_networks for network code), making selection unambiguous.
All tools follow a clean verb_noun snake_case pattern (list_networks, list_reports, run_report, list_orders, list_line_items). No deviations or mixed conventions.
Five tools is a reasonable, focused set for a reporting/listing workflow, though it leans slightly thin for a platform as broad as Ad Manager. Each tool clearly earns its place with no redundancy.
The surface is entirely read-only: it can list networks, reports, orders, and line items and run reports, but has no get-single-item, create, update, or delete operations for any resource. For an Ad Manager management domain this leaves major gaps (order/line item lifecycle, creatives, inventory) that would cause agent dead ends.
Read-only MCP access to your DEXUN AdWhiz account: ad accounts, AI recommendations, savings.
GA4, Google Ads and Search Console in Claude. Read-only OAuth, multi-account for agencies.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
The HubSpot MCP Server acts as a bridge that enables AI assistants and Large Language Models to securely interact with HubSpot CRM data through natural conversation, without requiring users to understand complex API structures. It provides read-only access to standard CRM objects (contacts, companies, deals, tickets, products, invoices, and more) and their associations, secured via OAuth 2.0, allowing AI agents to perform tasks like summarizing deals, fetching company updates, and looking up record changes.
