Ad results, CRM revenue and account alerts for AI assistants. Meta changes are previewed first.
Scored across 33 tools
Several tools overlap substantially: get_insights, meta_ads_read, performance_dashboard, performance_overview, audit_account, get_advice, and revenue_report all answer adjacent questions about performance, while build_campaign competes with meta_ads_create's create_campaign operation. The lengthy descriptions do provide use-case guidance, but the agent must parse a lot of text to avoid misselection.
Platform routers follow a clear platform_ads_action pattern (meta_ads_read, google_ads_create, tiktok_ads_update), but many standalone tools mix noun and verb styles: billing, usage, performance_dashboard, start_here, audit_account, get_advice. Everything is snake_case and readable, yet there is no single predictable convention across the full set.
There are 33 top-level tools, and several routers expand into dozens of internal operations, making the selection surface very large for an agent. The breadth reflects a genuinely broad ad-management product, but it exceeds a well-scoped tool set and creates a heavy routing burden.
Read, audit, reporting, and monitoring coverage is very strong across Meta, Google Ads, GA4, Search Console, LinkedIn, Microsoft, and TikTok, and Meta/TikTok have meaningful write operations. However, Google Ads create/update/delete only manage this server's monitors rather than actual Google Ads objects, while LinkedIn and Microsoft are read-only and TikTok lacks campaign-creation operations, leaving notable gaps in cross-platform management.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| pixel_id | No | Pixel to check when the ad account has several. Default: the pixel most of the active ad sets optimise for. | |
| connection | No | Which 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. |
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.
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.
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.
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.
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.
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.
Check whether the conversion events the active ad sets optimise for are actually arriving. Reads the pixels of the ad account, the active ad sets with the event each one optimises for, the pixel fires of the last 168 hours (browser and server-side), the dataset quality Meta reports for the pixel, the custom conversions those ad sets use, and a day-by-day trend of recorded actions over the lookback window. Returns a health score from 0 to 100 with a grade, the weighted checks it is made of, the ad sets with their events and budgets, and findings in plain words. status "incomplete" means a check could not be run; a pixel that is read but silent is a failed check, not an incomplete audit. With no active ad set there is no score at all, because there is nothing optimising for an event. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day of an explicit window, YYYY-MM-DD, in the ad account time zone. Needs start_date. | |
| pixel_id | No | Which pixel to audit, from list_pixels. Needed only when the ad account has several. | |
| raw_data | No | true returns the measured numbers only: no severity, scores, recommendations or quick_actions. | |
| connection | No | Which 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. | |
| date_range | No | Window as a named range. Ignored when start_date and end_date are given. | |
| start_date | No | First day of an explicit window, YYYY-MM-DD, in the ad account time zone. Needs end_date. | |
| lookback_days | No | Window of the event trend in days: 7, 14, 30, 60 or 90. Default 30. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint, and non-destructive, but the description adds substantial context beyond them: the 30-second caching behavior with data_age_seconds, the 'incomplete' status semantics, the distinction between a silent pixel (failed check) and an incomplete audit, the absence of a score when no active ad set exists, and that it doesn't count toward the monthly change limit. This is rich behavioral disclosure that annotations alone don't provide.
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 a single, dense paragraph that front-loads the core purpose and then layers in behavioral details. It's efficient and every sentence adds value, though the sentence describing all the data it reads is somewhat long and could be tightened.
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?
With no output schema, the description adequately describes the return values (health score, grade, weighted checks, ad sets, findings, status) and covers key behavioral edge cases. It is nearly complete, but lacks specifics on output format structure or pagination, which would be helpful for an agent parsing the response.
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 documents all parameters and their formats. The description adds no parameter-specific syntax or usage details beyond what the schema provides, so the baseline of 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 states a specific verb and resource — 'Check whether the conversion events the active ad sets optimise for are actually arriving' — which is unambiguous and distinct from siblings like get_insights or audit_account. It explains the audit's scope by listing exactly what it reads, so an agent can tell it apart from generic reporting tools.
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?
It implies the context (auditing conversion tracking for active ad sets) but doesn't explicitly name alternatives or state when not to use it, beyond the note about no active ad sets. The explanation of the 'incomplete' status and the no-score case provides useful decision context, but explicit routing to alternatives like get_insights is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
status — plan and usage (from the database, no call to Stripe); upgrade — a checkout link; manage — a link to the billing portal: card, invoices, cancellation. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | Plan key for upgrade, for example solo | |
| action | Yes | What you need |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: 'status' reads from the database and makes no Stripe call, while 'upgrade' and 'manage' return links rather than performing the mutation themselves, which explains why readOnlyHint is false despite the agent never directly changing billing. 'Free' hints at no cost/quota impact, though it is too terse to be unambiguous. No contradiction with the annotations.
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?
Extremely compact, action names front-loaded, each fragment carries distinct information. The telegraphic dash style and the dangling 'Free.' cost a little clarity but there is no wasted sentence.
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 2-parameter tool with no output schema, the description usefully characterizes return values (status data vs. links) across all three actions, which the schema cannot convey. It stops short of noting what 'status' contains in detail or any failure modes, but nothing essential for invoking 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?
Schema description coverage is 100%, so the schema already documents both 'action' (with enum) and 'plan' (with the 'solo' example). The description explains what each action yields but never mentions the 'plan' parameter or when it is required, so it adds no meaning over the schema; 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?
The description enumerates all three modes (status, upgrade, manage) and what each produces, so an agent can identify the tool's scope as plan/billing management. It never states an overarching verb+resource in sentence form and does nothing to differentiate from siblings like 'usage', but the per-action breakdown is specific enough to act on.
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?
Mapping each action to a need (plan/usage info, checkout link, card/invoices/cancellation) implicitly tells the agent which action to pick, which is the main routing decision for this tool. There is no explicit when-to-use/when-not wording, no mention of prerequisites, and no alternative tool named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a Meta campaign together with the person, two related questions at a time, shown in the chat as a form with buttons: goal and budget, page and conversion, creative and texts, audience and name — and first the ad account when several are connected. Call it when the person wants to build a campaign step by step or is unsure what to fill in. Nothing is created in the ad account and nothing counts toward the monthly change limit: the answers are kept under draft_id. When everything is answered, create_campaign with that draft_id returns the full preview and confirm_token.
| Name | Required | Description | Default |
|---|---|---|---|
| clear | No | Fields to remove from the draft, e.g. ["end_time"]. | |
| defer | No | Set by the form itself: questions the person left to the assistant for the end. Leave it out. | |
| answers | No | Fields of create_campaign the person chose: the "answer" of the picked options, or what they wrote, mapped to fields. | |
| draft_id | No | The draft to continue, from an earlier answer. Omit to start a new one. | |
| language | No | Language of the conversation, e.g. "ru", "uk", "pl" or "en": the form shows its questions and buttons in it. Always pass it; without it the form falls back to the language of the chat interface. | |
| connection | No | Ad account: connection id or ad account number — the answer of the ad account question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations marking this as non-read-only and open-world, the description clarifies that nothing is created in the ad account and nothing counts toward the change limit, with answers held under draft_id. This is precisely the extra context an agent needs to trust invoking a write-flagged 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 a single dense paragraph but front-loads the core action and each sentence carries information (form fields, trigger condition, side-effect safety, finalization path). Some sentences run long, slightly hurting readability.
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 6-parameter, no-output-schema tool, the description covers what the tool does, when to invoke it, its side-effect profile, and how the workflow concludes via create_campaign with the draft_id. Nothing essential to correct invocation 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?
Schema description coverage is 100%, so every parameter is already documented in the schema. The description reinforces the draft_id lifecycle but adds little param-level syntax or format detail beyond what the schema provides, so the 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?
The description states a specific verb and resource (building a Meta campaign) and makes clear this is an interactive, form-driven builder rather than a direct creator. It distinguishes itself from the sibling create_campaign by positioning that tool as the finalizing step.
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?
"Call it when the person wants to build a campaign step by step or is unsure what to fill in" gives explicit when-to-use context. It implies the alternative (direct creation) via the create_campaign handoff, though it never states an explicit when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a single-use link where the ad account owner grants us access. The link must be opened in a regular browser. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | meta (default) for Facebook and Instagram ads, google for Google Ads accounts, Google Analytics properties and Search Console sites. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, non-idempotent, non-destructive operation but say nothing about the mechanism. The description adds meaningful traits beyond that: the returned link is single-use, it is a grant-of-access flow, and it must be opened in a real browser rather than programmatically. It stops short of explaining expiry, latency, or what happens if the link is never used.
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, front-loaded with the return value and followed by the operational constraint and cost. 'Free.' is a terse fragment but earns its place as a cost signal. No wasted prose.
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 one-parameter tool with no output schema, the description covers what is produced (a single-use link), how it must be used (regular browser), and that it carries no cost. The main gaps are the absence of any statement about prerequisites or when the returned link expires.
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% and the single platform parameter is fully documented in the schema, so the schema carries the semantics. The description never mentions platform at all, so it adds nothing beyond the baseline for a fully-covered parameter set.
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 concrete outcome — returning a single-use link that grants access to an ad account — which is a specific verb+resource combination an agent can act on. It does not explicitly differentiate itself from siblings like audit_account or the platform-specific meta_ads_* tools, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (this is how you get authorization for an ad account) and gives one hard operational constraint — the link must be opened in a regular browser. It never states when to call this versus alternatives, nor that it is a prerequisite before the platform read/write tools, leaving the agent to infer sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is worth doing in the connected ad accounts today: at most three things per ad account, ordered by the money at stake, plus one thing missing from the data that would make the advice stronger, and once a week the findings of a read-only check of each ad account. Picked every morning from the last 14 days and the payments the account sent in, by rules backtested on real campaigns. Call it when the person asks what to do today, what needs attention, or for advice. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds value beyond that: freshness (recomputed every morning over the last 14 days and inbound payments), rule provenance (backtested rules), and cost ("Free"), all of which help an agent decide whether to call it.
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 core output is front-loaded, but the first sentence is overloaded, tucking the weekly-check clause mid-list, and the provenance/marketing line ("backtested on real campaigns") adds padding. Information density is high yet the structure is harder to parse than it needs to be.
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?
With no output schema, the description carries the return-shape burden, and it does describe contents, ordering (by money at stake), cadence, and cost. For a parameterless read tool this is nearly sufficient, though it could state limits such as account coverage when none are connected.
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 tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to clarify. Baseline 4 applies; no parameter-level claims are needed or missing.
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 specifies the exact payload: up to three ranked recommendations per ad account, one data-gap suggestion, and a weekly read-only check. That is a concrete, distinctive resource an agent can recognize. It does not, however, explicitly contrast itself with adjacent retrieval tools such as get_insights or mark_advice, so sibling differentiation is left to inference.
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?
It gives explicit trigger phrasing: "Call it when the person asks what to do today, what needs attention, or for advice," which maps user intent to invocation. There are no exclusions or named alternatives, so it stops short of 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.
Metrics for the ad account or an object inside it. Date ranges use the AD ACCOUNT time zone. Spend, impressions, clicks, CTR, CPC, CPM, reach, frequency, actions and cost per action, with the attribution setting and date window, for the ad account or one campaign, ad set or ad. Dates use the ad account time zone; money values are already in account currency, not minor units. Rows include the campaign, ad set and ad ids for their level. Optional: a breakdown (age, gender, country, region, placement, device, hour, creative asset), time_increment slices, extra field groups (include), a status filter, a minimum spend, sort order, attribution windows and totals. Up to 500 rows per call, fewer when the rows would not fit in one tool result; complete=false means more exist. next_after is given only when the page fit whole: pass it as after with the same other fields for the next rows; without it narrow the level, object, breakdown or date window. notes say which fields or rows Meta may leave out: a missing value is not zero. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Row order, e.g. spend_descending. Reach and frequency sorts do not work with the hourly breakdown. | |
| after | No | next_after from the previous call with the same other fields, to read the next rows. | |
| level | No | Aggregation level of the rows. Omit to report at the level of object_id. | |
| limit | No | Rows per call, 1 to 500. Default 500. | |
| totals | No | true adds summary: totals for the whole result, as Meta computes them. | |
| include | No | Extra field groups: names (account, campaign, ad set and ad names); results (results, cost_per_result, objective, optimization goal; not at level account); value (action_values, purchase_roas, website_purchase_roas; not at level account); links (inline and outbound link clicks, CTR and cost); video (plays, 25–100% watched, ThruPlay, average watch time; not with region or hourly); ranking (quality, engagement rate and conversion rate rankings). | |
| min_spend | No | Only rows that spent more than this in the window, in the ad account currency (not minor units); 0 drops rows without spend. | |
| object_id | No | Campaign, ad set or ad id, or act_<ad account id>, from a read of this ad account. Omit for the whole ad account. | |
| breakdowns | No | Split the rows by one Meta breakdown. publisher_platform with platform_position is the placement split; hourly_stats_aggregated_by_advertiser_time_zone is by hour in the ad account time zone and has no reach or frequency; device_platform is mobile or desktop; image_asset, body_asset, title_asset and description_asset split ads by creative asset. | |
| connection | No | Which 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. | |
| time_range | No | Explicit inclusive window, as an object {"since":"2026-08-01","until":"2026-08-31"}, not a JSON string. | |
| date_preset | No | Relative window in the ad account time zone, e.g. today, yesterday, last_7d, last_30d, this_month, maximum. Default last_7d (applied in run). Ignored when time_range is given. | |
| time_increment | No | Time slices: a number of days per row (1 to 90), "monthly", or "all_days" for one row per window. | |
| effective_status | No | Only rows of objects whose effective status is one of these, e.g. ["ACTIVE"]; needs level campaign, adset or ad. List ARCHIVED or DELETED to include such objects. | |
| attribution_windows | No | Report actions per attribution window, e.g. ["7d_click","1d_view"]: each action gets a key for every window that has a value. Omit for the attribution setting of the ad sets. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses the 500-row cap, that complete=false signals more rows, how next_after/after pagination works, that an identical read within 30 seconds may be cached (data_age_seconds), that reads are free and don't count toward the monthly change limit, and that missing values are not zero. This is rich operational context an agent cannot get from annotations alone.
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 purpose and key constraints are front-loaded, but the prose is dense and redundant: 'Date ranges use the AD ACCOUNT time zone' is restated as 'Dates use the ad account time zone', and the optional-parameter list partly duplicates the schema. Several sentences are run-ons that bury the pagination contract mid-paragraph.
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 15-parameter, no-required-arg tool with no output schema, the description covers the essentials an agent needs: scope, time zone, currency, pagination contract, caching, and status-filter level constraints. Return-shape detail is limited (no output schema exists to compensate), but complete/next_after/data_age_seconds/notes give enough to consume results safely.
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 15 params each carry their own schema descriptions. The description still adds meaning the schema does not: money values are in account currency not minor units (relevant to min_spend), dates resolve in the ad account time zone, rows carry campaign/adset/ad ids at their level, and next_after must be replayed with identical other fields. This pushes it above the 3 baseline.
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+resource: metrics for the ad account or an object inside it, and enumerates the returned measures (spend, impressions, CTR, CPC, CPM, reach, frequency, actions). An agent can tell what it produces without opening the schema. It does not, however, explicitly distinguish itself from siblings like performance_overview, performance_dashboard or meta_ads_read, so differentiation is left implicit.
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 contextual cues for specific parameters (e.g. when to use breakdowns, that hourly has no reach/frequency, that effective_status needs a non-account level, and that include results/value are not available at account level). But it never states when to prefer this tool over sibling read/performance tools, nor any prerequisite beyond 'from a read of this ad account'. Use guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For each named operation: the full input schema, description, spend, metered, reversible and the router that executes it (null: called directly). Does not call Meta. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_names | Yes | Operation names, e.g. ["pause_ad","update_budget"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavior: it costs nothing and makes no Meta API call, which materially affects tool selection. It omits any statement about batch limits or latency, but that is a minor gap against the annotation coverage.
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 tightly packed sentences, front-loaded with the return contract and finishing with the two facts that most influence selection (no Meta call, no cost). No 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?
With no output schema present, the description correctly compensates by listing the returned fields, so an agent knows the response shape. It does not mention the 10-name cap or ordering, though the schema covers the cap.
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% and the single parameter carries its own example (["pause_ad","update_budget"]), so the schema does the heavy lifting. "For each named operation" mildly confirms batch semantics that match the array type, but adds no syntax 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 explicitly enumerates what is returned per operation (full input schema, description, spend, metered, reversible, router), which is a concrete resource definition an agent can act on. It does not, however, distinguish this tool from the sibling search_tools, which likely overlaps in intent, and the verb itself is only implied by the name.
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 each named operation" implies the calling pattern (pass operation names), and "Free. Does not call Meta." gives a practical incentive to prefer this over live-API siblings. There is no explicit when-to-use/when-not statement and no routing against search_tools, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates this server’s monitors for a Google Ads account. Nothing in Google Ads changes. Call google_ads_create with {"action":"execute","tool_name":"google_create_monitor","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:
google_create_monitor: Watch every campaign or ad group of this Google Ads account and email when a rule holds on one of them. Changes only this server’s own monitor, nothing in Google Ads, and never counts toward the monthly change limit. Every operation takes two calls with the same tool_name and arguments; the first changes nothing and returns a preview with confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. None of them count toward the monthly change limit. Input schemas: get_tool_schema for named operations; google_ads_read {"action":"list_tools"} lists them all.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Always "execute". | |
| arguments | Yes | The fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call. | |
| tool_name | Yes | The operation name, e.g. google_create_monitor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses that Google Ads is never mutated, that changes stay inside this server, that the monthly change limit is unaffected, and that every operation is a two-call preview/confirm flow with a confirm_token accepted for 10 minutes. This is exactly the kind of side-effect, reversibility, and confirmation context annotations cannot convey.
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?
Front-loads the core purpose and the dispatch example before enumerating operations, which is the right ordering for an agent. There is mild redundancy ('nothing in Google Ads' and 'never counts toward the monthly change limit' are each stated twice), but the length is justified by the non-obvious two-call protocol.
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?
With no output schema, the description steps in and describes what the first call returns (a preview with confirm_token), which is the critical return-shape information. For a non-destructive, non-idempotent wrapper with richly annotated safety hints, this covers everything an agent needs; extra detail on error handling or token expiry behavior would be the only remaining gap.
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 action/tool_name/arguments are already documented, but the description adds the operative semantics: that the same tool_name and arguments must be reused across both calls and that 'connection' is required when multiple ad accounts exist. The 10-minute confirm_token validity is additional information not present in 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?
States a specific verb and resource ('Creates this server's monitors for a Google Ads account') and immediately disambiguates from the sibling operate-in-Google-Ads tools with 'Nothing in Google Ads changes.' An agent can tell this is a monitor-creation wrapper, not a Google Ads write, without inspecting the 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?
Gives clear context for when to call it (watching campaigns/ad groups, triggering email when a rule holds) and routes the agent to get_tool_schema and google_ads_read {"action":"list_tools"} for operation discovery. It does not explicitly state when to prefer it over siblings like build_campaign, but there is no true alternative for monitor creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes this server’s monitors of a Google Ads account. Nothing in Google Ads changes. Call google_ads_delete with {"action":"execute","tool_name":"google_delete_monitor","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:
google_delete_monitor: Delete a Google Ads monitor: it stops being checked and stops sending email. Changes only this server’s own monitor, nothing in Google Ads, and never counts toward the monthly change limit. Every operation takes two calls with the same tool_name and arguments; the first changes nothing and returns a preview with confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. None of them count toward the monthly change limit. Input schemas: get_tool_schema for named operations; google_ads_read {"action":"list_tools"} lists them all.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Always "execute". | |
| arguments | Yes | The fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call. | |
| tool_name | Yes | The operation name, e.g. google_delete_monitor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false, and the description goes well beyond them: it explains the two-call preview/confirm_token flow (token valid 10 minutes), that the first call changes nothing, that only this server's monitor is affected, and that it never counts toward the monthly change limit. That is meaningful behavioral context the annotations cannot carry.
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?
Purpose is front-loaded in the first sentence, then mechanics and operations follow in a logical order. The single dense paragraph is efficient, though the nested procedural detail makes it slightly run-on.
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?
With no output schema, the description carries the return burden and does explain the preview/confirm_token result of the first call. Minor gap: it doesn't describe what else the preview contains or error behavior, but nothing essential to invoking it 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?
Schema coverage is 100%, but the arguments object is free-form (additionalProperties: {}), so the schema alone is thin. The description adds real meaning: arguments carry the operation's fields plus 'connection' when several ad accounts are connected, and confirm_token on the second call.
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 ('Deletes this server's monitors of a Google Ads account') and immediately bounds the scope ('Nothing in Google Ads changes'). This distinguishes it clearly from siblings like google_ads_update, google_ads_read, and meta_ads_delete.
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?
Gives concrete routing guidance: use google_ads_delete with action=execute and tool_name=google_delete_monitor, get schemas via get_tool_schema, and list operations via google_ads_read {'action':'list_tools'}. It doesn't explicitly state when to choose delete over update, but the operating context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads Google Ads accounts. action "list_tools" lists every Google Ads operation with its field names and flags (get_tool_schema returns the input schema); it does not call Google and is free. action "execute" runs one read: {"action":"execute","tool_name":"google_account_summary","arguments":{}}. Reads:
google_account_summary: The connected Google Ads account: name, currency, time zone, status, test or production, manager or client.
google_list_campaigns: Campaigns in the Google Ads account: status, why they do or do not serve, type, bidding, budget and dates. Removed campaigns only on request.
google_list_ad_groups: Ad groups of one Google Ads campaign: status, type and the default CPC bid.
google_ad_performance: Google Ads metrics per ad over a period: cost, clicks, CTR, CPC, conversions, CPA, ROAS, with ad strength and serving status.
google_search_terms: What people actually searched for when your Search ads showed, with the keyword that matched and the metrics of each search term.
google_placement_performance: Where Display, Video, Demand Gen and Performance Max ads were shown — websites, apps, YouTube channels and videos — with metrics.
google_reach_frequency: How many unique people Display, Video and Demand Gen campaigns reached and how often each saw the ads, over a period.
google_conversion_performance: Conversions and their value per conversion action over a period, for the account or split by campaign.
google_recommendations: Recommendations Google Ads itself offers for the account, grouped by type, with Google's own estimate of what applying them would change, plus the budget options and keyword ideas behind them. Read only: this server never applies a recommendation.
google_landing_pages: Landing pages of Google Ads over a period: spend, clicks, conversions and value per page, with the mobile loading speed score Google gives the page, and findings about pages that take money without converting.
google_campaign_structure: What a Google Ads campaign is made of: its ad groups with bids, and on request their keywords, negative keywords and ads.
google_campaign_settings: All settings of one Google Ads campaign: dates, bidding and targets, budget, networks, location options, tracking template and URL parameters, frequency caps, Shopping feed and AI Max.
google_ad_group_settings: Settings of one Google Ads ad group: status, type, bids and targets, ad rotation, targeting or observation per audience dimension, tracking, device bid adjustments and Demand Gen channels.
google_ads: Ads with their texts: headlines, descriptions, paths and final URLs of responsive search, display and Demand Gen ads.
google_ad_policy_issues: Ads that Google disapproved or limited, with the policy topics and the evidence Google gives.
google_labels: Labels of the Google Ads account, or the labels on one campaign.
google_change_history: Who changed what in the Google Ads account and when: campaigns, budgets, ad groups, ads, keywords, targeting and assets.
google_campaign_targeting: Who and where a Google Ads campaign targets: locations and radius, languages, ad schedule, devices, audiences, demographics and exclusions.
google_ad_group_criteria: Targeting inside ad groups: keywords, placements, YouTube channels and videos, apps, topics, audiences and demographics — for Search, Display and Demand Gen.
google_search_audiences: Find audiences by name: Google interest and in-market categories, the account custom audiences, remarketing lists and audiences.
google_locations: Find Google location ids by name — countries, regions, cities, postal codes — with their full names and parents.
google_languages: Languages Google Ads can target, with their ids and codes; search narrows by name or code.
google_campaign_assets: Assets (extensions) a campaign uses — sitelinks, callouts, structured snippets, calls, images, texts — at campaign, account and ad group level.
google_asset_library: Assets already in the account library — images, YouTube videos, texts, sitelinks, callouts and more — to reuse in campaigns.
google_pmax_asset_groups: Asset groups of a Performance Max campaign: status, why they serve or not, ad strength, final URLs and metrics over a period.
google_pmax_assets: Texts, images, logos and videos in Performance Max asset groups, with whether each serves and why not.
google_pmax_signals: Search themes and audience signals of Performance Max asset groups — the hints that steer who Performance Max looks for.
google_conversion_goals: Which conversion goals a campaign bids for: each goal category and source, and whether it is biddable.
google_product_groups: The product group tree of a Shopping ad group: how products are split by brand, category, type, item id or custom label, with bids.
google_listing_filters: Which products or pages a Performance Max asset group advertises: its listing group filter tree.
google_merchant_center_links: Merchant Center accounts linked to this Google Ads account — the product feeds Shopping and Performance Max can use.
google_conversion_actions: Conversion actions of the account: what counts as a conversion, primary or secondary, value, counting, attribution and windows.
google_wasted_spend: Where Google Ads money brings nothing back: campaigns with no conversions or with a cost per conversion far above target, and the costliest search terms that never converted.
google_budget_allocation: A plan to move daily budget between Google Ads campaigns toward those that bring conversions (or value) cheaper, within limits. Nothing is changed.
google_explain_change: Why a Google Ads metric changed between two periods: which campaigns moved it, and which edits in the account (budgets, statuses, bids, targeting, ads) happened around that time.
google_ad_copy_brief: Everything needed to write new Google ad texts for a campaign: current headlines and descriptions with Google ratings, converting keywords and search terms, landing pages and character limits. The assistant writes the texts.
google_search_term_insights: What to do with search terms: converting terms that are not keywords yet, costly terms that never converted (negative keyword candidates), and how each match type performs.
google_revenue_report: Money your CRM or payment system received beside Google Ads spend, per campaign or ad group: revenue, payments, ROAS, cost per payment and a verdict. Payments that matched nothing are a line of their own.
google_audit_conversion_tracking: Audit how this Google Ads account tracks conversions: a 0–100 score and A–F grade with the findings behind it.
google_diagnose_funnel: Walk the Google Ads funnel step by step — tracking, value, traffic, conversion, landing pages, spend — and stop at the first broken step.
google_list_signals: What the watchdog found in this Google Ads account and has not seen resolved.
google_run_watch_now: Run the watchdog over this Google Ads account right now instead of waiting for its next pass.
google_get_signal_briefing: One finding of the watchdog or a monitor on this Google Ads account, with the live context to judge it: status, daily numbers, recent changes.
google_list_monitors: Monitors of this Google Ads account: their conditions, status, last check and how often they triggered.
google_get_monitor_history: When a Google Ads monitor triggered, on which campaigns or ad groups, with what numbers, and whether an email went out.
google_test_monitor: Dry-run a Google Ads monitor now: which campaigns or ad groups would trigger and which are skipped, without recording or emailing. google_campaign_performance is its own tool, not behind this router. Read-only and free: changes nothing and does not count toward the monthly change limit. Google counts every request toward this server’s daily Google Ads API quota, so a read can be refused for a while when that quota runs low.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | list_tools: every operation with its field names, flags and router. execute: run the read named by tool_name. | |
| arguments | No | For execute: the fields of the operation, plus "connection" when several ad accounts are connected. Omit or {} when it has none. | |
| tool_name | No | For execute: the operation name from list_tools, e.g. google_list_campaigns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, but the description adds meaningful operational context: list_tools is free and does not call Google, execute reads count against the daily Google Ads API quota, and reads can be refused when quota runs low. It also states the server never applies recommendations and changes nothing.
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 opening action semantics are front-loaded and clear, but the enormous operation catalog makes the description far longer than necessary. Much of that catalog duplicates what the list_tools action already provides, though the structure remains readable.
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 router tool with many underlying reads, it explains the discovery path (list_tools, get_tool_schema), the execution path (execute with tool_name and arguments), the read-only/free behavior, and the API quota constraint. No output schema exists, but the return-shape burden is appropriately delegated to the discovery actions.
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 baseline is 3, but the description adds substantial meaning beyond the schema by enumerating all valid tool_name values and describing what each read returns. It does not detail every operation's arguments, leaving that to list_tools/get_tool_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?
Starts with a specific verb and resource: reads Google Ads accounts. It clearly separates the two actions, list_tools versus execute, and explicitly says google_campaign_performance is not behind this router, which distinguishes it from a key sibling.
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?
Explains when to use list_tools (free, no Google call, lists operations) versus execute (runs one named read), and provides a concrete execute example. It also names the main sibling alternative by stating google_campaign_performance is its own tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pauses or resumes this server’s monitors of a Google Ads account. Nothing in Google Ads changes. Call google_ads_update with {"action":"execute","tool_name":"google_manage_monitor","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:
google_manage_monitor: Pause or resume a Google Ads monitor. Changes only this server’s own monitor, nothing in Google Ads, and never counts toward the monthly change limit. Every operation takes two calls with the same tool_name and arguments; the first changes nothing and returns a preview with confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. None of them count toward the monthly change limit. Input schemas: get_tool_schema for named operations; google_ads_read {"action":"list_tools"} lists them all.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Always "execute". | |
| arguments | Yes | The fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call. | |
| tool_name | Yes | The operation name, e.g. google_manage_monitor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructive/not-read-only/not-idempotent; the description adds substantive context beyond that: the first call changes nothing and returns a preview with a confirm_token valid for 10 minutes, the second call applies it, the change touches only the server's own monitor state, and it never counts toward the monthly change limit.
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 front-loads the purpose well, but the text repeats itself: 'nothing in Google Ads changes' appears in the opening line and again in the operation bullet, and the monthly-change-limit exemption is stated twice. That redundancy blunts the structure of an otherwise information-dense definition.
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 meta-wrapper with a two-phase confirmation flow, no output schema, and a now-write/timeout constraint, the description covers the invocation shape, the two-call protocol and token lifetime, the scope of the change, and where to find further operations. Only one operation is enumerated, but discovery is explicitly delegated to get_tool_schema and list_tools, which is reasonable.
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, but the schema's arguments object is a free-form bag the schema cannot describe semantically. The description explains that arguments carry the operation's own fields, 'connection' when multiple ad accounts exist, and the confirm_token on the second call, which is the polymorphic detail an agent actually needs.
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 gives a specific verb+resource ('pauses or resumes this server's monitors of a Google Ads account') and immediately scopes it as a server-side monitor toggle, not a Google Ads mutation. That scope statement is what separates it from google_ads_create/delete/read siblings. It stops short of naming a specific alternative for other update needs, but the purpose is unambiguous.
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?
It states when to use it (pause/resume a monitor), when not to expect Google Ads changes, and routes discovery to siblings ('get_tool_schema for named operations; google_ads_read {"action":"list_tools"}'). It also prescribes the mandatory two-call confirmation sequence. No explicit exclusion list for other update-style tools, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads connected Google Analytics (GA4) properties: traffic, engagement and key events by source, campaign and landing page. action "list_tools" lists every operation of this router with its field names (get_tool_schema returns the input schema); it does not call Google and is free. action "execute" runs one read: {"action":"execute","tool_name":"ga4_report","arguments":{}}. Reads:
ga4_report: A Google Analytics (GA4) report of the connected property: chosen dimensions and metrics over a period, with totals and an optional comparison with the period before.
ga4_attribution_check: Checks where GA4 loses the source of traffic and key events: sessions with no channel, sessions without a source, key events piling up in Direct, your own domains and payment services as referrals, and Facebook or Instagram clicks without UTM tags.
ga4_landing_pages: Landing pages of the connected GA4 property: sessions, engagement and key events per page against the average, for all traffic or one channel or source / medium — which pages lose the traffic you pay for and which convert best.
ga4_google_ads_check: Compares Google Ads with GA4 campaign by campaign: paid clicks against GA4 sessions from google / cpc, and Google Ads conversions against GA4 key events — where the tracking between them loses traffic or conversions.
ga4_meta_ads_check: Compares Meta ads with GA4 campaign by campaign: link clicks and landing page views against GA4 sessions from Meta, and Meta results against GA4 key events — where UTM tags, visits or leads get lost between Meta and the site.
ga4_list_signals: What the watchdog found about this site and has not seen fixed: a missing Meta pixel, a key event that never fires, lost attribution.
ga4_property_setup: The setup of the connected GA4 property: time zone and currency, data streams, key events and how many of each were recorded in the last 30 days, links to Google Ads accounts and how long event data is kept — with what to fix. Read-only and free: changes nothing and does not count toward the monthly change limit. Google Analytics and Search Console have their own request quotas; they do not use this server’s Google Ads API quota.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | list_tools: every operation with its field names, flags and router. execute: run the read named by tool_name. | |
| arguments | No | For execute: the fields of the operation, plus "connection" when several Google Analytics properties are connected. Omit or {} when it has none. | |
| tool_name | No | For execute: the operation name from list_tools, e.g. ga4_report. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond them: list_tools 'does not call Google and is free', and GA4/Search Console use their own request quotas rather than the server's Google Ads API quota. It does not describe pagination or result-size behavior, so it stops short of a 5.
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?
Front-loaded with purpose, then router mechanics, then a bulleted operation list — good structure for a seven-operation router. It is long, and the operation catalogue partially duplicates what action 'list_tools' returns at runtime, which is mild redundancy, but each bullet does help an agent decide whether this tool covers its question.
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 router with three parameters, full schema coverage and no output schema, the description covers everything an agent needs: what each operation returns in substance, how to discover operations, how to invoke one, and the quota/cost model. Nothing material is left undocumented.
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 baseline is 3. The description earns the extra point by clarifying semantics the schema cannot: that list_tools is a free non-calling discovery step, that arguments carries the operation's fields plus an optional 'connection' key, and by showing a literal execute payload. It still does not enumerate the per-operation field names, deferring that to list_tools.
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 — 'Reads connected Google Analytics (GA4) properties: traffic, engagement and key events by source, campaign and landing page' — and then enumerates the seven concrete read operations available through the router. An agent can immediately distinguish this from google_ads_read, meta_ads_read and search_console_read by the data domain.
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?
It clearly explains the router contract (list_tools to discover operations, execute to run one) and gives per-operation conditions of use, e.g. ga4_attribution_check is for finding 'where GA4 loses the source of traffic' and ga4_google_ads_check for comparing Ads against GA4 sessions. What is missing is explicit cross-sibling routing — nothing says when to prefer this over search_console_read or performance_dashboard for overlapping questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Ads metrics for the account, its campaigns, ad groups or keywords over a period: cost, impressions, clicks, CTR, CPC, conversions, value, CPA, ROAS. Period: date_preset (LAST_* periods do not include today) or since and until, in the account time zone. level: account, campaign (default), ad_group or keyword; campaign_id narrows campaign, ad group and keyword rows to one campaign. by_day adds a row per date. Rows are ordered by cost, highest first (by date with by_day). Cost is in micros and as text in the account currency; conversions_value is in the account currency. Cost and clicks update about hourly, and conversions can be added for days afterwards. totals are over the returned rows; complete=false means more rows exist than were returned. Ads: google_ad_performance; search terms: google_search_terms. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | account, campaign, ad_group or keyword. Default campaign. | |
| limit | No | Most rows to return, 1–500. Default 200. | |
| since | No | First day, YYYY-MM-DD, in the account time zone. Goes with until. | |
| until | No | Last day, YYYY-MM-DD, in the account time zone. Goes with since. | |
| by_day | No | A row per date instead of one row for the whole period. | |
| connection | No | Which connected Google Ads account to use: the connection id from start_here or the customer id (123-456-7890 or 1234567890). Needed only when several Google Ads accounts are connected. | |
| campaign_id | No | Only this campaign: for level campaign, ad_group or keyword. | |
| date_preset | No | A predefined period. Omit with since and until; with neither, LAST_7_DAYS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds substantial non-obvious behavior: cost is in micros and as text in account currency, cost/clicks refresh roughly hourly while conversions can postdate days, totals cover only returned rows with complete=false signaling truncation, and an identical read within 30 seconds may return cached data (data_age_seconds). It also states the tool is free and does not consume the monthly change limit.
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?
Front-loaded with purpose and metric list before the period/level mechanics, then behavior and routing. It is dense and long for a single paragraph, but nearly every clause carries distinct operational information (freshness, caching, ordering, units) rather than repeating the schema.
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?
With no output schema, the description carries the return-value burden and does so: row ordering by cost (or by date with by_day), totals scope, complete=false truncation, and data_age_seconds. Combined with unit and freshness notes, an agent has everything needed to call and interpret this tool correctly.
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 baseline is 3, but the description goes beyond it: it warns that LAST_* presets do not include today, confirms the campaign default level, explains that campaign_id narrows campaign/ad_group/keyword rows, and specifies that cost is in micros plus text while conversions_value is plain currency. The limit parameter's default of 200 is only in the schema, so it is not fully additive.
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+resource: Google Ads performance metrics across four levels (account/campaign/ad_group/keyword) over a period, with the exact metric list (cost, impressions, clicks, CTR, CPC, conversions, value, CPA, ROAS). It also explicitly routes to nearby siblings, naming google_ad_performance for ads and google_search_terms for search terms, so an agent can separate it from the other google_ads_* tools.
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?
Gives clear usage context: how to pick a period (date_preset vs since/until, and the default LAST_7_DAYS), how level selects granularity, when campaign_id applies, and when by_day is useful. Two alternatives are named for adjacent result types. It stops short of exclusions against other read siblings like google_ads_read or performance_overview, 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.
Reads Meta ad accounts. action "list_tools" lists every operation of every router with its field names, flags and the router that executes it (get_tool_schema returns the input schema); it does not call Meta and is free. action "execute" runs one read: {"action":"execute","tool_name":"list_campaigns","arguments":{}}. Reads:
linkedin_account_summary: The connected LinkedIn ad account: name, currency, status, whether it can serve ads, and on whose behalf it advertises.
linkedin_list_campaigns: Campaigns of the LinkedIn ad account: objective, status, whether they serve, daily and total budget, bidding.
linkedin_performance: What the LinkedIn ad account spent and got for it: spend, impressions, clicks, leads from lead forms and website conversions. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | list_tools: every operation with its field names, flags and router. execute: run the read named by tool_name. | |
| arguments | No | For execute: the fields of the operation, plus "connection" when several ad accounts are connected. Omit or {} when it has none. | |
| tool_name | No | For execute: the operation name from list_tools, e.g. linkedin_list_campaigns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), but the description adds genuinely non-obvious behavior: reads are free and do not count toward the monthly change limit, and an identical read within 30 seconds may return cached data (data_age_seconds). That caching/limit disclosure is real added value beyond the structured fields.
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 operation list is front-loaded and earns its space, but the first sentence ('Reads Meta ad accounts') is erroneous dead weight and the repeated 'Meta' reference later ('it does not call Meta') muddles a LinkedIn tool. Otherwise the structure is acceptable.
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?
With no output schema, the description does enumerate the fields each read returns (name, currency, status, objective, spend, impressions, clicks, leads, etc.), which is helpful. However it omits error/empty-result behavior and the multi-account 'connection' nuance (left to the schema), and the Meta/LinkedIn confusion undercuts completeness for a read router that already has many sibling reads.
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 action/tool_name/arguments are already documented, making 3 the baseline. The description adds an example invocation, but the example uses 'list_campaigns' while the schema and the read list use the 'linkedin_' prefix, introducing a naming inconsistency rather than clarity.
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 opening sentence says 'Reads Meta ad accounts', which names the wrong resource for a LinkedIn tool that has a separate sibling (meta_ads_read) covering Meta. The body recovers by enumerating three clearly-named LinkedIn reads (linkedin_account_summary, linkedin_list_campaigns, linkedin_performance), so the actual purpose is discernible, but the leading mislabel wastes the strongest position and risks mis-routing.
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?
It explains the two-step router pattern explicitly: 'list_tools' to discover operations, then 'execute' with tool_name/arguments to run one read, including a concrete call example. It also states when the tool is appropriate (read-only, free, outside the monthly change limit). No explicit routing guidance versus google_ads_read/meta_ads_read/microsoft_ads_read siblings, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record whether a piece of today's advice is right: yes, no or nonsense. Changes nothing in any ad account; the advice rules are tuned on these marks. Use the id from get_advice. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| mark | Yes | yes — right; no — wrong for this account; nonsense — makes no sense. | |
| advice_id | Yes | The id of the piece of advice, from get_advice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false the agent knows this writes, and the description adds valuable non-obvious context: it 'Changes nothing in any ad account', the marks tune advice rules, and it is 'Free'. This clarifies the write's true blast radius beyond what the annotations convey, though it doesn't restate the declared idempotent behavior.
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 padding, and the core action and its scope ('changes nothing in any ad account') are front-loaded. Every clause 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 simple two-parameter, non-destructive, idempotent write with no output schema, the description covers effect, cost, safety scope, and parameter source. 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?
Schema coverage is 100% and the enum values are fully documented in the schema, so the baseline is 3. The description still adds meaning beyond the schema by telling the agent where advice_id originates ('from get_advice'), which the schema does not state.
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 ('Record') plus the exact resource ('whether a piece of today's advice is right') and enumerates the possible values (yes/no/nonsense). It is clearly distinguishable from the sibling get_advice, which only retrieves advice rather than rating it.
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?
It gives clear workflow context ('Use the id from get_advice'), telling the agent where the required advice_id comes from. It stops short of stating when NOT to mark or how marks interact (e.g., overwriting a prior mark), so it is 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.
Creates new objects in a Meta ad account; nothing existing is modified. Call meta_ads_create with {"action":"execute","tool_name":"create_ad_creative","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:
create_ad_creative: Create a single-image creative. No impressions and no spend.
create_video_creative: Create a creative from a video that is already in the ad account library. No impressions and no spend.
create_carousel_creative: Create a carousel creative of 2 to 10 cards. No impressions and no spend.
create_ad: Create an ad in an ad set. Always PAUSED: turning it on is a separate action by a person.
upload_image: Upload one image, or a batch of up to ten, from https links into the ad account library. No impressions and no spend.
upload_video: Upload a video from an https link to the ad account library. No impressions and no spend.
duplicate_adset: Copy an audience into a new ad set, WITHOUT ads, for a new creative. The copy is paused.
copy_ad_to_new_adset: Copy a winning ad into a new ad set: a paused copy of its ad set with only this ad, under the same name.
create_campaign: Create a complete campaign: creative → campaign → ad set → ad. Everything is paused.
create_adset: Create a paused ad set in an existing campaign, with its budget, schedule and audience.
create_dynamic_creative_ad: Create one paused Dynamic Creative ad: Meta combines the images and texts itself.
duplicate_campaign: Copy a whole campaign with its ad sets and ads. The copy is paused unless ACTIVE is asked for. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
create_monitor: Watch every campaign, ad set or ad of this ad account and email when a rule holds on one of them. Changes only this server’s own monitor, nothing in Meta, and never counts toward the monthly change limit.
schedule_brief: Email a performance brief of every connected ad account on a schedule: daily, weekly on Mondays, or every N days. Changes only this server’s own monitor, nothing in Meta, and never counts toward the monthly change limit.
send_brief_now: Send a scheduled brief right now, without waiting for its schedule; the next scheduled send stays as it is. Reads the connected ad accounts and sends an email now; nothing in them changes, and it never counts toward the monthly change limit.
create_audience: Create a custom audience: website visitors, people who engaged with a Facebook Page or an Instagram account, or a lookalike.
create_ab_test: Start an A/B test between 2–5 campaigns or ad sets: Meta splits the audience so nobody sees more than one version.
rebuild_adset: Rebuild an ad set with a new goal: a paused copy with the same audience, budget and ads that optimises for another result, pixel event or a minimum ROAS.
create_product_set: Creates a product set (a filter over existing products) in a catalog the business can access. It creates no products and changes no feed.
create_catalog_creative: Create a creative that shows products from a product set. No impressions and no spend.
create_catalog_campaign: Create a paused catalog campaign: campaign, ad set on a product set, catalog creative and one ad. Nothing delivers until a person turns it on.
create_catalog_adset: Create a paused ad set on a product set inside an existing catalog campaign.
create_catalog: Create a product catalog in the business behind this ad account, optionally with a feed that fetches products from a URL.
create_product: Add one product to a catalog: name, price, availability, link and image.
create_product_feed: Add a product feed to a catalog: a file Meta fetches on a schedule, or one filled by uploads.
upload_product_feed: Fetch a feed file once, right now, outside the schedule.
create_feed_rule: Add a rule that fixes a feed file on the way in: take an attribute from another column, map values, change letter case or set a default.
connect_catalog_event_source: Connect a pixel to a product catalog, so its events are matched to the catalog's products for catalog ads.
boost_instagram_post: Turn an existing Instagram post into an ad in an existing ad set. The ad is created PAUSED. Every operation takes two calls with the same tool_name and arguments; the first makes no change in Meta and returns a preview. If the operation cannot increase spend, the preview includes confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. An operation that can increase spend is never executed from chat: its preview has no token, only an approve_url for a signed-in person. Executed changes count toward the monthly change limit; the preview is refused once the limit is reached. If the same change was already executed or its outcome is unknown, the preview has no confirm_token; check with a read first. If a proposal for the same change is still pending after its confirm_token expired, the call returns awaiting_human and only a person can apply it via approve_url. Input schemas: get_tool_schema for named operations; meta_ads_read {"action":"list_tools"} lists every operation with its field names.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Always "execute". | |
| arguments | Yes | The fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call. | |
| tool_name | Yes | The operation name, e.g. create_ad_creative. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give only the generic profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false); the description carries far more: the two-call preview/execute protocol, the 10-minute confirm_token, approve_url for spend-increasing operations, the monthly change-limit refusal, and the paused-by-default semantics of nearly every create. Because duplicate_campaign and create_campaign can increase spend, the description correctly flags that as opt-in by a signed-in person rather than contradicting destructiveHint=false.
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?
Front-loaded with the verb, scope and invocation shape before the long operation list, and the procedural protocol is placed at the end where it is needed. The operation list is long but each entry carries distinct capability and safety information (paused state, no impressions/spend), so little is filler; only the sheer volume costs it a point.
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 high-complexity, nested-object, no-output-schema tool, the description covers execution protocol, confirmation, error/limit states and per-operation safety posture. The only omission, per-operation field names, is deliberately deferred to get_tool_schema and meta_ads_read, which is the right design.
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% and the schema already defines action/tool_name/arguments, so baseline would be 3. The description goes further by explaining what 'arguments' actually carries (the operation's fields, 'connection' when several ad accounts are connected, confirm_token on the second call), which gives the opaque additionalProperties object real meaning.
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 (creates new objects in a Meta ad account) and immediately narrows scope with 'nothing existing is modified', cleanly separating it from meta_ads_update and meta_ads_delete. Every one of the ~30 operations is enumerated with a one-line purpose, so an agent knows exactly what capability it is selecting.
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 sibling tools for schema discovery ('get_tool_schema for named operations; meta_ads_read {"action":"list_tools"}'), and states when NOT to proceed ('check with a read first'), when spend-increasing ops are refused from chat, and when a proposal expires into awaiting_human. This is about as complete a when/when-not/alternatives set as a description can carry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archives or deletes objects in a Meta ad account. Delivery stops for good: Meta does not bring an archived or deleted object back, and an archived one accepts only DELETED afterwards. Call meta_ads_delete with {"action":"execute","tool_name":"archive_object","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:
archive_object: Archive or delete a campaign, an ad set or an ad. It stops delivery for good: Meta cannot bring an archived or deleted object back. Only reduces spend, and counts toward the monthly change limit.
delete_monitor: Delete a monitor: it stops being checked and stops sending email. Changes only this server’s own monitor, nothing in Meta, and never counts toward the monthly change limit.
delete_scheduled_task: Delete a scheduled brief or a monitor: it stops for good. Changes only this server’s own monitor, nothing in Meta, and never counts toward the monthly change limit.
delete_audience: Delete a custom audience that no running ad uses.
delete_product: Delete one product from a catalog. Ads stop showing it; product sets simply no longer include it.
delete_product_set: Delete a product set that no catalog ad set of this ad account promotes. The products themselves stay in the catalog. Only reduces spend, and counts toward the monthly change limit.
delete_product_feed: Delete a product feed and its schedule. Products that came only from it are removed, and ads stop showing them. Only reduces spend, and counts toward the monthly change limit.
disconnect_catalog_event_source: Disconnect a pixel from a product catalog: its events stop being matched to the catalog's products. Only reduces spend, and counts toward the monthly change limit. Every operation takes two calls with the same tool_name and arguments; the first makes no change in Meta and returns a preview. If the operation cannot increase spend, the preview includes confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. An operation that can increase spend is never executed from chat: its preview has no token, only an approve_url for a signed-in person. Executed changes count toward the monthly change limit; the preview is refused once the limit is reached. This is not the pause lane: when Meta rate limits the ad account the request may be held, so check the result with a read. If the same change was already executed or its outcome is unknown, the preview has no confirm_token; check with a read first. If a proposal for the same change is still pending after its confirm_token expired, the call returns awaiting_human and only a person can apply it via approve_url. Input schemas: get_tool_schema for named operations; meta_ads_read {"action":"list_tools"} lists every operation with its field names.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Always "execute". | |
| arguments | Yes | The fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call. | |
| tool_name | Yes | The operation name, e.g. archive_object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare destructiveHint=true and idempotentHint=false; the description goes far beyond them, disclosing the two-call preview/execute flow, the 10-minute confirm_token lifetime, approve_url for spend-increasing operations, the monthly change limit, awaiting_human behavior, and that archived objects accept only DELETED afterwards. It also states that delete_monitor and delete_scheduled_task affect only the server and never touch Meta.
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?
Front-loaded with the operation list and the two-call mechanics, and nearly every sentence carries an actionable rule. It loses a point for redundancy: the 'stops delivery for good / cannot bring it back' warning appears twice, and the 'only reduces spend, counts toward the monthly change limit' boilerplate is repeated in most bullets where a single statement would do.
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, so the description carries the return burden and does so: it describes what a preview returns (confirm_token or approve_url, or neither when the change was already executed) and what awaiting_human means. All prerequisite states an agent needs before calling are covered.
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?
With 100% schema coverage the baseline is 3, but the description adds real meaning: 'arguments' carries the operation's fields plus 'connection' when multiple ad accounts are connected, and confirm_token only on the second call. It also routes the agent to get_tool_schema and meta_ads_read list_tools for per-operation field names, which the schema itself does not convey.
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 ('Archives or deletes objects in a Meta ad account') and then enumerates all nine operations with what each one destroys. It also implicitly separates itself from meta_ads_update by naming 'This is not the pause lane' and from meta_ads_read by directing status checks there.
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?
Gives explicit when-to-use guidance per operation, plus decision rules for the hard cases: use a read when the change was already executed, when the outcome is unknown, or when rate limited; only a signed-in person can apply spend-increasing changes via approve_url. Alternatives and exclusions are spelled out rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads Meta ad accounts. action "list_tools" lists every operation of every router with its field names, flags and the router that executes it (get_tool_schema returns the input schema); it does not call Meta and is free. action "execute" runs one read: {"action":"execute","tool_name":"list_campaigns","arguments":{}}. Reads:
account_summary: The connected ad account: name, currency, status, lifetime spend.
list_pages: Facebook Pages that ads can run under.
list_campaigns: Campaigns in the ad account: configured and effective status, objective, budget. Deleted campaigns are not shown, archived only on request.
campaign_details: One campaign in full: settings, budget and its ad sets with a targeting summary, optionally its ads.
list_adsets: Ad sets across the whole ad account or one campaign (except deleted and archived by default): configured and effective status, budgets. Join with campaigns on campaign_id.
list_ads: Ads in the ad account, or in one campaign or ad set: status, effective status, creative.
ad_statuses: Statuses for a batch of ads in one request, so you do not have to guess what is already off.
list_images: Images in the ad account library, with the hashes that create_ad_creative takes.
list_videos: Videos in the ad account library, with the ids that create_video_creative takes.
list_creatives: Creatives already built in this ad account: what each one says, where it links and which picture it uses.
preview_ad: See the ad as it looks in the feed, drawn by Meta. Answers with a link for a person; no impressions and no spend.
upload_link: A page where a person adds creatives and sees the ones already in the library. Nothing is sent to Meta by this call.
read_landing_page: What a landing page says — headline, sections, numbers, prices, buttons and its language — to write ad texts from. Nothing is sent to Meta.
list_instagram_accounts: Instagram accounts this ad account can run ads from.
list_custom_audiences: Custom and lookalike audiences that Meta lists for this ad account, with size and whether they can be used.
search_targeting: Search Meta targeting options by words: interests, behaviors, demographics, life events, employers, job titles, schools, majors, locations and languages.
list_pixels: Meta pixels (datasets) this ad account can use, and when each last fired.
list_custom_conversions: Custom conversions of the ad account: event type, pixel and whether they still fire.
pixel_stats: Event counts of one pixel, by event and by hour, for up to the last 28 days.
ad_issues: Ads Meta rejected or holds with a delivery issue in running campaigns, with Meta's reasons, and ad sets that are Learning limited.
dashboard_data: The numbers behind performance_dashboard: spend, results, cost per result, link CTR and CPM against the previous period, by day and by campaign.
account_playbook: A skill for the assistant made from this ad account: what it sells, how campaigns are named, which result counts, targets, house rules, pitfalls and questions with real names.
analyze_wasted_spend: Classify the campaigns that spent in a window: wasted, below target, lead campaigns, learning or too little data.
analyze_audiences: Which age and gender groups the money goes to, what each of them brings, and where a result costs more than it does across the ad account.
analyze_placements: Which placements the money goes to — Feed, Stories, Reels, Audience Network and the rest — what each brings and where a result costs more than across the ad account.
detect_creative_fatigue: Score the active ads for creative fatigue: frequency, link CTR decline and how long they have been running.
ad_copy_brief: Everything needed to write new Meta ad texts for a campaign: its primary texts and headlines with spend, link CTR, results and cost per result, which ones beat the other texts beyond chance, the money they brought when payments are sent in, the landing pages and Meta's recommended text lengths, overall and by placement. The assistant writes the texts.
explain_anomaly: Explain why a metric changed — cost per result (CPA, cost per lead or purchase), ROAS, CTR, CPC, CPM, conversions — against the 30, 60 and 90 day baselines: which campaigns and ad sets moved it, at which funnel step, whether it is beyond chance, and what was edited in the ad account in those days.
optimize_budget: Recommend how to split a monthly budget pool across campaigns or ad sets. It changes nothing.
diagnose_funnel: Walk the funnel in order — tracking, revenue, traffic, conversion, spend — and stop at the first broken step.
browse_targeting: Browse a whole Meta targeting category: interests, behaviors, demographics, life events, industries, income or family statuses.
select_campaign_type: The order of tools that builds a campaign of a given type, and what it needs before it can be built.
copy_status: Check an asynchronous campaign copy: whether Meta finished it and what it produced.
app_performance: App promotion campaigns of this ad account: spend, installs and cost per install by campaign, ad set or ad, with the in-app events Meta reports for them.
list_promotable_apps: Mobile apps this ad account may advertise, with their store links and the events they report.
list_monitors: Monitors of this ad account: their conditions, status, last check and how often they triggered.
get_monitor_history: When a monitor triggered, on which campaigns, ad sets or ads, with what numbers, and whether an email went out.
test_monitor: Dry-run a monitor now: which campaigns, ad sets or ads would trigger and which are skipped, without recording or emailing.
list_scheduled_tasks: Scheduled briefs of this account and monitors of this ad account, with status, schedule and last run.
list_signals: What the watchdog found in this ad account and has not seen resolved.
run_watch_now: Run the watchdog over this ad account right now instead of waiting for its next pass.
list_pending_actions: Changes the watchdog and monitors prepared for approval: pauses and budget changes, with what each would do.
get_signal_briefing: One finding of the watchdog or a monitor: what was seen, since when, and the changes prepared for it.
get_opportunity_score: Meta's opportunity score for this ad account (0–100) and the recommendations Meta gives to raise it.
audience_details: One custom or lookalike audience in full: what it is built from, its size, its status and whether it can be used.
audience_adsets: Which ad sets use a custom or lookalike audience, with how many of their ads do.
pixel_details: One pixel (dataset) in full: its settings, when it last fired, and the checks Meta runs on it.
pixel_quality: How well the customer information sent with a pixel's server-side events can be matched to people, per event.
list_creative_ads: Ads that use one creative: id, name, status and where they sit.
list_business_pages: Facebook Pages owned by the business behind this ad account, and Pages it manages for clients.
activity_log: What was changed in this ad account and when: budgets, targeting, bids, statuses, schedules and new campaigns and ad sets.
list_experiments: A/B tests and lift studies that involve this ad account: what each tests, its dates and whether it is running.
get_experiment: One A/B test: its cells and how each cell did over the test window — spend, results and cost per result.
get_business_profile: The business behind this ad account as its owner described it: what it sells, its goal, target cost per result or ROAS, markets and rules.
infer_business_profile: Suggest a business profile from this ad account and its website: main goal, markets, what it sells. Saves nothing.
client_report_file: Make a report file for a client: this ad account's results for a period, with the agency's name, logo and commentary.
why_did_this_fail: What failed lately and why: your recent failed calls and approved changes that failed, with Meta's real error and who fixes it.
explain_error: Explain an error message from Meta or from this server: the cause in plain words, what to do and who does it.
list_catalogs: Product catalogs the business behind this ad account can use.
list_product_sets: Product sets of one catalog: the saved rules ads can promote.
list_products: Products of a catalog or of one product set, one page at a time, optionally only those matching a rule.
check_catalog_readiness: Whether a catalog is ready for dynamic ads: products, event sources, matching and must-fix diagnostics.
analyze_catalog_performance: Break catalog spend down by product: what sells, what is below target, what spends without a purchase.
product_performance: One product across the catalog ad sets: spend, purchases, return and its funnel.
catalog_funnel: View, add to cart, checkout and purchase across the catalog ad sets, with the biggest drop.
catalog_waste: Catalog spend that is bringing nothing back, by product, with how much of it is recoverable.
compare_product_sets: Product sets side by side by return, and the products that spend inside more than one of them.
list_catalog_data_sources: Where the products of a catalog come from: its feeds with their schedules and last uploads, and other data sources.
list_product_sets_for_product: Which product sets of its catalog a product is in.
product_feed_details: One product feed in full: file, schedule, format, default currency and its last upload.
list_feed_uploads: Recent fetches of a product feed: when, how many products were found and kept, errors and warnings.
list_feed_rules: Rules a product feed applies to its file: renamed columns, mapped values, letter case, defaults.
list_event_source_catalogs: Which product catalogs of the business a pixel is connected to as an event source.
list_instagram_posts: Recent posts, reels and stories of an Instagram account linked to this ad account, with whether each can become an ad.
list_lead_forms: Instant forms of a Facebook Page: name, status, how many submissions each has and the keys of its questions. get_insights, audit_conversion_tracking, audit_account, revenue_report are their own tools, not behind this router. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | list_tools: every operation with its field names, flags and router. execute: run the read named by tool_name. | |
| arguments | No | For execute: the fields of the operation, plus "connection" when several ad accounts are connected. Omit or {} when it has none. | |
| tool_name | No | For execute: the operation name from list_tools, e.g. list_campaigns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, yet the description still adds substantive context: list_tools 'does not call Meta and is free', several operations send 'nothing to Meta', the whole tool 'changes nothing and does not count toward the monthly change limit', and identical reads within 30 seconds may return cached data (data_age_seconds). These are real behavioral traits beyond the annotation set.
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 action semantics and cost/caching notes are correctly front-loaded, but the description then reproduces an enormous catalog of every operation even though it also tells the agent that list_tools exists precisely to return that catalog. That redundancy makes the block far longer than it needs to be for an agent deciding whether to call the router.
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 router of this complexity, the description covers the actions, the call shape, the operation inventory, the free/read-only/no-change-limit guarantees and the caching caveat. No output schema exists, but the return behavior is adequately implied, and nothing essential for calling 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?
Schema coverage is 100%, so the baseline is 3, but the description genuinely extends the schema: it shows a worked execute payload, clarifies that arguments carry the operation's own fields plus 'connection' when multiple ad accounts exist, and the ~60-operation catalog effectively enumerates the otherwise opaque valid values of tool_name.
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 opening sentence states a specific verb and resource ('Reads Meta ad accounts') and immediately defines the two actions, 'list_tools' and 'execute', with their distinct purposes. The operation catalog makes clear this is a read-only router and the closing note explicitly distinguishes it from get_insights, audit_conversion_tracking, audit_account and revenue_report, which are separate tools.
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?
It states when to use each action ('list_tools' to enumerate operations with field names and routers, 'execute' to run one named read) and gives a concrete call shape. It also names the sibling reads that are NOT behind this router. What's missing is guidance on when an agent should reach for this router versus the sibling read tools in the first place.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Changes existing objects in a Meta ad account. Call meta_ads_update with {"action":"execute","tool_name":"pause_ad","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:
pause_ad: Pause one ad, or up to ten at once. To turn them back on: launch_ad (approved by a signed-in person) or Ads Manager. Free pause.
launch_adset: Turn on delivery for an ad set: the campaign, the ad set, and its ads switch to ACTIVE. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
pause_campaign: Pause a whole campaign, together with all of its ad sets and ads. Free pause.
launch_ad: Turn on a single ad. If its ad set and campaign are on, it starts spending immediately. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
pause_adset: Pause delivery of an ad set, or up to ten at once. Spend stops. Free pause.
rename_object: Rename a campaign, ad set, ad or creative. Only the name changes.
update_budget: Raise or change a budget on an ad set or a campaign. The amount is in regular currency units. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
lower_budget: Lower a budget, or cap what an ad set may take from a campaign budget. It can only go down. Only reduces spend, and counts toward the monthly change limit.
swap_ad_creative: Replace the creative on an ad that cannot deliver right now. Nothing is turned on and spend does not change.
swap_live_ad_creative: Replace the creative on an ad that can deliver. The ad goes back to Meta review and may restart learning. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
narrow_adset_targeting: Narrow an ad set's audience: fewer locations, a tighter age range, more exclusions, fewer placements. It cannot widen anything.
update_adset_targeting: Change an ad set's audience: locations, age, gender, detailed targeting, custom audiences, placements. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
update_ad_tracking: Change the URL parameters on an ad, or on every ad in an ad set, or opt an ad out of multi-advertiser ads. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
launch_campaign: Turn on a campaign. Every ad set in it with its own ACTIVE status starts spending. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
update_schedule: Change when an ad set or a campaign starts and stops delivering. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
shorten_schedule: Bring the end of a schedule forward, or push a start that has not arrived yet later. It can only shorten. Only reduces spend, and counts toward the monthly change limit.
update_bid: Change how Meta bids for an ad set, or the bid strategy of a campaign. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
manage_scheduled_task: Pause or resume a monitor or a scheduled brief. Changes only this server’s own monitor, nothing in Meta, and never counts toward the monthly change limit.
manage_action: Approve or reject one prepared action. Approving runs its change the usual way; an increase in spend needs a signed-in person. Only reduces spend, and counts toward the monthly change limit.
apply_signal_actions: Apply every prepared action of one finding that can be applied from chat. Only reduces spend, and counts toward the monthly change limit.
update_audience: Rename a custom audience or change its description. Who is in it stays the same.
set_campaign_spend_cap: Set, change or remove a campaign's spending limit: the most it may spend in total before it stops. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
update_ab_test: Rename an A/B test, change its description or end time, or cancel it.
apply_recommendation: Apply one of Meta's recommendations from get_opportunity_score: Meta makes the change it describes. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
save_business_profile: Save the business profile of this ad account — or of every connected Meta ad account. Only the fields given change. Changes only this server’s own monitor, nothing in Meta, and never counts toward the monthly change limit.
update_optimization_goal: Change what an ad set of a traffic or awareness campaign optimises for: link clicks, landing page views, reach. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
update_catalog_campaign: Change an existing catalog campaign: name, status, budget, spend cap, bid strategy, schedule or the catalog it promotes. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
update_catalog_adset: Change an existing catalog ad set: budget, bid, optimisation, schedule and the product set it promotes. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
update_catalog_ad: Change a catalog ad: its name, status, or the creative — either another creative id, or a rebuilt product template. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
update_catalog: Rename a product catalog. Its products, feeds and product sets stay as they are.
update_product: Change fields of one catalog product: name, price, sale price, availability, link, image, brand.
update_product_set: Rename a product set or change its rule. Ad sets that promote it start showing the products the new rule matches.
update_product_feed: Rename a product feed, or change its file link, how often it is fetched, or its default currency.
update_feed_rule: Change the parameters of one rule of a product feed. Its attribute and type stay; Meta does not allow deleting rules.
set_adset_whatsapp_number: Change the WhatsApp number an ad set sends people to. CAN INCREASE SPEND, and this account allows it from chat: say so before executing. Every operation takes two calls with the same tool_name and arguments; the first makes no change in Meta and returns a preview. If the operation cannot increase spend, the preview includes confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. An operation that can increase spend is never executed from chat: its preview has no token, only an approve_url for a signed-in person. Pauses are free, can only reduce spend and never count toward the monthly change limit; other changes count when executed. For changes other than pauses: If the same change was already executed or its outcome is unknown, the preview has no confirm_token; check with a read first. If a proposal for the same change is still pending after its confirm_token expired, the call returns awaiting_human and only a person can apply it via approve_url. For pauses: After an unknown outcome a new preview includes confirm_token: repeating a pause is safe. If the same pause was already executed, a repeat within 15 minutes returns already_done, and a later preview has no confirm_token. If the confirm_token of a pause expired, calling again without confirm_token returns a working confirm_token for the same proposal. Input schemas: get_tool_schema for named operations; meta_ads_read {"action":"list_tools"} lists every operation with its field names.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Always "execute". | |
| arguments | Yes | The fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call. | |
| tool_name | Yes | The operation name, e.g. pause_ad. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic destructive/non-readOnly profile. The description goes far beyond: the two-call preview/confirm_token protocol, spend-increase flags per operation, the monthly change limit, approval requirements, awaiting_human, already_done, and idempotency caveats for pauses versus other mutations. This is rich behavioral disclosure that the annotations cannot carry.
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?
Front-loaded with the invocation pattern, which is good, but the body is an extremely long 30-bullet enumeration followed by dense paragraphs of protocol nuance. Much of the per-operation prose repeats the identical spend-increase sentence, inflating length without adding 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?
Given a 3-param meta-tool with a nested free-form arguments object, no output schema, and openWorld-free annotations, the description covers invocation form, per-operation semantics, approval gates, token lifecycle, and error outcomes. An agent has everything needed to drive the two-call flow correctly.
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 already 100% for the three top-level params. The description adds real meaning beyond the schema by explaining that arguments is a free-form object keyed by operation name, that it must include confirm_token on the second call, and that connection is required with multiple ad accounts, and it points agents to get_tool_schema for per-operation fields.
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+resource (changes existing objects in a Meta ad account) and then enumerates 30 distinct operations, each with a one-line scope. An agent can distinguish this tool from meta_ads_create/delete/read purely from the text.
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?
Extensive when-to-use guidance: it explicitly says which operations increase spend, that chat-executed increases are disallowed, when to check with a read first, how the 15-minute already_done window works, and when to route to a signed-in person via approve_url. Alternatives are named (launch_ad for un-pausing, Ads Manager, meta_ads_read list_tools).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads Meta ad accounts. action "list_tools" lists every operation of every router with its field names, flags and the router that executes it (get_tool_schema returns the input schema); it does not call Meta and is free. action "execute" runs one read: {"action":"execute","tool_name":"list_campaigns","arguments":{}}. Reads:
microsoft_account_summary: The connected Microsoft Advertising ad account: name, number, currency, time zone and status.
microsoft_list_campaigns: Campaigns of the Microsoft Advertising account, of every type: status, type, daily budget and whether the budget is shared.
microsoft_performance: What the Microsoft Advertising account spent and got for it: spend, impressions, clicks, conversions and revenue, by day or in total. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | list_tools: every operation with its field names, flags and router. execute: run the read named by tool_name. | |
| arguments | No | For execute: the fields of the operation, plus "connection" when several ad accounts are connected. Omit or {} when it has none. | |
| tool_name | No | For execute: the operation name from list_tools, e.g. microsoft_list_campaigns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, non-open-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the call is free, it does not consume the monthly change limit, and an identical read inside 30 seconds may return stale data (with data_age_seconds as the tell). That is substantive disclosure.
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 three-read list is dense and well structured, but the lead sentence about Meta accounts earns nothing and actively misleads, and the passing reference to 'every router' and 'get_tool_schema' is never grounded. Front-loading a wrong claim is the worst possible use of the most prominent position.
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?
With no output schema, the description carries the burden of describing returns and does so for all three operations (name/number/currency/time zone/status; status/type/budget; spend/impressions/clicks/conversions/revenue). Missing only date-range or pagination mechanics for the performance read, which the agent would need to guess.
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. The description goes beyond the schema by enumerating the concrete valid values for tool_name (microsoft_account_summary, microsoft_list_campaigns, microsoft_performance) and giving a worked execute payload, information the schema leaves as an open string.
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 opening sentence says 'Reads Meta ad accounts,' which flatly contradicts the tool name (microsoft_ads_read) and title, and is especially dangerous in a sibling set that also contains meta_ads_read and google_ads_read. The subsequent enumeration (microsoft_account_summary, microsoft_list_campaigns, microsoft_performance) is specific and does make the real scope clear, so the purpose is eventually recoverable, but the first thing an agent reads is wrong.
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?
It explains the internal action split usefully: list_tools to discover operations (free, no account call) versus execute to run a read. However it never says when to choose this tool over google_ads_read or meta_ads_read, which is the critical routing decision given the sibling set — and the mislabeled 'Meta' opening actively pushes the agent toward the wrong sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An interactive dashboard of one Meta ad account inside the chat: spend, results, cost per result, link CTR and CPM against the previous period, a chart by day and the campaigns — with 7, 14, 30, 60 and 90-day tabs the person switches in the window, and payments and ROAS from the business's own payments loading into it. Call it when the person asks how their ads are doing, or for a dashboard, overview or report of an ad account. It reads the numbers itself: do not read them first. Free and read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Period: the last 7, 14, 30, 60 or 90 full days, ending yesterday in the ad account time zone. Default 30. | |
| part | No | Set by the dashboard window itself to load payments and ROAS. Leave it out. | |
| connection | No | Ad account: connection id or ad account number. Needed when several are connected. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/destructiveHint/idempotent, so the safety profile is covered. The description adds genuine behavioral context beyond them: the dashboard is interactive with in-window tabs, payments/ROAS load into it, and the agent must not pre-read the numbers. It does not explain pagination or latency, but this is a rendering 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?
Front-loaded: the resource and its contents come first, then the trigger, then the 'do not read first' rule, then the free/read-only note. It is a dense run-on sentence, but nearly every clause carries distinct information, so the length is largely earned.
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-required-param, read-only rendering tool with no output schema, the description covers what is shown, when to invoke it, and how to avoid redundant reads. Minor gap: it does not note that a connection/ad account must be disambiguated when several are linked, though the schema covers that.
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. The description still adds meaning by tying the 7/14/30/60/90 tabs to the day window the person switches, and by explaining that payments/ROAS load into the dashboard (the purpose of `part`, which the schema tells you to leave out). This is context the schema does not carry.
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+resource: renders an interactive dashboard of ONE Meta ad account, and enumerates exactly what it shows (spend, results, cost per result, link CTR, CPM, daily chart, campaigns, payments/ROAS). It is clearly distinguishable from siblings like performance_overview, show_dashboard and meta_ads_read.
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?
Gives an explicit trigger ('when the person asks how their ads are doing, or for a dashboard, overview or report of an ad account') plus a strong procedural rule ('it reads the numbers itself: do not read them first'). It never names the alternative tools it should be picked over, so the when-not/alternative half is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One period across everything connected: spend, clicks and results of every Meta ad account, Google Ads account, TikTok ad account, Microsoft Advertising account and LinkedIn ad account, then the visits and key events the site itself recorded in Google Analytics and the clicks from Google Search — with the gaps between what the ads report and what the site sees. Start here when the question is "where did the money go and what came of it". Free; each connected Google Ads account costs one Google Ads operation.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | First day, YYYY-MM-DD. Together with until. | |
| until | No | Last day, YYYY-MM-DD. Together with since. | |
| date_preset | No | Period, ending yesterday. Default LAST_7_DAYS. Use since and until instead for exact dates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnly/idempotent/non-destructive, so safety is covered; the description adds genuinely new behavioral context: the cost model ("Free; each connected Google Ads account costs one Google Ads operation") and the fact that it computes a discrepancy between ad-reported and site-observed numbers. It says nothing about freshness/latency or how gaps are computed.
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 scope enumeration comes first, then the routing guidance ("Start here..."), then cost, which is good front-loading and no filler. The first sentence is long and comma-dense with vendors, which costs some readability.
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?
With no output schema, the description should carry the burden of telling an agent what comes back; listing the covered sources and the ad-vs-site gap does that at a high level, but it never indicates the shape of the response or whether all connected sources always appear.
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% and the schema already documents YYYY-MM-DD formats, enum presets and the since/until-vs-date_preset tradeoff. The phrase "One period across everything" weakly reinforces that a single period applies to all sources, but adds little beyond structured data, so 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?
The description names the specific aggregation it performs (spend, clicks and results across Meta, Google, TikTok, Microsoft and LinkedIn plus GA visits/key events and Search Console clicks, with gap analysis) rather than restating the title. It does not, however, distinguish itself from siblings 'performance_dashboard' or 'revenue_report', which plausibly overlap.
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?
"Start here when the question is 'where did the money go and what came of it'" gives an explicit entry-point trigger. It stops short of naming when NOT to use it (e.g. single-channel or revenue-specific questions that the sibling reports cover).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the ads actually earned: spend from the ad account against the payments the business sent in, per campaign, ad set, ad or creative. Spend of the window against the payments this account sent to POST /v1/revenue, matched by the tags in the ad link, precise first: ad, then ad set, then campaign — by id or by name alike; when no tag names one object alone, the tags together (ad name and ad set name) may — and matched_by says which route carried how many. A name several objects share is never guessed: that money stays in unattributed with the tags it carried. level "creative" puts together the ads that share a name — one creative reused across ad sets — so money tagged with that name lands on it: the way to compare creatives by money. by "payment_date" (default) counts money that arrived; by "lead_date" what the leads of the window have paid. Ratios only in the ad account currency. Each row carries a verdict against target_roas (default 1.0) and against how long THIS account's leads take to pay, measured from its own payments: a cohort that has not had time to pay is never called a loss. If no payments of its own have ever been sent in (not only none in this window) and Meta counted purchases, the money is what Meta counted — purchases within 7 days of a click, with their value — and money_source says so: a shop whose pixel records every purchase gets its revenue and ROAS without sending anything. Without connection, when several ad accounts are connected, each is read and summarised — totals and the campaigns that spent most; call with connection for the full report of one. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | payment_date (default): money that arrived in the window. lead_date: money earned by the leads of this window, whenever it was paid — needs lead_at on the events. | |
| level | No | Rows per campaign (default), ad set, ad, or creative — the ads that share one name, as one creative reused across ad sets. | |
| end_date | No | Last day of an explicit window, YYYY-MM-DD, in the ad account time zone. Needs start_date. | |
| raw_data | No | true returns the measured numbers only: no severity, scores, recommendations or quick_actions. | |
| connection | No | Which 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. | |
| date_range | No | Window as a named range. Ignored when start_date and end_date are given. | |
| start_date | No | First day of an explicit window, YYYY-MM-DD, in the ad account time zone. Needs end_date. | |
| target_roas | No | What this account expects back per unit of spend. Default 1.0. | |
| lookback_days | No | Window in days: 7, 14, 30, 60 or 90. Default 30. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint/idempotentHint/destructiveHint=false), the description adds cost and caching behavior ('free', does not count toward the monthly change limit, identical reads within 30s may return cached data via data_age_seconds), plus the full attribution fallback chain (tag matching, unattributed bucket, money_source/Meta-counted purchases, cohort that has not had time to pay never called a loss). This is genuinely useful context the annotations do not carry.
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 core purpose is front-loaded, but the body is a single dense run-on block of em-dashes and semicolons that is hard to parse. Much of it earns its place, yet the size and lack of structure impose a real reading cost for a 9-parameter tool.
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?
With no output schema and nine optional parameters, the description does substantial work: it explains return-relevant fields (matched_by, money_source, data_age_seconds), the multi-account summarise-vs-full-report behavior, and the attribution rules. It stops short of enumerating the row shape, so it is strong but not fully exhaustive.
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, but the prose adds real meaning: it explains the payment_date vs lead_date semantics, why level 'creative' exists (ads sharing a name = one reused creative), that target_roas drives a per-row verdict, and that raw_data strips severity/scores/recommendations. These enrich parameters beyond their schema text.
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 opening sentence names a concrete verb and resource — spend from the ad account matched against payments, broken down per campaign/ad set/ad/creative. It is far more specific than the title alone, but it never names or differentiates itself from siblings like get_insights, performance_dashboard or google_campaign_performance, so an agent must infer when this report is the right one.
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?
Usage is only implied. The description explains mode switching ('call with connection for the full report of one') and defaults, but gives no explicit 'use this when you need X rather than Y' and names no alternative tool. An agent can infer the purpose but gets no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads connected Search Console sites: clicks, impressions, CTR and position in Google Search by query, page, country and device. action "list_tools" lists every operation of this router with its field names (get_tool_schema returns the input schema); it does not call Google and is free. action "execute" runs one read: {"action":"execute","tool_name":"search_console_performance","arguments":{}}. Reads:
search_console_performance: Google Search performance of the connected Search Console site: clicks, impressions, CTR and average position by query, page, country, device, date or search appearance, with the site totals for the period.
search_console_paid_organic: Compares Google Search results of the connected site with the search terms of a connected Google Ads account: terms Google Ads pays for where the site already ranks in the top 3, searches on page 2 and lower with no ads, and terms that convert in Google Ads where the site is not visible organically.
search_console_indexing: Indexing state of pages as Google sees them: whether the page is indexed, which address Google picked as canonical, whether robots.txt or a noindex tag blocks it, when Google last crawled it and whether the fetch succeeded.
search_console_opportunities: Where Google Search is close to paying off: pages or queries sitting just off the first page, ones shown often but rarely clicked, and ones that lost position against the previous period. Read-only and free: changes nothing and does not count toward the monthly change limit. Google Analytics and Search Console have their own request quotas; they do not use this server’s Google Ads API quota.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | list_tools: every operation with its field names, flags and router. execute: run the read named by tool_name. | |
| arguments | No | For execute: the fields of the operation, plus "connection" when several Search Console sites are connected. Omit or {} when it has none. | |
| tool_name | No | For execute: the operation name from list_tools, e.g. search_console_performance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable context beyond them: it is free, does not consume the monthly change limit, and uses separate quota pools from the Google Ads API. It does not cover pagination or response shape, but no output schema exists so that is less critical.
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?
Front-loads the tool's purpose and action mechanics, then presents each sub-operation as a structured bullet. Slightly verbose and mildly redundant with annotations on the read-only point, but for a four-operation router the detail is largely justified 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?
Covers purpose, router mechanics, all four sub-operations, parameter usage via the execute example, and cost/quota behavior. With annotations handling safety and no output schema to explain, an agent has everything needed to select and invoke it correctly.
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 baseline is 3. The description enumerates four valid tool_name values with rich explanations of what each read returns, going beyond the schema's single example and helping the agent choose the right operation. Semantics for action and arguments remain delegated to 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?
States a specific verb (reads) and resource (connected Search Console sites) with exact metrics, and differentiates from siblings by naming get_tool_schema and clarifying the distinct role of list_tools versus get_tool_schema. It also separates its quota from the Google Ads API quota, making its scope unmistakable.
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?
Explains the two router actions and when to use each: list_tools is free discovery with field names, execute runs one read with a concrete example. Lacks explicit when-not guidance or direct contrast with other read tools like google_analytics_read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks the Meta operations of this server by the words of the query against their names, titles and descriptions, and returns tool_name, the router that executes each one (null: called directly), title, summary, read_only and spend. Does not call Meta. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Words describing the task, e.g. pause ad or daily budget. | |
| top_k | No | How many operations to return, 1 to 25. Default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety burden is covered. The description adds two useful behavioral facts not in the annotations: it does not call the Meta API and it is free, which is exactly what an agent needs before a discovery call.
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, front-loaded with the core action and followed by the return contract and the cost caveat. Dense but every clause carries information; no 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?
With no output schema, the description correctly enumerates the returned fields (tool_name, router with null meaning, title, summary, read_only, spend), which is the main completeness gap this tool would otherwise have. It is close to fully sufficient, missing only details like ranking order or what happens when top_k is omitted beyond the schema's stated default.
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. The description goes further by explaining how 'query' is actually consumed — words are matched against operation names, titles and descriptions and used to rank results — which is semantic information the schema's example does not convey. Only top_k behavior is left entirely to 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?
States a specific verb and resource: it ranks the server's Meta operations against query words and returns a defined set of fields. It is clearly distinguishable from siblings like get_tool_schema and start_here, though the 'Meta operations' scope could be read as excluding the non-Meta siblings (google_ads_*, audit_*, etc.).
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?
Usage is implied rather than stated: an agent can infer this is a cheap discovery step ('Free', 'Does not call Meta'), but there is no explicit when-to-use guidance or routing against alternatives such as get_tool_schema or start_here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draws numbers as cards and a sortable table inside the chat. Call it whenever the person asks to see, show, list, compare or rank numbers, in any language — right after the read that produced them, with those numbers as the arguments. Do not write that table by hand in your reply when this tool can draw it: draw it, then add a sentence or two in words. It reads nothing itself, changes nothing, and is free; clients without a window get the same report as text. For how one Meta ad account is doing overall, call performance_dashboard instead: it reads the numbers itself and switches periods.
| Name | Required | Description | Default |
|---|---|---|---|
| kpis | No | Up to eight cards on top. Put the numbers the person asked about first. | |
| notes | No | Short lines under the table: findings, caveats, what to do. | |
| table | No | The table under the cards. | |
| title | Yes | Headline of the dashboard, e.g. "Meta ads, last 28 days". | |
| subtitle | No | One line under the headline: the account, the period, the filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world. The description goes beyond them by stating 'it reads nothing itself, changes nothing, and is free' and disclosing graceful degradation for clients without a window ('the same report as text') — a real behavioral fact an agent needs. It stops short of explaining rendering failure modes, so not a full 5.
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 sentences, all load-bearing: what it draws, when to call it plus the anti-pattern, and the alternative. The primary instruction and the negative rule are front-loaded before the sibling routing note.
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-parameter presentation tool with full schema coverage and no output schema, the description covers purpose, trigger, timing, side-effect profile, and fallback rendering. It does not spell out what the rendered output looks like or how failures surface, but nothing essential to correct invocation 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?
Schema description coverage is 100%, so every field (kpis, table, columns, notes, title, subtitle) is already documented with examples and limits in the schema. The description only adds a usage hint that the read's numbers are 'the arguments'; it adds no new field-level meaning. 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 concrete verb and rendering resource: 'Draws numbers as cards and a sortable table inside the chat.' It explicitly distinguishes itself from the closest sibling by naming performance_dashboard and describing the difference (this one draws what you pass; that one reads the numbers itself and switches periods).
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?
Gives the trigger ('whenever the person asks to see, show, list, compare or rank numbers, in any language'), the timing ('right after the read that produced them'), a negative instruction ('Do not write that table by hand'), and the routing rule for the alternative tool. When/when-not/alternative are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who is connected, which ad accounts are available, how billing works — and the path from zero: the steps to set up, learn and grow, with the ones already done. Call it when the person asks what this can do or how to begin. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered externally. The description adds one genuinely new behavioral fact — 'Free' (no cost to call) — plus the notion that completed steps are included. With annotations carrying the burden, this modest addition merits a 3 rather than higher.
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 content is front-loaded and the usage trigger is placed last, which is reasonable ordering. But the middle clause ('the path from zero: the steps to set up, learn and grow, with the ones already done') is padded and hedged, and the em-dash construction is loose — it could be tightened to half the length without losing meaning.
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?
With no parameters and no output schema, the description carries the burden of conveying what comes back, and it largely does so by listing the four content areas. There is no mention of format or scope limits, but for a zero-argument orientation tool the coverage is adequate.
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 tool takes zero parameters and the schema is 100% documented, so there is nothing for the description to clarify; the baseline for a no-parameter tool applies. No parameter claims are made or contradicted.
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 enumerates what the tool surfaces — connection status, available ad accounts, billing behavior, and onboarding progress — which is concrete and distinguishable from sibling list/report tools. However, the verb is left implicit and the phrasing is somewhat impressionistic ('the path from zero', 'learn and grow'), so it reads more as a themed pitch than a precise capability statement.
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?
It gives an explicit trigger: 'Call it when the person asks what this can do or how to begin.' That is clear when-to-use guidance. It does not name alternatives or exclusions (e.g., versus the 'usage' or 'billing' siblings), so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates this server’s monitors for a TikTok ad account. Nothing in TikTok changes. Call tiktok_ads_create with {"action":"execute","tool_name":"tiktok_create_monitor","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:
tiktok_create_monitor: Watch every campaign, ad group or ad of this TikTok ad account and email when a rule holds on one of them. Changes only this server’s own monitor, nothing in TikTok, and never counts toward the monthly change limit. Every operation takes two calls with the same tool_name and arguments; the first changes nothing and returns a preview with confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. None of them count toward the monthly change limit. Input schemas: get_tool_schema for named operations; tiktok_ads_read {"action":"list_tools"} lists them all.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Always "execute". | |
| arguments | Yes | The fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call. | |
| tool_name | Yes | The operation name, e.g. tiktok_create_monitor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well past the annotations: it declares the tool is a no-op on the TikTok side, exempt from the monthly change limit, requires two calls with a confirm_token valid for 10 minutes, and that the first call changes nothing. These are exactly the behavioral facts an agent cannot infer from readOnlyHint/destructiveHint=false.
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?
Front-loaded and operationally ordered: scope, invocation shape, operation list, then the confirm-token protocol. It loses a point for repeating the same two facts twice ("nothing in TikTok changes" and "never counts toward the monthly change limit").
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?
Despite the nested arguments object and no output schema, the description covers the invocation envelope, the confirm-token round trip, and how to enumerate operations. An agent can construct a correct first and second call from this text alone.
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 action, tool_name, and arguments are already documented. The description adds only the "connection" and confirm_token conventions for arguments, which the schema description also covers, so it does not add meaningful semantics beyond the structured fields.
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 (creates this server's monitors for a TikTok ad account) and immediately scopes it: "Nothing in TikTok changes." That scope sentence alone separates it from tiktok_ads_update and tiktok_ads_delete, which operate on the ad platform itself.
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?
Explains when to reach for it (watch every campaign/ad group/ad and email when a rule holds) and gives the exact two-call protocol plus the discovery path via get_tool_schema and tiktok_ads_read {"action":"list_tools"}. It does not explicitly say when to prefer a different sibling over this one, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes this server’s monitors of a TikTok ad account. Nothing in TikTok changes. Call tiktok_ads_delete with {"action":"execute","tool_name":"tiktok_delete_monitor","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:
tiktok_delete_monitor: Delete a TikTok monitor: it stops being checked and stops sending email. Changes only this server’s own monitor, nothing in TikTok, and never counts toward the monthly change limit. Every operation takes two calls with the same tool_name and arguments; the first changes nothing and returns a preview with confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. None of them count toward the monthly change limit. Input schemas: get_tool_schema for named operations; tiktok_ads_read {"action":"list_tools"} lists them all.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Always "execute". | |
| arguments | Yes | The fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call. | |
| tool_name | Yes | The operation name, e.g. tiktok_delete_monitor. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite destructiveHint=true, the description supplies context annotations cannot: changes are confined to this server's own monitor, nothing in TikTok is mutated, and the action never consumes the monthly change limit. It also discloses the mandatory two-call preview/confirm_token flow with a 10-minute token window.
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?
Front-loaded with the core scope statement, then the call pattern, then the operation list. Slightly redundant, since 'nothing in TikTok changes' appears twice and the monthly-limit exclusion is stated in two places, but the density of useful information is high.
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?
With no output schema, the description still explains the two-phase response (preview plus confirm_token, then apply) and the safety boundary, which is everything an agent needs to call this destructive tool correctly.
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; the description earns more by explaining that "arguments" carries the operation's fields, the optional "connection" for multi-account setups, and the confirm_token on the second call, plus that tool_name selects the named operation.
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 (deletes this server's TikTok ad-account monitors) and immediately scopes it: 'Nothing in TikTok changes.' The named operation tiktok_delete_monitor is described concretely as stopping checks and email, which distinguishes it from the read/create/update 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?
Gives explicit invocation form, the rule for passing "connection" when multiple ad accounts exist, and pointers to get_tool_schema and tiktok_ads_read {"action":"list_tools"} for discovering operations. It does not explicitly say when to prefer tiktok_ads_update over delete, but the operational context is otherwise unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads Meta ad accounts. action "list_tools" lists every operation of every router with its field names, flags and the router that executes it (get_tool_schema returns the input schema); it does not call Meta and is free. action "execute" runs one read: {"action":"execute","tool_name":"list_campaigns","arguments":{}}. Reads:
tiktok_account_summary: The connected TikTok ad account: name, currency, time zone, country and status.
tiktok_list_campaigns: Campaigns of the TikTok ad account: objective, budget, whether they are on, and what TikTok says about delivery.
tiktok_list_adgroups: Ad groups of the TikTok ad account, or of one campaign: budget, bid, optimisation goal and schedule.
tiktok_list_ads: Ads of the TikTok ad account, or of one campaign or ad group: what they say, where they lead and which video they use.
tiktok_performance: What the TikTok ad account spent and got for it: spend, impressions, clicks, CTR, CPC, CPM, reach, conversions and results.
tiktok_revenue_report: Money your CRM or payment system received beside TikTok spend, per campaign or ad group: revenue, payments, ROAS, cost per payment and a verdict. Payments that matched nothing are a line of their own.
tiktok_ad_review_issues: Which switched-on TikTok ads failed review or run only partly, with TikTok's reasons and suggestions: the first thing to check when an ad does not spend.
tiktok_audience_breakdown: Where TikTok spend goes and what it brings by age, gender, country, region, placement or operating system.
tiktok_change_history: Who changed what in the TikTok ad account and when: budgets, bids, on/off status, targeting, creation and deletion.
tiktok_list_monitors: Monitors of this TikTok ad account: their conditions, status, last check and how often they triggered.
tiktok_get_monitor_history: When a TikTok monitor triggered, on which campaigns, ad groups or ads, with what numbers, and whether an email went out.
tiktok_test_monitor: Dry-run a TikTok monitor now: which campaigns, ad groups or ads would trigger and which are skipped, without recording or emailing. 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).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | list_tools: every operation with its field names, flags and router. execute: run the read named by tool_name. | |
| arguments | No | For execute: the fields of the operation, plus "connection" when several ad accounts are connected. Omit or {} when it has none. | |
| tool_name | No | For execute: the operation name from list_tools, e.g. tiktok_list_campaigns. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description adds genuinely new behavior: reads do not count toward the monthly change limit, and an identical read within 30 seconds may return cached data (see data_age_seconds). That caching disclosure is exactly the kind of non-obvious trait that saves an agent from misreading stale results.
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 twelve-operation bullet list is largely justified because the tool_name routing requires knowing available operation names, but the preamble wastes its most prominent sentences on Meta references and meta-commentary about list_tools instead of front-loading what the tool is. The critical routing example is buried mid-paragraph rather than leading.
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?
With no output schema, the per-operation bullets usefully describe what each read returns (spend, CTR, ROAS, review reasons, change attribution), which is the main burden here. The residual gap is the platform mix-up: an agent reading only the first line could conclude this touches Meta rather than TikTok ad accounts.
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 exceeds it by supplying a concrete invocation example ({"action":"execute","tool_name":"list_campaigns","arguments":{}}) and noting that "connection" is needed when several ad accounts are connected. The Meta/TikTok confusion in the preamble slightly muddies which account identifiers apply.
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 opening sentence, "Reads Meta ad accounts," names the wrong platform entirely and contradicts the tool name/title (TikTok), which is a real risk of misselection against meta_ads_read. The bulleted enumeration of twelve tiktok_* operations does eventually make the purpose unambiguous, but the agent has to read past a misleading lead to get there.
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?
It clearly explains the two-mode pattern — list_tools to discover operation names and fields, execute to run one read — and states that list_tools is free and makes no API call. What it does not do is tell the agent how to choose between this router and platform siblings like meta_ads_read, google_ads_read, revenue_report or performance_dashboard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pauses or switches back on objects and changes budgets in a TikTok ad account, and pauses or resumes this server’s TikTok monitors. Call tiktok_ads_update with {"action":"execute","tool_name":"tiktok_pause_campaign","arguments":{…}}; arguments carry the fields of the operation and "connection" when several ad accounts are connected. Operations:
tiktok_pause_campaign: Pause one TikTok campaign: it stops delivering and spending. Free, and it can be switched back on in TikTok Ads Manager. Free pause.
tiktok_pause_adgroup: Pause one TikTok ad group: it stops delivering and spending. Free, and it can be switched back on in TikTok Ads Manager. Free pause.
tiktok_pause_ad: Pause one TikTok ad: it stops delivering and spending. Free, and it can be switched back on in TikTok Ads Manager. Free pause.
tiktok_lower_campaign_budget: Lower the budget of one TikTok campaign. Only lowering: a higher budget is a separate change that increases spend. Only reduces spend, and counts toward the monthly change limit.
tiktok_lower_adgroup_budget: Lower the budget of one TikTok ad group. A daily budget changes from the next day; a lifetime budget at once. Only reduces spend, and counts toward the monthly change limit.
tiktok_enable_campaign: Switch one paused TikTok campaign back on: it starts delivering and spending again. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
tiktok_enable_adgroup: Switch one paused TikTok ad group back on: it starts delivering and spending again. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
tiktok_enable_ad: Switch one paused TikTok ad back on: it starts delivering and spending again. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
tiktok_raise_campaign_budget: Raise the budget of one TikTok campaign. It increases spend: approved by a signed-in person unless this account allows it from chat. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
tiktok_raise_adgroup_budget: Raise the budget of one TikTok ad group. A daily budget changes from the next day; a lifetime budget at once. CAN INCREASE SPEND, and this account allows it from chat: say so before executing.
tiktok_manage_monitor: Pause or resume a TikTok monitor. Changes only this server’s own monitor, nothing in TikTok, and never counts toward the monthly change limit. Every operation takes two calls with the same tool_name and arguments; the first changes nothing in TikTok and returns a preview. If the operation cannot increase spend, the preview includes confirm_token (accepted for 10 minutes): call again with it added to arguments to apply the change. An operation that can increase spend (switching on, a higher budget) runs from chat only if this account allows it — it does: say plainly that spend will grow before you execute one; otherwise its preview has no token, only an approve_url for a signed-in person. Pauses and monitor changes are free; other changes count toward the monthly change limit. Input schemas: get_tool_schema for named operations; tiktok_ads_read {"action":"list_tools"} lists them all.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Always "execute". | |
| arguments | Yes | The fields of the operation, "connection" when several ad accounts are connected, and on the second call the confirm_token from the first call. | |
| tool_name | Yes | The operation name, e.g. tiktok_pause_campaign. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only flag destructive/idempotent hints; the description goes far beyond by disclosing the preview returns no change, confirm_token lifetime (10 minutes), the approve_url path for spend-increasing operations with no token, and the monthly change limit. It also distinguishes free operations (pauses, monitor changes) from limit-consuming ones.
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 envelope and safety rules are front-loaded and the operation list is scannable. Some boilerplate repeats verbatim across entries ('Free pause.', 'CAN INCREASE SPEND, and this account allows it from chat: say so before executing'), which bloats the text without adding per-operation 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?
For a mutation tool with no output schema, the description covers everything an agent needs: what each operation does, the two-step confirmation, token expiry, the human-approval fallback, and cost/limit consequences. Nothing material about correct invocation 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?
Schema coverage is 100%, so the baseline is 3, but the description adds the meaning of the confirm_token round-trip and the "connection" field's purpose (multiple ad accounts). It also supplies the full operation vocabulary for tool_name, which the schema only exemplifies with one value.
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 opening sentence gives specific verbs (pause, switch back on, change budgets) and the resource (TikTok ad objects, plus this server's monitors), then enumerates every operation by name. It is clearly demarcated from siblings tiktok_ads_create/delete/read, which cover different mutation classes.
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?
It states explicitly when to use it (per-operation breakdown), how to invoke it (the {"action":"execute","tool_name":...,"arguments":{...}} envelope), and the alternative reads for discovery (get_tool_schema, tiktok_ads_read list_tools). The two-call preview-then-confirm protocol is spelled out rather than implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many changes were made this month and which ones. Free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds only the scoping of the data (changes this month) and the pricing note; it says nothing about plan limits, quota thresholds, or what an empty result means.
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, front-loaded sentences with no wasted framing. The telegraphic ending ('and which ones. Free.') is clipped but still readable and compact.
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?
With no output schema, the description usefully sketches the return (a count plus the list of changes) for a zero-parameter read tool. Missing only context on the limit itself, such as whether the count is against a quota or reset window.
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 tool takes zero parameters, so per the baseline there is nothing for the description to clarify beyond what the empty schema conveys. No parameter-related value could be added here.
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 concrete verb+resource: counting this month's changes and identifying which ones, framed as monthly change-limit usage. It is distinguishable from audit/billing siblings in intent, though it never names an alternative to disambiguate. Clear but without explicit sibling differentiation.
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 when-to-use guidance, no prerequisites, and no mention of how this relates to near-neighbours like billing or audit_account. 'Free' is a cost signal rather than usage direction, so the agent must infer when to reach for this tool.
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.
tiktok_ads_createtiktok_ads_deletetiktok_ads_readtiktok_ads_updatelinkedin_ads_readmicrosoft_ads_readaudit_accountaudit_conversion_trackingbillingbuild_campaignconnect_accountget_adviceget_insightsget_tool_schemagoogle_ads_creategoogle_ads_deletegoogle_ads_readgoogle_ads_updategoogle_analytics_readgoogle_campaign_performancemark_advicemeta_ads_createmeta_ads_deletemeta_ads_readmeta_ads_updateperformance_dashboardperformance_overviewrevenue_reportsearch_console_readsearch_toolsshow_dashboardstart_hereusageMeta Ads in your AI: approval before changes, undo for pauses and budgets, profit after returns.
Review authorized ad-account metrics with your AI assistant. Early access by invitation.
Your Google, Meta, Microsoft, TikTok and LinkedIn ads in your AI. Changes wait for your OK.
Google Ads, GA4, Search Console and Tag Manager for AI assistants. Every change is proposed first.
Add one secure layer between your agents and this server.