Skip to main content
Glama

Ad account audit

audit_account
Read-onlyIdempotent

Audit the whole ad account in one call: account status, ads Meta rejected, tracking, Learning limited ad sets, ads spending without results, creative fatigue, a rise in cost per result over a recent week and missing data — each finding with its numbers and the next step. Reads, in one call and read-only: the ad account itself (status, account spending limit, default DSA payer and beneficiary); the ads that are on in running campaigns but rejected in Meta’s review or stopped by a delivery issue, with Meta’s reasons — an ad set left with nothing to deliver that spent or was changed in the last 7 days is high; the ads with spend in the 14 days ending yesterday — the same read and rules as the daily advice; the active ad sets with Meta’s learning status; the conversion tracking of the pixel most active ad sets optimise for — the same checks as audit_conversion_tracking; creative fatigue — the same scoring as detect_creative_fatigue on the same 14 days, counting only ads whose frequency reached three quarters of its bar, when the request budget allows; the cost per result of the 7 days that end three days ago against the 30 days before them (the two latest days still collect results and are left out), by campaign and named by the result the campaigns optimise for, when the request budget allows — reported only when it rose beyond chance by 25% or more (40% is high), with how much of the rise the campaigns themselves made, the campaign that pushed it up most and, when the budget allows, that campaign's edits from Meta's change history; and, from what this account already sent in, payments, leads, the CRM and the link tags of the ads. Returns findings ordered by severity (high, medium, low), each with evidence and a next step; what is fine; what could not be checked and why; the money received; and the latest daily advice for this ad account. Running ads that spent enough to expect four results at the account’s own cost per result and got none are counted in full, not cut to three as in the daily advice. At most 15 Meta requests: a check the request budget does not allow is named under what could not be checked; when Meta’s limit, a temporary Meta failure or the request cap stops a read midway, the answer is also marked partial. Read-only and free: changes nothing and does not count toward the monthly change limit. An identical read within 30 seconds may return the same data (see data_age_seconds).

Input Schema

NameRequiredDescriptionDefault
pixel_idNoPixel to check when the ad account has several. Default: the pixel most of the active ad sets optimise for.
connectionNoWhich connected ad account to use: the connection id from start_here or the ad account number (act_123 or 123). Needed only when several ad accounts are connected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/destructive=false, but the description adds substantial behavioral context beyond them: a hard cap of at most 15 Meta requests, the request-budget mechanism, partial-answer marking when Meta limits or fails, caching behavior within 30 seconds via data_age_seconds, and that it is free and does not count toward the monthly change limit. This is exactly the kind of operational transparency an agent needs for a heavy multi-check read.

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

Conciseness2/5

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

The summary front-loads the purpose well, but the body is a single sprawling run-on paragraph packing every check, threshold, and edge case into one dense block. Large stretches (e.g. the embedded cost-per-result window arithmetic) are hard to parse and would be better as structured bullets. It is informative but far from concise, and structure works against readability.

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 high-complexity, multi-check audit with no output schema, the description covers returns in prose (findings ordered by severity with evidence and next steps, what is fine, what could not be checked, money received, latest advice) and explains budget-driven partial results. This is close to complete, with only the sheer density leaving minor risk of a missed constraint rather than any missing category.

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% for the two parameters, so the schema already documents pixel_id and connection fully. The description only indirectly touches parameter meaning by describing 'the pixel most active ad sets optimise for', matching the schema's default note. Baseline 3 is appropriate when the schema carries the parameter documentation.

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 opening sentence states a specific verb+resource (audit the whole ad account in one call) and enumerates the exact checks performed, from rejected ads to creative fatigue to cost-per-result trends. It actively distinguishes itself from siblings by naming audit_conversion_tracking and detect_creative_fatigue and noting it reuses their rules. An agent can immediately tell what this tool returns and how it differs from narrower audit tools.

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?

The description makes the selection context clear: this is the one-call whole-account audit that bundles the same reads as audit_conversion_tracking plus other checks. That strongly implies 'prefer this for a full sweep, use the narrower tools for a single check', but it never states an explicit when-not or 'use X instead when Y' rule. Clear context without explicit exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.