Skip to main content
Glama
filippofinke

reddit-ads-mcp

by filippofinke
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get performance report

reddit_ads_get_report
Read-only

Fetch performance metrics for a Reddit Ads account over a date range, with filters and breakdowns, to analyze campaign, ad group, or ad performance.

Instructions

Get performance metrics for an ad account. Metric keys come back lowercase. spend, cpc, cpv, ecpm, conversion_*ecpa, app_installecpa, app_install_skan and app_install_*revenue are micro-currency (divide by 1000000); conversion*_total_value is in cents. Data can take up to 6 hours to settle.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fieldsNoUppercase metric names. Default IMPRESSIONS, CLICKS, SPEND, CTR, CPC, ECPM. Others: REACH, FREQUENCY, VIDEO_STARTED, VIDEO_WATCHED_25_PERCENT..VIDEO_WATCHED_100_PERCENT, VIDEO_VIEWABLE_IMPRESSIONS, CPV, CONVERSION_PAGE_VISIT_CLICKS, CONVERSION_PURCHASE_CLICKS, CONVERSION_PURCHASE_VIEWS, CONVERSION_PURCHASE_TOTAL_VALUE, CONVERSION_PURCHASE_ECPA, CONVERSION_SIGN_UP_CLICKS, CONVERSION_LEAD_CLICKS, CONVERSION_ADD_TO_CART_CLICKS, KEY_CONVERSION_TOTAL_COUNT, KEY_CONVERSION_ECPA, APP_INSTALL_INSTALL_COUNT, etc.
filterNoFilter like campaign:id==123 or ad_group:name=@brand or ad:effective_status==ACTIVE; comma separated conditions are ORed
ends_atYesEnd date YYYY-MM-DD (inclusive) or ISO 8601 (rounded to the hour)
max_pagesNoDefault 10
page_sizeNo
starts_atYesStart date YYYY-MM-DD or ISO 8601 (rounded to the hour)
breakdownsNoUp to 3 breakdowns (4 when COUNTRY and REGION are both used). Use at most one of KEYWORD, COMMUNITY, INTEREST, LANGUAGE and do not combine them with geo, OS_TYPE, GALLERY_ITEM_ID or CAROUSEL_CARD; HOUR only for ranges up to 7 days
time_zone_idNoIANA time zone, e.g. America/New_York
ad_account_idNoAd account ID (t2_... or a2_...). Defaults to REDDIT_ADS_ACCOUNT_ID.
custom_column_idsNo
conversion_metricsNo[{conversion_field, action_sources: [WEBSITE|APP|PHYSICAL_STORE|OTHER]}]
conversion_custom_eventsNo[{name, metrics: [{metric_type: VIEWS|CLICKS|ECPA|TOTAL_VALUE|TOTAL_ITEMS|AVG_VALUE|ROAS, action_sources}]}]

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds genuinely non-obvious behavior: metric keys return lowercase, specific fields are micro-currency (divide by 1,000,000) while conversion_*_total_value is in cents, and data can take up to 6 hours to settle. These are high-value operational facts an agent cannot get from the schema. It stops short of covering pagination behavior despite max_pages/page_size params.

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

Conciseness4/5

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

Three sentences, front-loaded with the purpose, then the most failure-prone details (units, lowercase keys, settlement lag). The currency sentence is dense but every clause maps to a real integration pitfall. No filler.

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?

For a complex 12-parameter reporting tool with no output schema, the description covers the return-value semantics that would otherwise be missing (units, key casing, freshness). The remaining gaps — pagination and filter/breakdown constraints — are documented in the schema, so the agent is not left blind.

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?

Schema coverage is already 83%, so baseline is 3. The description adds meaning beyond the schema by explaining the return-side semantics of the fields parameter (lowercase output keys, currency units per metric family), which the schema does not document. It does not add anything about filter, breakdowns, or pagination syntax.

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

Purpose4/5

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

States a specific verb and resource: 'Get performance metrics for an ad account.' An agent can tell this is the reporting/analytics tool rather than a list/get-entity tool. It does not explicitly differentiate itself from adjacent read siblings (e.g., get_ad_account_history), but the resource is unambiguous.

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

Usage Guidelines2/5

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

No when-to-use guidance, no prerequisites, and no named alternatives. The agent must infer that this is the metrics-retrieval tool from the name alone. Nothing states when to prefer it over other query/history tools.

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

Deploy Server

Other Tools