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., "@NewsBreak Ads MCP Server show me my ad accounts"
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.
A Model Context Protocol (MCP) server for the NewsBreak Business API, built with FastMCP. This server provides tools and resources for analytics, reporting, and campaign management through the NewsBreak advertising platform.
The server provides the following tools for interacting with NewsBreak's advertising API:
get_ad_accounts - Retrieve ad accounts for specified organization IDs
get_campaigns - List campaigns with filtering and pagination support
get_tracking_events - Access pixel and postback tracking events
run_performance_report - Generate synchronous performance reports with custom metrics and dimensions
get_campaign_summary - Quick overview of recent campaign performance
Read-only resources available through URI templates:
accounts://{org_id}/ad-accounts - Ad accounts for an organization
campaigns://{ad_account_id}/active - Active campaigns for an ad account
events://{ad_account_id}/tracking - Tracking events for an ad account
Related MCP server: microsoft-ads-mcp
Python 3.10 or higher
NewsBreak for Business account
NewsBreak API Access Token
Clone or download this repository
Install dependencies
pip install -r requirements.txtConfigure environment variables
Create a .env file in the project root:
cp .env.example .envEdit .env and add your NewsBreak access token:
NEWSBREAK_ACCESS_TOKEN=your_access_token_hereLog in to NewsBreak for Business
Navigate to your account settings
Go to the API section
Generate or copy your access token
The server supports multiple authentication methods and transport options.
python server.py --help
Options:
--token TOKEN NewsBreak API access token (overrides environment variable)
--transport {stdio,http,sse}
Transport method (default: stdio)
--host HOST Host for HTTP/SSE transport (default: localhost)
--port PORT Port for HTTP/SSE transport (default: 8000)
--version Show version and exitMethod 1A: Using command-line argument (RECOMMENDED)
python server.py --token YOUR_ACCESS_TOKENMethod 1B: Using environment variable
# Ensure .env file has NEWSBREAK_ACCESS_TOKEN set
python server.pyMethod 1C: Using the run script
./run_server.shmacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Method 2A: Pass token via command-line argument (RECOMMENDED - more secure)
{
"mcpServers": {
"newsbreak-ads": {
"command": "python",
"args": [
"/path/to/newsbreak-ads-mcp-server/server.py",
"--token",
"your_access_token_here"
]
}
}
}Method 2B: Pass token via environment variable
{
"mcpServers": {
"newsbreak-ads": {
"command": "python",
"args": [
"/path/to/newsbreak-ads-mcp-server/server.py"
],
"env": {
"NEWSBREAK_ACCESS_TOKEN": "your_access_token_here"
}
}
}
}Method 2C: Use .env file (most secure - no token in config)
{
"mcpServers": {
"newsbreak-ads": {
"command": "python",
"args": [
"/path/to/newsbreak-ads-mcp-server/server.py"
]
}
}
}Note: Requires .env file with NEWSBREAK_ACCESS_TOKEN in the project directory
Restart Claude Desktop after updating the configuration.
Run as an HTTP server for remote access:
# Using command-line token
python server.py --token YOUR_TOKEN --transport http --port 8000
# Or using environment variable
python server.py --transport http --port 8000 --host 0.0.0.0
# Or using fastmcp CLI
fastmcp run server.py --transport http --port 8000Server will be available at: http://localhost:8000/mcp
Deploy to FastMCP Cloud for instant HTTPS endpoints:
# Make sure to set NEWSBREAK_ACCESS_TOKEN in cloud environment
fastmcp deploy --config fastmcp_cloud.json# In Claude or through MCP client
use_mcp_tool(
server="newsbreak-ads",
tool="get_ad_accounts",
arguments={
"org_ids": ["123456789"]
}
)use_mcp_tool(
server="newsbreak-ads",
tool="run_performance_report",
arguments={
"ad_account_id": "987654321",
"date_from": "2024-01-01",
"date_to": "2024-01-31",
"dimensions": ["date", "campaign_id"],
"metrics": ["impressions", "clicks", "spend", "conversions"],
"level": "campaign"
}
)use_mcp_tool(
server="newsbreak-ads",
tool="get_campaign_summary",
arguments={
"ad_account_id": "987654321",
"days": 7
}
)read_resource(
uri="campaigns://987654321/active"
)get_ad_accounts(org_ids: List[str])Retrieves all ad accounts for specified organization IDs.
Parameters:
org_ids: List of organization IDs
Returns: JSON with organizations and their ad accounts
get_campaigns(ad_account_id: str, page_no: int = 1, page_size: int = 50, search: Optional[str] = None, online_status: Optional[str] = None)Lists campaigns with optional filtering and pagination.
Parameters:
ad_account_id: Target ad account ID
page_no: Page number (default: 1)
page_size: Results per page - options: 5, 10, 20, 50, 100, 200, 500 (default: 50)
search: Optional search query
online_status: Filter by status (WARNING, INACTIVE, ACTIVE, DELETED)
Returns: JSON with campaigns and pagination info
get_tracking_events(ad_account_id: str, os_filter: Optional[str] = None)Retrieves tracking events (pixels and postbacks) for an ad account.
Parameters:
ad_account_id: Target ad account ID
os_filter: Optional OS filter ("IOS", "ANDROID", or "" for web)
Returns: JSON with tracking events
run_performance_report(ad_account_id: str, date_from: str, date_to: str, dimensions: Optional[List[str]] = None, metrics: Optional[List[str]] = None, level: Optional[str] = None)Generates a synchronous performance report.
Parameters:
ad_account_id: Target ad account ID
date_from: Start date (YYYY-MM-DD)
date_to: End date (YYYY-MM-DD)
dimensions: Optional dimensions (e.g., ["date", "campaign_id"])
metrics: Optional metrics (e.g., ["impressions", "clicks", "spend"])
level: Report level ("campaign", "ad_set", "ad")
Returns: JSON with report data
get_campaign_summary(ad_account_id: str, days: int = 7)Quick summary of recent campaign performance.
Parameters:
ad_account_id: Target ad account ID
days: Number of days to look back (default: 7)
Returns: JSON with campaign summary
The server is built with the following components:
server.py - Main FastMCP server with tools and resources
client.py - NewsBreak API client wrapper with authentication and rate limiting
models.py - Pydantic data models for type safety and validation
fastmcp.json - FastMCP deployment configuration
.env - Environment variables (not committed to git)
Rate Limiting: Built-in rate limiter (10 requests/second by default)
Error Handling: Automatic retry with exponential backoff
Type Safety: Full Pydantic model validation
Async/Await: High-performance async operations
Environment-based Config: Secure credential management
This server implements the following NewsBreak Business API endpoints:
GET /v1/ad-account/getGroupsByOrgIds - Get ad accounts
GET /v1/campaign/getList - List campaigns
GET /v1/event/getList/{adAccountId} - Get tracking events
POST /v1/report/runSync - Run synchronous report
Base URL: https://business.newsbreak.com/business-api/v1
Authentication: Access-Token header
For complete API documentation, visit: https://business.newsbreak.com/business-api-doc/docs/overview/
Make sure you've created a .env file with your access token or set it in your environment:
export NEWSBREAK_ACCESS_TOKEN=your_token_hereYour access token may be expired or invalid. Generate a new one from your NewsBreak for Business account.
The client includes built-in rate limiting (10 req/s). If you need to adjust this:
client = NewsBreakClient(access_token="...", rate_limit=5) # 5 requests per secondDefault timeout is 30 seconds. Adjust if needed:
client = NewsBreakClient(access_token="...", timeout=60.0) # 60 secondsnewsbreak-ads-mcp-server/
├── server.py # Main MCP server
├── client.py # API client wrapper
├── models.py # Pydantic models
├── requirements.txt # Python dependencies
├── fastmcp.json # STDIO deployment config
├── fastmcp_cloud.json # Cloud deployment config
├── claude_desktop_config.json # Claude Desktop example
├── run_server.sh # Local run script
├── .env.example # Environment template
├── .env # Your credentials (gitignored)
├── .gitignore
└── README.md# Install dev dependencies
pip install pytest pytest-asyncio httpx
# Run tests (when implemented)
pytestContributions are welcome! Areas for enhancement:
Add support for asynchronous reports
Implement custom report creation
Add ad set and ad management tools
Create comprehensive test suite
Add more resource templates
Implement webhook support
Add caching layer for frequently accessed data
MIT License - feel free to use and modify as needed.
For issues with:
This MCP server: Open an issue in this repository
NewsBreak API: Contact NewsBreak support through your business account
FastMCP framework: Visit https://github.com/jlowin/fastmcp
Built with FastMCP v2.13.0
Get all ad accounts for specified organization IDs.
This retrieves ad account IDs and names grouped by organization, filtered by user access permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| org_ids | Yes | List of organization IDs to fetch ad accounts for |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose useful behavioral traits: results are grouped by organization and filtered by user access permissions. But it does not mention side effects, authentication needs, rate limits, or pagination; 'Get' implies a read operation but unsupported behavioral detail is limited.
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 with no filler. The core action is front-loaded in the first sentence, and the second adds valuable grouping and access-filtering behavior. 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?
For a single-parameter read tool with an output schema, the description covers the essential behavior: what is retrieved, how it is grouped, and how access is filtered. It lacks explicit alternative-usage guidance, but sibling resource names and the structured schema compensate. Overall 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 coverage is 100%, so the schema already fully documents org_ids. The description phrase 'specified organization IDs' merely restates the parameter in prose and adds no deeper semantic detail such as format, constraints, or behavior beyond what the schema provides. 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?
The description opens with a specific verb and resource: 'Get all ad accounts for specified organization IDs.' The second sentence clarifies the return content (ad account IDs and names) and the grouping/filtering behavior, clearly distinguishing this tool from sibling tools that target campaigns, ads, events, or performance reports.
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?
The description implies the tool is used when ad account IDs and names are needed for specific organizations, and it notes access-permission filtering. However, it does not explicitly state when to prefer this tool over sibling tools or provide any exclusion conditions, relying instead on resource-name differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ads with complete creative asset details including images, videos, headlines, descriptions, and CTAs.
This retrieves all ad information including the creative content (headlines, descriptions, call-to-action buttons, images/videos, landing page URLs, etc.) that users see.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional search query to filter ads by name | |
| page_no | No | Page number for pagination (default: 1) | |
| page_size | No | Number of results per page - valid values: 5, 10, 20, 50, 100, 200, 500 (default: 50) | |
| ad_set_ids | No | Optional list of ad set IDs to filter by specific ad sets | |
| campaign_ids | No | Optional list of campaign IDs to filter by specific campaigns | |
| ad_account_id | Yes | The ad account ID to retrieve ads from | |
| online_status | No | Optional status filter - values: WARNING, INACTIVE, ACTIVE, DELETED, PENDING, REJECTED |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the responsibility for behavioral disclosure. It communicates a read-only operation via 'retrieves' and specifies the creative fields returned. It does not discuss pagination or rate limits, but for a straightforward get operation the key behavior is sufficiently transparent.
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?
The first sentence is front-loaded and precise. The second sentence is slightly redundant, repeating headlines, descriptions, and images/videos, but it does add 'landing page URLs' and user-facing context, so it still contributes value. Overall the description is short and easy to scan.
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 list/retrieval tool with a fully documented schema and an output schema present, the description covers what an agent needs to understand the returned data. It could mention pagination or filtering behavior explicitly, but those are already encoded in the parameters.
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?
Input schema description coverage is 100%, so the schema already documents all seven parameters including filters, pagination, and status values. The description adds no parameter-specific semantics beyond that, so the 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?
The description uses a specific verb ('Get') with a clear resource ('ads') and enumerates the concrete content returned (images, videos, headlines, descriptions, CTAs). This clearly distinguishes it from sibling tools like get_campaigns and get_ad_accounts by focusing on the ad entity with creative details.
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?
The description provides a clear retrieval context: use this to fetch ads with complete creative content. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5, but an agent can confidently select it for ad-level creative data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get campaigns for an ad account with optional filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional search query to filter campaigns by name | |
| page_no | No | Page number (default: 1) | |
| page_size | No | Results per page - options: 5, 10, 20, 50, 100, 200, 500 (default: 50) | |
| ad_account_id | Yes | The ad account ID to fetch campaigns for | |
| online_status | No | Optional status filter - values: WARNING, INACTIVE, ACTIVE, DELETED |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it merely restates that the tool returns campaigns with filtering. It does not disclose pagination behavior, default sttus scope, or whether this is purely read-only; the schema hints at pagination but the description adds no behavioral context.
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?
One sentence, front-loaded with action and resource, no filler. Despite its brevity, every word contributes.
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 5-param tool with sibling ambiguity (campaign_summary) and no annotations, the single sentence is underspecified. The output schema covers return shape, but the description still leaves the agent guessing about pagination defaults, status behavior, and when to pick this tool over get_campaign_summary.
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 the schema documents all five parameters in detail. The description's 'optional filtering' is a general nod to search/status parameters but adds no meaning beyond the schema, hence the baseline 3.
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 action ('Get') and resource ('campaigns') scoped to an ad account, and mentions optional filtering. It clearly names the primary object but does not distinguish itself from sibling get_campaign_summary, leaving some ambiguity about list vs summary.
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?
No guidance on when to choose this tool over siblings such as get_campaign_summary or get_ads; no explicit exclusions or preferred use cases. The only context is 'for an ad account', but that applies equally to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quick summary of recent campaign performance.
This is a convenience tool that fetches active campaigns and provides a high-level overview of account activity.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to look back (default: 7) | |
| ad_account_id | Yes | The ad account ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool fetches active campaigns and produces a high-level overview, which are useful behavioral traits. However, it does not explicitly state read-only behavior, potential omissions, or how the summary is shaped beyond the output schema.
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?
The description is short and front-loaded with the core purpose. The second sentence adds useful context about active campaigns and account-level overview, though it partly overlaps with 'quick summary' and 'high-level overview.' Overall it is appropriately sized with minimal waste.
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 simple read-only summary tool with fully documented parameters and an output schema, the description covers the essentials. The main gap is not explicitly routing the agent to sibling tools for detailed reports or raw campaign data, leaving some tool-selection ambiguity.
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. The description only loosely connects 'recent' to the days parameter and 'active campaigns' to the tool's behavior, adding no additional semantic or formatting details beyond the schema.
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?
The description states a clear verb and resource: 'Get a quick summary of recent campaign performance.' It also clarifies that it covers active campaigns and provides a high-level overview, which distinguishes it from raw campaign listing or detailed reporting. However, it does not explicitly name sibling tools, so differentiation is implicit rather than explicit.
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?
The phrase 'quick summary' and 'convenience tool' implies this is for high-level overviews rather than deep analysis. But the description does not explicitly say when not to use it or mention alternatives like run_performance_report or get_campaigns. Usage context is implied, not clearly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all tracking events for an ad account.
Retrieves pixel and postback tracking events configured for the account.
| Name | Required | Description | Default |
|---|---|---|---|
| os_filter | No | Optional OS filter - values: "IOS", "ANDROID", or "" (empty string for web) | |
| ad_account_id | Yes | The ad account ID to fetch events for |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It correctly signals a read operation ('Get'/'Retrieves') and scopes results to configured pixel and postback tracking events, but it does not mention pagination, authorization requirements, or potential empty results. That is a minor gap for a simple read 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 sentences, front-loaded with the core operation, followed by a clarifying detail about event types. No repetition or filler.
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 only two parameters, full schema coverage, and an output schema, the description provides enough context to select and invoke the tool. It lacks only minor operational details like pagination or filtering behavior, which are not essential given the schema.
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?
The input schema already provides full descriptions for both ad_account_id and os_filter (100% coverage). The tool description adds no parameter-specific guidance, so it earns the baseline score rather than extra credit.
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 operation ('Get all tracking events') on a specific resource ('an ad account') and clarifies the event types ('pixel and postback'). This distinguishes it from sibling tools focused on accounts, campaigns, ads, and reports.
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?
The description gives clear context: use this tool when you need the configured pixel/postback tracking events for an ad account. It does not explicitly name alternatives or exclusion conditions, but none of the sibling tools serve this purpose, so the intended usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a synchronous performance report for campaigns, ad sets, or ads.
This generates immediate reports on auction and reservation ads data.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Optional reporting level - values: "campaign", "ad_set", "ad" | |
| date_to | Yes | End date in YYYY-MM-DD format (e.g., "2024-01-31") | |
| metrics | No | Optional list of metrics (e.g., ["impressions", "clicks", "spend", "conversions"]) | |
| date_from | Yes | Start date in YYYY-MM-DD format (e.g., "2024-01-01") | |
| dimensions | No | Optional list of dimensions (e.g., ["date", "campaign_id"]) | |
| ad_account_id | Yes | The ad account ID to generate report for |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully reveals that reports are synchronous and immediate, and that they cover auction and reservation ads data. However, it does not mention whether the operation is read-only, can be expensive/slow, or has other side effects, which would be valuable for a report-generation 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?
The description is two short sentences with no filler. The core action ('Run a synchronous performance report') is front-loaded, and the second sentence adds distinctive behavioral context about immediacy and data scope without redundancy.
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?
Given the 100% schema coverage, the presence of an output schema, and the clear statement of synchronous behavior, the description is largely complete for invoking the tool. The main gap is the absence of explicit guidance on when this tool should be chosen over the sibling summary/retrieval tools, but that gap is partially covered by the word 'synchronous' and the report-oriented framing.
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 coverage is 100%, so the baseline is 3 and the description does not need to restate parameter details. It adds mild contextual value by referencing campaign/ad set/ad levels, which maps to the 'level' parameter, but it does not meaningfully expand on the schema's parameter descriptions.
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?
The description uses a specific verb ('Run') and identifies the resource ('a synchronous performance report') with clear scoping to campaigns, ad sets, or ads. It also distinguishes itself from the sibling 'get_*' tools by framing this as report generation rather than simple retrieval, and the mention of auction/reservation data adds useful specificity.
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?
The description implies usage when an immediate, synchronous report is needed, but it does not explicitly state when to prefer this tool over alternatives like get_campaign_summary or get_campaigns. No when-not-to-use guidance or named alternatives are provided, so the guidance remains implicit rather than explicit.
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.
v1.3.0get_ad_accountsget_adsget_campaign_summaryget_campaignsget_tracking_eventsrun_performance_reportScored across 6 tools
Most tools are clearly distinct by resource: accounts, campaigns, ads, tracking events, and reports. However, get_campaign_summary overlaps somewhat with both get_campaigns and run_performance_report, so an agent may hesitate between the quick-summary and full-report options.
The naming convention is largely consistent with get_<resource> (get_ad_accounts, get_campaigns, get_ads, get_tracking_events). run_performance_report deviates from the get_ pattern, but it is still predictable and readable.
Six tools is a well-scoped count for an ads-focused server. Each tool addresses a meaningful part of the domain without unnecessary redundancy or feature bloat.
The read side is fairly complete, covering accounts, campaigns, ads, tracking events, and performance reporting. However, there are no mutation tools for managing campaigns or ads, and ad sets are referenced in reporting but have no direct retrieval tool, leaving potential gaps for a full ads workflow.
Marketing intelligence MCP server providing campaign performance data and analytics tools.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Google Ads MCP server — manage campaigns, keywords, and metrics.
A hosted MCP server for planning, scheduling, media, analytics, and social publishing.
