Meta Ads by Get MCP Ads

meta get delivery diagnostics

meta_get_delivery_diagnostics

Read-onlyIdempotent

Aggregate read-only delivery diagnostics across campaigns, ad sets, and ads to surface status, effective_status, and issues_info problems and review simple delivery insights.

Instructions

Aggregate read-only delivery diagnostics across campaigns, ad sets, and ads using status/effective_status/issues_info where available plus simple delivery insights.

Input Schema

Name	Required	Description	Default
`level`	No	Entity or aggregation level for the requested report.	all
`limit`	No	Maximum number of returned items or rows. The declared bounds and default apply; use pagination for additional results.
`cursor`	No	Pagination cursor from previous response
`timeRange`	No	Optional custom insights date range.
`datePreset`	No	Insights date preset for simple delivery metrics. Defaults to last_7d.
`adAccountId`	Yes	Ad account ID (e.g., act_123456789)
`effectiveStatusFilter`	No	Optional effective_status filter values such as ACTIVE, PAUSED, WITH_ISSUES, DISAPPROVED.

Output Schema

Name	Required	Description	Default
`result`	Yes	Original tool result: parsed JSON when the text is JSON, otherwise the text or multiple MCP content blocks. Provider fields depend on the selected query.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.1.1Oct 30, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / timeRange / additionalProperties
```
Removed value: -false
```

changedOutput schema / properties / result / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "properties": {},
-    "type": "object"
-  },
-  {
-    "items": {},
-    "type": "array"
-  },
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": {},
+    "properties": {},
+    "type": "object"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

First observedv2.0.1Sep 23, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the description repeating 'read-only' adds nothing. It does add modest value by flagging that status/issue fields are only present 'where available' and that the insights returned are 'simple', but it says nothing about pagination behavior or partial-failure handling for a multi-level aggregation.

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?

A single dense sentence with the aggregation intent front-loaded and no wasted words. It is efficient, though the compressed phrasing ('issues_info where available') assumes familiarity with Meta field names.

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

Completeness3/5

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

An output schema exists and annotations cover the safety profile, so return values need not be explained. However, for a 7-parameter, multi-level aggregation tool sitting among many insight/hierarchy siblings, the description leaves level semantics and pagination contract unaddressed, so it is adequate but with clear gaps.

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?

Schema description coverage is 100%, so level, limit, cursor, timeRange, datePreset, adAccountId, and effectiveStatusFilter are all documented in the schema itself. The description maps loosely onto the status/issue filters and the lightweight insights, but adds no format, default, or interaction guidance beyond that, making baseline 3 correct.

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 (aggregate) and resource (delivery diagnostics) with explicit scope across campaigns, ad sets, and ads, and names the fields it draws on (status/effective_status/issues_info). It does not explicitly distinguish itself from close siblings like meta_get_insights or meta_get_ad_activity, so it stops short of a 5.

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

Usage Guidelines3/5

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

The word 'diagnostics' implies troubleshooting rather than performance measurement, which implicitly separates it from insights tools, but there is no explicit when-to-use, when-not-to-use, or named alternative. With 40 siblings, an agent must infer the routing decision.

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

Deploy Server