Go Shift
Server Details
Manage Google, Meta, TikTok, Snapchat and LinkedIn ads, plus GA4, Tag Manager and Search Console, by chat from Claude or ChatGPT. Spend increases need your confirmation first.
- Status
- Healthy
- Uptime
- 50.0% over the last 24 hours
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-06-18
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Score is being calculated.
Available Tools
223 toolsbudget_pacing_planBudget pacing plan for a clientARead-onlyInspect
Budget Guard: work out the total daily spend that keeps a client inside its budget for the rest of the period and split it across the client's ad accounts in proportion to their recent spend. It changes nothing. To apply it, read each account's campaigns with the platform's campaigns tool and propose new daily budgets with the platform's update_budget tool (increases need the user's confirmation as usual). Go Shift never pauses ads automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | Yes | Client folder name. | |
| language | No | The language the user is writing in. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'It changes nothing' plus the explicit two-step apply path through campaigns and update_budget. It also discloses that increases need user confirmation and that Go Shift never pauses ads automatically, which is genuine safety context beyond the annotations. It doesn't cover rate limits, auth requirements, or error behavior, so it is not a full behavioral 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 purpose is front-loaded in the first sentence, and each subsequent sentence adds the read-only guarantee, the apply workflow, and the no-auto-pause guarantee. The 'Budget Guard:' brand prefix and the trailing Go Shift safety note are slightly tangential, but nothing is redundant enough to obscure the core instruction.
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 two-parameter, read-only planning tool with no output schema, the description conveys what the result contains (a total daily spend figure and a per-account proportional split) and how to act on it. It lacks detail on the exact response structure and on how the remaining-period calculation handles edge cases like zero recent spend, which keeps it below a 5.
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%, with both folder and language documented inline including the enum values, so the schema carries parameter meaning. The description adds nothing about how folder scoping affects the split across accounts or how language shapes the response. Baseline 3 applies when the schema does the heavy lifting.
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 computation and its output shape: total daily spend that keeps a client within budget for the remaining period, split across the client's ad accounts proportional to recent spend. That is a clear verb+resource for a planning tool. It does not explicitly differentiate itself from sibling tools like google_ads_budget_plan, budget_status, or budgets_at_risk, so the agent must infer the client-level vs platform-level distinction.
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 downstream workflow guidance: read each account's campaigns with the campaigns tool, then propose new daily budgets via update_budget, with increases requiring user confirmation. This tells the agent what to do after the call. It stops short of stating when this tool should be chosen over budget_status or budgets_at_risk, leaving that selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
budgets_at_riskClient budgets at riskARead-onlyInspect
Budget Guard: list the clients whose budget is exceeded, forecast to overrun, or spending well below plan, worst first, with the main numbers. Use for 'which clients need attention on budget'. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | The language the user is writing in. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the trailing "Read-only" adds no new information. The description does contribute ordering (worst first) and scope (three risk conditions), but leaves thresholds for "well below plan" and the shape of the returned numbers undefined. Adequate but not rich.
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: the resource and scope come first, then the intended query, then a short safety note. No redundant clauses or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description's "with the main numbers" leaves the returned fields ambiguous, and the risk thresholds that determine inclusion are unstated. For a zero-required-parameter read tool this is workable, but the agent calling it cannot predict the response shape.
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?
There is a single optional language parameter with full schema description and an enum, so the schema carries the semantics. The description adds nothing about parameter behavior, which is acceptable at 100% coverage but earns only the 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?
States a concrete verb and resource: lists clients whose budget is exceeded, forecast to overrun, or under-spending, ordered worst first. Conditions and ordering give an agent a precise picture. It does not name the adjacent budget_status or budget_pacing_plan siblings, so the boundary between them remains 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 phrase "Use for 'which clients need attention on budget'" anchors a clear use case, giving the agent a real trigger. It stops short of naming alternatives or exclusions, so an agent must infer that budget_status and budget_pacing_plan cover different questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
budget_statusClient budget statusARead-onlyInspect
Budget Guard: a client's budget for the current period — spent, % used, remaining, planned to date, average and needed daily rate, forecast at period end, run-out date and state (green/yellow/red/grey), from the numbers Go Shift stores (refreshed every few hours; the reply says when). Omit folder to get every client that has a budget. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. Optional. | |
| language | No | The language the user is writing in. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/destructive/openWorld, so the bar is lower, and the description still adds substantive context: the numbers come from what Go Shift stores, they are refreshed every few hours, and the reply itself reports when. It also discloses the fan-out behavior when folder is omitted. It does not explain how the state colours are thresholded, which is the one behavioral detail an agent might need when interpreting 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?
It is front-loaded with the returned metrics, then the data-source and freshness caveat, then scoping, then the read-only tag — a sensible order with no filler sentences. The metric enumeration is long but each item is a distinct return field, so it earns its space rather than padding.
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?
There is no output schema, so the description carries the burden of describing the return payload, and it does so field by field including the period-end forecast and run-out date. It also covers freshness and the all-clients case. What is missing is any definition of the green/yellow/red/grey state semantics, which an agent would otherwise have to guess when reporting status.
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 exceeds that by defining the semantics of omitting folder — every client that has a budget — which the schema only marks as "Optional." The language parameter is left entirely to the schema, which is acceptable at full coverage.
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 concretely what the tool returns: spent, % used, remaining, planned to date, average and needed daily rate, forecast at period end, run-out date and a green/yellow/red/grey state. That is a specific resource with an enumerated payload, so an agent can tell it is a read of client budget status rather than a pacing plan or an alert list. It stops short of naming the near-identical siblings (budget_pacing_plan, budgets_at_risk), which is the only thing separating it from 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?
"Omit folder to get every client that has a budget" gives real guidance on scoping a call, and "Read-only" signals the safe class of operation. There is no statement of when to prefer this over budget_pacing_plan or budgets_at_risk, which is the key ambiguity given three budget siblings. Usage is therefore implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
client_briefClient instructionsRead-onlyInspect
Read the agency's instructions for one client folder (goals, target cost per result, tone for ad copy, things to avoid). Call it before analysing, writing ads or changing anything for a client that has instructions, and follow them.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | Yes | Client folder name. |
create_client_reportCreate a client report linkInspect
Build a shareable performance report for a client (Google Ads, Meta and TikTok accounts in a client folder, or one account) in the agency's own branding — logo, colours and sections set in Go Shift › Client reports. Returns a private link the user can send to their client or save as PDF. Use when the user asks for a report to send to a client.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Short note from the agency to its client shown on the report, in the report's language. Optional. | |
| title | No | Report title. Optional. | |
| folder | No | Client folder name. Omit to include every active ad account (up to 10). | |
| account | No | One ad account name or ID instead of a folder. | |
| end_date | No | YYYY-MM-DD. | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date) for a custom period. |
ga4_audienceGA4 audience breakdownRead-onlyInspect
Break down sessions and users by device, country or city.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| dimension | No | ||
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
ga4_create_custom_definitionCreate a GA4 custom dimension or metricInspect
Create a GA4 custom dimension or custom metric from an event parameter in the selected GA4 property (display name, parameter name, scope, optional unit). The first call returns a preview and changes nothing; it is created only on a second call with confirm=true after the user explicitly agrees in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | Yes | ||
| folder | No | Client folder name. | |
| confirm | No | ||
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| description | No | ||
| display_name | Yes | ||
| parameter_name | Yes | ||
| definition_type | Yes | ||
| measurement_unit | No |
ga4_custom_definitionsGA4 custom dimensions and metricsRead-onlyInspect
List custom dimensions and metrics defined for the selected property.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. |
ga4_custom_reportGA4 custom reportRead-onlyInspect
Run a GA4 report with dimensions and metrics validated against the property's getMetadata catalog. Use GA4 API field names.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| metrics | Yes | ||
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| dimensions | Yes | ||
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
ga4_ecommerceGA4 ecommerceRead-onlyInspect
Ecommerce performance including purchases, purchase revenue and top purchased items.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
ga4_key_eventsGA4 key eventsRead-onlyInspect
Show key events and event counts with optional campaign breakdown, plus which events are configured as key events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
ga4_link_google_adsLink GA4 to Google AdsDestructiveInspect
Link the selected GA4 property to a Google Ads account (customer ID without hyphens) so conversions and audiences can be shared. The first call returns a preview and changes nothing; the link is created only on a second call with confirm=true after the user explicitly agrees in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| confirm | No | ||
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| customer_id | Yes |
ga4_overviewGA4 property overviewRead-onlyInspect
GA4 overview with previous-period comparison and daily trend: sessions, users, new users, views, key events and purchase revenue.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
ga4_pagesGA4 pages and landing pagesRead-onlyInspect
Top pages and landing pages by views, sessions, engagement and key events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). | |
| landing_pages | No |
ga4_realtimeGA4 realtime (last 30 minutes)Read-onlyInspect
Realtime active users in the last 30 minutes by country, source/medium and page title.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. |
ga4_set_key_eventMark or unmark a GA4 key eventDestructiveInspect
Mark a GA4 event as a key event (conversion) or unmark it, in the selected GA4 property. The first call returns a preview and changes nothing; the change is applied only on a second call with confirm=true after the user explicitly agrees in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| folder | No | Client folder name. | |
| confirm | No | ||
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| event_name | Yes |
ga4_tracking_checkGA4 tracking checkRead-onlyInspect
Check linked Google Ads accounts, paid sessions with missing campaign data, and whether GA4 key events are defined.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
ga4_traffic_acquisitionGA4 traffic acquisitionRead-onlyInspect
Traffic acquisition by source/medium, campaign and default channel group, including sessions, engaged sessions, conversions/key events and revenue.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| dimension | No | ||
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
google_ads_add_assetsAdd sitelinks, callouts or a call assetInspect
Create sitelinks, callouts and/or a call asset and attach them to a campaign (or the whole account if campaign_id is omitted).
| Name | Required | Description | Default |
|---|---|---|---|
| call | No | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. Use to preview. | |
| callouts | No | ||
| sitelinks | No | ||
| campaign_id | No |
google_ads_add_audiencesAdd audiences to a campaign or ad groupInspect
Add audience segments (from google_ads_find_audiences) to a campaign or ad group, as observation (default: no reach change, just reporting and bid insight) or targeting (narrows reach). Runs directly. Not for Performance Max (use audience signals in the Google Ads UI).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| ad_group_id | No | ||
| campaign_id | No | ||
| user_list_ids | No | Remarketing / customer list IDs. | |
| user_interest_ids | No | Affinity / in-market segment IDs. |
google_ads_add_display_adAdd a Display ad (or ad group) to a Display campaignInspect
Add a responsive display ad to an existing Display ad group, or create a new ad group (paused) in a Display campaign with the ad. Images by https URL.
| Name | Required | Description | Default |
|---|---|---|---|
| logos | No | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| final_url | Yes | ||
| headlines | Yes | ||
| ad_group_id | No | ||
| campaign_id | No | With ad_group_name, creates a new ad group. | |
| descriptions | Yes | ||
| ad_group_name | No | ||
| business_name | Yes | ||
| long_headline | Yes | ||
| square_images | Yes | ||
| landscape_images | Yes |
google_ads_add_keywordsAdd keywords to an ad groupInspect
Add keywords to an ad group. If the campaign is running, keywords are added PAUSED (turn them on with google_ads_set_status).
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. Use to preview. | |
| keywords | Yes | ||
| ad_group_id | Yes |
google_ads_add_more_assetsAdd structured snippets, business name or image assetsInspect
Add structured snippets, a business name and/or image assets (by https URL) to a campaign or the account. (Sitelinks, callouts and calls: google_ads_add_assets.)
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| snippets | No | ||
| image_urls | No | Landscape 1.91:1 or square 1:1 images, https. | |
| campaign_id | No | ||
| business_name | No |
google_ads_add_negative_keywordsAdd negative keywordsIdempotentInspect
Add negative keywords to a campaign (or an ad group). Runs immediately because it only reduces spend.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. Use to preview. | |
| keywords | Yes | ||
| ad_group_id | No | ||
| campaign_id | No |
google_ads_add_radiusAdd radius (proximity) targetingInspect
Target people within a radius of a point (latitude/longitude) on a campaign. Widens reach, so it needs confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | ||
| label | No | Name of the place, for the record. | |
| radius | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| latitude | Yes | ||
| longitude | Yes | ||
| campaign_id | Yes |
google_ads_ad_performanceGoogle Ads performance per adRead-onlyInspect
Use this to compare individual Google Ads ads. Returns one row per ad with spend, conversions, cost per conversion, CTR, approval status and its first headlines. Read-only. The result is also displayed as a visual card. Default period: last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in. | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). | |
| campaign_id | No |
google_ads_adsGoogle Ads ads and approval statusRead-onlyInspect
Ads with type, status, policy approval status, final URL, headlines/descriptions (responsive search ads) and performance for the period.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). | |
| campaign_id | No | Limit to one campaign ID. |
google_ads_assetsGoogle Ads assets (extensions and Performance Max assets)Read-onlyInspect
List assets with IDs: campaign/account sitelinks, callouts, snippets, calls, images, and Performance Max asset-group assets with Google's performance label. Use to find asset IDs before removing or replacing.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| campaign_id | No | Optional: one campaign. |
google_ads_breakdownGoogle Ads performance breakdownRead-onlyInspect
Performance split by device, date, day of week, hour of day, location (country/region), age or gender. Optionally for one campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| by | Yes | ||
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). | |
| campaign_id | No | Limit to one campaign ID. |
google_ads_budget_planGoogle Ads budget allocation planRead-onlyInspect
Use this when the user asks how to split or move budget between Google Ads campaigns. Returns a proposed new daily budget per enabled campaign, based on cost per conversion, impression share lost to budget and current budget usage. Read-only: it only proposes; applying a budget is done with google_ads_update_budget after the user confirms. The result is also displayed as a visual card. Default period: last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). | |
| total_daily_budget | No | Optional new total daily budget to distribute (account currency). Default: keep the current total. |
google_ads_bulk_statusPause or turn on many items at onceDestructiveIdempotentInspect
Pause or enable many campaigns, ad groups, ads or keywords in one call. Pausing runs directly; enabling needs the user's confirmation in chat. For ads and keywords pass ids as 'adGroupId~id'.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | IDs. For ads/keywords use 'adGroupId~adId' / 'adGroupId~criterionId'. | |
| level | Yes | ||
| status | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. |
google_ads_campaignsGoogle Ads campaign settingsRead-onlyInspect
List campaigns with their settings: status, serving status, channel type, bidding strategy and targets (tCPA/tROAS), daily budget, start/end dates and networks. Use before changing anything.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| status | No | Default ALL (except removed). | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. |
google_ads_campaign_targetingGoogle Ads campaign targetingRead-onlyInspect
Full targeting of one campaign: locations (and radius), languages, ad schedule, device bid adjustments, audiences, attached negative keyword lists and campaign negatives. Use before changing targeting.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| campaign_id | Yes |
google_ads_change_historyGoogle Ads change historyRead-onlyInspect
Recent changes made in the account (who, what, when) from Google Ads change history. Covers up to the last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Default 14 (Google keeps 30 days). | |
| limit | No | ||
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. |
google_ads_conversion_performancePerformance per conversion actionRead-onlyInspect
Use this to see which conversion actions are being recorded. Returns conversions and conversion value per conversion action (for example purchase, lead, call), including secondary actions. Read-only. The result is also displayed as a visual card. Default period: last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in. | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
google_ads_conversionsGoogle Ads conversion actionsRead-onlyInspect
Conversion actions (name, category, status, primary/secondary, counting, source) with conversions recorded for each in the period.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
google_ads_create_adCreate a responsive search ad (paused)Inspect
Add a responsive search ad to an ad group. Created PAUSED so it can be reviewed before it runs.
| Name | Required | Description | Default |
|---|---|---|---|
| path1 | No | ||
| path2 | No | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. Use to preview. | |
| final_url | Yes | ||
| headlines | Yes | ||
| ad_group_id | Yes | ||
| descriptions | Yes |
google_ads_create_ad_groupCreate an ad group (paused) with keywords and an adInspect
Add an ad group to an existing campaign, with keywords and a responsive search ad. Created PAUSED.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| path1 | No | ||
| path2 | No | ||
| account | No | Google Ads customer ID or account name. | |
| cpc_bid | No | ||
| dry_run | No | Validate with Google without making changes. Use to preview. | |
| keywords | No | ||
| final_url | No | ||
| headlines | No | ||
| campaign_id | Yes | ||
| descriptions | No |
google_ads_create_app_campaignCreate an App campaign (paused)Inspect
Create an App campaign for app installs (or in-app actions) from Google Play or the App Store: budget, target cost per install, locations, languages, and an app ad with headlines (≤30), descriptions (≤90), images and YouTube videos. Always PAUSED.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| name | Yes | ||
| store | Yes | ||
| app_id | Yes | Package name (com.example.app) or App Store numeric ID. | |
| images | No | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| headlines | Yes | ||
| languages | No | ||
| locations | Yes | ||
| target_cpi | Yes | Target cost per install/action. | |
| daily_budget | Yes | ||
| descriptions | Yes | ||
| youtube_videos | No |
google_ads_create_conversion_actionCreate a website conversion actionInspect
Create a website (WEBPAGE) conversion action and return its event snippet for the site or GTM. Created as secondary unless primary=true. Doesn't change spend directly.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| value | No | Default value per conversion. | |
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| primary | No | Use for bidding. Default false. | |
| category | Yes | ||
| counting | No | Leads: ONE_PER_CLICK. Purchases: MANY_PER_CLICK. | |
| use_dynamic_value | No | Value sent by the site per conversion. | |
| click_lookback_days | No |
google_ads_create_demandgen_campaignCreate a Demand Gen or YouTube campaign (paused)Inspect
Create a Demand Gen campaign (YouTube, Discover, Gmail, Display) with one ad group and one ad: an image ad (landscape/square/portrait images + logo) or a video ad (YouTube links + logo). Pick channels for YouTube-only. Always PAUSED.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| logos | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| bidding | No | ||
| dry_run | No | Validate with Google without making changes. | |
| max_cpc | No | ||
| channels | No | Channels. Omit for all Google channels. YouTube-only: the three YOUTUBE_* values. | |
| final_url | Yes | ||
| headlines | Yes | ||
| languages | No | ||
| locations | Yes | ||
| target_cpa | No | ||
| target_roas | No | ||
| daily_budget | Yes | ||
| descriptions | Yes | ||
| business_name | Yes | ||
| square_images | No | ||
| user_list_ids | No | ||
| call_to_action | No | e.g. Learn more, Shop now, Sign up. | |
| long_headlines | No | Video ads. | |
| youtube_videos | No | YouTube links or IDs — makes it a video ad. | |
| portrait_images | No | ||
| landscape_images | No | ||
| user_interest_ids | No |
google_ads_create_display_campaignCreate a Display campaign (paused)Inspect
Create a Display campaign with one ad group and a responsive display ad: budget, bidding, locations, languages, final URL, headlines (1–5, ≤30), long headline (≤90), descriptions (1–5, ≤90), business name, images by https URL (≥1 landscape 1.91:1, ≥1 square 1:1; logo optional). Optional audience segment IDs (targeting). Always PAUSED.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| logos | No | ||
| account | No | Google Ads customer ID or account name. | |
| bidding | No | ||
| dry_run | No | Validate with Google without making changes. | |
| max_cpc | No | ||
| final_url | Yes | ||
| headlines | Yes | ||
| languages | No | ||
| locations | Yes | ||
| target_cpa | No | ||
| daily_budget | Yes | ||
| descriptions | Yes | ||
| business_name | Yes | ||
| long_headline | Yes | ||
| square_images | Yes | ||
| user_list_ids | No | ||
| landscape_images | Yes | ||
| user_interest_ids | No |
google_ads_create_pmax_campaignCreate a Performance Max campaign (paused)Inspect
Create a Performance Max campaign with one asset group: budget, bidding, locations, languages, final URL, headlines (3–15, ≤30), long headlines (1–5, ≤90), descriptions (2–5, ≤90, one ≤60), business name, and images by https URL (at least 1 landscape 1.91:1 ≥1200×628, 1 square 1:1 ≥1200×1200, 1 square logo ≥128×128). Optional search themes. Always created PAUSED.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| logos | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| bidding | No | ||
| dry_run | No | Validate with Google without making changes. | |
| final_url | Yes | ||
| headlines | Yes | ||
| languages | No | ||
| locations | Yes | ||
| target_cpa | No | ||
| target_roas | No | e.g. 3 = 300%. | |
| daily_budget | Yes | ||
| descriptions | Yes | ||
| business_name | Yes | ||
| search_themes | No | ||
| square_images | Yes | ||
| long_headlines | Yes | ||
| landscape_images | Yes |
google_ads_create_search_campaignCreate a Google Ads Search campaign (paused)Inspect
Create a Google Ads Search campaign in one call: campaign budget and bidding strategy, locations (people in the location by default) and languages, the Search Partners setting, start and end dates, one ad group with keywords and negative keywords, and one responsive search ad (headlines, descriptions, final URL, display paths). The campaign is always created PAUSED and spends nothing; enabling it is a separate step that needs the user's confirmation. Locations can be names (for example 'Alexandria', 'Riyadh') or geo target IDs. Use dry_run=true to validate without creating anything.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| path1 | No | ||
| path2 | No | ||
| reason | No | Short justification. | |
| account | No | Google Ads customer ID or account name. | |
| bidding | No | Default MAXIMIZE_CLICKS. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. Use to preview. | |
| max_cpc | No | CPC ceiling for MAXIMIZE_CLICKS, or default bid for MANUAL_CPC. | |
| end_date | No | ||
| keywords | Yes | ||
| final_url | Yes | ||
| headlines | Yes | Max 30 chars each. | |
| languages | No | Default ['ar','en']. | |
| locations | Yes | ||
| start_date | No | ||
| target_cpa | No | For TARGET_CPA, in account currency. | |
| daily_budget | Yes | In account currency. | |
| descriptions | Yes | Max 90 chars each. | |
| ad_group_name | No | ||
| location_mode | No | Default PRESENCE. | |
| search_partners | No | Default false. | |
| negative_keywords | No |
google_ads_create_shopping_campaignCreate a Standard Shopping campaign (paused)Inspect
Create a Standard Shopping campaign for a linked Merchant Center feed: budget, bidding (manual CPC, max clicks or tROAS), locations, one product ad group with a default product bid. Always PAUSED. Split products with google_ads_product_groups.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| bidding | No | ||
| dry_run | No | Validate with Google without making changes. | |
| priority | No | ||
| locations | Yes | ||
| feed_label | No | Optional, e.g. SA. | |
| default_bid | No | Product max CPC. Default 1. | |
| target_roas | No | ||
| daily_budget | Yes | ||
| merchant_center_id | Yes |
google_ads_demandgen_ad_groupDemand Gen ad groups, ads and channelsDestructiveInspect
On an existing Demand Gen campaign: add an ad group (paused) with an image or video ad, add an ad to an ad group, or change an ad group's channels. Widening channels needs confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| logos | No | ||
| action | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| channels | No | Channels. Omit for all Google channels. YouTube-only: the three YOUTUBE_* values. | |
| final_url | No | ||
| headlines | No | ||
| ad_group_id | No | ||
| campaign_id | No | ||
| descriptions | No | ||
| ad_group_name | No | ||
| business_name | No | ||
| square_images | No | ||
| call_to_action | No | ||
| long_headlines | No | ||
| youtube_videos | No | ||
| portrait_images | No | ||
| landscape_images | No |
google_ads_display_targetingDisplay / video ad group targetingDestructiveInspect
On a Display (or Demand Gen/Video) ad group: add placements (websites, apps 'android:com.x' / 'ios:123', YouTube channel/video), topics (IDs from google_ads_find_topics), contextual keywords, or set demographics (age ranges and genders to show to). Or exclude placements at campaign level, or remove criteria by ID. Adding targeting narrows reach and runs directly; removing targeting widens reach and needs confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| ages | No | Age ranges to SHOW to (others are excluded). | |
| action | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| genders | No | Genders to SHOW to. | |
| keywords | No | ||
| topic_ids | No | ||
| placements | No | Website URLs, YouTube channel/video links, or apps as 'android:com.package' / 'ios:123456'. | |
| ad_group_id | No | ||
| campaign_id | No | For exclude_placements. | |
| criterion_ids | No |
google_ads_enable_campaignTurn a Google Ads campaign onDestructiveInspect
Turn a paused campaign on (starts spending). The first call returns a preview; ask the user to confirm in the chat, then call again with confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | ||
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| confirm | No | Set true only after the user explicitly confirmed in the chat. | |
| campaign_id | Yes |
google_ads_explain_changeExplain a Google Ads performance changeRead-onlyInspect
Explain why a metric changed between the selected period and the previous period of equal length: which campaigns, devices and networks drove the change. Shown as a card. Default: last 7 days vs the 7 days before.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| metric | No | Metric to explain. Default conversions. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
google_ads_find_audiencesFind Google Ads audience segmentsRead-onlyInspect
Search Google's affinity and in-market segments by name, and list the account's own audience lists (remarketing, customer lists). Returns IDs for google_ads_add_audiences.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Words to search in segment names, e.g. 'real estate', 'travel'. English works best. | |
| account | No | Google Ads customer ID or account name. |
google_ads_find_locationsFind Google Ads locationsRead-onlyInspect
Search Google's location targets by name (countries, regions, cities, districts, postal codes) and return their IDs and types.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| language | No | Language of the card: the language the user is writing in. | |
| country_code | No | Optional, e.g. SA, EG. |
google_ads_find_topicsFind Display topicsRead-onlyInspect
Search Google's Display topic categories by name and return their IDs (for google_ads_display_targeting).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| language | No | Language of the card: the language the user is writing in. |
google_ads_ga4_campaign_comparisonGoogle Ads vs GA4 campaign comparisonRead-onlyInspect
Compare Google Ads campaign cost with GA4 sessions and key events by campaign name. Choose an Ads account and a GA4 property.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| property | No | GA4 property ID or property name. Required when multiple AI-enabled properties exist. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
google_ads_keyword_ideasGoogle Ads keyword research (Keyword Planner)Read-onlyInspect
Keyword Planner ideas from seed keywords and/or a website URL: average monthly searches, competition and top-of-page bid range in the account currency, for chosen locations and language. Shown as a card.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Optional website or landing page URL to get ideas from. | |
| limit | No | Max ideas. Default 50. | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| keywords | No | Seed keywords (in the target language). | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| locations | No | Location names, e.g. 'Saudi Arabia', 'Riyadh', 'Egypt'. Default: the account's country is unknown, so pass at least one. | |
| keyword_language | No | Language of the searches. Default ar. |
google_ads_keywordsGoogle Ads keywords and quality scoreRead-onlyInspect
Keywords with match type, status, quality score (and its components), bids and performance. Set negatives=true to list negative keywords instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| negatives | No | ||
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). | |
| campaign_id | No | Limit to one campaign ID. |
google_ads_labelsLabelsRead-onlyInspect
List the account's labels and which campaigns carry each label.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| language | No | Language of the card: the language the user is writing in. |
google_ads_link_merchant_centerLink or unlink Merchant CenterDestructiveInspect
Send a link invitation to a Merchant Center account (accept it in Merchant Center), or remove a link (see google_ads_merchant_links). Needed for Shopping and retail Performance Max.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| product_link_id | No | ||
| merchant_center_id | No |
google_ads_manage_labelsCreate and apply labelsDestructiveInspect
Create a label, or attach/detach a label to campaigns, to organise and report on campaigns. Runs directly.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| color | No | Hex like #E85D04 (create). | |
| action | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| label_id | No | ||
| campaign_ids | No |
google_ads_merchant_linksMerchant Center linksRead-onlyInspect
Merchant Center accounts linked to this Google Ads account (needed for Shopping and retail Performance Max), including pending invitations.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| language | No | Language of the card: the language the user is writing in. |
google_ads_negative_listManage shared negative keyword listsDestructiveInspect
Manage shared negative keyword lists: create a list (with keywords), add keywords to a list, attach a list to campaigns, or detach it. Create/add/attach reduce spend and run directly; detach widens reach and needs confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | For create. | |
| action | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| list_id | No | Shared set ID (not needed for create). | |
| keywords | No | ||
| campaign_ids | No |
google_ads_negative_listsShared negative keyword listsRead-onlyInspect
List the account's shared negative keyword lists, which campaigns use them, and the keywords of one list (list_id).
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| list_id | No | ||
| language | No | Language of the card: the language the user is writing in. |
google_ads_organic_vs_paidOrganic vs paid searchRead-onlyInspect
Compare Search Console queries with Google Ads search terms for the same period: terms you pay for while already ranking top 3 organically (possible savings), paid terms with no organic presence (SEO gaps), and organic winners you don't advertise on.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | YYYY-MM-DD | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| date_range | No | ||
| start_date | No | YYYY-MM-DD |
google_ads_pause_campaignPause a Google Ads campaignDestructiveIdempotentInspect
Pause a campaign. Pausing never spends money, so it runs immediately if the workspace allows pausing.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| campaign_id | Yes |
google_ads_performanceGoogle Ads performanceRead-onlyInspect
Use this when the user asks how their Google Ads account or campaigns are performing. Returns spend, conversions, cost per conversion, clicks, CTR, CPC, conversion value and ROAS for the period, the change versus the previous period, a daily trend and a per-campaign table (or per ad group with level=ad_group), plus short automatic insights. Read-only. The result is also displayed to the user as a visual dashboard card. Default period: last 30 days; amounts are in each account's currency.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | account/campaign = dashboard (default). ad_group = ad-group table. | |
| limit | No | Max rows per account for the ad-group table. Default 50. | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the dashboard. Always set it to the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
google_ads_placementsWhere ads ran (placements)Read-onlyInspect
Use this to see where Display, Video, Demand Gen and Performance Max ads were shown. Returns the websites, apps and YouTube channels or videos with their spend and conversions, so the user can decide which placements to exclude. Read-only. The result is also displayed as a visual card. Default period: last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in. | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). | |
| campaign_id | No |
google_ads_pmax_asset_groupPerformance Max asset groupsDestructiveInspect
Add a new asset group (paused) to an existing Performance Max campaign with its texts and images, or update an asset group's name, final URL or status (pause/enable — enabling needs confirmation).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| logos | No | ||
| action | Yes | ||
| status | No | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| final_url | No | ||
| headlines | No | ||
| campaign_id | No | ||
| descriptions | No | ||
| business_name | No | ||
| search_themes | No | ||
| square_images | No | ||
| asset_group_id | No | ||
| long_headlines | No | ||
| landscape_images | No |
google_ads_pmax_assetsAdd or remove Performance Max asset-group assetsDestructiveInspect
Add text assets (headlines, long headlines, descriptions) and images (https URLs) to a Performance Max asset group, or unlink assets by asset ID and field type. Runs directly.
| Name | Required | Description | Default |
|---|---|---|---|
| logos | No | ||
| remove | No | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| headlines | No | ||
| descriptions | No | ||
| square_images | No | ||
| asset_group_id | Yes | ||
| long_headlines | No | ||
| landscape_images | No |
google_ads_pmax_audience_signalPerformance Max audience signalsDestructiveInspect
Add an audience signal (segments from google_ads_find_audiences: affinity/in-market IDs and/or your audience lists) to a Performance Max asset group, or remove a signal by its resource name (see google_ads_campaign_targeting / assets). Signals guide Google; they don't restrict reach. Runs directly.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| action | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| user_list_ids | No | ||
| asset_group_id | Yes | ||
| user_interest_ids | No | ||
| signal_resource_name | No |
google_ads_pmax_insightsPerformance Max search categories and asset ratingsRead-onlyInspect
Use this for one Performance Max campaign. Returns the search-term categories it matched (with clicks and conversions) and Google's performance rating of each asset (Best, Good, Low). Read-only. The result is also displayed as a visual card. Default period: last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in. | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). | |
| campaign_id | Yes |
google_ads_pmax_listing_filtersRetail Performance Max product filtersDestructiveInspect
Rebuild which products a retail Performance Max asset group advertises, by one dimension: include only some values, or include all except some. Including more products needs confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| dimension | Yes | ||
| asset_group_id | Yes | ||
| exclude_values | No | Advertise everything except these. | |
| include_values | No | Advertise only these (others excluded). |
google_ads_pmax_search_themesPerformance Max search themesDestructiveInspect
Add or remove search themes (signals of what people search for) on a Performance Max asset group. Adding widens reach and needs confirmation; removing runs directly.
| Name | Required | Description | Default |
|---|---|---|---|
| add | No | ||
| remove | No | Exact theme texts to remove. | |
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| asset_group_id | Yes |
google_ads_policy_issuesDisapproved and limited adsRead-onlyInspect
Ads that are disapproved or limited by Google policy, with the policy reasons. Shown as a card.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| language | No | Language of the card: the language the user is writing in. |
google_ads_product_groupsShopping product groupsDestructiveInspect
Rebuild a Shopping ad group's product groups by one dimension (brand, product type, item ID, custom label, condition): give each value a bid or exclude it, plus a bid (or exclusion) for everything else. Higher bids or un-excluding need confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| dimension | Yes | ||
| others_bid | No | ||
| ad_group_id | Yes | ||
| exclude_others | No |
google_ads_queryGoogle Ads query (GAQL, read-only)Read-onlyInspect
Run a read-only Google Ads Query Language SELECT statement on one account for analysis not covered by other tools. Only SELECT is allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A GAQL SELECT statement. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. |
google_ads_reach_frequencyReach and frequencyRead-onlyInspect
Use this for reach questions on Display, Video and Demand Gen campaigns. Returns, per campaign, the number of unique users reached and the average number of impressions per user. Read-only. The result is also displayed as a visual card. Default period: last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in. | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
google_ads_recommendationsGoogle Ads recommendationsRead-onlyInspect
Google's optimization recommendations for the account (type, campaign, estimated impact). Read-only: nothing is applied.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. |
google_ads_removeRemove a campaign, ad group, ad or keywordsDestructiveInspect
Permanently remove (status REMOVED) a campaign, ad group, ad or keywords. Cannot be undone. Always needs the user's explicit confirmation in chat: call once to get the preview, then again with confirm=true and confirm_name set to the exact name shown. Prefer pausing when unsure.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Campaign or ad group ID; for ads/keywords 'adGroupId~id'. | |
| level | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| confirm_name | No | The exact name from the preview (for keywords: the keyword text). |
google_ads_remove_assetsRemove assets from a campaign or the accountDestructiveInspect
Unlink assets (sitelinks, callouts, snippets, calls, images) from a campaign or the account by asset ID and type (see google_ads_assets). The assets stay in the library. Runs directly.
| Name | Required | Description | Default |
|---|---|---|---|
| assets | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| campaign_id | No | Omit for account-level assets. |
google_ads_remove_negative_keywordsRemove negative keywordsDestructiveInspect
Remove campaign- or ad-group-level negative keywords by criterion ID (see google_ads_keywords or google_ads_campaign_targeting). Widens reach, so it needs the user's confirmation in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| ad_group_id | No | ||
| campaign_id | No | ||
| criterion_ids | Yes |
google_ads_search_term_insightsGoogle Ads search-term insightsRead-onlyInspect
Use this to analyse the real search terms that triggered Google Ads. Returns three lists: converting search terms not yet added as keywords, search terms that spent without converting (negative keyword candidates), and single words that waste money across many terms. Read-only. The result is also displayed as a visual card. Default period: last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). | |
| campaign_id | No | Limit to one campaign. |
google_ads_search_termsGoogle Ads search termsRead-onlyInspect
Search terms that triggered ads, with spend and conversions, sorted by spend. Useful for finding wasted spend and negative keywords.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| date_range | No | Preset period. Default LAST_7_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
google_ads_set_ad_scheduleSet a campaign's ad scheduleDestructiveInspect
Replace a campaign's ad schedule (days and hours, account time zone) with optional bid adjustments. Restricting a 24/7 campaign runs directly; widening or replacing an existing schedule needs confirmation. Pass an empty list to remove the schedule (runs 24/7, needs confirmation).
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| schedule | Yes | ||
| campaign_id | Yes |
google_ads_set_asset_statusPause or enable an extension on a campaignDestructiveInspect
Pause or re-enable a campaign's asset link (e.g. a call asset outside working hours) without deleting it. Enabling needs confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| status | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| asset_id | Yes | ||
| campaign_id | Yes |
google_ads_set_dates_and_frequencyCampaign dates and frequency capDestructiveInspect
Set a campaign's start date (only before it starts), end date (or clear it), and an impression frequency cap (Display, Video, Demand Gen). Extending or clearing the end date, or raising/removing a cap, needs confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| end_date | No | ||
| start_date | No | ||
| campaign_id | Yes | ||
| frequency_cap | No | ||
| clear_end_date | No | ||
| remove_frequency_cap | No |
google_ads_set_device_bidsSet device bid adjustmentsDestructiveInspect
Bid up or down by device (mobile, desktop, tablet) on a campaign or an ad group. -100 excludes the device. Lowering runs directly; raising needs confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| mobile_pct | No | ||
| tablet_pct | No | ||
| ad_group_id | No | ||
| campaign_id | No | ||
| desktop_pct | No |
google_ads_set_keyword_bidChange a keyword or ad group CPC bidDestructiveInspect
Set the max CPC bid of a keyword (with ad_group_id) or of an ad group. Lowering runs immediately; raising needs the user's confirmation in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Short justification. | |
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| cpc_bid | Yes | ||
| keyword_id | No | Omit to change the ad group default bid. | |
| ad_group_id | Yes |
google_ads_set_statusPause or turn on an ad group, ad or keywordDestructiveIdempotentInspect
Pause or enable an ad group, ad or keyword (campaigns: use google_ads_pause_campaign / google_ads_enable_campaign). Pausing runs immediately; enabling needs the user's confirmation in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Ad group ID, ad ID or keyword criterion ID. | |
| level | Yes | ||
| reason | No | Short justification. | |
| status | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| ad_group_id | No | Required for ad and keyword. |
google_ads_tracking_auditGoogle Ads tracking health checkRead-onlyInspect
Checks conversion tracking health: auto-tagging, enabled primary conversion actions, actions with no recent conversions, duplicate primary actions in the same category, and clicks without conversions. Returns findings with severity and a fix for each.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. |
google_ads_update_adEdit a responsive search adDestructiveInspect
Replace the headlines, descriptions, final URL and/or display paths of an existing responsive search ad. The ad goes back to Google review. Does not raise spend, so it runs directly.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_id | Yes | ||
| path1 | No | ||
| path2 | No | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| final_url | No | ||
| headlines | No | 3–15, max 30 chars each. Replaces all headlines. | |
| descriptions | No | 2–4, max 90 chars each. Replaces all descriptions. |
google_ads_update_ad_groupUpdate ad group settingsDestructiveInspect
Rename an ad group or change its default max CPC or target CPA. Raising a bid or target needs the user's confirmation in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| cpc_bid | No | ||
| dry_run | No | Validate with Google without making changes. | |
| target_cpa | No | ||
| ad_group_id | Yes |
google_ads_update_app_adEdit an App campaign adDestructiveInspect
Replace headlines/descriptions and add images or YouTube videos on an App campaign ad (or remove all images/videos with clear_images/clear_videos). Runs directly.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_id | Yes | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| headlines | No | ||
| add_images | No | ||
| add_videos | No | ||
| clear_images | No | ||
| clear_videos | No | ||
| descriptions | No |
google_ads_update_budgetChange a Google Ads campaign budgetDestructiveInspect
Change a campaign's daily budget (in the account currency). Decreases run immediately. Increases need the user's explicit confirmation in the chat: the first call returns a preview; ask the user, then call again with confirm=true. Budgets above the user's daily cap are blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Short justification. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| confirm | No | Set true only after the user explicitly confirmed this increase in the chat. | |
| campaign_id | Yes | ||
| daily_budget | Yes |
google_ads_update_campaignUpdate campaign settingsDestructiveInspect
Change campaign settings: name, end date, location mode (presence vs interest), add/remove locations, search partners/display network, bidding strategy or target CPA. Changes that can raise spend or reach (bidding, higher target, more locations, networks) need the user's confirmation in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| reason | No | Short justification. | |
| account | No | Google Ads customer ID or account name. | |
| bidding | No | ||
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. Use to preview. | |
| end_date | No | YYYY-MM-DD | |
| target_cpa | No | ||
| campaign_id | Yes | ||
| target_roas | No | For MAXIMIZE_CONVERSION_VALUE, e.g. 3 = 300%. | |
| add_locations | No | ||
| location_mode | No | ||
| display_network | No | ||
| search_partners | No | ||
| remove_location_ids | No |
google_ads_update_conversion_actionUpdate a conversion actionDestructiveInspect
Rename, change value or counting, enable/hide, or switch a conversion action between primary (used for bidding) and secondary. Changing primary status or value affects automated bidding, so it needs confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| value | No | ||
| status | No | ||
| account | No | Google Ads customer ID or account name. | |
| confirm | No | Set true only after the user explicitly confirmed this change in the chat. | |
| dry_run | No | Validate with Google without making changes. | |
| primary | No | ||
| counting | No | ||
| conversion_action_id | Yes |
google_ads_update_display_adEdit a responsive display adDestructiveInspect
Replace headlines, long headline, descriptions, business name, final URL and/or images of a responsive display ad. Goes back to review. Runs directly.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_id | Yes | ||
| logos | No | ||
| account | No | Google Ads customer ID or account name. | |
| dry_run | No | Validate with Google without making changes. | |
| final_url | No | ||
| headlines | No | ||
| descriptions | No | ||
| business_name | No | ||
| long_headline | No | ||
| square_images | No | ||
| landscape_images | No |
google_ads_wasted_spendGoogle Ads wasted spendRead-onlyInspect
Use this when the user asks where Google Ads money is being wasted. Returns the campaigns, keywords and search terms that spent money with zero conversions in the period, the total wasted amount and its share of total spend, and suggested negative keywords. Read-only: it changes nothing (adding negatives is a separate tool). The result is also displayed as a visual card. Default period: last 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. Use instead of account to cover every Google Ads account in that client's folder. | |
| account | No | Google Ads customer ID (e.g. 123-456-7890) or part of the account name. Optional when only one account is available. | |
| end_date | No | Custom end date YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| min_cost | No | Only list items that spent at least this much (account currency). Default: auto. | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | Custom start date YYYY-MM-DD (use with end_date instead of date_range). |
go_shift_usageGo Shift plan and usage balanceRead-onlyInspect
Show the user's Go Shift plan and remaining usage balance (shown as a card). Free to call. Use when the user asks about their plan, balance, limits or renewal. Never talk about tokens or how usage is counted; call it 'usage balance'.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language of the card: the language the user is writing in. |
gsc_breakdownSearch breakdownRead-onlyInspect
Break organic performance down by country, device, search appearance or date.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| device | No | ||
| folder | No | Client folder name. | |
| country | No | ISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE. | |
| end_date | No | YYYY-MM-DD | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| dimension | Yes | ||
| date_range | No | ||
| start_date | No | YYYY-MM-DD | |
| search_type | No | Defaults to web. | |
| page_contains | No | Only pages whose URL contains this text. | |
| query_contains | No | Only queries containing this text. |
gsc_inspect_urlInspect a URL in Google's indexRead-onlyInspect
Google's index status for one URL: indexed or not and why, last crawl, Google-selected vs declared canonical, robots/indexing allowed, mobile usability and rich results.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL on the site. | |
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). |
gsc_opportunitiesSEO opportunitiesRead-onlyInspect
Find quick SEO wins: striking-distance keywords (positions 4–20 with real impressions), snippets with CTR below what their position should get, queries that dropped vs the previous period, and keyword cannibalisation (several pages competing for one query).
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| device | No | ||
| folder | No | Client folder name. | |
| country | No | ISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE. | |
| end_date | No | YYYY-MM-DD | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| date_range | No | ||
| start_date | No | YYYY-MM-DD | |
| min_impressions | No | Defaults to 50. |
gsc_pagesTop pages in searchRead-onlyInspect
Pages ranked by organic clicks with impressions, CTR and position. Optionally show the top queries of one page (page_contains).
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| device | No | ||
| folder | No | Client folder name. | |
| country | No | ISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE. | |
| end_date | No | YYYY-MM-DD | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| date_range | No | ||
| start_date | No | YYYY-MM-DD | |
| search_type | No | Defaults to web. | |
| page_contains | No | Only pages whose URL contains this text. | |
| query_contains | No | Only queries containing this text. |
gsc_performanceOrganic search performanceRead-onlyInspect
Organic Google Search performance for a site: clicks, impressions, CTR and average position vs the previous period, plus top queries and top pages. Data is usually 2–3 days behind.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| device | No | ||
| folder | No | Client folder name. | |
| country | No | ISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE. | |
| end_date | No | YYYY-MM-DD | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| date_range | No | ||
| start_date | No | YYYY-MM-DD | |
| search_type | No | Defaults to web. | |
| page_contains | No | Only pages whose URL contains this text. | |
| query_contains | No | Only queries containing this text. |
gsc_queriesSearch queriesRead-onlyInspect
Search queries (keywords) the site appears for, with clicks, impressions, CTR and position. Filter by page, query text, country or device; sort by clicks, impressions or position.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| sort | No | ||
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| device | No | ||
| folder | No | Client folder name. | |
| country | No | ISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE. | |
| end_date | No | YYYY-MM-DD | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| date_range | No | ||
| start_date | No | YYYY-MM-DD | |
| search_type | No | Defaults to web. | |
| page_contains | No | Only pages whose URL contains this text. | |
| query_contains | No | Only queries containing this text. |
gsc_remove_sitemapRemove a sitemapDestructiveInspect
Remove a sitemap from Search Console. Requires the user's explicit yes: call without confirm to preview, then confirm=true with confirm_name equal to the exact sitemap URL.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| folder | No | Client folder name. | |
| confirm | No | ||
| language | No | Language of the card (ar for Arabic, en for English). | |
| sitemap_url | Yes | ||
| confirm_name | No |
gsc_sitemapsSitemapsRead-onlyInspect
Submitted sitemaps with status, last read date, errors, warnings and submitted vs indexed URL counts.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). |
gsc_sitesSearch Console sitesRead-onlyInspect
List the Search Console sites enabled for AI with permission level. Start here for SEO / organic search questions.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). |
gsc_submit_sitemapSubmit a sitemapDestructiveInspect
Submit or resubmit a sitemap URL so Google re-reads it and recrawls changed pages. Safe: it doesn't change the website.
| Name | Required | Description | Default |
|---|---|---|---|
| site | No | Site (domain or URL) as listed by gsc_sites. Required when several sites are enabled. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| sitemap_url | Yes | Full sitemap URL, e.g. https://example.com/sitemap.xml |
gtm_auditTag Manager tracking auditRead-onlyInspect
Audit the LIVE container: which GA4 / Google Ads / Meta / TikTok / Snap IDs fire, missing Conversion Linker, tags without triggers, duplicates, retired Universal Analytics, paused tags, unused triggers/variables and unpublished drafts. Use for 'is my tracking OK' questions about the website.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. |
gtm_containersTag Manager containersRead-onlyInspect
List the Google Tag Manager containers enabled for AI, with public IDs (GTM-XXXX), accounts and client folders. Start here for Tag Manager questions.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). |
gtm_create_tagCreate a Tag Manager tagInspect
Create a tag in the workspace DRAFT from a template (GA4 config/event, Google Ads conversion/remarketing, Conversion Linker, Meta/TikTok/Snap pixel, custom HTML). Nothing goes live until gtm_publish. Use dry_run=true to preview the tag body.
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | Custom HTML (custom_html template only). | |
| name | No | ||
| folder | No | Client folder name. | |
| paused | No | ||
| dry_run | No | ||
| currency | No | Currency code or {{Variable}}. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| pixel_id | No | ||
| template | Yes | ga4_config = Google tag with a G- ID; meta/tiktok/snap_pixel without pixel_event = base code, with pixel_event = event code. | |
| triggers | No | Trigger names or IDs. 'All Pages' is available. Defaults to All Pages for base/config tags. | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. | |
| event_name | No | GA4 event name (e.g. purchase, generate_lead). | |
| pixel_event | No | Meta: Purchase, Lead, AddToCart… TikTok: CompletePayment, SubmitForm… Snap: PURCHASE, SIGN_UP… | |
| conversion_id | No | Google Ads conversion ID (digits, from AW-XXXXXXX). | |
| measurement_id | No | GA4 measurement ID (G-XXXX). | |
| transaction_id | No | Order ID or {{Variable}} (deduplication). | |
| conversion_label | No | ||
| conversion_value | No | Number or {{Variable}}. | |
| event_parameters | No | GA4 event parameters: name → value or {{Variable}}. |
gtm_create_triggerCreate a Tag Manager triggerInspect
Create a trigger in the workspace DRAFT: page view (optionally on matching URLs), custom dataLayer event, click, link click, form submission, history change or scroll depth. Needed built-in variables (Click URL, Form ID…) are enabled automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | Yes | ||
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. | |
| conditions | No | ||
| event_name | No | custom_event: dataLayer event name (e.g. purchase). | |
| scroll_percentages | No | scroll_depth: e.g. 25,50,75,90 |
gtm_create_variableCreate a Tag Manager variableInspect
Create a variable in the workspace DRAFT: data layer variable, constant, URL part, JavaScript variable or cookie.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | data_layer: key path (ecommerce.value); javascript: global name; cookie: cookie name; url: component (URL, HOST, PATH, QUERY, FRAGMENT). | |
| name | Yes | ||
| type | Yes | ||
| value | No | constant: the value. url+QUERY: query key. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. |
gtm_discard_changeDiscard a draft change in Tag ManagerDestructiveInspect
Revert one tag, trigger or variable in the workspace draft back to its live version (undo an unpublished edit, or drop a newly added item).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| entity | Yes | ||
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. |
gtm_overviewTag Manager container overviewRead-onlyInspect
Inventory of a container's workspace draft: every tag with type, firing triggers and status; triggers with their conditions; variables; pending (unpublished) changes and the live version.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. |
gtm_pending_changesTag Manager unpublished changesRead-onlyInspect
What is changed in the workspace draft and would go live on the next publish, including merge conflicts.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. |
gtm_publishPublish Tag Manager changesDestructiveInspect
Publish the workspace draft to the live website. ALWAYS preview first (without confirm) and show the user the full list of changes, including ones made by other people; publish only on a second call with confirm=true after the user explicitly says yes in chat.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| confirm | No | ||
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. | |
| version_name | No |
gtm_removeDelete a Tag Manager tag, trigger or variableDestructiveInspect
Delete from the workspace draft. Requires the user's explicit yes in chat: call first without confirm to preview, then with confirm=true and confirm_name equal to the exact item name. The deletion goes live only on gtm_publish.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| entity | Yes | ||
| folder | No | Client folder name. | |
| confirm | No | ||
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. | |
| confirm_name | No |
gtm_setup_conversionSet up a conversion in Tag ManagerInspect
One step: create the trigger (thank-you page, dataLayer event or click) and the conversion tag for Google Ads, GA4, Meta, TikTok or Snap in the workspace DRAFT. Adds a Conversion Linker for Google Ads if missing. Nothing goes live until gtm_publish.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Conversion name, e.g. Purchase or Lead. | |
| when | Yes | ||
| match | Yes | URL fragment, event name, click text or form ID. | |
| folder | No | Client folder name. | |
| dry_run | No | ||
| currency | No | Currency code or {{Variable}}. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| pixel_id | No | ||
| platform | Yes | ||
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. | |
| event_name | No | GA4 event name (e.g. purchase, generate_lead). | |
| pixel_event | No | Meta: Purchase, Lead, AddToCart… TikTok: CompletePayment, SubmitForm… Snap: PURCHASE, SIGN_UP… | |
| conversion_id | No | Google Ads conversion ID (digits, from AW-XXXXXXX). | |
| measurement_id | No | GA4 measurement ID (G-XXXX). | |
| transaction_id | No | Order ID or {{Variable}} (deduplication). | |
| conversion_label | No | ||
| conversion_value | No | Number or {{Variable}}. |
gtm_tag_detailsTag Manager tag detailsRead-onlyInspect
Full settings of one tag: type, IDs, parameters, firing and blocking triggers, custom HTML.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | Tag name or ID. | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. |
gtm_update_tagUpdate a Tag Manager tagDestructiveInspect
Edit a tag in the workspace DRAFT: rename, pause/unpause, add/remove firing triggers, change parameters (e.g. conversionLabel, measurementIdOverride, eventName) or custom HTML. Nothing goes live until gtm_publish.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | Yes | ||
| html | No | ||
| folder | No | Client folder name. | |
| paused | No | ||
| language | No | Language of the card (ar for Arabic, en for English). | |
| new_name | No | ||
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. | |
| add_triggers | No | ||
| set_parameters | No | Template parameter key → new value. | |
| remove_triggers | No |
gtm_versionsTag Manager versionsRead-onlyInspect
Live version and recent container versions (publish history).
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| language | No | Language of the card (ar for Arabic, en for English). | |
| container | No | Container name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled. | |
| workspace | No | Workspace name or ID. Defaults to 'Default Workspace'. |
linkedin_ad_libraryLinkedIn Ad Library (competitor ads)ARead-onlyInspect
Competitor ad research: search LinkedIn's public Ad Library by keyword (ad text) and/or advertiser (company Page name). Returns each ad's advertiser, format, who paid, first/last shown dates, impressions range, top countries, targeting summary (EU ads), ad copy when LinkedIn includes it, and a link to the ad's public Ad Library page, plus a summary of formats, long-running ads (running 30+ days = likely winners) and repeated offers/CTAs. Public ad-transparency data, not the user's account data. Impressions, dates and targeting are mostly reported for ads shown in the EU. countries: ISO codes (e.g. SA, AE); defaults to the client's market when one client is in play; pass ["ALL"] for no filter. Dates filter when the ad was shown.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Ads to return (default 25 for keyword searches, 100 for an advertiser; max 200). | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder, used only to default the country to the client's market. | |
| keyword | No | Words in the ad (e.g. a product or offer). | |
| end_date | No | YYYY-MM-DD: shown on or before. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| countries | No | ISO 3166-1 alpha-2 codes where the ads were shown, e.g. ["SA","AE"]. ["ALL"] = no filter. | |
| advertiser | No | Advertiser / company Page name (e.g. a competitor). | |
| start_date | No | YYYY-MM-DD: shown on or after. | |
| exact_advertiser | No | Default true: keep only ads whose advertiser or payer is this company. false = also partners and others LinkedIn matches. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive, open-world behavior, yet the description adds real substance: the exact return fields, the fact that impressions, dates and targeting are mostly EU-only, and an interpretive heuristic (30+ days running = likely winners). It does not cover cost/latency of broad searches, empty-result behavior, or how 'exact_advertiser' affects match quality beyond the schema's own text.
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?
Information is front-loaded — purpose, then returned fields, then the EU data caveat, then parameter notes — with no filler adjectives. It is long for a single paragraph, and the closing countries/dates sentences duplicate schema text, so trimming those would sharpen it without losing anything.
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 full burden of explaining returns, and it does so field by field plus the summary sections. Combined with the EU-coverage caveat and the winner heuristic, an agent has enough to call this tool correctly and to set expectations about gaps in the data.
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 every parameter is already documented; the description largely restates that (ISO codes, ["ALL"] for no filter, dates filtering on when the ad was shown). Its only genuine additions are the and/or combinability of keyword and advertiser and the note that countries defaults to the client's market, which the schema also implies via the folder parameter. Baseline 3 is appropriate when the schema carries the load.
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 specific verb and resource — 'search LinkedIn's public Ad Library by keyword (ad text) and/or advertiser (company Page name)' — and frames it as competitor ad research. The clause 'Public ad-transparency data, not the user's account data' cleanly separates it from the account-owning siblings like linkedin_ads, linkedin_campaigns and linkedin_performance.
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?
Use context is clear: competitive research over public transparency data rather than the user's own account, and the keyword/advertiser inputs are described as combinable ('and/or'). It stops short of explicitly naming the sibling to use instead (e.g. linkedin_ads) for own-account questions, and gives no guidance on what to do when a search returns nothing or is too broad.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_adsLinkedIn adsBRead-onlyInspect
Ads (creatives) with status, review status, serving holds and period performance (spend, results, leads, CTR, CPC). Filter by campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| status | No | ||
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| campaign | No | Campaign name or ID. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the data shape (status, review status, serving holds, metrics), which is genuinely useful beyond the annotations. It says nothing about pagination, row caps, or how the summary/full detail mode changes output volume, which the schema covers only partially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence with the resource front-loaded and results listed in a compact parenthetical, followed by a short filter clause. No filler sentences. The nested parentheses ('Ads (creatives) ... performance (spend, results, ...)') are slightly harder to parse but still efficient.
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 nine optional parameters, no output schema, and read-only annotations, this definition is adequate but thin. The description does the important work of naming the returned fields, which compensates for the missing output schema. It leaves out anything about result volume, ordering, or how the 'detail' mode affects the response, which matters for a list tool with a summary/full switch.
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 89%, so the schema already carries the parameter documentation burden. The description adds only marginal meaning, reinforcing that 'campaign' is the primary filter and identifying which metrics appear in results. That is consistent with the baseline 3 for a high-coverage 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 names a concrete resource (LinkedIn ads/creatives) and enumerates the exact fields returned: status, review status, serving holds, and performance metrics (spend, results, leads, CTR, CPC). It also states the supported filter ('Filter by campaign'). It does not explicitly contrast itself with close siblings like linkedin_campaigns or linkedin_performance, so an agent must infer that this is the ad-level, not campaign-level, retrieval tool.
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?
'Filter by campaign' implies the intended narrow use, and the mention of period performance implies a reporting context. However, the definition never says when to prefer this over linkedin_performance, linkedin_breakdown, or linkedin_campaigns, and gives no exclusions. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_breakdownLinkedIn audience breakdownARead-onlyInspect
Break performance down by the professional audience LinkedIn reached: job function, seniority, industry, company size or country. Optionally for one campaign. LinkedIn's demographic numbers are approximate, can lag 12–24 hours and omit small values, so totals may not match the account.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| campaign | No | ||
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| dimension | Yes | ||
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe read operation (readOnlyHint true, destructiveHint false), so the description's real contribution is data-quality behavior: figures are approximate, lag 12–24 hours, omit small values, and may not reconcile with account totals. That reconciliation warning is exactly the kind of context an agent needs before reporting numbers, though it does not mention result size or row limits when detail=full.
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 with zero waste: purpose and dimension list first, scope second, data caveat last. Nothing needs to be re-read or unpacked.
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 9-parameter read tool with no output schema, the description covers the core purpose, dimension options, campaign scoping, and caveats. It stops short of saying what metrics come back or what 'summary vs full' costs, leaving the shape of the result partly unspecified.
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 78%, so the baseline is 3. The description adds modest value by clarifying that campaign scoping is optional and by naming the dimension choices, but folder, account, language, and date handling are 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?
A specific verb ('break performance down') plus a specific resource (LinkedIn professional-audience demographics), with the five supported dimensions spelled out. It is clearly distinguishable from linkedin_performance or linkedin_campaigns, though it never names those siblings explicitly to route the agent.
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?
'Optionally for one campaign' gives scoping guidance, and the dimension list implies when this tool is the right one. But there is no explicit when-to-use versus linkedin_performance or when-not, so usage must be inferred from the tool name and dimension list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_campaignsLinkedIn campaignsARead-onlyInspect
Campaign groups and campaigns with status, type, objective, daily/total budget, bid (cost type and amount or automated bidding), run schedule and period spend/results. Use to find IDs before changes.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| status | No | Default all (not archived or removed). | |
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). | |
| campaign_group | No | Campaign group name or ID to filter by. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds value by listing what is returned and by signalling this is a lookup step before mutations, but it says nothing about pagination, account scoping, or how campaign groups and campaigns are combined in the result.
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 sentences: a dense but front-loaded field inventory followed by the actionable routing hint. No filler, no restatement of the title.
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 9 all-optional parameters, no output schema, and read-only annotations, the description adequately tells the agent what rows and metrics come back, which compensates for the missing output schema. The main residual gap is not clarifying how campaign groups are nested relative to campaigns in 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 description coverage is 100%, so every parameter including the detail and date_range enums is already documented in the schema. The description's attribute list (budget, bid, schedule) describes output rather than parameter meaning, so it adds little beyond the baseline for a fully documented 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 names the resources (campaign groups and campaigns) and enumerates the attributes returned (status, type, objective, budgets, bid, schedule, spend/results), which lets an agent distinguish it from linkedin_performance or linkedin_breakdown. The verb is only implied ('Campaign groups and campaigns with...'), so it reads as an inventory of returned fields rather than a stated action.
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?
'Use to find IDs before changes' gives one clear use case, but it never says when to prefer this over sibling tools such as linkedin_performance, linkedin_ads, or linkedin_breakdown. The detail enum guidance in the schema covers summary-vs-full depth, but routing between LinkedIn tools is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_conversionsLinkedIn conversion rulesARead-onlyInspect
Conversion rules (Insight Tag / Conversions API) on the ad account: ID, name, type, on/off, attribution windows and the campaigns they're attached to. Website-conversion campaigns need one attached.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real context by disclosing what is returned (ID, name, type, on/off status, attribution windows, attached campaigns), which matters because there is no output schema, but it says nothing about scope (all rules on the account vs. filtered), pagination, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler, and the resource definition is front-loaded before the domain hint. The first sentence is a noun-phrase fragment rather than an action statement, which slightly weakens the opening.
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 read-only listing tool with no output schema, the description covers the important ground: what the objects are, which fields come back, and the key domain constraint about website-conversion campaigns. The main omission is scope/pagination behavior for the returned list.
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 folder, account, and language are already fully documented in the schema. The description adds no meaning beyond that, such as whether account scoping narrows the returned rule set — 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?
Names the specific resource (conversion rules from Insight Tag / Conversions API) and enumerates the fields exposed, which distinguishes it from sibling listing tools like linkedin_campaigns or linkedin_ads. The verb is only implicit — it reads as a field inventory rather than 'List/retrieve all conversion rules' — and it does not explicitly name a sibling it is not.
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?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The closing note that website-conversion campaigns need an attached rule implies the practical use case (auditing rule attachment) but leaves the agent to infer it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_get_leadsLinkedIn leadsARead-onlyInspect
Leads submitted through LinkedIn Lead Gen Forms, newest first, with their answers (personal data: show only to the user). Find lead_form_id with linkedin_lead_forms.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| folder | No | Client folder name. | |
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| lead_form_id | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, open-world), and the description adds ordering ('newest first'), payload content ('with their answers'), and a privacy handling constraint that no annotation conveys. It stops short of describing pagination/volume behavior or whether an unfiltered call returns all forms' leads.
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 sentences, front-loaded with the resource and ordering, followed by the dependency pointer. The parenthetical privacy note is compact; nothing is redundant with the title, though the phrasing is slightly fragmented.
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 payload (leads plus their answers) and ordering. For a five-parameter, zero-required read tool it is nearly sufficient, missing only guidance on defaults when no lead_form_id or account is supplied.
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 60%, below the high-coverage threshold, so the description must carry some weight. It meaningfully clarifies lead_form_id by telling the agent where to obtain it, but limit, folder, account, and language semantics are left entirely to the schema, including the 1-100 cap and the Arabic/enum rule.
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?
Names the exact resource (leads submitted through LinkedIn Lead Gen Forms) and the ordering guarantee (newest first). It also distinguishes itself from the adjacent metadata tool by pointing to linkedin_lead_forms, so an agent can pick between listing leads and listing forms without opening either 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 a concrete prerequisite: find lead_form_id with linkedin_lead_forms before calling. It also flags a handling rule for personal data ('show only to the user'). No explicit exclusions or when-not conditions are stated, keeping it just 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.
linkedin_lead_formsLinkedIn lead formsARead-onlyInspect
Lead Gen Forms on the ad account (ID, name, status, review), to use as lead_form_id in lead generation ads.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety and reach are covered. The description adds the account scoping and the returned field set, but says nothing about result volume, pagination, or whether forms are all statuses (active/paused/archived).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the resource and its purpose front-loaded, and every clause carries information. The parenthetical field list is slightly clunky but earns its place by previewing the return shape.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with no output schema, the description covers what is fetched and why, which is enough to call it correctly. The only real gap is pagination/result-size behavior, which is minor at this complexity.
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 three parameters (folder, account, language) are already documented in the schema, including the 'optional when only one is enabled' note for account. The description adds no parameter meaning beyond that, making the baseline 3 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 names the specific resource (Lead Gen Forms on the ad account) and enumerates the fields returned (ID, name, status, review), so the agent knows exactly what comes back. It doesn't explicitly distinguish itself from the sibling linkedin_get_leads, though the field list implies the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to use as lead_form_id in lead generation ads' implies the workflow (discover form IDs before building lead gen ads), but there is no explicit statement of when to call this versus linkedin_get_leads or linkedin_ads, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_performanceLinkedIn Ads performanceARead-onlyInspect
LinkedIn Ads performance dashboard: spend, results (One Click Leads + website conversions), cost per result, clicks, CTR, CPC, CPM, leads, lead-form completion rate and conversion value vs the previous period, with a daily trend, a per-campaign (or per-campaign-group) table and automatic insights. Shown as an interactive dashboard; summarise the main findings. Default: last 30 days. Amounts are in the account currency.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Rows of the table. Default campaign. | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful non-schema context: the output is an interactive dashboard, the agent should summarise findings, and amounts are in the account currency. It does not mention rate limits, latency, or how missing data is handled, so it is helpful but not rich.
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 metric list is dense but front-loaded and immediately tells the agent what the dashboard contains. The trailing sentences about dashboard form, summarisation, default period and currency are each short and functional, though the long enumeration of metrics could be compressed slightly.
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 read-only, zero-required-parameter analytics tool with full schema coverage and no output schema, the description covers what is returned, how it is presented, the default time window, currency handling and the expected agent behaviour. Nothing an agent needs to invoke it correctly appears to be 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, including the detail=summary vs full trade-off and the campaign/campaign_group levels. The description reinforces the default period and currency but adds no syntax or format detail beyond the schema, which is the expected baseline when the schema does the heavy lifting.
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 a specific verb-and-resource pair (LinkedIn Ads performance dashboard) and enumerates the exact metrics delivered: spend, One Click Leads, website conversions, cost per result, clicks, CTR, CPC, CPM, leads, lead-form completion rate and conversion value. It also states the output structure (daily trend, per-campaign table, automatic insights), which distinguishes it from siblings like linkedin_ads or linkedin_breakdown that serve different purposes.
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 says to summarise the main findings and gives a default of last 30 days, which implies a reporting/analysis use case. However, it never states when to use this tool versus linkedin_breakdown, linkedin_campaigns, linkedin_conversions or the other platform performance tools (meta_performance, google_ads_performance, tiktok_performance), so the agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_reach_estimateLinkedIn audience size and bid estimateARead-onlyInspect
Audience size for a targeting spec (or an existing campaign's targeting), with a warning under LinkedIn's 300-member minimum, plus LinkedIn's recommended bid and minimum daily budget when objective is given.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| format | No | Default single_image. video_views needs video; text ads are small right-rail desktop ads. | |
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| campaign | No | Use this campaign's targeting instead. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| objective | No | ||
| targeting | No | Who sees the ads. Facet names: locations, profile_locations, job_titles, past_job_titles, job_functions, seniorities, industries, company_sizes, company_names, past_companies, company_followers, skills, member_groups, schools, degrees, fields_of_study, interests, member_traits, ages, genders, languages, years_of_experience, company_growth, company_category, company_revenue, audiences. Values are URNs from linkedin_targeting_search. | |
| bid_strategy | No | Default maximum_delivery (LinkedIn bids automatically). target_cost / cost_cap / manual_* need bid. | |
| daily_budget | No | Account currency. | |
| audience_expansion | No | Let LinkedIn add similar members. Default false. | |
| targeting_criteria | No | Advanced: LinkedIn targetingCriteria object as-is ({include:{and:[{or:{<facet URN>:[…]}}]}, exclude:{or:{…}}}). Overrides targeting. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered; the description adds real value by disclosing conditional behavior (bid and minimum-budget figures are only returned when objective is supplied) and a built-in threshold warning at LinkedIn's 300-member minimum. It does not mention latency, API quota cost, or whether zero/suppressed results are returned as an error, which keeps it from 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?
A single front-loaded sentence naming the primary output first, then the warning, then the conditional bid/budget, with two tight parentheticals that carry real information. Nothing is redundant with the title or restates the tool name.
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 an 11-parameter tool with a nested targeting object and no output schema, the description does the essential work of naming the three return values (audience size, minimum-size warning, bid and minimum daily budget). It leaves account/currency resolution and the targeting_criteria escape hatch entirely to the schema, which is acceptable given 91% coverage but leaves a small gap for a read-only estimator whose results feed budget decisions.
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 91%, so the schema already carries nearly all parameter meaning, including the targeting facet list, language rules, and bid_strategy enum effects. The description reinforces the two mutually exclusive input paths (targeting spec vs. campaign) and the objective-gated bid output, but adds little parameter detail the schema does not already state, 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?
States a concrete verb+resource pair ('Audience size for a targeting spec') and adds the two secondary outputs it returns: the 300-member warning and the recommended bid / minimum daily budget. The 'LinkedIn' framing plus the specified outputs make it distinguishable from generic reach tools and from linkedin_targeting_search, which supplies the URNs this tool consumes.
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: it accepts either an ad-hoc targeting spec or an existing campaign's targeting, and the bid/budget portion only appears 'when objective is given'. What's missing is any explicit exclusion or prerequisite routing, e.g. that targeting URNs must first be resolved via linkedin_targeting_search, or when to skip estimation and go straight to campaign creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_targeting_searchSearch LinkedIn targetingARead-onlyInspect
Find LinkedIn targeting values (URNs) by name: locations, job titles, job functions, seniorities, industries, company sizes, company names, skills, member groups, schools, degrees, fields of study, interests, member traits, ages, genders, profile languages, years of experience and more. Enumerated facets (seniorities, job_functions, company_sizes, ages, genders, languages, years_of_experience …) list every value when query is empty. Show the user once, in their language: "LinkedIn tools may not be used to discriminate based on personal characteristics like gender, age, race, or ethnicity." (Arabic: «لا يجوز استخدام أدوات LinkedIn للتمييز بين الأشخاص على أساس خصائص شخصية مثل الجنس أو العمر أو العرق أو الأصل.»)
| Name | Required | Description | Default |
|---|---|---|---|
| facet | Yes | ||
| limit | No | ||
| query | No | ||
| folder | No | Client folder name. | |
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered; the description adds genuinely new behavior: results are URNs (identifiers, not display strings) and empty-query behavior differs by facet type. That enumeration semantics is a real behavioral trait beyond structured fields, though there is no mention of result volume, pagination, or limits against LinkedIn's lookup service.
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 critical statement is front-loaded, but the facet list duplicates the 26-value enum verbatim and pads the opening sentence. The mandatory disclaimer with full Arabic translation is required content, yet it is long and placed after the technical text, making the whole description heavier 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?
For a read-only lookup tool with no output schema, the description does the essential work: it explains that results are URNs, which facets are enumerable, and how empty queries behave. Only the behavior of `limit` and any result-volume expectations are missing, which are minor gaps for this kind of resolver.
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 only 50%, so the description needs to compensate and it partly does — it clarifies facet semantics and the empty-query behavior of `query`, and its 'in their language' phrasing hints at the `language` parameter. However, `limit` is undocumented in both schema and description, and the long facet roll-call merely restates the enum values already in the schema, so the net semantic gain is moderate.
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 ('Find LinkedIn targeting values (URNs) by name') and enumerates the facet families it resolves. An agent can distinguish it immediately from siblings such as linkedin_reach_estimate or linkedin_campaigns, since this is the resolver, not the estimator or the campaign reader.
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 a concrete usage rule for the key case: enumerated facets (seniorities, job_functions, company_sizes, ages, genders, languages, years_of_experience) list every value when query is empty, which tells the agent when to pass a query vs. when to browse. It does not explicitly say when NOT to use it or name an alternative flow (e.g., reuse cached URNs), so it stops short of full alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
linkedin_wasted_spendLinkedIn wasted spendARead-onlyInspect
Find money spent without results: lead-gen/conversion campaigns with spend and zero leads or conversions, cost per result above 2× the account average, CPC outliers and low-CTR ads. Read-only; suggests what to pause or fix.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | LinkedIn ad account name or ID. Optional when only one is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, and the description's 'Read-only' statement is a partial restatement. What it adds beyond that is meaningful: the exact waste-detection thresholds an agent should expect in the results, and the fact that output includes remediation suggestions rather than raw rows only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core criteria and closed with the safety/advisory note. Every clause carries information an agent needs; nothing is padding.
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 seven-parameter, fully-documented, read-only diagnostic tool with no output schema, the description covers what it finds, how it defines waste, and that it returns recommendations. An agent can decide to call it and interpret the response without needing more.
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 every parameter (detail, folder, account, date_range, start/end_date, language) is documented in the schema itself. The description adds no parameter-level meaning such as how thresholds interact with date_range or what the default scope is, 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?
Names a specific analytical resource with concrete detection criteria: lead-gen/conversion campaigns with spend and zero results, cost per result above 2× account average, CPC outliers, low-CTR ads. The LinkedIn prefix in the name and the criteria make it unmistakable against siblings like linkedin_performance or linkedin_breakdown.
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 opening phrase establishes the use case (finding money spent without results) and the closing claim ('suggests what to pause or fix') implies the follow-up action. It does not explicitly say when NOT to use it or name linkedin_performance as the alternative for general reporting, 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.
list_accountsList accounts and client foldersRead-onlyInspect
List the client folders and ad accounts the user has made available to AI in Go Shift. Call this first to discover account IDs and folder names.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language of the card: the language the user is writing in. |
media_libraryUploaded filesARead-onlyInspect
Files the user uploaded in Go Shift (images/videos) with their media_id, newest first. Use when the user refers to a file they attached earlier.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful non-annotation context — it returns media_id values and orders results newest first — but says nothing about result volume, pagination, or whether the 50-item cap is the only bound.
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: the first front-loads what the tool returns and how it is ordered, the second front-loads the usage trigger. No filler, no restatement of the tool name, nothing to cut.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with one optional parameter and no output schema, the description covers purpose, contents (media_id plus images/videos), ordering, and trigger. The only real omission relative to tool complexity is the meaning/default of 'limit', which the schema does not describe either.
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?
There is one optional parameter, 'limit', and schema description coverage is 0%, so the description was the only place to explain it — yet it never mentions limiting result size. The parameter name plus the schema's 1-50 bounds make its meaning largely self-evident, so the omission is a gap rather than a failure.
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 resource ('files the user uploaded in Go Shift'), its domain ('images/videos'), the key returned identifier ('media_id'), and the ordering ('newest first'). It is clearly a listing/retrieval tool rather than an upload, which distinguishes it from siblings like meta_upload_image or tiktok_upload_video, though it never explicitly says it is read-only list retrieval or names those 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?
It gives an explicit trigger condition: 'Use when the user refers to a file they attached earlier.' That is a clear when-to-use cue. It stops short of stating when not to use it or pointing at an alternative (e.g., platform-specific upload/creative tools), so it falls 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.
meta_ab_testsMeta A/B testsCRead-onlyInspect
A/B tests (split tests) on the ad account's business with their cells, dates and status.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that each test carries cells, dates and status, which is genuinely useful return-shape context given no output schema exists, but it says nothing about pagination, permissions, or whether inactive/completed tests are included.
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?
It is a single short sentence with no padding, but it is a sentence fragment whose phrasing ('on the ad account's business') is opaque and could be read as scoping to a business entity rather than the ad account. Brevity is achieved at the cost of grammatical clarity.
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 read-only list tool with three fully documented parameters and safety annotations, the definition is minimally sufficient. However, the absent action verb and the lack of any indication of result scope or volume leave the agent with a partially formed picture of what invoking it will produce.
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 all three parameters (folder, account, language) are documented in the schema, including the enum for language and the optional-account note. The description adds no meaning beyond that, 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 sentence names the resource (A/B tests / split tests) and the fields returned (cells, dates, status), but supplies no verb — an agent must infer that this retrieves existing tests rather than creating them. The distinction from the sibling meta_create_ab_test is only implied by omission, not stated.
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?
There is no when-to-use guidance, no prerequisites, and no explicit alternative named. A reader can guess this is the read counterpart to meta_create_ab_test, but nothing in the text confirms that or says when A/B test data should be pulled versus using meta_performance or meta_insights_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_account_statusMeta ad account statusBRead-onlyInspect
Ad account health: status and disable reason, amount spent, spending limit, balance, currency, time zone and business.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the useful behavioral detail that the card surfaces a disable reason and financial limits (spend, limit, balance), which is real context beyond the annotations, but it says nothing about latency, caching, or what happens when the account param is omitted.
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?
A single compact clause with zero filler, and the most important signal (account health/status) is front-loaded. It reads as a fragment rather than a sentence, but nothing in it is wasted.
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 return values and does so by listing the concrete fields returned. For a read-only, zero-required-parameter status lookup that is essentially complete; only the relationship to account-level budget siblings is left unexplained.
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 folder, account, and language are already fully documented in the schema, including the optional-when-single-account note and the Arabic-dialect enum guidance. The description adds no parameter meaning beyond that, which is the baseline 3 case.
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 a specific resource (the Meta ad account) and enumerates exactly what is retrieved: status, disable reason, spend, limit, balance, currency, time zone, business. That is enough for an agent to tell it apart from siblings like meta_performance or budget_status, though it is a verbless noun fragment rather than an explicit 'returns/get' 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?
There is no guidance on when to use this instead of alternatives such as list_accounts, meta_performance, or budget_status, and no stated preconditions (e.g. account must be enabled, or how it differs from budget_status). The agent must infer usage from the field list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_activityMeta change historyARead-onlyInspect
Recent changes on the ad account (who changed what and when): budgets, statuses, targeting, creatives.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context about which change types are surfaced, but says nothing about retention window, whether deletions are included, ordering, or whether the result is capped — the 'recent' framing is vague against a default LAST_30_DAYS range in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tightly packed sentence with zero filler, and the subject ('recent changes on the ad account') is front-loaded. It is arguably over-compressed for an eight-parameter tool, but nothing is wasted.
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?
Incorrect score placeholder replaced below.
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 88%, so limits, defaults and enums (limit, detail, date_range, account) are already well documented in the schema. The description contributes no parameter guidance of its own, 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?
States a specific resource and scope: change history on the Meta ad account, with an explicit attribute list ('who changed what and when') and object coverage ('budgets, statuses, targeting, creatives'). An agent can distinguish it from read tools like meta_ads or meta_insights_query, but the description never names the closest sibling, meta_explain_change, which also deals with changes.
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?
'Recent changes' implies an audit/review use case, but there is no explicit when-to-use framing, no when-not guidance, and no routing to alternatives such as meta_explain_change for understanding why a change happened or google_ads_change_history for the other platform. Usage must be inferred from the word 'recent'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_ad_previewMeta ad previewARead-onlyInspect
Get a preview link for an ad (or creative) in a given placement so the user can see how it looks before activating.
| Name | Required | Description | Default |
|---|---|---|---|
| ad | Yes | ||
| folder | No | Client folder name. | |
| format | No | ||
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds value beyond that by disclosing the return artifact ('a preview link') and the lifecycle position ('before activating'), which tells the agent this is a non-mutating inspection step. It does not mention link expiry, permission requirements, or error behavior for invalid placements.
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?
A single front-loaded sentence with the action, the artifact, and the motivation in that order, with no filler. The parenthetical '(or creative)' adds a small amount of ambiguity but also useful flexibility, so it largely 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 five-parameter read-only tool with no output schema, the description covers what it returns (a link) and why it is used (pre-activation review). The remaining gaps, namely how folder and account scope the lookup and what happens when a placement is unsupported, are minor for a simple preview call.
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 60%, so the schema already documents folder, account, and language. The description adds only marginal meaning: 'ad (or creative)' hints that the ad parameter accepts a creative reference, and 'given placement' maps loosely to the format enum. It says nothing about the account/folder scoping parameters or valid placement values beyond the enum itself.
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: 'Get a preview link for an ad (or creative) in a given placement'. An agent can distinguish this from meta_ads (listing) or meta_creative_insights (analytics) because the deliverable is explicitly a preview link, not data. It stops short of naming a sibling alternative, so it is clear but not fully differentiated.
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 clause 'so the user can see how it looks before activating' implies the usage context (pre-launch creative review) without stating it as a rule. There is no explicit when-not guidance, no mention of what to do if the ad is already active, and no pointer to alternative preview approaches among the many meta_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_adsMeta adsRead-onlyInspect
Ads with status (including review/rejection), creative text, headline, link, and period performance. Filter by campaign or ad set.
| Name | Required | Description | Default |
|---|---|---|---|
| adset | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| status | No | ||
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| campaign | No | ||
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
meta_adsetsMeta ad setsRead-onlyInspect
Ad sets with status, optimisation goal, budget, bid, schedule, targeting summary and period performance. Filter by campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| status | No | ||
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| campaign | No | Campaign name or ID. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
meta_audiencesMeta audiencesBRead-onlyInspect
Custom and lookalike audiences in the account with type, approximate size, status and source.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful output context by listing what is returned (type, approximate size, status, source), which matters since there is no output schema. It says nothing about pagination, account scoping, or how many rows come back at default detail, which are the traits most likely to trip an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with no filler, and the field list is front-loaded. It loses a point for being a fragment with no verb phrase, which leaves the operation (list vs. read) implicit.
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?
Without an output schema, the description carries the burden of telling the agent what comes back, and it does so by enumerating the four fields. Combined with annotations covering read-only safety and a fully documented schema, an agent has enough to call this 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%: detail, folder, account, and language are all documented, including the summary-vs-full tradeoff and the Arabic language note. The description adds no parameter meaning beyond the schema, 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?
Names the resource (custom and lookalike audiences in the account) and the fields surfaced, which distinguishes it from generic campaign tools. But it is a bare noun phrase with no verb, and it does not distinguish it from the closely related siblings meta_saved_audiences, meta_create_audience, or meta_create_customer_list_audience. An agent can guess it is a read/list tool, but must infer that.
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?
There is no guidance on when to use this versus meta_saved_audiences, meta_targeting_search, or the audience-creation tools. No prerequisites, no exclusions, no statement that it is a listing operation. The only usage hint lives in the schema's 'detail' parameter, not in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_breakdownMeta breakdownARead-onlyInspect
Break performance down by age, gender, age and gender, country, region, platform (Facebook/Instagram/Audience Network/Messenger), placement, device or hour of day. Optionally for one campaign or ad set.
| Name | Required | Description | Default |
|---|---|---|---|
| adset | No | ||
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| campaign | No | ||
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| dimension | Yes | ||
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this a safe, read-only, open-world operation, so the description does not need to re-litigate safety. It adds the scoping behavior (whole account by default, one campaign/ad set optionally), which is real context, but says nothing about volume of rows, ranking of results, or rate limits beyond what the detail parameter already documents in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core capability and followed by the scoping caveat. The long dimension list is necessary content, not padding, and there is no filler or hedging.
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 10 parameters, no output schema, and an open-world read, the description is complete on the input side (dimension list plus optional scoping) but silent on what an agent gets back, e.g. which metrics appear per row or how many rows a default summary contains. That is a notable gap for a reporting tool with no return-value schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description expands the opaque "platform" enum dimension by naming the four surfaces (Facebook/Instagram/Audience Network/Messenger), and enumerates the dimension choices in readable prose rather than raw enum tokens. It leaves date_range, detail, language, folder and account to the schema, which covers them adequately at 70% coverage, so this is meaningful added meaning rather than repetition.
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?
"Break performance down by age, gender, ... country, region, platform, placement, device or hour of day" gives a specific verb plus an exhaustive list of the resources being sliced, so an agent knows exactly what the call produces. It does not, however, distinguish itself from close siblings such as meta_insights_query, meta_performance, or meta_ads, which likely overlap heavily.
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?
"Optionally for one campaign or ad set" implies the default is account-wide and narrowing is opt-in, which is useful context. But there is no explicit when-to-use versus meta_insights_query/meta_performance, and no stated preconditions such as needing an enabled account or a folder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_campaignsMeta campaignsRead-onlyInspect
Campaigns with objective, status, budget (campaign budget or ad-set budgets), bid strategy and period spend/results. Use to find IDs before changes.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| status | No | Default all (excluding deleted/archived). | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
meta_conversionsMeta conversions detailARead-onlyInspect
Every conversion/action Meta recorded (purchases, leads, add to cart, messages, registrations, link clicks…) with counts, cost per action and value, overall and per campaign. The purchase event that matches Ads Manager is highlighted. Use when the user asks exactly what was tracked.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| campaign | No | ||
| end_date | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | ||
| start_date | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, open-world), so the description's job is to add context, and it does: it discloses what the card contains (counts, cost per action, value, overall plus per campaign) and flags that the purchase event matching Ads Manager is highlighted, which is real reconciliation guidance. It says nothing about date defaults, pagination or row limits, which keeps it 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?
Two sentences, front-loaded with the payload and then the usage cue, with no filler. The event enumeration is a little long but earns its place by telling the agent what categories will appear.
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 has to convey what comes back, and it does at a high level (overall and per-campaign counts, cost per action, value). An 8-parameter tool with zero required parameters could say more about defaults, such as which date range applies when dates are omitted, but nothing essential for calling 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 50%: the ambiguous parameters (detail with its summary/full semantics, account optionality, folder, language) are already documented in the schema, and the description adds no parameter guidance of its own. The undocumented ones (campaign, start_date, end_date, date_range) are largely self-describing, so the schema carries the load and 3 is the appropriate 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 names a specific resource and scope: every conversion/action Meta recorded (purchases, leads, add to cart, messages, registrations, link clicks) with counts, cost per action and value, overall and per campaign. That is far more concrete than the bare name. It does not, however, differentiate itself by name from close siblings such as meta_performance, meta_insights_query or meta_tracking_audit.
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 one usage cue, 'Use when the user asks exactly what was tracked', which implies an event-level breakdown instead of aggregated performance. It offers no exclusions and never names an alternative, so an agent comparing this with meta_performance or google_ads_conversions must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_create_ab_testCreate a Meta A/B testAInspect
Create a split test between 2–5 existing campaigns or ad sets (each cell gets an equal share of the audience) for a date range. The tested objects keep their own budgets and must be activated separately.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| end_date | Yes | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| start_date | Yes | ||
| description | No | ||
| ids_or_names | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish this is a write operation (readOnlyHint=false) with no destructive semantics, so the description's job is to add context. It does: equal audience split per cell, tested objects retain their own budgets, and the test does not auto-activate the objects — they must be activated separately. What is missing is any note on permissions, whether the test can be edited/deleted later, or what identifies the created test.
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 core action and its cardinality limit, with no redundant or filler wording. Every clause adds operational 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 9-parameter mutation tool with no output schema, the description covers the domain semantics well but omits the metadata parameters (name, description, folder, account, language) and says nothing about what is returned (e.g., a test ID or URL). An agent would know what the tool does conceptually but still guess at several inputs.
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 only 33%, so the description must compensate. It clarifies ids_or_names (2-5 existing campaigns/ad sets, equal audience share) and end_date/start_date (a date range), but name, description, folder, and account are unexplained in both description and schema, leaving four of nine parameters opaque.
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 (Create) plus resource (split test between existing campaigns or ad sets), with the 2-5 cell constraint spelled out. It implicitly distinguishes itself from the sibling meta_ab_tests (which lists tests) by requiring pre-existing objects, but never names that sibling or meta_create_campaign as the alternative path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing campaigns or ad sets' implies a prerequisite that the tested objects must already exist, which is useful context. However, there is no explicit when-to-use versus when-not guidance, no mention of how this differs from simply creating a new campaign, and no pointer to meta_ab_tests for reviewing results afterward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_create_adCreate a Meta adAInspect
Create an ad (always PAUSED) in an ad set: either from an existing Facebook/Instagram post (post_id) or a new image/video ad with primary text, headline, description, link and call to action. Use meta_pages for page_id and meta_upload_image for image_hash.
| Name | Required | Description | Default |
|---|---|---|---|
| link | No | ||
| name | Yes | ||
| adset | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| dry_run | No | ||
| page_id | No | ||
| post_id | No | Existing post: PAGEID_POSTID. | |
| headline | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| video_id | No | ||
| image_hash | No | ||
| description | No | ||
| lead_form_id | No | Instant form id for a lead ad (see meta_lead_forms / meta_create_lead_form). | |
| primary_text | No | ||
| call_to_action | No | ||
| instagram_user_id | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this writes, is not destructive, and is open-world, so the description only needs to add what annotations cannot. It does add the important trait that the ad is always created PAUSED (no immediate spend) and that page_id/image_hash come from prerequisite sibling tools. It does not describe failure modes, permission requirements, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the mode choice and the always-PAUSED caveat front-loaded; nothing is padding. The embedded field list is dense but scannable, though it would read slightly better broken into mode-specific clauses.
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 17-parameter creation tool with no output schema and thin schema documentation, the description leaves gaps: it never names the two required parameters, never states what the call returns (e.g., the new ad ID), and doesn't clarify mutually exclusive parameter sets. It covers the headline behavior (paused creation, prerequisite lookup tools) adequately but not the full calling contract.
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 only 29%, so the description carries real weight here and partially meets it: it explains post_id as an existing post, maps image_hash/page_id to their source tools, and enumerates the fresh-creative fields (primary text, headline, description, link, CTA). However, many of the 17 parameters receive no treatment at all — dry_run, video_id, instagram_user_id, account, folder, language, and the required name/adset — and the exclusivity of post_id versus image_hash/video_id is only hinted at by 'either...or'.
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 and resource ('Create an ad ... in an ad set') and distinguishes two creation modes: reusing an existing Facebook/Instagram post via post_id versus building a new image/video ad from creative fields. That framing also implicitly separates it from the carousel sibling, so an agent can pick between them without opening 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?
It tells the agent what to do before calling: get page_id from meta_pages and image_hash from meta_upload_image, and it flags that the ad is always created PAUSED. What's missing is explicit routing against meta_create_carousel_ad or meta_update_ad_creative, and no statement of which parameters are mandatory per mode (name and adset are required but never mentioned).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_create_adsetCreate a Meta ad setAInspect
Create an ad set (always PAUSED) in a campaign: optimisation goal, budget (if the campaign has none), targeting (countries/cities, age, gender, interest IDs from meta_targeting_search, custom audiences, Advantage+ audience), automatic placements, optional pixel event and schedule. dry_run validates.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| cities | No | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| age_max | No | ||
| age_min | No | ||
| dry_run | No | ||
| genders | No | ||
| page_id | No | Required for lead/conversation ad sets. | |
| campaign | Yes | ||
| end_time | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| pixel_id | No | ||
| countries | No | ||
| bid_amount | No | ||
| start_time | No | ||
| daily_budget | No | ||
| interest_ids | No | ||
| lifetime_budget | No | ||
| destination_type | No | ||
| custom_event_type | No | PURCHASE, LEAD, COMPLETE_REGISTRATION, ADD_TO_CART, INITIATED_CHECKOUT, CONTACT… | |
| optimization_goal | Yes | ||
| advantage_audience | No | Let Meta expand beyond the targeting. Default true. | |
| custom_audience_ids | No | ||
| excluded_audience_ids | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-read-only, open-world, non-destructive mutation, and the description adds operationally important behavior by saying the new ad set is always created PAUSED and that dry_run validates. It does not cover authentication, rate limits, or failure modes, so it is useful but not fully rich.
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 definition is front-loaded and dense but not wasteful: one sentence covers purpose, default state, budget condition, targeting, placements, pixel event, and schedule, followed by a short dry-run note. For a 25-parameter tool it stays compact and 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 complex 25-parameter mutation with low schema-description coverage and no output schema, the description gives a good high-level map but omits important operational details such as destination/page prerequisites, bid semantics, excluded audiences, and validation output. It is adequate for selecting and broadly invoking the tool, but not complete for correct use across all options.
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 only 24% across 25 parameters, and the description compensates for some gaps by grouping targeting fields and noting that interest_ids come from meta_targeting_search and that budget applies only when the campaign lacks one. However, it leaves many parameters such as destination_type, page_id requirement, bid_amount, excluded_audience_ids, and language unexplained beyond their names.
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 starts with a specific verb and resource, 'Create an ad set', and scopes it to 'in a campaign', which clearly distinguishes it from sibling campaign and ad creation tools. It also names the core inputs such as optimization goal, budget, targeting, and schedule, so an agent knows exactly what this tool builds.
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 contextual cues such as budget only if the campaign has none, interest IDs sourced from meta_targeting_search, and dry_run for validation, but it never explicitly states when to choose this over meta_create_campaign or meta_create_ad, nor the prerequisite ordering. Usage is inferable from the resource name rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_create_audienceCreate a Meta custom or lookalike audienceAInspect
Create a website audience (pixel visitors or event, N days), an engagement audience (Page or Instagram engagers), or a lookalike from an existing audience.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | Yes | ||
| event | No | website: PageView (default) or an event like Purchase, Lead, AddToCart. | |
| ratio | No | Lookalike size, 0.01 = 1%. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| country | No | ||
| page_id | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| pixel_id | No | ||
| url_contains | No | ||
| retention_days | No | ||
| instagram_user_id | No | ||
| source_audience_id | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, open-world write operation, so the safety profile is covered. The description adds the meaningful hint that lookalikes are derived 'from an existing audience', implying a source dependency. It says nothing about whether created audiences are immediately usable, whether duplicates are rejected, or what happens on partial failure — relevant for a persistent mutation across 14 parameters.
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?
A single sentence that leads with the verb and partitions the three modes with parallel parentheticals. No filler, no restatement of the title, and the branching structure mirrors the enum an agent will actually pick from.
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 14-parameter mutation with no output schema and low schema coverage, the definition covers the mode selection but not the conditional parameter matrix or the return value (e.g., the new audience ID). An agent can choose the right `type` but still has to guess which of the remaining 12 parameters each mode expects.
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 only 36% schema description coverage, the description must carry weight, and it does partially by grouping parameters per audience type: pixel/event/retention days for website, Page or Instagram identity for engagement, source audience plus ratio semantics for lookalike. It leaves the other half undocumented in both places — `name`, `folder`, `account`, `country`, `language`, `url_contains`, `page_id`, `pixel_id` — and never states which parameters are conditionally required for each `type`.
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 (Create) and resource (audience) and enumerates the three supported variants — website pixel, engagement, and lookalike — which map cleanly onto the `type` enum. It does not explicitly name the near-identical sibling `meta_create_customer_list_audience`, so an agent must infer that customer-list audiences are out of scope here.
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 parentheticals imply when each variant applies (pixel visitors/event for website, Page or Instagram engagers for engagement, existing audience for lookalike), which is useful usage context. However, there is no explicit when-not guidance, no mention of the customer-list sibling, and no stated prerequisites such as needing an enabled ad account or an existing pixel.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_create_campaignCreate a Meta campaignAInspect
Create a campaign (always PAUSED). Optional campaign budget (Advantage campaign budget). Use special_ad_categories for housing, employment, credit, politics. dry_run validates without creating.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| dry_run | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| objective | Yes | ||
| bid_strategy | No | ||
| daily_budget | No | Campaign budget (CBO). Omit to set budgets on ad sets. | |
| lifetime_budget | No | ||
| special_ad_categories | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly=false, destructive=false, openWorld=true - a generic write profile. The description adds genuinely new behavior: campaigns land PAUSED (so nothing goes live unexpectedly), dry_run is a no-side-effect validation path, and budget is optional/CBO. It omits permission requirements and what the response contains, but the added context is substantive.
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?
Four short sentences, no filler, and the core action plus the PAUSED default are front-loaded. The 'Advantage campaign budget' parenthetical and the category example are slightly compressed but still 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 10-parameter mutation with no output schema, the description covers the highest-risk behaviors (PAUSED default, dry_run) but leaves gaps on bid strategy, budget exclusivity, and account/folder defaults that an agent needs to construct a correct call.
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 40%, so the description must compensate and does so only partially: it explains dry_run, the campaign-level budget (CBO) and the purpose of special_ad_categories for regulated verticals. It leaves bid_strategy, lifetime_budget vs daily_budget, objective enum meanings, and account/folder resolution undocumented in both places.
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 precise verb+resource ('Create a campaign') and names Meta-specific mechanics (Advantage campaign budget, special_ad_categories, dry_run). It is clearly a Meta campaign creation tool as distinct from meta_create_adset or meta_create_ad, though the description itself never points to those siblings by 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?
It tells the agent two valuable things - the campaign is always created PAUSED, and dry_run validates without creating - which implicitly guides safe use. It does not say when to choose this tool over meta_create_adset/ad, or what sequence to follow afterward, so the when-to-use guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_create_carousel_adCreate a Meta carousel adBInspect
Create a carousel ad (2–10 cards, each with image_hash, link, headline and optional description) in an ad set, PAUSED.
| Name | Required | Description | Default |
|---|---|---|---|
| link | Yes | Main link (also the 'see more' link). | |
| name | Yes | ||
| adset | Yes | ||
| cards | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| dry_run | No | ||
| page_id | Yes | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| primary_text | No | ||
| call_to_action | No | ||
| instagram_user_id | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the write/safe/open-world profile, so the description only needs to add context. It does add one genuinely valuable trait — the ad is created PAUSED, i.e., it will not spend until activated — but says nothing about account/page permissions, whether dry_run performs validation only, or what gets returned on success.
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?
A single front-loaded sentence that packs verb, resource, card count, card fields and initial status with no filler. Nothing here could be cut without losing 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 12-parameter, low-coverage mutation tool with no output schema, this is thin. An agent still cannot tell where image_hash values come from, what dry_run does, whether primary_text/call_to_action are required for a usable ad, or what the call returns.
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 only 33% (12 params), so the description carries a heavy burden. It helpfully defines card composition (image_hash, link, headline, optional description) and the 2–10 bound, but leaves name, adset, page_id, primary_text, call_to_action, language, account, folder, instagram_user_id and dry_run entirely unaddressed in both schema and description.
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?
Specific verb+resource ('Create a carousel ad') with the defining structural constraint (2–10 cards) and the resulting state (PAUSED). 'Carousel' implicitly separates it from meta_create_ad, but no sibling is named, so differentiation is inferred rather than stated.
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?
'in an ad set' implies the parent adset must already exist, which is real usage context. However, there is no explicit when-to-use-vs-alternative guidance (single-image ad via meta_create_ad, or a full campaign/adset build first), and no prerequisite noted for obtaining image_hash values via meta_upload_image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_create_customer_list_audienceCreate a Meta audience from a customer listAInspect
Create a custom audience from customer emails and/or phone numbers (hashed with SHA-256 before sending; raw data is never stored). Phones should include the country code. Up to 10,000 rows per call; call again with audience_id to add more.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| emails | No | ||
| folder | No | Client folder name. | |
| phones | No | ||
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| audience_id | No | Add to an existing customer-list audience instead of creating one. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic write/openWorld/non-destructive profile; the description adds genuinely new behavior: SHA-256 hashing is applied before transmission, raw data is never persisted, and there is a hard 10,000-row ceiling per call with an append path via audience_id. What it omits is the outcome of the call (does it return a new audience ID?) and whether the created audience is immediately usable.
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 dense sentences with no filler: the core action and data-handling guarantee come first, then the operational constraints (phone format, row limit, append behavior). Every clause carries information an agent needs before invoking the 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?
For a 7-parameter write tool with no output schema and no required fields, the description covers the data-handling contract, size limits, and the incremental-add pattern, which are the highest-risk unknowns. The remaining gap is silent on the return value and on the implicit account/folder targeting that an agent must otherwise infer from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 57%, and the description compensates for the undocumented array parameters by specifying the hashing applied to emails/phones, the required country-code format for phones, and the per-call row cap plus the audience_id append semantics. It adds nothing about name, folder, account, or language, which remain schema-only, so it is above baseline but not exhaustive.
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 and resource ('Create a custom audience from customer emails and/or phone numbers'), and the 'customer list' qualifier distinguishes it from the generic meta_create_audience and the read-only meta_audiences/meta_saved_audiences siblings. It stops short of explicitly naming which sibling to use for non-customer-list audiences, so it is clear but not fully differentiated.
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 context is strongly implied (you have a customer list of emails/phones to upload) and the description gives a concrete workflow rule: call again with audience_id to add beyond 10,000 rows. However, it never states when NOT to use this versus meta_create_audience or meta_audiences, nor any prerequisites such as which account or folder to target.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_create_ruleCreate a Meta automated ruleADestructiveInspect
Create an automated rule that checks campaigns/ad sets/ads every 30 minutes or daily and pauses, turns on, changes budget or just notifies when a metric crosses a threshold. Rules that turn things on or raise budgets need confirm=true after the user's yes.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | No | Limit to these object IDs. Omit for all active objects of that level. | |
| name | Yes | ||
| value | Yes | ||
| action | Yes | ||
| entity | Yes | ||
| folder | No | Client folder name. | |
| metric | Yes | ||
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| operator | Yes | ||
| schedule | No | ||
| min_spent | No | Only apply after this much spend (account currency). | |
| time_preset | No | ||
| budget_change_pct | No | For CHANGE_BUDGET: e.g. 20 or -20. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds real context beyond them: the evaluation cadence (semi-hourly or daily), which actions are possible, and a human-in-the-loop confirmation gate specifically for the actions that increase spend or reactivate delivery. It still does not say whether the rule is created live immediately or what happens on failure/validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the most important constraint (the confirm gate) is placed last where it reads as the required precondition. Nothing is redundant with the title.
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 destructive creation tool with no output schema, the description covers the concept and the confirmation gate but omits scope questions an agent will hit in practice: whether omitting ids applies the rule to all active objects, how account selection defaults, and what identifier comes back on success. Adequate but with clear gaps.
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 only 40% across 15 parameters, so the description must compensate and it partially does: it maps plain-language actions to the action enum (pauses/turns on/changes budget/notifies) and covers the schedule concept and confirm. It says nothing about ids, account, folder, language, time_preset, min_spent, or budget_change_pct, leaving roughly half the surface to the schema and enums alone.
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 ('Create an automated rule') plus the mechanism (checks campaigns/ad sets/ads every 30 minutes or daily) and the outcome space (pause, turn on, change budget, notify on a metric threshold). That is enough to distinguish it from the read-oriented siblings meta_rules and meta_delete_rule without opening any 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 an explicit prerequisite for the risky subset of actions: turn-on or budget-raise rules require confirm=true after the user's yes. It does not name alternatives (e.g. use meta_rules to inspect existing rules, meta_delete_rule to remove one) or say when not to create a rule, 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.
meta_creative_insightsMeta creative insightsARead-onlyInspect
Rank ads by efficiency: best and worst creatives by cost per result and CTR, plus fatigue signals (rising frequency with falling CTR vs the previous period).
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without description help. The description usefully discloses an analytical behavior the annotations cannot convey: fatigue detection is a cross-period comparison ('rising frequency with falling CTR vs the previous period'), which tells the agent the tool performs period-over-period math rather than a point-in-time snapshot. It says nothing about return shape, whether both extremes are always present, or minimum spend/impression thresholds for ranking.
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?
A single sentence with the core action front-loaded and the qualifier about fatigue appended after the primary metrics. Every clause carries information; there is no filler or restatement of the title.
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 read-only analytics tool with zero required parameters, 100% schema coverage and no output schema, the description gives enough to know what question it answers and what signals come back. The gap is that it never sketches the returned structure (ranked rows, sections, which metrics beyond cost per result and CTR), leaving the agent to guess at output shape.
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 all seven parameters carry inline descriptions, including the summary/full enum trade-off and the date_range default, so the schema does the heavy lifting. The description adds no parameter-level meaning of its own. Baseline 3 applies when structured fields fully document the inputs.
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 combination ('Rank ads by efficiency') and enumerates the exact outputs: best and worst creatives by cost per result and CTR, plus fatigue signals. That is far more concrete than the bare name 'meta_creative_insights'. It stops short of naming the sibling it displaces (e.g. meta_ads or meta_insights_query), so an agent must infer the boundary from the metric set alone.
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 use case ('best and worst creatives', 'fatigue signals') is implied by the output description, so an agent can infer this is the tool for creative-level efficiency questions. However, there is no explicit when-to-use statement, no exclusions, and no named alternative such as meta_insights_query for general metric pulls or meta_ads for the raw ad list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_delete_ruleDelete a Meta automated ruleADestructiveInspect
Delete an automated rule. Preview first, then confirm=true with confirm_name equal to the rule name.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| confirm | No | ||
| rule_id | Yes | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| confirm_name | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is known. The description adds real value beyond that by disclosing the guard mechanism: confirmation requires both confirm=true and a matching confirm_name, which is exactly the context an agent needs before an irreversible delete. It stops short of saying what failure looks like on a name mismatch.
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 sentences with zero filler, the destructive action stated first and the prerequisite sequence second. Every clause carries 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 destructive, multi-account tool with no output schema, the description covers the confirmation protocol but leaves the preview step undefined — an agent does not know whether previewing means calling this tool without confirm, or calling meta_rules. That single omission is the difference between safe and accidental deletion.
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 50%, and the description does compensate for the undocumented parameters by explaining confirm and confirm_name's matching constraint, and implying rule_id identifies the target. However, folder, account, and language get nothing beyond the schema, and 'rule name' is never tied to a discovery source.
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?
Specific verb+resource: 'Delete an automated rule', which is unambiguous in this ecosystem and distinct from meta_remove (generic entity removal) or meta_create_rule. It does not explicitly name those siblings, so an agent must infer the boundary from the noun 'rule' alone.
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?
'Preview first, then confirm=true' implies a two-step flow, but never says how to preview — whether a bare call acts as a dry-run, or whether another tool (meta_rules) must be consulted first. There is no guidance on exclusions or on what to do if the rule is active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_duplicateDuplicate a Meta campaign, ad set or adAInspect
Copy a campaign, ad set or ad (with its children for campaigns/ad sets). Copies are created PAUSED. Optionally into another campaign/ad set.
| Name | Required | Description | Default |
|---|---|---|---|
| into | No | Target campaign (for ad sets) or ad set (for ads) name or ID. | |
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| id_or_name | Yes | ||
| rename_suffix | No | Default ' - Copy'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral fact the annotations do not carry: copies are created PAUSED, which materially changes what an agent must do afterward. It also discloses that campaigns/ad sets bring their children along. It does not say what the tool returns (no output schema exists) or how name collisions are resolved beyond the schema's rename_suffix.
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 action and resource, then the two facts an agent most needs (resulting PAUSED state, optional target placement). No filler or redundant restatement of the title.
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 openWorldHint and no output schema, the description covers the essentials: what gets copied, what state the copy lands in, and where it can be placed. It omits the return value (presumably new entity IDs) and whether the source must be in the same account, which an agent may need before chaining further calls.
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 71%, and the two required params (level, id_or_name) have no schema descriptions at all; the description partially compensates by mapping "campaign, ad set or ad" to the level enum and framing id_or_name as the source entity. It restates the 'into' semantics already in the schema and adds nothing about account/folder scoping or how id_or_name resolves ambiguity.
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?
"Copy a campaign, ad set or ad" names a specific verb and the three resource levels, which inherently separates it from the create_* siblings (meta_create_campaign, meta_create_adset, meta_create_ad) and from meta_rename. It also states the child-copying scope, but never names an adjacent tool explicitly, so it stops just short of full 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?
"Optionally into another campaign/ad set" conveys the cross-placement use case, so an agent can infer this is for reusing an existing structure rather than authoring a new one. There is no explicit when-not guidance (e.g. cross-account copying, or when to prefer building fresh with the create_* tools), leaving that to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_explain_changeExplain a Meta performance changeARead-onlyInspect
Explain why results or cost changed between this period and the previous one: decomposes cost per result into CPM, CTR and conversion rate, and shows which campaigns drove the change.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description earns credit beyond that by disclosing the analytical output shape (CPM/CTR/conversion-rate decomposition and campaign-level drivers) in the absence of an output schema, though it says nothing about latency, account-scope requirements or period defaults.
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?
A single sentence with the purpose front-loaded and no filler; the clause after the colon exists to specify the analytical method, so every word 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 seven-parameter, zero-required analytical tool with no output schema, the description tells an agent what question it answers and what the result contains. It stops short of clarifying how the comparison window is chosen (the schema defaults date_range to LAST_30_DAYS) or what happens when the account is ambiguous, which would fully close the 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% with all seven parameters documented, including enum explanations for detail, language and date_range, so the schema carries the parameter burden. The description adds no parameter-level guidance of its own (no mention of detail=full vs summary, folder scoping, or date_range versus start_date/end_date), which is the expected baseline when the schema is complete.
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 ('Explain why results or cost changed between this period and the previous one') and then details the mechanism: decomposition of cost per result into CPM, CTR and conversion rate, plus attribution to campaigns. This is clearly distinguishable from sibling reporting tools like meta_performance or meta_insights_query, which return metrics but do not explain change.
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 opening clause establishes the triggering context — the user asks why results or cost moved versus the prior period — which is a clear use condition. It does not, however, name alternatives or state when to use meta_performance/meta_insights_query instead for raw numbers, so routing among the meta reporting siblings is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_get_leadsDownload Meta leadsARead-onlyInspect
Get the leads submitted to a lead form (or a lead ad), newest first, with their answers. Use since to get only new leads. Treat lead data as personal data: show it only to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| ad | No | ||
| limit | No | ||
| since | No | YYYY-MM-DD | |
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| form_id | No | ||
| page_id | No | Page that owns the form (needed for form_id). | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that: newest-first ordering, inclusion of lead answers, and a privacy instruction to show lead data only to the user. It does not cover whether results are paginated beyond limit or what happens when no form is specified.
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 purpose before the parameter hint and the privacy caveat. Every sentence carries information, though the personal-data sentence is guidance rather than tool behavior and could have been folded more tightly.
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 9-parameter tool with no output schema, the description is adequate but thin: it does not explain how a caller identifies which form/ad to pull leads from, despite form_id, page_id, ad and folder all existing as selectors. The ordering and privacy notes help, but the selection workflow is left implicit.
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 67% schema description coverage, the schema already documents since, detail, folder, account, page_id and language. The description reinforces the meaning of since ('only new leads'), which the schema only formats as YYYY-MM-DD, adding a real semantic cue. It says nothing about limit's 1–500 bound, ad, or form_id.
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 ('Get the leads submitted to a lead form (or a lead ad)') plus the return ordering ('newest first, with their answers'), so an agent knows exactly what it retrieves. It does not explicitly differentiate itself from the sibling meta_lead_forms, leaving ambiguity about which tool lists forms versus which lists submissions.
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 one concrete usage hint ('Use since to get only new leads') and a handling constraint about personal data. However, it never states when to choose this over meta_lead_forms or linkedin_get_leads, nor any prerequisite such as needing a form_id or page_id first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_insights_queryMeta custom insights (read-only)ARead-onlyInspect
Run a custom read-only Insights query for analysis not covered by other tools: choose level, Insights API fields, breakdowns and time increment.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| limit | No | ||
| fields | Yes | Insights fields, e.g. spend, impressions, actions, cost_per_action_type, video_p75_watched_actions. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| breakdowns | No | ||
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). | |
| time_increment | No | 1 for daily, 7 for weekly, monthly, or all_days. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, and the description's 'read-only' merely restates that. It adds the useful framing of a raw, customizable query surface but says nothing about rate limits, field-validation failures, or how the request is assembled against the Insights API. With annotations carrying the safety profile, a 3 is appropriate.
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?
A single front-loaded sentence that states the action and the scope before enumerating the knobs. Nothing is wasted and the fallback rationale is not buried.
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 an 11-parameter passthrough query tool with no output schema, the definition is thin: it doesn't explain how date_range interacts with start_date/end_date, what values breakdowns accepts, or how invalid Insights fields are surfaced. Annotations cover safety, but the operational gaps remain for an agent composing a non-trivial query.
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 73%, so the schema already documents most parameters including date_range defaults and account resolution. The description names four of the eleven parameters (level, fields, breakdowns, time_increment) without adding format or valid-value meaning beyond what the schema says, and leaves breakdowns and limit unexplained in both places.
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 ('Run a custom read-only Insights query') and scopes it as the escape hatch for 'analysis not covered by other tools'. An agent can tell it apart from the fixed-report siblings like meta_performance or meta_breakdown, though those siblings are never named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for analysis not covered by other tools' gives a clear fallback-to-this condition and implies the standard report tools come first. It stops short of naming which sibling to try before falling back, so the agent must infer the ordering from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_lead_formsMeta lead formsBRead-onlyInspect
Instant (lead) forms on a Facebook Page with status, lead count and creation date.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| page_id | Yes | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, open-world, non-destructive operation, so the safety profile is covered. The description adds useful context by naming the fields returned, but it does not explain permissions, pagination, or the distinction between listing forms and retrieving submitted leads.
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 efficient sentence with no filler. It is appropriately short, though it could be front-loaded more explicitly with a verb such as 'List' to clarify the operation immediately.
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 read-only listing tool with annotations and a mostly documented schema, the description is adequate but thin. Because there is no output schema, it should do more to explain the return shape, pagination, or how this differs from meta_get_leads.
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 80%, so most parameters are already explained by the schema, including detail, folder, account, and language. The description adds no parameter-specific meaning beyond the schema, and the required page_id parameter remains undocumented in both the schema and the description.
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 clearly identifies the resource as instant lead forms on a Facebook Page and lists the returned attributes: status, lead count, and creation date. It stops short of explicitly distinguishing the tool from related siblings such as meta_get_leads, which likely retrieves the actual lead submissions rather than the forms.
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?
There is no guidance on when to use this tool versus alternatives such as meta_get_leads or the lead-form tools for LinkedIn and TikTok. It also does not state prerequisites, exclusions, or the workflow context for listing forms before retrieving leads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_pagesMeta Pages and Instagram accountsBRead-onlyInspect
Facebook Pages (and linked Instagram accounts) the user can advertise with; needed to create ads.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context that results are permission-scoped ('the user can advertise with') and act as a prerequisite for ad creation, but says nothing about the shape or size of the result 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?
A single compact sentence with no filler, and the resource is front-loaded before the dependency note. It is efficient, though the semicolon clause could have been used to name an alternative tool instead of repeating the ad-creation dependency.
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 read-only lookup with no output schema, the description should at least hint at what comes back (page IDs/names used later in ad creation), since the whole point is to obtain identifiers. It covers the input side adequately via the schema but leaves the return contract implicit.
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% with three well-documented parameters, including the enum for language and the account ID format hint, so the schema carries the burden. The description adds no parameter meaning at all, which lands it at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource (Facebook Pages plus linked Instagram accounts) and its scope (the ones the user can advertise with), so an agent knows it retrieves ad-eligible pages rather than general account data. It does not explicitly say 'list/retrieve' or distinguish itself from nearby siblings such as list_accounts or meta_account_status, which keeps it below 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 clause 'needed to create ads' implies the usage context: fetch page/IG identity before calling meta_create_ad or meta_create_campaign. There is no explicit when-not guidance and no named alternative (e.g., list_accounts for ad accounts), so the routing signal is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_performanceMeta Ads performanceRead-onlyInspect
Meta Ads performance dashboard: spend, results (purchases/leads/messages… chosen per campaign objective), cost per result, link clicks, CTR, CPC, purchase value and ROAS vs the previous period, with a daily trend, per-campaign table and automatic insights. Shown as an interactive dashboard; summarise the main findings. Default: last 30 days. Amounts are in the account currency.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
meta_reach_estimateMeta audience size estimateBRead-onlyInspect
Estimate the audience size for a targeting spec before creating or changing an ad set.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| targeting | Yes | Meta targeting spec (geo_locations, age_min, age_max, genders, flexible_spec, custom_audiences…). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered by structured data. The description adds the pre-flight positioning value of the call, but says nothing about whether the estimate is a range or a point value, its typical latency, or account/folder resolution behavior when multiple accounts are enabled.
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?
A single front-loaded sentence with no filler; the purpose and the moment of use arrive immediately. It is arguably too terse rather than padded, so brevity is not the issue.
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 is the only place an agent could learn what an "estimate" looks like (a number, a range, a breakdown by placement), and that is absent. For a read-only, open-world lookup with a fully documented schema, it is workable but leaves a real gap around the return value.
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 all four parameters – including the nested targeting object with its example sub-fields – are already documented. The description names the targeting spec but adds no syntax guidance, example payloads, or constraints for the optional folder/account/language parameters, so it stays at the 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?
Description pairs a specific verb and resource ("Estimate the audience size") with the input type ("targeting spec"), so an agent knows exactly what the tool returns conceptually. It does not differentiate itself from near-siblings such as linkedin_reach_estimate or google_ads_reach_frequency, though the name prefix carries the platform scoping.
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 a timing cue for use ("before creating or changing an ad set"), which is genuine usage context. However, it names no alternatives and no exclusions – it never tells the agent to prefer meta_targeting_search for finding valid targeting options first, or what to do if the spec is rejected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_removeDelete a Meta campaign, ad set, ad or audienceADestructiveInspect
Delete a campaign, ad set, ad or custom audience. Requires the user's explicit yes: call first without confirm to preview, then with confirm=true and confirm_name equal to the exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| id_or_name | Yes | ||
| confirm_name | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds the human-in-the-loop preview/confirm gate, which is genuinely new behavioral context. It omits whether deletion is permanent/irreversible and whether deleting a campaign cascades to its adsets and ads — meaningful gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The destructive scope is front-loaded and the confirm protocol follows immediately, in the order the agent needs it.
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 destructive tool with seven parameters and no output schema, the definition covers the confirmation workflow but not the consequences: irreversibility, cascade behavior, or what the preview call returns. An agent could execute the flow correctly yet still be unable to warn the user accurately about impact.
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 only 43% schema coverage, the description usefully explains two otherwise undocumented params: `confirm` as the execution flag and `confirm_name` as an exact-name match check. However, it says nothing about `id_or_name` (whether an ID or a display name is accepted, or how ambiguity is resolved) — a required parameter 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 (Delete) plus the exact resources (campaign, ad set, ad, custom audience), matching the `level` enum. An agent can distinguish it from siblings like meta_rename, meta_set_status, meta_duplicate, and meta_delete_rule without opening any 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 an explicit two-step protocol: call first without `confirm` to preview, then call again with `confirm=true` and the matching `confirm_name`. That is strong when-to-use guidance for this tool. It stops short of naming alternatives — e.g. when to pause via meta_set_status instead of deleting — so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_renameRename a Meta campaign, ad set or adCDestructiveInspect
Rename an object.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| new_name | Yes | ||
| id_or_name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the mutation risk is carried by structured data rather than the description. The description adds no behavioral context such as irreversibility, required permissions, or what happens when id_or_name matches multiple objects, so it provides essentially nothing beyond 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?
At two words there is no wasted verbiage, but the definition is under-specified rather than concise. It fails to front-load any of the scoping or target information an agent needs before invoking a destructive mutation.
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 six-parameter destructive mutation across three object levels, with no output schema and half the parameters undocumented, the description is entirely inadequate. An agent cannot determine scope, resolution behavior of id_or_name, or expected outcome from it.
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 50%, with folder, account, and language documented in the schema itself. The description adds no meaning for the three undocumented required parameters (level, id_or_name, new_name), notably the ambiguity of whether id_or_name accepts a display name or an ID. With half the schema covered, this sits at the minimum viable 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 'Rename an object' merely restates the tool name in generic terms and never names the resource domain. It is only via the title (campaign, ad set, ad) that an agent learns what kind of object is renamed, and it does nothing to distinguish this from sibling tools like snapchat_rename or tiktok_rename.
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?
There is no guidance on when to use this tool versus the platform-specific rename siblings, no prerequisites, and no mention of which account/folder context is required. The agent must infer everything from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_rulesMeta automated rulesBRead-onlyInspect
Automated rules on the ad account (e.g. pause ad sets when cost per result is too high) with status, conditions and action.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds the useful detail that returned rules include status, conditions and action, but says nothing about volume, pagination, or whether all rules or only active ones are returned.
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?
A single compact sentence with no filler, and the resource is front-loaded. It is slightly under-specified rather than padded, which costs it nothing in wastefulness but leaves a clause of explanatory example that could have carried usage guidance instead.
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-parameter read tool with full schema descriptions and no output schema, the definition is adequate but thin. An agent still has to infer that this reads rules rather than managing them, and gets no hint about result size or scope across 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%, and the folder/account/language/detail parameters are already fully documented, including the summary-vs-full guidance. The description adds nothing beyond the schema, so the baseline of 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?
Names a specific resource (automated rules on the ad account) and enumerates the payload the agent will see (status, conditions, action), with a concrete example of a rule. It never uses an explicit verb like 'list' or 'retrieve', so the read-only nature is only inferred from sibling names like meta_create_rule and meta_delete_rule.
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 statement of when to reach for this tool versus meta_create_rule, meta_delete_rule, or any of the many meta_* performance tools. The presence of create/delete siblings makes the listing role guessable, but the description never confirms it or says what question it answers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_saved_audiencesMeta saved audiencesCRead-onlyInspect
Saved audiences (reusable targeting presets) in the ad account with their targeting summary.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds context about the returned content ('with their targeting summary'), which is useful, but says nothing about pagination, result limits, or what happens on an empty account.
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?
A single compact sentence with no waste, and the resource and its enrichment are front-loaded. It could be slightly stronger with an explicit verb, but it is efficient.
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 read-only list tool with no output schema and fully documented parameters, the description covers the essentials. The main gap is the lack of differentiation from sibling audience tools and any mention of result scope or limits, which an agent needs to 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% for all three parameters (folder, account, language), so the schema carries the burden. The description adds no parameter-level meaning beyond the schema, which is the expected baseline when coverage is complete.
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 resource ('Saved audiences') and clarifies it with a parenthetical ('reusable targeting presets'), and mentions it includes 'their targeting summary'. However, there is no explicit verb (list/read) and no differentiation from the sibling tool 'meta_audiences', leaving an agent unsure which to call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus 'meta_audiences', 'meta_targeting_search', or 'meta_create_audience'. The description neither states prerequisites nor exclusions, so the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_set_statusPause or activate a Meta campaign, ad set or adADestructiveInspect
Pause runs immediately. Activating starts spending: the first call returns a preview; ask the user, then call again with confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| status | Yes | ||
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| id_or_name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, so the safety profile is covered; the description adds genuinely non-obvious behavior: pause is immediate, activation starts spending, and activation requires a two-step preview/confirm handshake. It does not say whether pausing is reversible without side effects or what the preview card contains, keeping it 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?
Two short sentences, front-loaded with the safety-critical fact (pause is immediate) and then the spending consequence plus the required call sequence. Nothing is redundant.
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 7-parameter mutation tool with no output schema, the confirm handshake is well covered but key gaps remain: how id_or_name is resolved across levels, what happens when multiple accounts exist, and whether pause requires confirmation too. Adequate minimum, not complete.
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 43% and several params (level, id_or_name, confirm) have no schema description. The description compensates for exactly one of these by explaining what confirm=true does and when to set it, but leaves name-vs-ID resolution, level selection, account/folder scoping, and language undocumented.
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 the two concrete operations (pausing and activating) and their immediate effect, which lets an agent infer this is a status toggle. It never names the resource itself (campaign/ad set/ad) in the body – that only comes from the title – so it is clear but not fully self-contained.
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 usefully distinguishes the two modes of use by telling the agent to preview, ask the user, then re-call with confirm=true. It gives no guidance on when to choose this tool over siblings like meta_remove or the platform-specific status tools, nor any prerequisite/scope conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_targeting_searchSearch Meta targeting optionsARead-onlyInspect
Find targeting IDs: interests, behaviours, or locations (countries, regions, cities) by keyword, with audience size where available.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | ||
| query | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| country | No | Country code to narrow locations, e.g. SA. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety and external-network reach are covered. The description adds one genuinely useful behavioral fact beyond that: results may include audience size 'where available', which signals inconsistent return fields. It doesn't say how many results come back, whether matching is prefix or fuzzy, or whether audience-size lookups are slower or rate-limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action ('Find targeting IDs') and then qualifies the entity types and the returned audience size. No filler, no restatement of the tool name, nothing an agent must skip past to reach the operative 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?
With six parameters, no output schema, and an open-world search backend, the description should say more about what comes back (ID plus name pairs? a ranked list?) and any result limits. It covers entity types and the audience-size caveat but not the return shape, the meaning of the optional scoping parameters, or the relationship between location results and the `country` filter. Workable, not complete.
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 description expands the `location` option into 'countries, regions, cities', which adds real meaning beyond the bare enum value. However, with only 67% schema coverage, three parameters (folder, account, language) carry no explanation in the description, and it doesn't clarify how the `country` parameter interacts with `type=location`. Added value is real but partial.
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?
Specific verb-plus-resource: 'Find targeting IDs' for interests, behaviours, or locations, with the search mechanism (keyword) and the value-add (audience size). It clearly separates the three searchable entity types covered by the `type` enum. It doesn't distinguish itself from sibling lookup tools like meta_audiences or linkedin_targeting_search, but the platform prefix in the name plus the explicit entity list makes the purpose 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?
Usage is only implied: an agent can infer this is the lookup step before applying targeting via meta_update_targeting or meta_create_adset, but the description never says so. There is no guidance on when to prefer this over meta_audiences/meta_saved_audiences (existing vs. new targeting), nor any note that results are IDs meant to be passed downstream. Adequate but leaves the routing decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_tracking_auditMeta Pixel & Conversions API auditARead-onlyInspect
Check tracking: pixels/datasets on the account, last fired time, events received in the last 7 days (browser vs server/Conversions API), and campaigns optimising for events that aren't being received. Use for 'why no purchases/leads' questions.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, non-destructive, open-world operation. Beyond that, the description usefully discloses the audit dimensions and the 7-day event window, though it does not describe output shape or limitations such as missing permissions or unavailable pixel data.
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 definition is two tight sentences with no waste. The audit contents are front-loaded, followed by a practical use case, making it easy to scan and route.
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 read-only audit tool with no output schema, the description does a good job naming the sections and checks the agent should expect. It could go further by clarifying the return format or edge-case behavior, but it is largely complete for the tool's complexity.
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 all four parameters are already documented, including detail, folder, account, and language. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Check tracking,' and enumerates the exact Meta resources and signals audited: pixels/datasets, last fired time, browser vs server event receipt, and campaigns optimizing for missing events. The scope is clearly Meta-specific, so an agent can distinguish it from Google Ads, TikTok, and GA4 tracking-audit 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?
It gives a clear usage trigger: questions like 'why no purchases/leads.' That is helpful context, but it does not explicitly say when not to use it or name alternative sibling tools such as ga4_tracking_check or gtm_audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_update_ad_creativeEdit a Meta ad's text or linkADestructiveInspect
Change an ad's primary text, headline, description, link or call to action. Meta creatives can't be edited in place, so this builds a new creative from the current one and attaches it; the ad goes back to review and keeps its status.
| Name | Required | Description | Default |
|---|---|---|---|
| ad | Yes | ||
| link | No | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| headline | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| description | No | ||
| primary_text | No | ||
| call_to_action | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety bar is low, yet the description still adds real behavioral context: creatives cannot be edited in place, a new creative is cloned and attached, and the ad re-enters review while retaining its status. It stops short of saying what happens to the superseded creative or whether existing performance history is preserved, which is the main remaining gap given the destructive flag.
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: the first front-loads what can be changed, the second explains the non-obvious mechanism. No filler, no repetition of the title, and the important constraint arrives before the detail.
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 destructive, open-world mutation with no output schema and nine parameters, the description covers the essential non-obvious facts: the clone-and-attach mechanism, the review reset, and status retention. It is only slightly incomplete in not clarifying the ad identifier format or the account/folder scoping, which the schema handles thinly.
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 only 33% schema description coverage, the description must compensate, and it does partially by naming the five editable creative fields (primary_text, headline, description, link, call_to_action) that map to schema properties. It says nothing about the required 'ad' identifier, nor about folder/account/language, so several parameters remain unilluminated in both places.
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 ('Change an ad's primary text, headline, description, link or call to action') and enumerates exactly which creative fields are editable. That field list cleanly separates it from sibling mutations such as meta_rename, meta_set_status, meta_update_targeting, and meta_create_ad.
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: the agent can infer this is the tool for copy/link edits because the mechanism ('builds a new creative from the current one') is spelled out. There is no explicit when-not guidance pointing to meta_update_targeting, meta_update_placements, or meta_create_carousel_ad for other kinds of ad changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_update_bidChange a Meta ad set bidADestructiveInspect
Set bid strategy and/or bid/cost-cap amount (account currency) on an ad set. Raising a bid or removing a cap returns a preview and needs confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| adset | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| bid_amount | No | ||
| bid_strategy | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds real information beyond that: the two-step preview/confirm flow for bid-raise and cap-removal operations, plus the fact that amounts are in account currency. It does not state reversibility or what the preview contains, so it falls 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?
Two compact sentences: the operation and scope come first, the risky preview/confirm requirement second. No redundant restatement of the title, no filler, and the most agent-critical constraint (confirm=true) is given prominence.
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 destructive, open-world mutation with seven parameters, no output schema and thin schema descriptions, the description covers the essentials: what it changes, the currency unit, and the confirmation gate. Remaining gaps — adset identifier format, what the preview response looks like, and reversibility — are modest but real.
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 only 43% (folder, account, language documented), leaving adset, confirm, bid_amount and bid_strategy bare. The description compensates by explaining the 'and/or' relationship between strategy and amount, that bid_amount is in account currency, and precisely when the otherwise-undocumented confirm flag must be true — meaningful added semantics 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?
States a specific verb and resource: 'Set bid strategy and/or bid/cost-cap amount ... on an ad set,' which distinguishes it from the adjacent budget-editing sibling. It stops short of naming meta_update_budget or other siblings, but the bid-vs-budget distinction is unambiguous 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?
The conditional 'Raising a bid or removing a cap returns a preview and needs confirm=true' gives an explicit when-to-confirm rule, which is useful guidance. However, there is no when-to-use/when-not guidance relative to alternatives such as meta_update_budget, nor any stated prerequisites (e.g., ad set must exist and use the relevant bid strategy), so usage is only partially framed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_update_budgetChange a Meta budgetADestructiveInspect
Change the daily or lifetime budget of a campaign (campaign budget) or ad set, in the account currency. Decreases run immediately; increases return a preview and need confirm=true after the user's yes.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| id_or_name | Yes | ||
| daily_budget | No | ||
| lifetime_budget | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, so the write nature is known; the description adds the genuinely non-obvious asymmetry that only decreases are irreversible-now while increases are preview-gated. It leaves out permission/scope requirements, whether an approval failure leaves state unchanged, and rate-limit or rollback 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?
Two sentences, zero filler so far as it goes, with the object of the change stated before the conditional workflow. The clause order front-loads what is being mutated and back-loads the confirm rule, matching how an agent reads before acting.
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 destructive 8-parameter mutation with no output schema, the description covers the highest-risk behaviors: immediacy of decreases and the preview/confirm loop for increases, plus currency semantics. Gaps remain around scope resolution (folder/account/id_or_name), daily-vs-lifetime exclusivity, and what the preview or result card contains.
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 only 38%, and the description compensates meaningfully: it establishes account-currency units for the budget values (a real error vector), links level to which budget applies, and explains the otherwise undocumented confirm flag's role and timing. It adds nothing for folder, account, language, or id_or_name, and does not clarify whether daily_budget and lifetime_budget are mutually exclusive.
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 pairs a specific verb ('Change') with a precise resource ('daily or lifetime budget') and disambiguates the two targets, 'campaign (campaign budget)' vs 'ad set', which is a subtle Meta distinction an agent could otherwise get wrong. It stops short of naming or contrasting Meta siblings such as meta_update_bid, relying on the budget-vs-bid wording to carry that separation.
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 a concrete operational rule: decreases act immediately while increases return a preview and require confirm=true only after the user agrees, which effectively tells the agent when to pass a parameter and what conversational precondition must hold. It does not cover when to prefer a different Meta tool (e.g. bid changes) or how to handle requests that mix levels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_update_placementsChange Meta ad set placementsBDestructiveInspect
Switch an ad set between Advantage+ (automatic) placements and manual placements on Facebook, Instagram, Messenger and Audience Network positions (feed, stories, reels…).
| Name | Required | Description | Default |
|---|---|---|---|
| adset | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| devices | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| automatic | No | ||
| platforms | No | ||
| facebook_positions | No | ||
| instagram_positions | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is known. The description adds which positions and surfaces can be set, but says nothing about what existing placement settings are overwritten, whether ad review is re-triggered, or what permissions/account context are required — meaningful gaps for a destructive mutation.
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?
A single front-loaded sentence that packs the mode switch, the surfaces, and example positions with no filler. It is dense but readable, and nothing is wasted.
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 destructive, 9-parameter mutation with no output schema and low schema coverage, one sentence is not sufficient: it omits the automatic-vs-manual precedence rule, account/folder scoping, device targeting, and the consequence of overwriting existing placements.
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 description implicitly maps the platforms, facebook_positions and instagram_positions parameters by enumerating the surfaces (Facebook, Instagram, Messenger, Audience Network; feed, stories, reels). With only 33% schema coverage, it does not compensate for the undocumented remainder — notably the precedence of `automatic` over the position arrays, plus devices, folder, account and language.
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?
Names a specific verb (switch) and a specific resource (ad set placements), and spells out the two modes (Advantage+ automatic vs manual) plus the surface types covered. It is clearly distinguishable from sibling targeting tools like meta_update_targeting, though it never names that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the two use modes (automatic vs manual) but gives no explicit when-to-use, prerequisites, or alternatives. An agent must infer that manual position arrays only matter when automatic is false, and that other ad-set attributes are handled by different tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_update_scheduleChange a Meta ad set scheduleADestructiveInspect
Change an ad set's start/end date, or set day-parting (run only on certain days/hours; requires a lifetime budget). Extending the end date of a running ad set returns a preview and needs confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| adset | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| confirm | No | ||
| end_time | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| dayparting | No | ||
| start_time | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and openWorldHint=true, so the mutation profile is known. The description adds genuinely useful behavior beyond that — the preview-then-confirm flow for extending a running ad set's end date, plus the lifetime-budget prerequisite for day-parting — but says nothing about reversibility, which ad set states are affected, or what the preview payload looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the primary capability is front-loaded before the caveats. The parenthetical and the confirm note each carry distinct operational information rather than restating the name.
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 an eight-parameter destructive mutation with no output schema, the description covers the two behaviors an agent would most likely get wrong: the confirm/preview flow and the lifetime-budget requirement. Time formats, mutual exclusivity of dates vs dayparting, and failure modes remain unaddressed, keeping it short of complete.
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 only 38%, so the description must carry weight; it clarifies confirm (needed for the preview path) and day-parting semantics plus its budget precondition. However, adset, start_time, and end_time have no documentation anywhere — no timezone, format, or whether adset takes an ID or a name — which is a notable gap for a low-coverage 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 names a specific verb ('Change') and concrete resources: an ad set's start/end date and day-parting. That is enough to separate it from siblings like meta_update_budget or meta_update_targeting, though it never names those alternatives explicitly.
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 real conditional guidance: day-parting requires a lifetime budget, and extending the end date of a running ad set returns a preview and needs confirm=true. What's missing is routing against adjacent tools (meta_set_status, meta_update_budget) or what to do when neither dates nor dayparting are being changed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_update_targetingUpdate Meta ad set targetingADestructiveInspect
Change an ad set's targeting: locations, age, gender, interests, custom/excluded audiences, Advantage+ audience. Only the fields you pass change.
| Name | Required | Description | Default |
|---|---|---|---|
| adset | Yes | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| age_max | No | ||
| age_min | No | ||
| genders | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| countries | No | ||
| interest_ids | No | ||
| advantage_audience | No | ||
| custom_audience_ids | No | ||
| excluded_audience_ids | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The line "Only the fields you pass change" is genuinely useful partial-update semantics that the annotations do not convey. However, with destructiveHint=true, the description never states that overwriting targeting on a live ad set can reset delivery/learning, nor what permissions or state are required — real gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded and load-bearing: the first scopes the resource and fields, the second states the partial-update contract. Zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive 12-parameter mutation with no output schema and sparse schema descriptions, the definition leaves key operational questions unanswered: how to obtain interest/audience IDs, whether arrays replace or append, and what happens to existing targeting defaults. The core contract is present but incomplete.
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 only 25%, so the description should compensate more. It does map loosely onto the undocumented params (locations→countries, interests→interest_ids, custom/excluded audiences), but adds no format detail (ISO country codes, interest ID lookup via meta_targeting_search, Advantage+ interactions), and says nothing about folder, account, or language.
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?
Clear verb+resource ("Change an ad set's targeting") plus an enumeration of the exact targeting dimensions it controls. It distinguishes itself implicitly from meta_update_placements and meta_update_budget by naming targeting fields, though it never names a sibling explicitly.
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 by the field list, but there is no guidance on when to use this versus meta_create_adset or meta_targeting_search, and no prerequisites (e.g., that the ad set must already exist, or that IDs must be resolved first). No exclusions or warnings about live-ad impact.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_upload_imageUpload an image to MetaAInspect
Upload an image from a public URL to the ad account's image library; returns the image hash for meta_create_ad. Accepts media_id for a file attached in the Go Shift chat.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| media_id | No | A file the user attached in the Go Shift chat (media_id from the [attachment …] marker). Use instead of the URL. | |
| image_url | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag a non-read-only, non-destructive, open-world write, and the description usefully adds the write target (ad account image library) and the return value (image hash). It does not disclose permission/scope requirements, whether duplicates are deduplicated by hash, or any rate/size limits for fetching a public URL, which are the remaining behavioral risks.
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 with no filler; the action and return value lead, and the alternate input mode follows. Nothing is repeated from the title or 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?
For a zero-required-parameter upload tool with no output schema, the description covers the essential contract: source of the image, destination library, and returned hash. The main gap is the implicit one-of requirement between image_url and media_id, which an agent could get wrong.
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 80%, so most parameters are already documented. The description adds a constraint the schema does not: image_url must be a *public* URL, and it clarifies that media_id is the chat-attachment alternative. It leaves unresolved what happens if neither image_url nor media_id is supplied, which matters given that no parameter is required.
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 a specific verb and resource ('Upload an image ... to the ad account's image library') and distinguishes itself from the sibling meta_upload_video by scope of media type. It also states the downstream artifact (image hash) that makes the tool useful.
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 implies when to use it: before meta_create_ad, since the produced hash feeds that tool. It also contrasts the two input modes ('media_id ... Use instead of the URL'). It stops short of stating exclusions, such as when to prefer media_library or what to do if an image is already uploaded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_upload_videoUpload a video to MetaAInspect
Upload a video from a public URL to the ad account; returns the video_id for meta_create_ad. Processing can take a few minutes. Accepts media_id for a file attached in the Go Shift chat.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| media_id | No | A file the user attached in the Go Shift chat (media_id from the [attachment …] marker). Use instead of the URL. | |
| video_url | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, open-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: uploads are asynchronous ('Processing can take a few minutes') and the call yields a video_id rather than a finished asset. It does not mention format/size limits or permission requirements, which would have earned 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?
Three short sentences, each carrying distinct information (source, return value, latency), with the core action front-loaded. No filler and nothing redundant with the annotations.
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 discloses the return value, and the latency note covers the async gap. But with six parameters and an empty required list, it never states that one of video_url or media_id must actually be supplied, nor what title/folder do, leaving a real risk of a source-less call.
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 67%, so the baseline is a 3. The description does add one real constraint the schema lacks: video_url has no schema description at all, and 'from a public URL' is the only statement that the source must be publicly reachable. However, 'title', 'folder', and 'account' get no treatment, and the relationship between media_id and video_url is largely repeated from 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 ('Upload a video ... to the ad account'), names the destination, and ties the output to a concrete downstream consumer ('returns the video_id for meta_create_ad'). That distinguishes it cleanly from meta_upload_image and tiktok_upload_video without the agent opening any 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 both input modes: a public URL, or a media_id for a file attached in the Go Shift chat, with the explicit 'Use instead of the URL' rule carried in the schema. It stops short of saying when to pick this over meta_upload_image or media_library, and offers no exclusions, so it is strong context without full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
meta_wasted_spendMeta wasted spendARead-onlyInspect
Find money spent without results: ad sets and ads with spend and zero results, very high cost per result vs the account average, high frequency (audience fatigue) and low CTR. Read-only; suggests what to pause or fix.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Meta ad account name or ID (act_123 or 123). Optional when only one account is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so 'read-only' largely restates structured data. The one genuinely additive piece is that the tool only 'suggests what to pause or fix' — it recommends but never mutates, which matters to an agent deciding whether a follow-up call is needed. Nothing is said about data freshness, scan cost, or how the thresholds 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?
Two sentences: the first front-loads the purpose and the concrete detection criteria, the second supplies the read-only/advisory posture. No filler, no restatement of the name or title.
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 conveys enough shape to act on — flagged ad sets/ads with supporting signals — and the schema fully covers inputs. It stops short of defining what 'very high' or 'high frequency' mean numerically or what sections the output contains, which would help an agent interpret the result without a second call.
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% with all 7 parameters documented, including enum meanings and the 'optional when only one account is enabled' note. The description adds no additional parameter guidance, so the schema carries the full burden and 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?
States a specific verb and resource ('find money spent without results') and enumerates the exact detection signals: zero-result ad sets/ads with spend, cost per result far above account average, high frequency, and low CTR. This clearly separates it from generic reporting siblings like meta_performance or meta_insights_query, which return data rather than a diagnosis.
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 signals enumerated imply the usage context (diagnostic audit of wasted spend), and the closing clause clarifies the tool advises rather than acts. However, there is no explicit statement of when to reach for this versus meta_insights_query or meta_performance, and no when-not-to-use guidance (e.g. accounts with no conversion tracking).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_adsSnapchat adsCRead-onlyInspect
Ads with status, review status (approved/rejected + reason), ad type, creative ID and ad squad. Filter by campaign or ad squad.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| adsquad | No | Ad squad name or ID. | |
| campaign | No | ||
| language | No | Language of the card: the language the user is writing in. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the return payload (review status including rejection reason, creative ID linkage), but says nothing about pagination, cross-account scope, or volume, which matters for an openWorldHint 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?
Two tight sentences with no filler, and the returned-field list is front-loaded before the filter sentence. It is telegraphic enough that the missing verb costs a bit of clarity, but nothing is wasted.
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 read-only listing tool with annotations and no output schema, the field enumeration usefully substitutes for return-value documentation. However, it omits scope (all ads in account vs. filtered), pagination limits, and how an agent should choose between this and snapchat_adsquads or snapchat_creatives.
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 80%, so the schema already documents folder, account, adsquad, and language. The description only clarifies that campaign and adsquad act as filters, which marginally compensates for the undocumented campaign parameter; 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 the fields returned (status, review status with reason, ad type, creative ID, ad squad), which implies a read/list tool, but it never states a verb or object explicitly ('Retrieve Snapchat ads'). Mentioning creative ID and ad squad does help distinguish it from snapchat_creatives and snapchat_adsquads, but the differentiation is incidental rather than stated.
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?
'Filter by campaign or ad squad' gives a scoping hint, but there is no when-to-use guidance, no mention of alternatives such as snapchat_adsquads or snapchat_performance, and no note on prerequisites like needing an account context or the single-account default.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_adsquadsSnapchat ad squadsARead-onlyInspect
Ad squads (ad sets) with status, campaign, optimisation goal, budget, bid, targeting summary (countries, ages, devices, audiences) and schedule. Filter by campaign. Use to find IDs and settings before changes or duplicating.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| campaign | No | Campaign name or ID. | |
| language | No | Language of the card: the language the user is writing in. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful detail of which fields are returned, which matters because there is no output schema, but says nothing about pagination, result limits, or the open-world account scoping it performs.
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 sentences with the resource description first and the actionable routing second; the '(ad sets)' gloss and the field list earn their place. Minor deduction because the leading noun fragment lacks a verb, forcing a small inference about the operation type.
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 read-only, zero-required-parameter listing tool with full schema coverage, the description covers what is returned, how to narrow results, and why an agent would call it. Only return-volume behavior (pagination/limits) is left unaddressed, which is a modest gap for an open-world account listing.
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 all four parameters are already documented, which sets the baseline at 3. The description's 'Filter by campaign' echoes the campaign parameter but adds no format or matching semantics (name vs ID resolution) beyond what the schema already states.
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?
Names the specific resource (ad squads/ad sets) and enumerates the settings returned — status, campaign, optimisation goal, budget, bid, targeting, schedule — which cleanly separates it from snapchat_campaigns and snapchat_ads. The only weakness is that the opening is a noun fragment, so the agent must infer this is a read/list operation rather than being told with an explicit verb.
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 real when-to-use guidance: 'Use to find IDs and settings before changes or duplicating', which frames it as a discovery step preceding mutation tools like snapchat_update_budget or snapchat_duplicate. It doesn't name the sibling alternatives (e.g. snapchat_campaigns, snapchat_ads, snapchat_performance) explicitly, so the exclusion side is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_audiencesSnapchat audiencesARead-onlyInspect
Custom, lookalike and pixel audiences (segments) with type, size and status, to use in ad squad targeting.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that results carry type, size and status, which tells the agent roughly what comes back, but says nothing about volume, pagination or freshness. With annotations doing the heavy lifting, this is a modest but real addition.
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?
A single compact sentence with no filler, and the most identifying information (audience types) is front-loaded. It is slightly too terse in that the operation itself must be inferred from the attribute list.
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 read-only listing tool with complete schema coverage and no output schema, the description covers the resource scope and the shape of the returned fields. The main omission is any hint of result volume or how audiences are identified for follow-on targeting calls.
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 folder, account and language are already fully documented in the schema, including the enum values for language. The description adds no meaning beyond that, 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 names the specific resource (audiences/segments) and enumerates the variants it covers (custom, lookalike, pixel) plus the attributes returned (type, size, status). The retrieval verb is only implied by the attribute list rather than stated, and it is not contrasted against nearby siblings such as snapchat_pixels or snapchat_update_targeting.
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 trailing phrase 'to use in ad squad targeting' gives a downstream use context, which is better than nothing, but there is no explicit statement of when to call this versus other Snapchat tools or when not to call it. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_breakdownSnapchat breakdownARead-onlyInspect
Break Snapchat performance down by age, gender, OS (iOS/Android), country or region, for the account or one campaign: spend, impressions, swipes, swipe rate, add to cart, purchases and cost per result.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| campaign | No | ||
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in. | |
| dimension | Yes | ||
| date_range | No | Default LAST_30_DAYS (max 31 days). | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful scope context ('for the account or one campaign') and discloses the metric set, but says nothing about result limits, pagination, empty-data behavior, or how rows are ordered.
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?
A single front-loaded sentence that puts the segmentation axes before the metric list, with zero filler. The enumerated lists are dense but readable and every clause carries 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?
With 8 parameters and no output schema, the description usefully compensates by naming the metrics returned and the available dimensions. The remaining gaps (aggregation granularity, result limits) are modest for a read-only reporting tool whose annotations and schema cover the rest.
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 75%, so the schema already documents most parameters including the dimension enum. The description adds a little meaning by expanding OS to 'iOS/Android' and clarifying that campaign scope is optional versus account-level. It adds nothing for date_range, start_date/end_date, folder, or language.
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 a specific verb ('break ... down') and resource ('Snapchat performance'), and enumerates the exact segmentation axes (age, gender, OS, country, region) and metrics returned. It implicitly separates itself from snapchat_performance by being the segmented view, though it never names that sibling explicitly.
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: reach for this when you need performance split by demographic/geo/OS rather than an aggregate. There is no explicit 'use X instead when...' routing against snapchat_performance or snapchat_wasted_spend, and no prerequisites (e.g., account must be enabled) are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_campaignsSnapchat campaignsBRead-onlyInspect
List Snapchat campaigns with status, objective and daily budget.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds which fields are returned, which is modest value, but says nothing about pagination, result volume, or how the listing is scoped when folder/account are omitted.
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?
A single well-formed sentence with the resource and the returned fields front-loaded, and no filler. It is perhaps too terse for the sibling landscape, but nothing in it is wasted.
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 read-only listing tool with fully documented optional parameters and no output schema, the definition is minimally sufficient. It omits any statement of scope or filtering behavior, which an agent would need to call it confidently in a multi-account setup.
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 all three parameters (folder, account, language) are already documented, and the enum on language is explicit. The description adds no extra meaning about how those filters affect the listing, 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?
Specific verb plus resource ('List Snapchat campaigns') with the notable fields it surfaces (status, objective, daily budget). An agent can tell it is a read/list operation on Snapchat campaigns, but the description never contrasts it with siblings like snapchat_create_campaign, snapchat_launch_campaign, or the parallel meta_campaigns/tiktok_campaigns 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?
There is no when-to-use guidance at all: nothing says whether this is for overview vs. performance analysis (snapchat_performance), whether it needs a folder or account selected first, or what to do when multiple accounts are enabled. The only implied usage comes from the tool name itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_create_adCreate a Snapchat adAInspect
Create an ad (PAUSED) in an ad squad from an existing creative (see snapchat_creatives or snapchat_ads). The ad type is matched to the creative automatically. New ads go through Snap review.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| adsquad | Yes | Ad squad name or ID. | |
| dry_run | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| creative_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavior beyond the annotations: the ad is created in PAUSED state, ad type is inferred from the creative rather than chosen, and the ad enters Snap review. These are exactly the facts an agent needs to avoid assuming a live ad. It omits permission requirements and never mentions the dry_run option despite its availability.
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 core action and the PAUSED default, then the auto-matching behavior, then the review caveat. No filler and no repetition of the title.
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 creation tool with no output schema and openWorldHint, the description covers the key lifecycle facts (paused, auto-typed, reviewed) but omits what the call returns (e.g., new ad ID) and how dry_run/language affect behavior. Adequate but with clear gaps for a 7-parameter mutation.
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 only 57%, and the description does not add meaning for the uncovered parameters. creative_id and adsquad are only implied through prose, while dry_run and name are undocumented in both the schema and the description — the missing dry_run guidance is particularly consequential for a create 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 ("Create an ad") plus the exact container ("in an ad squad from an existing creative"), which cleanly distinguishes it from snapchat_create_creative, snapchat_create_adsquad, and the read-only snapchat_ads/snapchat_creatives siblings it cites.
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 prerequisite chain clearly: the creative must already exist (see snapchat_creatives or snapchat_ads) and the ad lands inside an existing ad squad. It does not explicitly state when NOT to use it (e.g., when a duplicate would do), so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_create_adsquadCreate a Snapchat ad squadAInspect
Create an ad squad (PAUSED) inside a campaign: optimisation goal (e.g. PIXEL_ADD_TO_CART, PIXEL_PURCHASE, SWIPES), daily budget in account currency, bid strategy, targeting and placements. Pixel goals use the account's Pixel automatically unless pixel_id is given. Targeting can be copied from an existing ad squad with copy_targeting_from, or given as a Snap targeting object (geos[{country_code}], demographics[{min_age,max_age,gender}], devices[{os_type}], segments[{segment_id:[...]}]). Offer dry_run=true first.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | Devices to target (overrides copied targeting). Empty array = all devices. | |
| bid | No | Max bid / target cost in account currency (not for AUTO_BID). | |
| name | Yes | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| dry_run | No | ||
| campaign | Yes | Campaign name or ID. | |
| end_time | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| pixel_id | No | ||
| targeting | No | Snap targeting object. Ignored when copy_targeting_from is set. | |
| start_time | No | ||
| bid_strategy | No | Default AUTO_BID. | |
| daily_budget | Yes | ||
| optimization_goal | Yes | ||
| copy_targeting_from | No | Ad squad name or ID whose targeting and placements to copy. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare non-read-only, non-destructive, open-world. The description adds real behavior: the squad is created PAUSED so nothing spends, pixel goals auto-resolve to the account pixel unless pixel_id is given, and dry_run can be used as a pre-flight check. It stops short of saying what dry_run actually returns or whether the response includes the new ad squad ID.
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 dense sentences, front-loaded with the action and its default state, then targeting, then the dry_run recommendation. The parenthetical enumerations are compact and each carries distinct 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 16-parameter mutation tool with a nested targeting object and no output schema, the description covers the highest-risk semantics (PAUSED creation, targeting precedence, pixel resolution). The remaining gap is that it never describes what a successful call returns or how the created squad is identified.
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 56% schema coverage across 16 params, the description earns credit for decomposing the untyped `targeting` object into geos/demographics/devices/segments and for stating that budget and bid are in account currency and that pixel_id is only needed to override the default. Start_time, end_time, folder, language, and name remain undocumented in both places.
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?
Opens with a precise verb+resource+parent ('Create an ad squad (PAUSED) inside a campaign') and enumerates the dimensions it controls (goal, budget, bid strategy, targeting, placements). The default PAUSED state and the 'inside a campaign' containment cleanly separate it from snapchat_create_campaign and snapchat_launch_campaign.
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 a concrete recommended workflow ('Offer dry_run=true first') and explains the two targeting paths (copy_targeting_from vs an inline Snap targeting object). It does not state when to prefer this over snapchat_launch_campaign or snapchat_duplicate, so routing between creation tools is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_create_campaignCreate a Snapchat campaignAInspect
Create a Snapchat campaign (PAUSED) with an objective. Optionally a campaign daily budget / lifetime spend cap. Then add ad squads with snapchat_create_adsquad and ads with snapchat_create_ad, or use snapchat_duplicate to copy an existing campaign. Offer dry_run=true first.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| dry_run | No | ||
| end_time | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| objective | Yes | ||
| start_time | No | ISO 8601. Default: now. | |
| daily_budget | No | Optional campaign daily cap in account currency. | |
| lifetime_spend_cap | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, open-world behavior. The description adds genuinely new traits: campaigns are created in PAUSED state (so nothing serves until explicitly activated) and a dry_run preview mode is available. It does not mention account/permission requirements or what the dry run returns, which keeps it 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?
Three tight sentences, front-loaded with the create action and the PAUSED default, then the optional budget, then the sequencing advice. Every clause carries information an agent needs; no filler or restatement of the title.
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 10-parameter mutation tool with no output schema, the description covers the critical unknowns: default paused status, optional budget fields, dry-run preview, and the downstream tool chain. Remaining gaps (return payload of a dry run, account/currency resolution) are minor rather than blocking.
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 50%, with name, dry_run, end_time, objective, and lifetime_spend_cap undocumented in the schema. The description recovers meaning for objective, the two budget fields, and dry_run's preview intent, but says nothing about name constraints, end_time, start_time, language, folder, or account selection. That is useful but partial compensation.
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 ('Create a Snapchat campaign') and immediately adds the key qualifier that it is created PAUSED with an objective. It also names the follow-on siblings (snapchat_create_adsquad, snapchat_create_ad, snapchat_duplicate), so an agent can place it in the workflow without opening any 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 routing guidance: use this to create, then snapchat_create_adsquad and snapchat_create_ad for children, or snapchat_duplicate to copy an existing campaign, plus the instruction to offer dry_run=true first. It does not contrast with snapchat_launch_campaign, which is the nearest ambiguous alternative, so the when-not case is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_create_creativeCreate a Snapchat creativeAInspect
Create a creative from an attached file (media_id), a public URL or a Snap media ID: headline (max 34 characters), website URL with call to action (or no URL for a plain Snap ad). Uses the account's Public Profile automatically. Then use snapchat_create_ad.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Website (https). Overrides the default. | |
| name | No | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| headline | Yes | ||
| language | No | Language of the card: the language the user is writing in. | |
| media_id | No | File attached in the Go Shift chat (from the [attachment … media_id=…] marker). | |
| media_url | No | Public https link to an image/video instead of media_id. | |
| brand_name | No | ||
| profile_id | No | ||
| creative_id | No | Reuse an existing creative instead. | |
| snap_media_id | No | Media already in Snapchat. | |
| call_to_action | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-read-only, open-world, non-destructive write, and the description adds one genuine behavioral fact: the account's Public Profile is applied automatically, plus that url "overrides the default". It does not disclose permissions needed, whether repeated calls create duplicates, validation failure modes (e.g. headline length rejection), or what is returned for chaining into snapchat_create_ad.
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 with the media-source options and the sequencing call-to-action front-loaded; nothing is filler. The colon-and-parenthetical style is dense but readable and every clause carries 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 13-parameter mutation tool with no output schema, the description covers the primary creation flow and the handoff to snapchat_create_ad, which is the critical path. It leaves secondary parameters (account selection, folder, language, brand_name, profile_id) and the returned identifier unexplained, so an agent still needs the schema and trial for those.
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 62% schema coverage across 13 parameters, the description meaningfully disambiguates the mutually exclusive media inputs (media_id from chat attachment, media_url, snap_media_id) and restates the 34-character headline limit and the URL/CTA vs plain-Snap-ad choice. It adds no meaning for name, folder, account, language, brand_name, or creative_id, which remain schema-only or undocumented.
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 ("Create a creative") and immediately enumerates the three supported media sources: attached file via media_id, public URL, or Snap media ID. It also names the follow-on tool snapchat_create_ad, so an agent can place it in the campaign-build sequence and distinguish it from snapchat_creatives (listing) and snapchat_create_ad (ad creation).
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 states the next step ("Then use snapchat_create_ad") and clarifies the no-URL path as "a plain Snap ad", which is real when-to-use guidance. It stops short of saying when to prefer media_id vs media_url vs snap_media_id vs the reuse path (creative_id), leaving that inference to the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_creativesSnapchat creativesBRead-onlyInspect
Creatives in the ad account (ID, name, type, headline, brand name, call to action, website) to reuse in new ads.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| search | No | Filter by name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true. The description adds the returned fields and reuse context, but it does not disclose list behavior, pagination, limits, or whether all creatives are returned.
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?
A single compact sentence with no filler; the field list is presented parenthetically. It is slightly fragmentary but front-loads the resource and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with rich schema and annotations, the description supplies the resource, purpose, and returned fields. It still omits pagination/limit behavior and does not clarify whether results are scoped to the account or folder beyond what the schema says.
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 description coverage, the four parameters are already documented in the schema. The description only echoes the ad-account scope and adds no syntax or selection semantics for folder, search, account, or language.
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 resource (creatives) and the fields returned, and the phrase 'to reuse in new ads' distinguishes it from creation tools like snapchat_create_creative. However, it does not explicitly say 'list' or name the sibling, 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?
It implies usage by saying the creatives are 'to reuse in new ads,' which points to selecting an existing creative. It does not state when not to use it or name snapchat_create_creative as the alternative for new creative creation, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_duplicateDuplicate a Snapchat campaign with a new goalAInspect
Copy a Snapchat campaign into a NEW campaign (PAUSED): same ad squad targeting (audiences, countries, ages, devices) and placements, same ads/creatives (optionally different devices via os), with a new objective, optimisation goal, daily budget and bid strategy. Works from Reach & Frequency campaigns too (the booking settings are dropped; only targeting, placements and creatives are copied). Use for 'make a sales campaign with the same ads and audience as campaign X'. Always run dry_run=true first and show the plan.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | Devices to target (overrides copied targeting). Empty array = all devices. | |
| bid | No | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| dry_run | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| new_name | Yes | ||
| pixel_id | No | ||
| objective | Yes | ||
| bid_strategy | No | ||
| daily_budget | Yes | Daily budget per new ad squad, account currency. | |
| only_active_ads | No | Copy only ads that are ACTIVE in the source. Default true. | |
| source_campaign | Yes | Campaign name or ID to copy. | |
| optimization_goal | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the new campaign is created PAUSED, that R&F booking settings are dropped, and that only targeting, placements and creatives are copied. It also mandates a dry-run planning step, which is important behavioral context for a mutating 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 dense but well structured: it leads with the core copy behavior, then lists what is preserved vs replaced, then states the required dry-run workflow. It is appropriately sized for a complex duplication tool without excessive filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutating tool with 14 parameters and no output schema, the description covers the critical behavioral facts: paused output, copied fields, dropped R&F booking settings, and mandatory dry-run planning. The main remaining gap is that several optional parameters are not explained, but the core duplication contract is clear.
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 description adds meaning for several parameters, notably that os can override copied targeting, that budget is per new ad squad, and that the objective/optimization goal/bid strategy are replaced. However, with only 50% schema description coverage across 14 parameters, it leaves account, folder, language, pixel_id, only_active_ads, and new_name largely undocumented in both schema and description.
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: it copies a Snapchat campaign into a new paused campaign. It clearly distinguishes duplication from creation by describing exactly what is copied and what is replaced with new values.
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 a concrete usage example ('make a sales campaign with the same ads and audience as campaign X') and a required workflow step ('Always run dry_run=true first'). It also explains the Reach & Frequency edge case, though it does not explicitly name when to choose this over snapchat_create_campaign or snapchat_launch_campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_launch_campaignBuild a full Snapchat campaign in one stepAInspect
Build a complete Snapchat campaign in ONE call: campaign + ad squad (goal, daily budget, bidding, targeting) + one ad per item in ads (uploads attached files, creates creatives). Everything is created PAUSED. Targeting: countries/ages/gender/os/audience segments, or copy_targeting_from an existing ad squad, or copy_from_campaign to reuse a whole campaign's setup with new files (no need to read its settings first). Prefer this over the step-by-step tools. Always call with dry_run=true first, show the plan, then call again with dry_run=false after the user agrees; turning it on later needs snapchat_set_status + confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | ||
| ads | Yes | ||
| bid | No | ||
| url | No | Default website for all ads (https). | |
| name | No | ||
| folder | No | Client folder name. | |
| gender | No | ||
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| dry_run | No | ||
| max_age | No | ||
| min_age | No | ||
| end_time | No | ||
| headline | No | Default headline. | |
| language | No | Language of the card: the language the user is writing in. | |
| pixel_id | No | ||
| segments | No | Audience (segment) IDs to include. | |
| countries | No | ISO codes, default SA. | |
| objective | No | Default SALES. | |
| brand_name | No | ||
| profile_id | No | ||
| start_time | No | ||
| bid_strategy | No | ||
| daily_budget | No | Account currency. | |
| call_to_action | No | ||
| optimization_goal | No | ||
| copy_from_campaign | No | Campaign name or ID to copy from: targeting, placements, goal, daily budget, Pixel, website, call to action, headline and profile. Use for 'same as campaign X but with this video'. Anything else you pass overrides it. | |
| copy_targeting_from | No | Ad squad name or ID to copy targeting and placements from. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond readOnlyHint=false/openWorldHint=true: it discloses the resulting state of every created entity ("Everything is created PAUSED"), the side effect that attached files are uploaded and creatives generated, and the required human-confirmation gate before going live. It also clarifies override precedence for copy_from_campaign, which is a behavioral contract, not just a parameter name.
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 what gets built, then targeting options, then the preference rule and the dry-run workflow — a sensible order with no filler sentences. It is dense and parenthetical-heavy, but nearly every clause carries decision-relevant 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 27-parameter, no-output-schema orchestration tool this covers the essentials: what is created, default paused state, targeting shortcuts, copy semantics, and the two-phase dry-run protocol. Return values are implied by "show the plan," and with no output schema an agent mostly needs the call sequence and side-effect profile, both of which are present.
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 only 41% across 27 parameters, so the description does real work on the highest-risk ones: it enumerates the targeting dimensions (countries/ages/gender/os/audience segments), explains that ads drives one ad per item with media/creative reuse, and defines copy_from_campaign's scope plus override semantics. It does not add meaning for bid, bid_strategy, optimization_goal, daily_budget, account, profile_id or the time fields, leaving those to bare schema names and enums.
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 a decomposed resource set: "campaign + ad squad (goal, daily budget, bidding, targeting) + one ad per item in ads (uploads attached files, creates creatives)." An agent can immediately distinguish it from the granular siblings snapchat_create_campaign, snapchat_create_adsquad and snapchat_create_ad.
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 routing rule ("Prefer this over the step-by-step tools") and a mandatory operating procedure ("Always call with dry_run=true first, show the plan, then call again with dry_run=false after the user agrees"). It also names the follow-up path for going live ("turning it on later needs snapchat_set_status + confirmation") and spells out the two copy alternatives, including when copy_from_campaign is preferable ("no need to read its settings first").
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_performanceSnapchat Ads performanceARead-onlyInspect
Snapchat Ads dashboard: spend, results (purchases + sign-ups from the Snap Pixel), cost per result, swipes (clicks), impressions, purchase value and ROAS with change vs the previous period, a daily trend and a per-campaign breakdown. Shown as an interactive dashboard; summarise instead of repeating every number.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in. | |
| date_range | No | Default LAST_30_DAYS (max 31 days). | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the output is an interactive dashboard, it includes period-over-period change, a daily trend and a per-campaign breakdown, and it should be summarised rather than recited. That output-shape disclosure matters because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first front-loads the metric inventory, the second sets the presentation expectation. Every clause carries information and there is no filler, though the metric list is dense enough that it reads as a 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 seven optional parameters, no output schema and no required fields, the description carries the burden of telling the agent what comes back, and it does so thoroughly (metric set, comparison period, trend, campaign breakdown, dashboard format). The only gap is routing guidance against the many adjacent Snapchat reporting siblings, which the description leaves unaddressed.
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 enum parameters (detail, date_range, language) already carry explicit guidance including the LAST_30_DAYS default and the 31-day cap. The description adds no syntax, format or scoping detail beyond the schema, so the baseline of 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 a specific resource (Snapchat Ads dashboard) and enumerates the metrics it returns: spend, results, cost per result, swipes, impressions, purchase value, ROAS, change vs previous period, daily trend and per-campaign breakdown. That is far more specific than a name restatement. It does not explicitly differentiate itself from sibling reporting tools such as snapchat_breakdown or snapchat_campaigns, which keeps it out of 5 territory.
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 a presentational instruction ('summarise instead of repeating every number'), and the schema's detail enum supplies the summary-vs-full decision rule. However, it never says when to choose this dashboard over snapchat_breakdown, snapchat_campaigns or snapchat_ads, so the agent must infer the boundary from the sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_pixelsSnapchat PixelsCRead-onlyInspect
Snap Pixels on the ad account with ID and status. Pixel goals (purchase, add to cart, sign-up, page view) need a pixel_id.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, non-destructive, open-world operation, so the description only needs to add context. It does add that pixel ID and status are the relevant data, but it does not explain what is returned beyond that or how the account/folder scoping behaves.
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?
It is short, but the opening is awkward and the second sentence about pixel goals is not clearly tied to this tool's behavior. Some wording does not earn 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 read-only pixel-listing tool with complete schema coverage and annotations, the description should at least clearly say it lists pixels and their statuses. Instead, it introduces an undocumented pixel_id requirement and leaves the actual retrieval behavior underspecified.
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 folder, account, and language. The description instead introduces a 'pixel_id' that is not a parameter in the schema, which is misleading and adds confusion rather than 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?
The description never states a clear verb such as 'list' or 'get'; 'Snap Pixels on the ad account with ID and status' reads as a restatement of the title rather than a definition of the action. An agent can infer it retrieves pixel IDs and statuses, but the purpose is not stated unambiguously.
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?
There is no guidance on when to use this tool, what prerequisites exist, or how it relates to sibling Snapchat tools. The note that pixel goals need a pixel_id does not explain where to obtain one or whether this tool supplies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_removeDelete a Snapchat campaign, ad squad or adADestructiveInspect
Delete a campaign, ad squad or ad. Requires the user's explicit yes: call first without confirm to preview, then with confirm=true and confirm_name equal to the exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| id_or_name | Yes | ||
| confirm_name | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, openWorldHint=true and readOnlyHint=false, so the safety profile is known. The description adds genuinely non-redundant behavior: a mandatory dry-run preview pass and an exact-name confirmation gate as a guard against accidental deletion. It omits whether deletion is reversible and whether removing a campaign cascades to its ad squads and ads, which would be valuable for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both load-bearing, with the destructive action stated first and the confirmation protocol immediately after. No filler or repetition of the title.
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 7-parameter destructive tool with no output schema and 43% schema coverage, the confirmation workflow is captured but material gaps remain: what the preview pass returns, how id_or_name resolves names vs IDs per level, and cascade/irreversibility semantics. Adequate for safe invocation, but not fully self-contained.
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 only 43%, and the description compensates well for the two most dangerous parameters — confirm and confirm_name — explaining their interaction and the exact-match requirement that the schema leaves undocumented. However, it says nothing about level, id_or_name, folder, account or language, leaving half the parameter surface to inference.
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 set — 'Delete a campaign, ad squad or ad' — matching the level enum exactly and clearly distinguishing this from sibling mutation tools like snapchat_set_status (pause) or snapchat_rename. An agent can identify the operation 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?
It gives explicit procedural guidance: call first without confirm to preview, then call again with confirm=true and confirm_name matching the exact name. That is a clear when/how-to-use recipe. It stops short of naming alternatives (e.g., 'use snapchat_set_status to pause instead of permanently deleting'), so exclusion guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_renameRename a Snapchat campaign, ad squad or adCDestructiveInspect
Rename a campaign, ad squad or ad.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in. | |
| new_name | Yes | ||
| id_or_name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the agent knows this mutates live ad entities. The description adds nothing beyond that: it does not say whether the old name is recoverable, whether the change is logged or audited, what happens if id_or_name is ambiguous, or whether permission scopes are required.
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?
A single front-loaded sentence with zero waste, but what is there is essentially a restatement of the title plus an enumeration of the level enum. It is short rather than efficient, since the brevity comes at the cost of missing 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?
This is a destructive write operation with no output schema and half of its parameters undocumented, so the description carries a heavy burden and does not meet it. An agent cannot tell from the definition how to resolve the target entity or what the response will confirm.
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?
Six parameters with only 50% schema description coverage, and the description contributes nothing for any of them. In particular id_or_name is entirely unexplained (is it an ID, a name, or either? does it accept partial matches?), and the optional folder/account scoping parameters go unmentioned.
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 (Rename) and the three resource levels it operates on (campaign, ad squad, ad), so the operation itself is unambiguous. However, it does not identify the platform as Snapchat in the description text, which matters given the sibling tools meta_rename and tiktok_rename that share the same verb.
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?
Contains no when-to-use or when-not-to-use guidance, and never routes the agent to an alternative such as snapchat_set_status or snapchat_duplicate. Prerequisites like needing a folder or ad account selected are not mentioned at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_set_campaign_statusPause or turn on a Snapchat campaignADestructiveInspect
Pause a Snapchat campaign (immediate), or turn one on. Turning on spends money: the first call returns a preview; call again with confirm=true only after the user says yes.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| status | Yes | ||
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| campaign_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and openWorldHint=true, so the description could have coasted. Instead it adds the two things an agent cannot infer: that activation spends real money and that the operation is two-phase (preview, then confirm=true after the user says yes). That is exactly the extra behavioral context the annotations lack.
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 sentences, no filler. The safety-critical information (activation spends money, confirmation protocol) is placed second only after the basic purpose, and every clause carries actionable content.
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 destructive, money-affecting mutation with no output schema, the definition covers the essential safety protocol and warns about the preview step. It stops short of describing what the preview contains or whether a paused campaign restores prior budget/schedule on reactivation, which would help an agent set expectations.
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?
At 50% schema coverage, the description supplies the critical missing meaning for the undocumented 'confirm' boolean and the money-spending consequence of status=ACTIVE. The remaining undocumented parameters (campaign_id, status enum) are self-evident, and account/folder/language already carry schema descriptions, so the gap is minor.
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 (pause / turn on) against a specific resource (a Snapchat campaign) and names the two resulting states. The campaign scope in the name implicitly separates it from the generic snapchat_set_status sibling, though the description never says so explicitly.
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: pausing is immediate, whereas turning on requires a preview first and a second confirm=true call only after explicit user approval. It does not state when to reach for a sibling (e.g. snapchat_set_status for ads or ad squads), but the when-to-use condition for its own two modes is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_set_statusPause or turn on a Snapchat campaign, ad squad or adADestructiveInspect
Pause runs immediately. Turning on starts spending: the first call returns a preview; call again with confirm=true only after the user says yes. A child only delivers when its campaign and ad squad are also on. include_children=true (with a campaign or ad squad) applies the same status to everything inside it in one step — use it to launch a new campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | campaign, adsquad (ad set) or ad. | |
| folder | No | Client folder name. | |
| status | Yes | ||
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| id_or_name | Yes | ||
| include_children | No | Also set every ad squad and ad inside (campaign) or every ad inside (ad squad). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses the critical two-step activation flow (first call returns a preview, second call with confirm=true actually spends), that pausing is immediate, and the delivery dependency where a child only serves when its campaign and ad squad are on. These are exactly the behavioral facts an agent needs before mutating spend.
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 irreversible action (pause is immediate) and the spend-gating confirm flow, then the cascade option. No filler or restatement of the title.
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 destructive mutation tool with no output schema, the description covers the safety-critical path (preview/confirm), the cascade semantics, and the delivery precondition. The remaining gap — what the preview response looks like — is minor given the annotations already flag destructiveness.
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 63%, so several parameters are undocumented structurally, but the description compensates for the two riskiest ones: confirm (only after user consent) and include_children (cascades the same status to all children, only valid with campaign or ad squad). It adds nothing for folder, account, or language 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 names the specific operation (pause / turn on) and the resources affected (campaign, ad squad, ad), with the level enum reinforcing scope. It does not, however, distinguish itself from the sibling snapchat_set_campaign_status, which appears to overlap for the campaign case, leaving an agent to infer which to pick.
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 situational guidance: use include_children 'to launch a new campaign', and only call with confirm=true after the user agrees. What is missing is explicit routing versus the sibling snapchat_set_campaign_status and versus snapchat_launch_campaign for new campaigns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_update_bidChange a Snapchat bidADestructiveInspect
Change an ad squad's bid strategy and/or bid (max bid or target cost, account currency). Raising a bid or moving to AUTO_BID returns a preview and needs confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| bid | No | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| adsquad | Yes | ||
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| bid_strategy | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a destructive, non-read-only, open-world mutation, so the bar is lower. The description still adds real behavioral context the annotations cannot: the preview-and-confirm two-step protocol for bid increases and AUTO_BID moves, and the account-currency unit convention for bid values. It stops short of saying whether changes are reversible or what the preview payload contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, front-loaded with what changes and immediately followed by the confirm requirement. The parenthetical units note is dense and earns its space.
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 destructive mutation with no output schema, the description covers the safety-critical part (confirm gating) and the value semantics (currency). Remaining gaps — which fields are required, whether a preview is always returned, and the effect of omitting bid_strategy — are moderate but not blocking for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 43%, so the description must carry more weight. It does explain 'bid' (max bid or target cost, in account currency), implies the bid_strategy values via AUTO_BID, and defines the confirm flag's trigger condition — but folder, account, adsquad, and language are left entirely to the schema. Meaningful compensation, but incomplete for seven parameters.
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?
Names a specific verb (change) and a specific resource pair (bid strategy / bid) on an ad squad, and clarifies the units (max bid or target cost, account currency). It is clearly distinct from sibling mutations like snapchat_update_budget or snapchat_update_schedule, though it never explicitly names those 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?
Provides one concrete usage rule — raising a bid or switching to AUTO_BID returns a preview and requires confirm=true — which tells the agent how to complete the two-step flow. However, it gives no guidance on when to prefer this tool over snapchat_update_budget or snapchat_create_adsquad, and no exclusions or prerequisites beyond the confirm gate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_update_budgetChange a Snapchat budgetADestructiveInspect
Change the daily budget (or lifetime budget if that is what is set) of an ad squad, or a campaign's daily cap, in account currency. Decreases run immediately; increases return a preview and need confirm=true after the user's yes.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| budget | Yes | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| id_or_name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds the crucial asymmetry the agent cannot get from annotations: decreases apply immediately while increases are staged behind a preview plus confirm=true. It also notes the value is in account currency, which affects how the agent should phrase the request. It does not state reversibility, required permissions, or what the preview card contains.
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 compact sentences, front-loaded with the resource and scope, then the operational caveat. No filler or repetition; the parenthetical about lifetime budget is slightly dense but earns its place by preventing a wrong assumption.
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 destructive, 7-parameter mutation with no output schema, the definition covers the two most important things an agent needs (level semantics and the preview/confirm flow). Gaps remain: how `id_or_name` resolves, what the preview returns, and how folder/account scoping interacts with account selection are all unaddressed.
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 only 43%, so the description has to carry weight: it does explain the semantics of `budget` (daily vs lifetime vs campaign cap, currency) and `confirm`, and implicitly the `level` enum. It says nothing about `id_or_name` (ID vs name matching), `folder`, `account`, or `language`, leaving four of seven parameters undocumented in both places.
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 (change budget) and disambiguates what 'budget' means at each level: adsquad daily/lifetime budget vs campaign daily cap, in account currency. That level-specific framing matches the `level` enum and separates it from bid/status siblings conceptually, though it never names an alternative tool such as snapchat_update_bid.
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 second sentence gives real invocation guidance for the increase path (preview first, then confirm=true after the user's yes), which is genuinely useful. However there is no guidance on when to reach for this versus snapchat_update_bid, budget_status, or google_ads_update_budget, so routing between siblings is still left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_update_scheduleChange Snapchat start/end datesADestructiveInspect
Set the start and/or end time (ISO 8601) of a campaign or ad squad. clear_end=true removes the end date (runs until paused) and needs confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| confirm | No | ||
| end_time | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| clear_end | No | ||
| id_or_name | Yes | ||
| start_time | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is known; the description adds value beyond that by disclosing the ISO 8601 format requirement and the confirm=true gate tied to clear_end. It still doesn't say whether confirm is needed for ordinary date changes, how existing schedules are overwritten, or any timezone handling – gaps that matter for a destructive mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and followed by the single non-obvious rule. Every clause earns its place and there is no redundant restatement of the title or annotations.
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 9-parameter destructive mutation with no output schema, the description covers the biggest trap (clearing an end date without confirm) but omits target resolution (id_or_name plus level/folder/account) and the result of the call. Adequate but with clear gaps an agent would have to guess at.
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 only 33%, so the description must carry weight; it explains start_time/end_time format and the clear_end/confirm interplay well, but the two required parameters (level, id_or_name) and how folder/account disambiguate the target are left entirely to the schema. Partial compensation justifies the baseline 3 rather than higher.
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 ("Set") and resource ("start and/or end time ... of a campaign or ad squad"), which cleanly separates it from sibling mutators like snapchat_update_budget, snapchat_update_bid, and snapchat_rename. It does not name any sibling explicitly, 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 clear_end sentence implies a usage condition ('removes the end date – runs until paused') and gates it on confirm=true, which is genuinely actionable. However there is no explicit statement of when to use this versus pausing (snapchat_set_status) or removing (snapchat_remove), and no prerequisites or scope caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_update_targetingChange Snapchat ad squad targetingADestructiveInspect
Change an ad squad's targeting. Pass only what changes: countries (ISO codes), min_age/max_age, gender, os (iOS/ANDROID/WEB), add or remove audience segment IDs; or a full Snap targeting object to replace it. Widening the audience returns a preview and needs confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| os | No | Empty array = all devices. | |
| folder | No | Client folder name. | |
| gender | No | ||
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| adsquad | Yes | ||
| confirm | No | ||
| max_age | No | ||
| min_age | No | ||
| language | No | Language of the card: the language the user is writing in. | |
| countries | No | ||
| targeting | No | Full replacement targeting object. | |
| add_segments | No | ||
| remove_segments | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true; the description adds genuinely new behavior: partial-merge semantics, full-replacement overwrite semantics for the targeting object, and the fact that widening the audience returns a preview gated by confirm=true. It does not spell out that a full replacement discards existing targeting or what permissions are required, leaving some risk unstated.
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 dense sentences, front-loaded with the action and the most consequential rule (partial vs. full replacement). Every clause carries information an agent needs; there is no filler or restatement of the title.
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 destructive 13-parameter mutation with a nested object and no output schema, the description covers the mechanics that matter: incremental vs. replacement, and the preview/confirm gate on widening. It is slightly incomplete on account/folder scoping and on what the non-preview response contains.
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 only 38%, so the description must carry weight, and it does for the core fields: countries are ISO codes, os takes iOS/ANDROID/WEB, add_segments/remove_segments are additive/subtractive audience IDs, and targeting is a full replacement. It leaves account, folder, language, and adsquad undocumented, which is a real gap at 13 parameters.
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 ('Change an ad squad's targeting') that cleanly separates it from sibling tools like snapchat_create_adsquad, snapchat_update_bid, and snapchat_update_schedule. It also enumerates the targetable fields, so an agent knows exactly what kind of change this tool performs without opening 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?
'Pass only what changes' vs. 'a full Snap targeting object to replace it' gives explicit guidance on the two operating modes and when to pick each. It also states the precondition for the preview path (widening needs confirm=true). It stops short of naming alternative tools or stating when not to use this one, so it falls just under a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_upload_mediaUpload an image or video to SnapchatAInspect
Upload a file to a Snapchat ad account: media_id (a file the user attached in the Go Shift chat) or a public https URL. Returns the Snap media ID. Usually not needed: snapchat_create_creative and snapchat_launch_campaign upload automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| name | No | ||
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in. | |
| media_id | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the write/open-world/non-destructive profile, so the description adds real value: it discloses the accepted input sources (an attached chat file via media_id, or a public https URL) and the return value (the Snap media ID). It does not mention format/size limits, whether the asset persists in the ad account library, or any auth/account-scoping requirement, which are the remaining behavioral gaps for a media mutation.
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 purpose and source options before the routing hint. Every clause carries information an agent needs; nothing is 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?
No output schema exists, and the description correctly covers the return value and the source options, so the basics are complete. For a zero-required-parameter write tool it should still resolve source precedence and mention constraints such as media type or file limits, which it does not.
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 50%, and the description does add meaning for the two most consequential parameters (media_id as an attached chat file, url as a public https endpoint). However, it never clarifies that url and media_id are alternative sources or which takes precedence, and it says nothing about name, folder, account, or the 'language of the card' enum, all of which remain ambiguous for a media upload.
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 ('Upload a file to a Snapchat ad account') and immediately clarifies the two accepted source forms. It also names the sibling tools that make it redundant, so an agent can distinguish it from snapchat_create_creative and snapchat_launch_campaign without opening any 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 an explicit 'usually not needed' exclusion plus the two alternatives that handle uploads automatically, which is strong routing guidance. It stops short of stating the positive case (e.g., pre-uploading assets for later reuse in a creative or ad squad), leaving the agent to infer when this tool is actually the right call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
snapchat_wasted_spendSnapchat wasted spendARead-onlyInspect
Use this when the user asks which Snapchat ads are wasting money. Returns ads that spent with zero results, ads whose cost per result is far above their ad squad's average, and ads with a very low swipe rate. Results follow each ad squad's goal (purchases, add to cart, sign-ups, swipes and so on). Read-only: it only suggests which ads to pause. Default period: last 14 days, active campaigns.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | Snapchat ad account name or ID. Optional when only one is enabled. | |
| campaign | No | Limit to one campaign (name or ID). | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in. | |
| date_range | No | Preset period. Default LAST_14_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint=false, but the description adds real value: it explains that findings follow each ad squad's goal, that the tool only suggests pausing rather than acting, and what the default time window and campaign scope are. It stops short of describing result limits, ranking, or output shape, which is the remaining gap.
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?
Four short sentences, front-loaded with the trigger, then the return criteria, then the safety note and defaults. Nothing is redundant with the schema beyond a minor restatement of the default period.
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 seven-parameter read-only analysis tool with no output schema, the description covers trigger, detection logic, goal-dependence, and default scope. What an agent might still want — how many ads come back, ordering, or the card contents — is unstated but not essential to calling 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 coverage is 100%, so all seven parameters are already documented, and the description mostly restates the LAST_14_DAYS default already present in the date_range schema. It does contribute one non-schema default (active campaigns only), but adds no syntax or interaction detail for folder/account/campaign or the start/end date pair.
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 ('which Snapchat ads are wasting money') and enumerates the three detection criteria: zero-result spend, cost per result far above the ad squad average, and very low swipe rate. The Snapchat prefix and ad-level granularity clearly separate it from snapchat_performance and the other platforms' *_wasted_spend 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?
Opens with an explicit trigger ('Use this when the user asks which Snapchat ads are wasting money') and adds a default scope of last 14 days on active campaigns. It does not name an alternative for adjacent questions (e.g., ad-squad-level or campaign-level diagnostics), so routing is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_adgroupsTikTok ad groupsBRead-onlyInspect
Ad groups with status, optimisation goal, budget, bid, placements, schedule and period performance. Filter by campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| status | No | ||
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| campaign | No | Campaign name or ID. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, openWorld, and non-destructive behavior. The description adds the data sections returned and the campaign filter, but it does not cover freshness, pagination, or how detail=summary vs full changes output, so it adds only moderate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact, front-loaded sentence with no filler. It could be slightly more complete, but every phrase maps to the resource or returned data.
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 9-parameter reporting tool with no output schema, the description gives a useful field list but omits the summary/full default behavior and the date/account/folder context. The schema handles most parameter meaning, but the description leaves some gaps about output shape and intended granularity.
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 89%, so the schema already defines most parameters. The description only reinforces the campaign filter and lists return fields, adding little semantic detail 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 identifies the exact resource (TikTok ad groups) and enumerates the fields returned, so the agent knows this is a read/list tool for ad-group data. It does not explicitly contrast with sibling tools such as tiktok_campaigns or tiktok_ads, so it stops short of full 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?
The only usage hint is 'Filter by campaign,' which points at one parameter but does not explain when to choose this tool over tiktok_campaigns, tiktok_ads, or tiktok_performance. No when-not-to-use conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_adsTikTok adsBRead-onlyInspect
Ads with status (including review/rejection), ad text, call to action, landing page and period performance. Filter by campaign or ad group.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| status | No | ||
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| adgroup | No | ||
| campaign | No | ||
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful return-shape context - that status surfaces review/rejection states and that each ad carries text, CTA, and landing page alongside period metrics. It says nothing about pagination, result caps, or account scoping behavior, which matters for a 10-parameter listing tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clipped sentences, front-loaded with what the tool returns before the filtering note. No filler. The telegraphic style is slightly terse ('Ads with status...') but every clause carries content.
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 10-parameter, zero-required, no-output-schema listing tool, the description covers the returned fields but omits how results are scoped (account/folder defaults), what 'period performance' means without a date range, and how summary vs full detail changes output. The schema's own descriptions patch some of this, leaving the definition adequate but not complete.
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 70%, so most parameters are already documented in the schema (detail, folder, account, language, date_range, dates). The description adds meaning only for the two filter parameters (campaign, adgroup) and implicitly for status by noting review/rejection values. It does not explain the status enum, detail modes, or date-range defaults beyond what the schema states, so it is roughly at the 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 names the resource (TikTok ads) and enumerates what the rows carry: status including review/rejection, ad text, call to action, landing page, and period performance. That is more specific than the bare title. It does not differentiate itself from close siblings such as tiktok_performance or tiktok_creative_insights, 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?
'Filter by campaign or ad group' hints at how to narrow results but gives no when-to-use condition or when-not. With siblings like tiktok_performance, tiktok_breakdown, and tiktok_creative_insights overlapping heavily, an agent gets no routing signal for choosing this tool over those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_audiencesTikTok audiencesCRead-onlyInspect
Custom and lookalike audiences in the account with type, size and status.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered externally. The description adds a modest amount by stating that returned entries carry type, size and status, giving a partial picture of what the response contains. It says nothing about result volume, pagination, or whether empty/zero-size audiences are included, so the added behavioral context is thin.
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?
A single short sentence with no filler, leading with the resource. It is efficient and front-loaded, though the absence of a verb makes it slightly less immediately actionable than a 'list X' phrasing would 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?
For a zero-required-parameter read tool with full schema coverage and no output schema, the description should at minimum describe the shape of what comes back; it mentions type/size/status but not the record structure, counts, or whether custom and lookalike audiences are returned together. Adequate to call correctly, but not complete for interpreting results.
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 every parameter (detail, folder, account, language) is fully documented in the schema, including enum meanings. The description adds no parameter meaning beyond that, which is acceptable at the baseline of 3 when the schema does the heavy lifting.
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 resource (custom and lookalike audiences in the account) and the fields surfaced (type, size, status), which tells an agent this is a retrieval tool. But it is a verb-less fragment: it never says whether it lists, retrieves, or analyzes audiences, and it gives no differentiation from parallel audience tools such as meta_audiences or snapchat_audiences.
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?
There is no when-to-use guidance at all — nothing about when to prefer this over other audience or reporting tools, no prerequisites about account/folder selection, and no note that this is read-only enumeration rather than audience creation. The only implied usage comes from the readOnlyHint annotation, not from the text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_breakdownTikTok breakdownBRead-onlyInspect
Break performance down by age, gender, country, platform (Android/iOS), network/connection or language. Optionally for one campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| campaign | No | ||
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| dimension | Yes | ||
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. Beyond that the description says nothing behavioural — not what the output card looks like, not that summary detail truncates rows, not any scoping or rate constraints. It adds essentially no context over 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?
Two short sentences, front-loaded with the resource and the dimensions, with the optional campaign scope last. No filler, no repetition of the title.
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 9-parameter reporting tool with no output schema, the description explains the core axis (dimension) and the optional campaign scope, which is the minimum an agent needs to pick and call it. It leaves open what metrics and row structure come back and how the detail/date_range controls interact, so it is adequate rather than complete.
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 78%, so the baseline is 3, and the description does add real meaning in two places: it expands 'platform' to Android/iOS and spells out the six allowed dimensions, and 'Optionally for one campaign' documents the campaign parameter's role as an optional filter, which the bare schema leaves undefined. It says nothing about detail, date_range, folder, account or language, but those are described 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?
The verb 'Break performance down by' plus the enumerated breakdown dimensions (age, gender, country, platform, network, language) states precisely what the tool returns, and the dimension list mirrors the enum so an agent can match intent quickly. It does not, however, name or contrast itself with near-siblings like tiktok_performance or tiktok_report_query, so the agent must infer the boundary.
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 only usage-shaped statement is 'Optionally for one campaign', which is a scoping detail rather than a when-to-use rule. There is no guidance on when a breakdown is preferred over tiktok_performance or tiktok_report_query, and no exclusions or prerequisites (e.g. account must be enabled, which dimension fits which question).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_campaignsTikTok campaignsBRead-onlyInspect
Campaigns with objective, status, budget, Smart+ flag and period spend/results. Use to find IDs before changes.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| status | No | Default all (not deleted). | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered without the description. The one useful addition is that the tool is intended for ID lookup ahead of edits, but there is no disclosure of pagination, output shape, or what 'period spend/results' actually looks like in the returned card.
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 sentences: the field inventory front-loads what you get, and the second sentence supplies the operational intent. Nothing is redundant, though the fragmentary style leaves the core verb implicit.
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 eight optional parameters and no output schema, the definition relies heavily on the schema text, which is thorough but does not describe what the returned campaign card contains at a structural level. The description covers intent adequately but underplays the folder, account, and date scoping that the parameters allow.
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, including the summary-vs-full detail enum, status values, date_range presets, and the account fallback rule, is documented within the schema itself. The description adds no meaning beyond it, which matches the baseline of 3 when the schema carries the full load.
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 lists the specific resource (TikTok campaigns) and the fields the tool surfaces (objective, status, budget, Smart+ flag, period spend/results), which is enough to distinguish it from tiktok_adgroups, tiktok_ads, and tiktok_performance. The verb is only implied by the bare noun phrase, so it is slightly less explicit than a full 'list campaigns' phrasing.
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?
'Use to find IDs before changes' gives a genuine when-to-use that fits the neighboring mutation tools (tiktok_set_status, tiktok_update_budget, tiktok_remove). It stops short, however, of naming alternatives for performance questions or of saying when-not to use it, so the guidance is implied rather than complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_create_adAdd an ad to a TikTok Smart+ ad groupAInspect
Create a PAUSED Smart+ ad in an existing ad group: one or more videos, texts, a call to action and a landing page (or instant form). Turning it on needs the user's confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| adgroup | Yes | Ad group name or ID. | |
| dry_run | No | ||
| form_id | No | ||
| ad_texts | Yes | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| video_ids | Yes | ||
| identity_id | Yes | ||
| identity_type | No | ||
| call_to_action | No | ||
| landing_page_url | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a non-read-only, open-world, non-destructive operation. The description adds important behavior beyond that: the ad is created PAUSED by default, and turning it on requires the user's confirmation. It still does not explain dry_run behavior or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words, front-loading the creation behavior and default paused state before the confirmation requirement. The structure makes the key operational facts easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter create tool with low schema description coverage and no output schema, the description is too thin. It covers the creative composition and paused default but omits required identity parameters and dry_run semantics, leaving the agent without enough guidance to 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 coverage is only 31%, so the description needs to carry more parameter meaning. It clarifies the creative content fields (videos, texts, call to action, landing page or instant form), but leaves critical required parameters such as identity_id and identity_type, plus dry_run and name, unexplained.
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: create a PAUSED Smart+ ad in an existing ad group. It also names the required creative composition, so the agent can distinguish this from upload, status, or campaign-creation 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 establishes a prerequisite that the ad group must already exist and notes that activation requires user confirmation. However, it does not name alternatives such as tiktok_upload_video for assets or tiktok_identities for identity IDs, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_create_campaignCreate a TikTok campaign (Smart+)AInspect
Create a complete TikTok campaign on the upgraded Smart+ API: campaign + ad group, and an ad when video_ids are given. Everything is created PAUSED. Goals: sales (website conversions with a Pixel event) or leads (instant form, a website form tracked by the Pixel, or a chat on WhatsApp, Messenger or TikTok direct messages). Targeting can be automatic (TikTok finds the audience) or manual (countries/locations, ages, gender, languages, custom audiences). Budget is daily or lifetime, at campaign level (TikTok distributes it) or ad group level. Always offer dry_run=true first and show the plan; turning it on later needs the user's confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| ages | No | ||
| goal | Yes | ||
| name | Yes | ||
| event | No | Pixel event to optimise for. Default purchase (sales) / submit_form (website leads). | |
| budget | Yes | In the account currency. | |
| folder | No | Client folder name. | |
| gender | No | ||
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| dry_run | No | ||
| form_id | No | Instant form page_id for lead_destination=instant_form. | |
| ad_texts | No | ||
| end_time | No | Optional 'YYYY-MM-DD HH:MM' in UTC; required for lifetime budgets. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| pixel_id | No | Pixel ID (numeric, from tiktok_tracking_audit). Required for sales and website leads. | |
| countries | No | Country codes, e.g. ["SA","AE"]. | |
| languages | No | Language codes, e.g. ["ar","en"]. | |
| targeting | No | Default automatic (TikTok's audience targeting, location still applies). | |
| video_ids | No | From tiktok_upload_video. TikTok rotates them automatically. | |
| placements | No | Default automatic. | |
| start_time | No | Optional 'YYYY-MM-DD HH:MM' in UTC. Default now. | |
| budget_type | No | Default daily. | |
| identity_id | No | From tiktok_identities; needed to create the ad. | |
| audience_ids | No | ||
| bid_cost_cap | No | Optional target cost per result (cost cap). Omit for maximum delivery. | |
| budget_level | No | campaign = TikTok distributes it (default). | |
| location_ids | No | Extra location IDs from tiktok_search_locations. | |
| identity_type | No | ||
| call_to_action | No | ||
| whatsapp_number | No | For whatsapp: the WhatsApp Business API number in international format, e.g. +9665XXXXXXXX. | |
| facebook_page_id | No | For messenger: the Facebook Page ID that receives the messages. | |
| landing_page_url | No | ||
| lead_destination | No | For goal=leads. instant_form needs form_id (see tiktok_lead_forms); website needs pixel_id and an event like submit_form; whatsapp needs whatsapp_number (a WhatsApp Business API number); messenger needs facebook_page_id; tiktok_dm sends people to the TikTok account's direct messages (needs a TikTok account identity). | |
| message_event_set_id | No | Optional messaging event set (from a TikTok Messaging Partner). With it the ad group optimises for conversations; without it, for clicks to chat. | |
| excluded_audience_ids | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavior beyond the annotations: everything is created PAUSED, so nothing spends until explicitly enabled, and the dry_run/confirm workflow is spelled out. The sales path requires a Pixel and event, and the leads path branches by destination, which tells the agent what side effects and prerequisites to expect from an openWorld write 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-loads the core action, then layers goal, targeting and budget, and ends with the safety workflow — a sensible order with little filler. It is dense, and the goal sentence partially duplicates what the lead_destination schema description already enumerates.
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 34-parameter composite creation tool with no output schema, the description covers scope, the paused state, prerequisite IDs (pixel, form, identity, video) and the dry-run contract. It omits what is returned (campaign/ad group IDs) and how partial failures behave, which are the remaining gaps.
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 68%, and the description adds conceptual meaning on top: what 'automatic' vs 'manual' targeting covers, that budget can be daily or lifetime and live at campaign or ad group level, and how goal values constrain which other parameters matter. Some of this restates the schema's own enum descriptions (targeting, lead_destination), so it is additive but not fully novel.
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?
Opens with a specific verb and resource ('Create a complete TikTok campaign') and immediately scopes it: campaign + ad group, plus an ad when video_ids are given. This distinguishes it from tiktok_create_ad and from the sibling list/read tools without needing 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 explicit operational guidance: always call with dry_run=true first, show the plan, and require user confirmation before a real launch. It also routes goal choice (sales vs leads) to the required supporting inputs. It stops short of naming when to use tiktok_create_ad or tiktok_campaigns instead, so it is clear context rather than full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_creative_insightsTikTok creative insightsARead-onlyInspect
Rank ads by efficiency: best and worst creatives by cost per result and CTR, with video hook rate (2s views / impressions) and completion rate.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value by defining the hook rate and completion rate formulas, which an agent cannot infer from structured fields. However, it says nothing about ranking window, how ties or low-volume creatives are handled, or whether the 'best/worst' selection is fixed-size.
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?
A single front-loaded sentence with the ranking action first, then the metrics, then the formula clarifications in parentheses. No filler, no restatement of the name or title.
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 read-only analytics tool with a fully documented 7-parameter schema and no output schema, the description covers what is measured and how two derived metrics are computed, which is enough to call it correctly. The minor gap is that the return shape of the ranked list (sections, row counts) is only hinted at through the 'detail' parameter rather than stated.
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 every parameter (detail, folder, account, dates, language) is already documented in the schema, and the description adds no parameter guidance of its own. Baseline 3 applies when the schema does the heavy lifting, and the metric definitions here relate to output rather than inputs.
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 and resource ('Rank ads by efficiency: best and worst creatives by cost per result and CTR') and explicitly defines the derived metrics (hook rate = 2s views / impressions, completion rate). This distinguishes it from siblings like tiktok_ads, tiktok_breakdown, and meta_creative_insights without opening a 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?
Usage is implied by the ranking framing — use this when the user wants to know which creatives are efficient or inefficient — but there is no explicit when-to-use or when-not guidance, and no mention of how it differs from tiktok_ads or tiktok_breakdown. The only routing guidance lives in the schema's 'detail' parameter description, not in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_identitiesTikTok identitiesBRead-onlyInspect
Identities (TikTok accounts or custom display names) the advertiser can run ads as. An identity is needed to create ads.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds the useful scoping fact that results are advertiser-bound identities usable for ad creation, but says nothing about result volume, pagination, or whether disabled identities are included — modest added value over 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?
Two short sentences with zero filler, and the definition of the resource is front-loaded before the usage hint. It is efficient, though the brevity borders on under-specification given the tool has three parameters.
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 at least hint at what comes back (identities with IDs usable in create calls), which it does only obliquely via "needed to create ads." Parameters and safety are fully covered elsewhere, so nothing critical is missing, but the return shape and the account-optional behavior are unexplained.
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 all three parameters (folder, account, language) are documented in the schema, including the enum semantics for language. The description contributes nothing about parameters, so the baseline 3 applies rather than a higher score.
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 resource precisely and even defines the term ("TikTok accounts or custom display names") plus its scope ("the advertiser can run ads as"), which is enough to distinguish it from siblings like tiktok_campaigns or tiktok_audiences. The only gap is that the verb is implicit — it never says list/retrieve, so an agent infers a read from the noun phrase and annotations.
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?
"An identity is needed to create ads" implies this is a prerequisite lookup before tiktok_create_ad, but the description never names that sibling or states the dependency explicitly. There is no when-not guidance and no mention of how this differs from list_accounts, which is a plausible confusion point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_lead_formsTikTok instant formsCRead-onlyInspect
Instant (lead) forms on the advertiser, needed for lead-generation campaigns that collect leads inside TikTok.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. Beyond that, the description adds only account scoping and says nothing about what is returned (a form list?), whether forms are per-campaign or account-wide, or pagination — with no output schema, that gap matters.
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?
A single short sentence with no filler, and the resource is front-loaded. The phrasing is a noun fragment with an awkward comma splice, which slightly undercuts readability, but nothing is wasted.
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?
The tool is simple (3 optional, fully documented params, no output schema, read-only annotation), yet the one thing an agent most needs — whether this lists or creates forms — is absent. That missing verb is a material ambiguity for a form-related tool in an account full of lead-gen tooling.
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 all three parameters are optional, so the schema already explains folder, account, and language. The description contributes no additional meaning about these parameters, which meets the baseline-3 expectation when the schema carries the load.
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 resource ("Instant (lead) forms") and scopes it to an advertiser, but never supplies a verb — it is ambiguous whether the tool lists existing forms, retrieves a single form, or creates one. Siblings such as meta_lead_forms and linkedin_lead_forms are not distinguished, though the "tiktok_" prefix does the platform disambiguation.
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 clause "needed for lead-generation campaigns that collect leads inside TikTok" hints at relevance but gives no explicit trigger, prerequisites, or exclusions. It does not tell the agent when to pick this over meta_lead_forms, linkedin_lead_forms, or the *_get_leads tools that likely operate on the submissions these forms collect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_performanceTikTok Ads performanceARead-onlyInspect
TikTok Ads performance dashboard: spend, results (the campaign objective's result, else conversions), cost per result, clicks, CTR, CPC, purchases, purchase value and ROAS vs the previous period, with a daily trend, per-campaign table and automatic insights. Shown as an interactive dashboard; summarise the main findings. Default: last 30 days. Amounts are in the account currency.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Preset period. Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, non-destructive, open-world behavior, and the description adds useful context: it renders an interactive dashboard, includes a daily trend and per-campaign table, defaults to the last 30 days, and reports amounts in the account currency. It does not cover data freshness or authorization requirements, but the annotations carry the safety profile.
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 front-loaded with the dashboard’s contents and metrics, then moves to rendering behavior, default period and currency. It is dense but every sentence contributes; no significant padding or repetition.
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 seven-parameter, output-schema-less dashboard tool, the description explains the return shape (interactive dashboard with trend and campaign table), the reporting expectation, defaults and currency. It is close to complete, though it could add one line distinguishing this from related TikTok reporting tools.
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 all seven parameters including the detail enum, date presets, account and folder fields are already documented. The description only reinforces the default date range and currency, adding little parameter meaning 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 names the specific resource (TikTok Ads performance dashboard) and lists the exact metrics returned: spend, results, cost per result, clicks, CTR, CPC, purchases, purchase value, ROAS, trend and per-campaign table. It is clearly a performance-reporting tool, but it does not explicitly distinguish itself from siblings like tiktok_report_query or tiktok_breakdown.
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: it is a dashboard for performance overviews, defaults to the last 30 days, and the agent should summarise the main findings. There is no explicit guidance on when to choose it over tiktok_report_query or a breakdown tool, which leaves the routing decision partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_removeDelete a TikTok campaign, ad group or adADestructiveInspect
Delete a campaign, ad group or ad. Requires the user's explicit yes: call first without confirm to preview, then with confirm=true and confirm_name equal to the exact name.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| id_or_name | Yes | ||
| confirm_name | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so safety is signaled structurally; the description adds genuinely new behavior: an explicit user-yes requirement, a dry-run/preview mode, and an exact-name guard. It does not disclose the blast radius (whether deleting a campaign also removes its ad groups and ads) or any irreversibility/auth detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the destructive action plus the required confirmation protocol are front-loaded. Every clause earns its place by conveying a constraint the agent must honor.
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 destructive, open-world tool with no output schema, the critical missing piece — the confirmation workflow — is covered well. What remains unstated is the preview's return content and whether deletion cascades to child entities, which an agent would want before calling.
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 only 43%, so the description carries weight here. It meaningfully explains `confirm` (gate for execution) and `confirm_name` (must equal the exact name), but leaves `id_or_name`, `level` interplay, `folder`, `account`, and `language` 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?
The description states a specific verb (Delete) and enumerates the exact resource levels it accepts (campaign, ad group or ad), matching the `level` enum. It is clearly distinguishable from siblings such as tiktok_set_status or tiktok_rename, though it does not name those alternatives explicitly.
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 specifies a concrete two-step calling protocol: first call without confirm to preview, then call with confirm=true plus an exact-name confirmation. That is real when-to-use guidance for the invoke sequence. The gap is that it never says when NOT to use this tool (e.g. pausing via tiktok_set_status instead of deleting).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_renameRename a TikTok campaign or ad groupCDestructiveInspect
Rename a campaign or ad group.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| new_name | Yes | ||
| id_or_name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is known without the description. The description adds nothing beyond them: it does not say the previous name is lost, that the rename applies immediately in the live TikTok account, or that name-based lookup may match multiple entities. No annotation contradiction exists, but the value-add is close to zero.
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 single sentence is front-loaded and free of waste, but its brevity reflects under-specification rather than disciplined editing. There is no structure indicating which parameter controls which object level.
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?
This is a destructive, open-world mutation with six parameters (two of them enums), a 50% documented schema, no output schema, and an ambiguous identifier parameter. A one-line description leaves an agent without the information needed to call it safely, and none of the gaps are covered elsewhere in structured fields.
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 only 50%, and the undocumented parameters are the critical ones: id_or_name has no description at all (is it an ID, a name, or either, and how is ambiguity resolved?), and new_name has bounds but no stated constraints or uniqueness rules. The description names neither parameter, so it does not compensate for the coverage gap.
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?
"Rename a campaign or ad group" restates the tool title almost verbatim and adds no scope detail beyond it. It does name a verb and the two object types, but an agent learns nothing new about what distinguishes this from the platform's other TikTok write tools (tiktok_set_status, tiktok_update_budget, 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?
There is no when-to-use guidance, no prerequisites (e.g. that the account must be enabled, or which folder to target), and no note about what to do if the name is ambiguous. Usage is only inferable from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_report_queryTikTok custom report (read-only)BRead-onlyInspect
Run a custom read-only integrated report for analysis not covered by other tools: choose level, dimensions (e.g. stat_time_day, campaign_id, ad_id, age, gender, country_code, placement) and metrics (e.g. spend, impressions, clicks, conversion, cost_per_conversion, video_watched_2s, video_views_p100, average_video_play, likes, shares, follows).
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| limit | No | ||
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| metrics | Yes | ||
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| dimensions | Yes | ||
| start_date | No | YYYY-MM-DD (with end_date). | |
| report_type | No | AUDIENCE for age/gender/country/platform dimensions. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, non-destructive behavior, so the safety profile is covered. The description adds the custom integrated-report intent and examples, but says nothing about account access, rate limits, pagination, or result behavior; with annotations, a 3 is appropriate.
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?
It is one front-loaded sentence with no filler; the examples are useful rather than padding, though the long parenthetical list is dense. Appropriate for a query 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?
For an 11-parameter custom reporting tool with no output schema, the description covers the core selection model but omits return shape, required parameter combinations, and practical account/date constraints. It is adequate but not fully complete.
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 description adds useful example values for dimensions and metrics (e.g., stat_time_day, cost_per_conversion) that are not in the schema. However, 4 of 11 parameters lack schema descriptions, and the description does not explain level enums, report_type, date handling, or limit/account/folder semantics, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Run a custom read-only integrated report') and resource (TikTok), and scopes it to 'analysis not covered by other tools' with example dimensions and metrics. This is clear enough to distinguish it from standard reporting tools, though it does not name the specific sibling to use instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'analysis not covered by other tools' gives a when-to-use signal, but it does not explicitly identify which siblings cover standard reporting or breakdowns, nor does it state prerequisites or exclusions. The agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_search_locationsSearch TikTok locationsARead-onlyInspect
Find TikTok location IDs (country, region/province, city) by name for targeting. Countries SA, AE, EG, KW, QA, BH, OM, JO, IQ, MA, LB, US, GB, TR can be passed directly as country codes instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| country | No | Country code to narrow results, e.g. SA. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description contributes the shape of the return (IDs per geographic level) and the direct-code shortcut, but says nothing about match behavior (exact vs fuzzy), result limits, or what happens when a name resolves to nothing — useful context for a lookup tool over an external taxonomy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and zero filler. The country-code caveat is appended as a distinct, scannable sentence rather than buried mid-thought.
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 five parameters, one required, 80% schema coverage and no output schema, the description needs to carry purpose, return shape and usage context — it does all three and even adds the direct-code escape hatch. It stops short of describing result granularity (does a query return IDs at every level simultaneously?) or any pagination, which is the only meaningful 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 already 80%, so the schema documents folder, account, country and language. The description still adds real meaning: "by name" clarifies what the undocumented required query parameter accepts, and the country-code list clarifies the accepted value format for country beyond the schema's single "e.g. SA" example.
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 pairs a specific verb ("Find") with a specific resource ("TikTok location IDs") and enumerates the geographic levels it resolves (country, region/province, city), plus the reason for doing so ("for targeting"). It reads clearly as the TikTok counterpart to google_ads_find_locations / meta_targeting_search, but it never explicitly contrasts itself with those siblings, leaving platform disambiguation to the tool name alone.
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 frames the use case (resolve names to IDs when building targeting) and adds a genuine short-circuit: for the fourteen listed countries, the code can be passed directly instead of searching. That is an implicit when-NOT-to-use. It doesn't state the converse condition, e.g. that regions and cities must go through this tool, or that unknown names need a fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_set_statusPause or activate a TikTok campaign, ad group or adADestructiveInspect
Pause runs immediately. Activating starts spending: the first call returns a preview; ask the user, then call again with confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| folder | No | Client folder name. | |
| status | Yes | ||
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| id_or_name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds the critical detail that activation starts spending money and is gated behind a preview-then-confirm handshake. This is exactly the kind of context annotations cannot convey. It does not mention reversibility (whether a pause can be undone), permission requirements, or what happens if id_or_name matches multiple entities.
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 sentences with zero filler, and the highest-stakes fact (activation spends money and needs confirmation) is placed immediately after the pause case. Every clause carries operational weight.
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 seven-parameter destructive mutation with no output schema, the description covers the riskiest path well but leaves real gaps: entity resolution via id_or_name, the effect of level and folder scoping, and whether the action can be reversed. Adequate to avoid the worst mistake (unconfirmed activation), not adequate to call it confidently in edge cases.
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 only 43%, and the description compensates for the most important gap by fully explaining the confirm parameter's two-step protocol. However, id_or_name — the riskiest parameter, since a fuzzy name match on a destructive mutation could hit the wrong entity — gets no explanation of whether names, IDs, or partial matches are accepted, and level/status meaning beyond their enums is also absent.
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 conveys that this toggles between pausing and activating, but never names the resource it operates on (campaign, ad group, ad) or the status-setting verb — that scope lives only in the title. An agent must combine name + title + description to know what is being changed, and there is no differentiation from siblings like tiktok_remove or tiktok_update_bid.
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 draws a clear behavioral fork: pause is a single immediate call, while activation requires a preview, a user check-in, then a second call with confirm=true. That is actionable procedural guidance. It stops short of naming alternatives or stating when this tool should not be used (e.g., use tiktok_remove to delete).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_tracking_auditTikTok Pixel auditARead-onlyInspect
Check TikTok Pixels on the account (status and events set up) and campaigns optimising for conversions that report none. Use for 'why no purchases/leads' questions.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read operation, so the description only needs to add scope. It does: it discloses that the audit covers both pixel status/events and conversion-optimised campaigns with zero reported conversions, which tells the agent what a result set contains. It does not discuss result size, truncation, or what happens when no pixel exists.
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: the first states what is inspected, the second states the question it answers. Nothing is duplicated or padded.
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 four optional parameters, no output schema, and flat structure, the description conveys enough for correct invocation: it frames both the data gathered and the diagnostic intent. A short note on output shape or empty-result behaviour would make it fully complete.
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 each parameter already has a thorough description, including the summary/full enum trade-off and the language hint. The description adds nothing about parameter behaviour, so the baseline of 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 resource (TikTok Pixels) and the two things it checks: pixel status/events and campaigns optimising for conversions that report none. That is more than a restated title and is clearly distinct from listing tools like snapchat_pixels. It stops short of explicitly contrasting with sibling audit tools such as ga4_tracking_check or gtm_audit.
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 supplies a concrete trigger phrase — 'why no purchases/leads' questions — that tells an agent exactly when to reach for this tool. There is no explicit when-not guidance or named alternative for related diagnostic scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_update_bidChange a TikTok ad group bidADestructiveInspect
Change the bid or cost cap (account currency) of an ad group that uses a manual bid. Raising it returns a preview and needs confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| bid | Yes | ||
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| adgroup | Yes | ||
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond the annotations: raising the bid returns a preview and requires confirm=true, which tells the agent that a raise is a two-step operation while implying a lower is applied directly. The units are clarified as account currency. It does not state what the preview looks like or whether a confirmed raise is reversible, which is a gap for a destructiveHint=true tool, but the key behavioral wrinkle is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The precondition and the units constraint are front-loaded and the preview/confirm mechanic follows immediately; nothing repeats the title or the annotations.
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 six-parameter mutation tool with no output schema, the description covers the bid semantics and the confirm gate but leaves account/folder scoping and the adgroup identifier unexplained. Adequate to call the tool safely, not complete enough to predict the result of a confirmed change.
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 50%. The description meaningfully explains 'bid' (account currency) and 'confirm' (needed when raising), which are the two parameters the schema leaves bare. It says nothing about 'adgroup' (the required identifier) and only implicitly relies on the schema descriptions for folder/account/language.
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?
Names a specific verb and resource: 'Change the bid or cost cap ... of an ad group', and scopes it to ad groups on manual bidding. The platform prefix and 'bid or cost cap' wording separate it from tiktok_update_budget and the other platform update tools, though it never names those alternatives explicitly.
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?
'an ad group that uses a manual bid' is a genuine applicability precondition that rules out auto-bid ad groups, which is real when-to-use guidance. It stops short of naming the alternative tool to use for budget changes or for ad groups on automatic bidding, so an agent must still infer that routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_update_budgetChange a TikTok budgetADestructiveInspect
Change the budget of a campaign or ad group (daily or lifetime, as currently set) in the account currency. Decreases run immediately; increases return a preview and need confirm=true after the user's yes.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | ||
| budget | Yes | ||
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| confirm | No | ||
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| id_or_name | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a destructive, non-read-only, open-world mutation, so the bar is lower, yet the description adds genuinely non-obvious behavior: the asymmetric confirmation flow for increases versus immediate decreases and the preview requirement. It stops short of saying what happens if confirm is omitted (error vs silent no-op) or whether the preview itself is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each carrying distinct payload: the first defines scope and unit, the second defines the mutation and approval behavior. The most decision-relevant fact (immediate vs preview-then-confirm) is front-loaded in the second sentence with 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?
For a 7-parameter mutation tool with no output schema, the description covers the safety-critical path and even references the returned preview. It is slightly thin on how id_or_name is resolved (name collisions, whether ID is preferred) and on account/folder context when multiple accounts are enabled.
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 only 43%, and the description compensates by explaining the semantics of the three most consequential parameters: level (campaign vs ad group), budget (interpreted in account currency and matching the existing daily/lifetime setting), and confirm (required only after a user's yes on increases). The remaining parameters (id_or_name resolution, folder, account scoping) are left to the schema, which documents only folder and account.
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 a specific verb and resource ("change the budget of a campaign or ad group") and adds scope (daily vs lifetime, account currency), which is far more informative than the bare title. It does not explicitly distinguish itself from near-neighbours like tiktok_update_bid or the other platforms' *_update_budget tools, relying on the prefixed name to do that work.
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 useful operational context: decreases apply immediately while increases require a confirm=true follow-up after user approval, which effectively tells the agent how to sequence calls. However, there is no guidance on when to prefer this tool over budget_status/budgets_at_risk for inspection, or over tiktok_update_bid when both bid and budget change.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_upload_videoUpload a video to TikTokAInspect
Upload a video to the advertiser's TikTok asset library from a public https URL (direct link to an MP4/MOV, 9:16 recommended, 5–60s). Returns a video_id for tiktok_create_campaign / tiktok_create_ad. Accepts media_id for a file attached in the Go Shift chat.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| media_id | No | A file the user attached in the Go Shift chat (media_id from the [attachment …] marker). Use instead of the URL. | |
| file_name | No | ||
| video_url | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, open-world write, so the safety bar is lower. The description adds real behavior beyond that: the source must be a publicly reachable direct link, accepted formats and aspect ratio, duration bounds of 5–60s, and the fact that a video_id is returned for reuse. It omits whether re-uploads duplicate assets or how long ingestion takes, which keeps it at 4 rather than 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 tight sentences, front-loaded with the action and source, then the return value, then the alternate input. Every clause carries information an agent needs; nothing is padding.
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 write tool with no output schema, it covers the inputs, the media constraints, and the return value (video_id). The one real gap is that required is empty in the schema and the description never states that exactly one of video_url or media_id must be supplied, which could let an agent fire a contentless call.
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?
At 67% schema coverage the schema does part of the work, but the description meaningfully enriches the two consequential parameters: video_url must be a direct public MP4/MOV link with 9:16 framing and 5–60s length, and media_id traces back to an [attachment …] marker in the Go Shift chat. folder, account, language and file_name get no narrative treatment, leaving a gap but not an ambiguous one.
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?
Specific verb plus resource ("Upload a video to the advertiser's TikTok asset library"), with the accepted sources made explicit and the downstream consumers (tiktok_create_campaign / tiktok_create_ad) named. An agent can immediately distinguish this from meta_upload_video or snapchat_upload_media as the TikTok-platform uploader.
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?
Clear guidance on which input path to use: a public https URL, or media_id when the file was attached in the chat ("Use instead of the URL"). It also signals this is a preparatory step for the create-campaign/create-ad tools. No explicit exclusion or prerequisite statement (e.g. account permissions, what to do if the upload fails), so it stops short of a full when/when-not treatment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
tiktok_wasted_spendTikTok wasted spendARead-onlyInspect
Find money spent without results: ad groups and ads with spend and zero results, very high cost per result vs the account average, and low CTR. Read-only; suggests what to pause or fix.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary (default): headline numbers and the top 5 rows — right for a specific question or a quick look. full: every row and section — only when the user asks for a full report, a complete list or all the details. | |
| folder | No | Client folder name. | |
| account | No | TikTok advertiser account name or ID. Optional when only one is enabled. | |
| end_date | No | YYYY-MM-DD. | |
| language | No | Language of the card: the language the user is writing in (ar for any Arabic dialect). | |
| date_range | No | Default LAST_30_DAYS. | |
| start_date | No | YYYY-MM-DD (with end_date). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description earns credit for what it adds beyond them: it discloses the analysis criteria and clarifies that the tool only suggests what to pause or fix rather than acting. It does not state how thresholds are defined (what counts as 'very high' CPR or 'low' CTR) or how results are ordered, which keeps it below 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?
One front-loaded sentence states the purpose and the detection criteria, followed by a short clause on read-only behavior and recommendations. There is no filler, though the semi-colon construction packs three criteria into a single long clause rather than structuring them for scanability.
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 7-parameter, all-optional diagnostic tool with no output schema, the description covers what is found and the nature of the output (suggestions rather than mutations). The remaining gaps (threshold definitions, tie-in to the detail enum's summary versus full modes) are minor given the fully documented schema and the read-only annotations.
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%, with the detail, language, date_range, account and folder parameters all documented in the schema itself, including the default detail mode and the default LAST_30_DAYS range. The description adds no parameter-level guidance beyond the schema, so the baseline of 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 uses a concrete verb ('Find') and defines the resource precisely by enumerating the three failure criteria it detects: spend with zero results, very high cost per result versus the account average, and low CTR. This clearly separates it from a generic metrics tool like tiktok_performance, though it never names a sibling outright.
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 by the framing ('money spent without results', 'suggests what to pause or fix'), which tells an agent this is for diagnosing inefficiency rather than general reporting. However, there is no explicit when-to-use statement, no exclusion pointing to tiktok_performance or tiktok_breakdown for broader analysis, and no note about prerequisites such as an enabled account.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publisher details
- Operator
- Go Shift Ads Connector · Publisher source
- Operator website
- https://goshift-eg.com/en/ · Publisher source
- Vendor relationship
- First-party · Publisher source
- Documentation
- https://goshift-eg.com/en/docs · Publisher source
- Trust center
- https://goshift-eg.com/en/security · Publisher source
- Restrictions
- Requires a Go Shift account (free plan available, sign in with OAuth). Creating and editing campaigns requires a paid plan. LinkedIn Ads is read-only for now. · Publisher source
Related MCP Connectors
Run Google Ads, Meta, TikTok, LinkedIn, GA4 & Search Console from chat. Changes wait for approval.
Run Google Ads, Meta Ads, LinkedIn Ads and ChatGPT Ads from Claude or ChatGPT. You approve every change.
Run Google Ads and Meta Ads from ChatGPT or Claude: audit wasted spend, create and manage campaigns.
Manage Google, Meta, LinkedIn, Microsoft, TikTok, Snapchat and Reddit ads in AI chat, with approvals
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceCreate, launch, and manage Meta + Google ads from Claude and ChatGPT. Analytics, strategy, and autopilot automation for any store.1Apache 2.0
- AlicenseBqualityCmaintenanceEnables AI assistants and agents to read analytics and manage advertising across Google Ads, Google Analytics 4, and Meta Ads through natural language, with preview-confirm guardrails and configurable account and budget limits.21MIT

PaidSync MCP Serverofficial
AlicenseNot gradedqualityFmaintenanceConnects Google Ads, Meta Ads, and LinkedIn Ads to AI assistants, enabling natural language ad campaign management, reporting, and optimization across platforms.MIT- AlicenseNot gradedqualityBmaintenanceEnables AI assistants to create, analyze, and optimize ad campaigns across Google Ads, Meta Ads, TikTok Ads, LinkedIn Ads, Amazon Ads, and ChatGPT Ads through natural language using 400+ tools.106MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.