Skip to main content
Glama

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.

Ownership verified
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 tools
budget_pacing_planBudget pacing plan for a clientA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
folderYesClient folder name.
languageNoThe language the user is writing in.

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 riskA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
languageNoThe language the user is writing in.

TDQS

A3.7/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 statusA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
folderNoClient folder name. Optional.
languageNoThe language the user is writing in.

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 instructions
Read-only
Inspect

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.

NameRequiredDescriptionDefault
folderYesClient 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.

NameRequiredDescriptionDefault
notesNoShort note from the agency to its client shown on the report, in the report's language. Optional.
titleNoReport title. Optional.
folderNoClient folder name. Omit to include every active ad account (up to 10).
accountNoOne ad account name or ID instead of a folder.
end_dateNoYYYY-MM-DD.
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date) for a custom period.
ga4_audienceGA4 audience breakdown
Read-only
Inspect

Break down sessions and users by device, country or city.

NameRequiredDescriptionDefault
limitNo
detailNosummary (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.
folderNoClient folder name.
end_dateNoCustom end date YYYY-MM-DD.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
dimensionNo
date_rangeNoPreset period. Default LAST_7_DAYS.
start_dateNoCustom 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.

NameRequiredDescriptionDefault
scopeYes
folderNoClient folder name.
confirmNo
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
descriptionNo
display_nameYes
parameter_nameYes
definition_typeYes
measurement_unitNo
ga4_custom_definitionsGA4 custom dimensions and metrics
Read-only
Inspect

List custom dimensions and metrics defined for the selected property.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
ga4_custom_reportGA4 custom report
Read-only
Inspect

Run a GA4 report with dimensions and metrics validated against the property's getMetadata catalog. Use GA4 API field names.

NameRequiredDescriptionDefault
limitNo
detailNosummary (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.
folderNoClient folder name.
metricsYes
end_dateNoCustom end date YYYY-MM-DD.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
date_rangeNoPreset period. Default LAST_7_DAYS.
dimensionsYes
start_dateNoCustom start date YYYY-MM-DD (use with end_date instead of date_range).
ga4_ecommerceGA4 ecommerce
Read-only
Inspect

Ecommerce performance including purchases, purchase revenue and top purchased items.

NameRequiredDescriptionDefault
limitNo
detailNosummary (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.
folderNoClient folder name.
end_dateNoCustom end date YYYY-MM-DD.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
date_rangeNoPreset period. Default LAST_7_DAYS.
start_dateNoCustom start date YYYY-MM-DD (use with end_date instead of date_range).
ga4_key_eventsGA4 key events
Read-only
Inspect

Show key events and event counts with optional campaign breakdown, plus which events are configured as key events.

NameRequiredDescriptionDefault
limitNo
detailNosummary (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.
folderNoClient folder name.
end_dateNoCustom end date YYYY-MM-DD.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
date_rangeNoPreset period. Default LAST_7_DAYS.
start_dateNoCustom start date YYYY-MM-DD (use with end_date instead of date_range).
ga4_overviewGA4 property overview
Read-only
Inspect

GA4 overview with previous-period comparison and daily trend: sessions, users, new users, views, key events and purchase revenue.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
end_dateNoCustom end date YYYY-MM-DD.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
date_rangeNoPreset period. Default LAST_7_DAYS.
start_dateNoCustom start date YYYY-MM-DD (use with end_date instead of date_range).
ga4_pagesGA4 pages and landing pages
Read-only
Inspect

Top pages and landing pages by views, sessions, engagement and key events.

NameRequiredDescriptionDefault
limitNo
detailNosummary (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.
folderNoClient folder name.
end_dateNoCustom end date YYYY-MM-DD.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
date_rangeNoPreset period. Default LAST_7_DAYS.
start_dateNoCustom start date YYYY-MM-DD (use with end_date instead of date_range).
landing_pagesNo
ga4_realtimeGA4 realtime (last 30 minutes)
Read-only
Inspect

Realtime active users in the last 30 minutes by country, source/medium and page title.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
ga4_set_key_eventMark or unmark a GA4 key event
Destructive
Inspect

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.

NameRequiredDescriptionDefault
actionYes
folderNoClient folder name.
confirmNo
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
event_nameYes
ga4_tracking_checkGA4 tracking check
Read-only
Inspect

Check linked Google Ads accounts, paid sessions with missing campaign data, and whether GA4 key events are defined.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
end_dateNoCustom end date YYYY-MM-DD.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
date_rangeNoPreset period. Default LAST_7_DAYS.
start_dateNoCustom start date YYYY-MM-DD (use with end_date instead of date_range).
ga4_traffic_acquisitionGA4 traffic acquisition
Read-only
Inspect

Traffic acquisition by source/medium, campaign and default channel group, including sessions, engaged sessions, conversions/key events and revenue.

NameRequiredDescriptionDefault
limitNo
detailNosummary (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.
folderNoClient folder name.
end_dateNoCustom end date YYYY-MM-DD.
languageNoLanguage of the card (ar for Arabic, en for English).
propertyNoGA4 property ID or property name. Required when multiple AI-enabled properties exist.
dimensionNo
date_rangeNoPreset period. Default LAST_7_DAYS.
start_dateNoCustom start date YYYY-MM-DD (use with end_date instead of date_range).
go_shift_usageGo Shift plan and usage balance
Read-only
Inspect

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'.

NameRequiredDescriptionDefault
languageNoLanguage of the card: the language the user is writing in.
gsc_breakdownSearch breakdown
Read-only
Inspect

Break organic performance down by country, device, search appearance or date.

NameRequiredDescriptionDefault
siteNoSite (domain or URL) as listed by gsc_sites. Required when several sites are enabled.
detailNosummary (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.
deviceNo
folderNoClient folder name.
countryNoISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE.
end_dateNoYYYY-MM-DD
languageNoLanguage of the card (ar for Arabic, en for English).
dimensionYes
date_rangeNo
start_dateNoYYYY-MM-DD
search_typeNoDefaults to web.
page_containsNoOnly pages whose URL contains this text.
query_containsNoOnly queries containing this text.
gsc_inspect_urlInspect a URL in Google's index
Read-only
Inspect

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.

NameRequiredDescriptionDefault
urlYesFull URL on the site.
siteNoSite (domain or URL) as listed by gsc_sites. Required when several sites are enabled.
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
gsc_opportunitiesSEO opportunities
Read-only
Inspect

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).

NameRequiredDescriptionDefault
siteNoSite (domain or URL) as listed by gsc_sites. Required when several sites are enabled.
detailNosummary (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.
deviceNo
folderNoClient folder name.
countryNoISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE.
end_dateNoYYYY-MM-DD
languageNoLanguage of the card (ar for Arabic, en for English).
date_rangeNo
start_dateNoYYYY-MM-DD
min_impressionsNoDefaults to 50.
gsc_pagesTop pages in search
Read-only
Inspect

Pages ranked by organic clicks with impressions, CTR and position. Optionally show the top queries of one page (page_contains).

NameRequiredDescriptionDefault
siteNoSite (domain or URL) as listed by gsc_sites. Required when several sites are enabled.
limitNo
detailNosummary (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.
deviceNo
folderNoClient folder name.
countryNoISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE.
end_dateNoYYYY-MM-DD
languageNoLanguage of the card (ar for Arabic, en for English).
date_rangeNo
start_dateNoYYYY-MM-DD
search_typeNoDefaults to web.
page_containsNoOnly pages whose URL contains this text.
query_containsNoOnly queries containing this text.
gsc_performanceOrganic search performance
Read-only
Inspect

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.

NameRequiredDescriptionDefault
siteNoSite (domain or URL) as listed by gsc_sites. Required when several sites are enabled.
detailNosummary (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.
deviceNo
folderNoClient folder name.
countryNoISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE.
end_dateNoYYYY-MM-DD
languageNoLanguage of the card (ar for Arabic, en for English).
date_rangeNo
start_dateNoYYYY-MM-DD
search_typeNoDefaults to web.
page_containsNoOnly pages whose URL contains this text.
query_containsNoOnly queries containing this text.
gsc_queriesSearch queries
Read-only
Inspect

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.

NameRequiredDescriptionDefault
siteNoSite (domain or URL) as listed by gsc_sites. Required when several sites are enabled.
sortNo
limitNo
detailNosummary (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.
deviceNo
folderNoClient folder name.
countryNoISO 3166-1 alpha-3 country code, e.g. SAU, EGY, ARE.
end_dateNoYYYY-MM-DD
languageNoLanguage of the card (ar for Arabic, en for English).
date_rangeNo
start_dateNoYYYY-MM-DD
search_typeNoDefaults to web.
page_containsNoOnly pages whose URL contains this text.
query_containsNoOnly queries containing this text.
gsc_remove_sitemapRemove a sitemap
Destructive
Inspect

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.

NameRequiredDescriptionDefault
siteNoSite (domain or URL) as listed by gsc_sites. Required when several sites are enabled.
folderNoClient folder name.
confirmNo
languageNoLanguage of the card (ar for Arabic, en for English).
sitemap_urlYes
confirm_nameNo
gsc_sitemapsSitemaps
Read-only
Inspect

Submitted sitemaps with status, last read date, errors, warnings and submitted vs indexed URL counts.

NameRequiredDescriptionDefault
siteNoSite (domain or URL) as listed by gsc_sites. Required when several sites are enabled.
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
gsc_sitesSearch Console sites
Read-only
Inspect

List the Search Console sites enabled for AI with permission level. Start here for SEO / organic search questions.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
gsc_submit_sitemapSubmit a sitemap
Destructive
Inspect

Submit or resubmit a sitemap URL so Google re-reads it and recrawls changed pages. Safe: it doesn't change the website.

NameRequiredDescriptionDefault
siteNoSite (domain or URL) as listed by gsc_sites. Required when several sites are enabled.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
sitemap_urlYesFull sitemap URL, e.g. https://example.com/sitemap.xml
gtm_auditTag Manager tracking audit
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
gtm_containersTag Manager containers
Read-only
Inspect

List the Google Tag Manager containers enabled for AI, with public IDs (GTM-XXXX), accounts and client folders. Start here for Tag Manager questions.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage 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.

NameRequiredDescriptionDefault
htmlNoCustom HTML (custom_html template only).
nameNo
folderNoClient folder name.
pausedNo
dry_runNo
currencyNoCurrency code or {{Variable}}.
languageNoLanguage of the card (ar for Arabic, en for English).
pixel_idNo
templateYesga4_config = Google tag with a G- ID; meta/tiktok/snap_pixel without pixel_event = base code, with pixel_event = event code.
triggersNoTrigger names or IDs. 'All Pages' is available. Defaults to All Pages for base/config tags.
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
event_nameNoGA4 event name (e.g. purchase, generate_lead).
pixel_eventNoMeta: Purchase, Lead, AddToCart… TikTok: CompletePayment, SubmitForm… Snap: PURCHASE, SIGN_UP…
conversion_idNoGoogle Ads conversion ID (digits, from AW-XXXXXXX).
measurement_idNoGA4 measurement ID (G-XXXX).
transaction_idNoOrder ID or {{Variable}} (deduplication).
conversion_labelNo
conversion_valueNoNumber or {{Variable}}.
event_parametersNoGA4 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.

NameRequiredDescriptionDefault
nameYes
typeYes
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
conditionsNo
event_nameNocustom_event: dataLayer event name (e.g. purchase).
scroll_percentagesNoscroll_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.

NameRequiredDescriptionDefault
keyNodata_layer: key path (ecommerce.value); javascript: global name; cookie: cookie name; url: component (URL, HOST, PATH, QUERY, FRAGMENT).
nameYes
typeYes
valueNoconstant: the value. url+QUERY: query key.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
gtm_discard_changeDiscard a draft change in Tag Manager
Destructive
Inspect

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).

NameRequiredDescriptionDefault
nameYes
entityYes
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
gtm_overviewTag Manager container overview
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
gtm_pending_changesTag Manager unpublished changes
Read-only
Inspect

What is changed in the workspace draft and would go live on the next publish, including merge conflicts.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
gtm_publishPublish Tag Manager changes
Destructive
Inspect

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.

NameRequiredDescriptionDefault
notesNo
detailNosummary (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.
folderNoClient folder name.
confirmNo
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
version_nameNo
gtm_removeDelete a Tag Manager tag, trigger or variable
Destructive
Inspect

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.

NameRequiredDescriptionDefault
nameYes
entityYes
folderNoClient folder name.
confirmNo
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
confirm_nameNo
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.

NameRequiredDescriptionDefault
nameYesConversion name, e.g. Purchase or Lead.
whenYes
matchYesURL fragment, event name, click text or form ID.
folderNoClient folder name.
dry_runNo
currencyNoCurrency code or {{Variable}}.
languageNoLanguage of the card (ar for Arabic, en for English).
pixel_idNo
platformYes
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
event_nameNoGA4 event name (e.g. purchase, generate_lead).
pixel_eventNoMeta: Purchase, Lead, AddToCart… TikTok: CompletePayment, SubmitForm… Snap: PURCHASE, SIGN_UP…
conversion_idNoGoogle Ads conversion ID (digits, from AW-XXXXXXX).
measurement_idNoGA4 measurement ID (G-XXXX).
transaction_idNoOrder ID or {{Variable}} (deduplication).
conversion_labelNo
conversion_valueNoNumber or {{Variable}}.
gtm_tag_detailsTag Manager tag details
Read-only
Inspect

Full settings of one tag: type, IDs, parameters, firing and blocking triggers, custom HTML.

NameRequiredDescriptionDefault
tagYesTag name or ID.
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
gtm_update_tagUpdate a Tag Manager tag
Destructive
Inspect

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.

NameRequiredDescriptionDefault
tagYes
htmlNo
folderNoClient folder name.
pausedNo
languageNoLanguage of the card (ar for Arabic, en for English).
new_nameNo
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
add_triggersNo
set_parametersNoTemplate parameter key → new value.
remove_triggersNo
gtm_versionsTag Manager versions
Read-only
Inspect

Live version and recent container versions (publish history).

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
languageNoLanguage of the card (ar for Arabic, en for English).
containerNoContainer name, public ID (GTM-XXXX) or container ID. Required when several containers are enabled.
workspaceNoWorkspace name or ID. Defaults to 'Default Workspace'.
linkedin_ad_libraryLinkedIn Ad Library (competitor ads)A
Read-only
Inspect

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.

NameRequiredDescriptionDefault
limitNoAds to return (default 25 for keyword searches, 100 for an advertiser; max 200).
detailNosummary (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.
folderNoClient folder, used only to default the country to the client's market.
keywordNoWords in the ad (e.g. a product or offer).
end_dateNoYYYY-MM-DD: shown on or before.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
countriesNoISO 3166-1 alpha-2 codes where the ads were shown, e.g. ["SA","AE"]. ["ALL"] = no filter.
advertiserNoAdvertiser / company Page name (e.g. a competitor).
start_dateNoYYYY-MM-DD: shown on or after.
exact_advertiserNoDefault true: keep only ads whose advertiser or payer is this company. false = also partners and others LinkedIn matches.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 adsB
Read-only
Inspect

Ads (creatives) with status, review status, serving holds and period performance (spend, results, leads, CTR, CPC). Filter by campaign.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
statusNo
accountNoLinkedIn ad account name or ID. Optional when only one is enabled.
campaignNoCampaign name or ID.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 breakdownA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoLinkedIn ad account name or ID. Optional when only one is enabled.
campaignNo
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
dimensionYes
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 campaignsA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
statusNoDefault all (not archived or removed).
accountNoLinkedIn ad account name or ID. Optional when only one is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).
campaign_groupNoCampaign group name or ID to filter by.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 rulesA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoLinkedIn ad account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 leadsA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
limitNo
folderNoClient folder name.
accountNoLinkedIn ad account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
lead_form_idNo

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 formsA
Read-only
Inspect

Lead Gen Forms on the ad account (ID, name, status, review), to use as lead_form_id in lead generation ads.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoLinkedIn ad account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 performanceA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
levelNoRows of the table. Default campaign.
detailNosummary (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.
folderNoClient folder name.
accountNoLinkedIn ad account name or ID. Optional when only one is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoPreset period. Default LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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 estimateA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
folderNoClient folder name.
formatNoDefault single_image. video_views needs video; text ads are small right-rail desktop ads.
accountNoLinkedIn ad account name or ID. Optional when only one is enabled.
campaignNoUse this campaign's targeting instead.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
objectiveNo
targetingNoWho 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_strategyNoDefault maximum_delivery (LinkedIn bids automatically). target_cost / cost_cap / manual_* need bid.
daily_budgetNoAccount currency.
audience_expansionNoLet LinkedIn add similar members. Default false.
targeting_criteriaNoAdvanced: LinkedIn targetingCriteria object as-is ({include:{and:[{or:{<facet URN>:[…]}}]}, exclude:{or:{…}}}). Overrides targeting.

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_wasted_spendLinkedIn wasted spendA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoLinkedIn ad account name or ID. Optional when only one is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A4.3/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 folders
Read-only
Inspect

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.

NameRequiredDescriptionDefault
languageNoLanguage of the card: the language the user is writing in.
media_libraryUploaded filesA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
limitNo

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 testsC
Read-only
Inspect

A/B tests (split tests) on the ad account's business with their cells, dates and status.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

C2.8/5.0
Behavior3/5

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.

Conciseness3/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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 statusB
Read-only
Inspect

Ad account health: status and disable reason, amount spent, spending limit, balance, currency, time zone and business.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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 historyA
Read-only
Inspect

Recent changes on the ad account (who changed what and when): budgets, statuses, targeting, creatives.

NameRequiredDescriptionDefault
limitNo
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 previewA
Read-only
Inspect

Get a preview link for an ad (or creative) in a given placement so the user can see how it looks before activating.

NameRequiredDescriptionDefault
adYes
folderNoClient folder name.
formatNo
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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

States a specific verb and resource: 'Get 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.

Usage Guidelines3/5

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 ads
Read-only
Inspect

Ads with status (including review/rejection), creative text, headline, link, and period performance. Filter by campaign or ad set.

NameRequiredDescriptionDefault
adsetNo
detailNosummary (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.
folderNoClient folder name.
statusNo
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
campaignNo
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).
meta_adsetsMeta ad sets
Read-only
Inspect

Ad sets with status, optimisation goal, budget, bid, schedule, targeting summary and period performance. Filter by campaign.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
statusNo
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
campaignNoCampaign name or ID.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).
meta_audiencesMeta audiencesB
Read-only
Inspect

Custom and lookalike audiences in the account with type, approximate size, status and source.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

B3.1/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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 breakdownA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
adsetNo
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
campaignNo
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
dimensionYes
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 campaigns
Read-only
Inspect

Campaigns with objective, status, budget (campaign budget or ad-set budgets), bid strategy and period spend/results. Use to find IDs before changes.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
statusNoDefault all (excluding deleted/archived).
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).
meta_conversionsMeta conversions detailA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
campaignNo
end_dateNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNo
start_dateNo

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
nameYes
levelYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
end_dateYes
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
start_dateYes
descriptionNo
ids_or_namesYes

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
linkNo
nameYes
adsetYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
dry_runNo
page_idNo
post_idNoExisting post: PAGEID_POSTID.
headlineNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
video_idNo
image_hashNo
descriptionNo
lead_form_idNoInstant form id for a lead ad (see meta_lead_forms / meta_create_lead_form).
primary_textNo
call_to_actionNo
instagram_user_idNo

TDQS

A4/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
nameYes
citiesNo
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
age_maxNo
age_minNo
dry_runNo
gendersNo
page_idNoRequired for lead/conversation ad sets.
campaignYes
end_timeNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
pixel_idNo
countriesNo
bid_amountNo
start_timeNo
daily_budgetNo
interest_idsNo
lifetime_budgetNo
destination_typeNo
custom_event_typeNoPURCHASE, LEAD, COMPLETE_REGISTRATION, ADD_TO_CART, INITIATED_CHECKOUT, CONTACT…
optimization_goalYes
advantage_audienceNoLet Meta expand beyond the targeting. Default true.
custom_audience_idsNo
excluded_audience_idsNo

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
nameYes
typeYes
eventNowebsite: PageView (default) or an event like Purchase, Lead, AddToCart.
ratioNoLookalike size, 0.01 = 1%.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
countryNo
page_idNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
pixel_idNo
url_containsNo
retention_daysNo
instagram_user_idNo
source_audience_idNo

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
nameYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
dry_runNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
objectiveYes
bid_strategyNo
daily_budgetNoCampaign budget (CBO). Omit to set budgets on ad sets.
lifetime_budgetNo
special_ad_categoriesNo

TDQS

A3.6/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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_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.

NameRequiredDescriptionDefault
nameNo
emailsNo
folderNoClient folder name.
phonesNo
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
audience_idNoAdd to an existing customer-list audience instead of creating one.

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 ruleA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
idsNoLimit to these object IDs. Omit for all active objects of that level.
nameYes
valueYes
actionYes
entityYes
folderNoClient folder name.
metricYes
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
operatorYes
scheduleNo
min_spentNoOnly apply after this much spend (account currency).
time_presetNo
budget_change_pctNoFor CHANGE_BUDGET: e.g. 20 or -20.

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 insightsA
Read-only
Inspect

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).

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 ruleA
Destructive
Inspect

Delete an automated rule. Preview first, then confirm=true with confirm_name equal to the rule name.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
confirmNo
rule_idYes
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
confirm_nameNo

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
intoNoTarget campaign (for ad sets) or ad set (for ads) name or ID.
levelYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
id_or_nameYes
rename_suffixNoDefault ' - Copy'.

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 changeA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 leadsA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
adNo
limitNo
sinceNoYYYY-MM-DD
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
form_idNo
page_idNoPage that owns the form (needed for form_id).
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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)A
Read-only
Inspect

Run a custom read-only Insights query for analysis not covered by other tools: choose level, Insights API fields, breakdowns and time increment.

NameRequiredDescriptionDefault
levelYes
limitNo
fieldsYesInsights fields, e.g. spend, impressions, actions, cost_per_action_type, video_p75_watched_actions.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
breakdownsNo
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).
time_incrementNo1 for daily, 7 for weekly, monthly, or all_days.

TDQS

A3.7/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 formsB
Read-only
Inspect

Instant (lead) forms on a Facebook Page with status, lead count and creation date.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
page_idYes
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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 accountsB
Read-only
Inspect

Facebook Pages (and linked Instagram accounts) the user can advertise with; needed to create ads.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 performance
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoPreset period. Default LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).
meta_reach_estimateMeta audience size estimateB
Read-only
Inspect

Estimate the audience size for a targeting spec before creating or changing an ad set.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
targetingYesMeta targeting spec (geo_locations, age_min, age_max, genders, flexible_spec, custom_audiences…).

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 audienceA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
id_or_nameYes
confirm_nameNo

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 adC
Destructive
Inspect

Rename an object.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
new_nameYes
id_or_nameYes

TDQS

C2.1/5.0
Behavior2/5

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.

Conciseness2/5

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.

Completeness1/5

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.

Parameters3/5

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.

Purpose2/5

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.

Usage Guidelines2/5

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 rulesB
Read-only
Inspect

Automated rules on the ad account (e.g. pause ad sets when cost per result is too high) with status, conditions and action.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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 audiencesC
Read-only
Inspect

Saved audiences (reusable targeting presets) in the ad account with their targeting summary.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

C2.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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 adA
Destructive
Inspect

Pause runs immediately. Activating starts spending: the first call returns a preview; ask the user, then call again with confirm=true.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
statusYes
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
id_or_nameYes

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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_tracking_auditMeta Pixel & Conversions API auditA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 linkA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
adYes
linkNo
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
headlineNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
descriptionNo
primary_textNo
call_to_actionNo

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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 bidA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
adsetYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
bid_amountNo
bid_strategyNo

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 budgetA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
id_or_nameYes
daily_budgetNo
lifetime_budgetNo

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 placementsB
Destructive
Inspect

Switch an ad set between Advantage+ (automatic) placements and manual placements on Facebook, Instagram, Messenger and Audience Network positions (feed, stories, reels…).

NameRequiredDescriptionDefault
adsetYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
devicesNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
automaticNo
platformsNo
facebook_positionsNo
instagram_positionsNo

TDQS

B3.3/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 scheduleA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
adsetYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
confirmNo
end_timeNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
daypartingNo
start_timeNo

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 targetingA
Destructive
Inspect

Change an ad set's targeting: locations, age, gender, interests, custom/excluded audiences, Advantage+ audience. Only the fields you pass change.

NameRequiredDescriptionDefault
adsetYes
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
age_maxNo
age_minNo
gendersNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
countriesNo
interest_idsNo
advantage_audienceNo
custom_audience_idsNo
excluded_audience_idsNo

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
media_idNoA file the user attached in the Go Shift chat (media_id from the [attachment …] marker). Use instead of the URL.
image_urlNo

TDQS

A4.2/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
titleNo
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
media_idNoA file the user attached in the Go Shift chat (media_id from the [attachment …] marker). Use instead of the URL.
video_urlNo

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 spendA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoMeta ad account name or ID (act_123 or 123). Optional when only one account is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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 adsC
Read-only
Inspect

Ads with status, review status (approved/rejected + reason), ad type, creative ID and ad squad. Filter by campaign or ad squad.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
adsquadNoAd squad name or ID.
campaignNo
languageNoLanguage of the card: the language the user is writing in.

TDQS

C2.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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 squadsA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
campaignNoCampaign name or ID.
languageNoLanguage of the card: the language the user is writing in.

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 audiencesA
Read-only
Inspect

Custom, lookalike and pixel audiences (segments) with type, size and status, to use in ad squad targeting.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in.

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 breakdownA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
campaignNo
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in.
dimensionYes
date_rangeNoDefault LAST_30_DAYS (max 31 days).
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.5/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 campaignsB
Read-only
Inspect

List Snapchat campaigns with status, objective and daily budget.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in.

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

NameRequiredDescriptionDefault
nameYes
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
adsquadYesAd squad name or ID.
dry_runNo
languageNoLanguage of the card: the language the user is writing in.
creative_idYes

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
osNoDevices to target (overrides copied targeting). Empty array = all devices.
bidNoMax bid / target cost in account currency (not for AUTO_BID).
nameYes
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
dry_runNo
campaignYesCampaign name or ID.
end_timeNo
languageNoLanguage of the card: the language the user is writing in.
pixel_idNo
targetingNoSnap targeting object. Ignored when copy_targeting_from is set.
start_timeNo
bid_strategyNoDefault AUTO_BID.
daily_budgetYes
optimization_goalYes
copy_targeting_fromNoAd squad name or ID whose targeting and placements to copy.

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
nameYes
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
dry_runNo
end_timeNo
languageNoLanguage of the card: the language the user is writing in.
objectiveYes
start_timeNoISO 8601. Default: now.
daily_budgetNoOptional campaign daily cap in account currency.
lifetime_spend_capNo

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
urlNoWebsite (https). Overrides the default.
nameNo
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
headlineYes
languageNoLanguage of the card: the language the user is writing in.
media_idNoFile attached in the Go Shift chat (from the [attachment … media_id=…] marker).
media_urlNoPublic https link to an image/video instead of media_id.
brand_nameNo
profile_idNo
creative_idNoReuse an existing creative instead.
snap_media_idNoMedia already in Snapchat.
call_to_actionNo

TDQS

A4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 creativesB
Read-only
Inspect

Creatives in the ad account (ID, name, type, headline, brand name, call to action, website) to reuse in new ads.

NameRequiredDescriptionDefault
folderNoClient folder name.
searchNoFilter by name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in.

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
osNoDevices to target (overrides copied targeting). Empty array = all devices.
bidNo
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
dry_runNo
languageNoLanguage of the card: the language the user is writing in.
new_nameYes
pixel_idNo
objectiveYes
bid_strategyNo
daily_budgetYesDaily budget per new ad squad, account currency.
only_active_adsNoCopy only ads that are ACTIVE in the source. Default true.
source_campaignYesCampaign name or ID to copy.
optimization_goalYes

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
osNo
adsYes
bidNo
urlNoDefault website for all ads (https).
nameNo
folderNoClient folder name.
genderNo
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
dry_runNo
max_ageNo
min_ageNo
end_timeNo
headlineNoDefault headline.
languageNoLanguage of the card: the language the user is writing in.
pixel_idNo
segmentsNoAudience (segment) IDs to include.
countriesNoISO codes, default SA.
objectiveNoDefault SALES.
brand_nameNo
profile_idNo
start_timeNo
bid_strategyNo
daily_budgetNoAccount currency.
call_to_actionNo
optimization_goalNo
copy_from_campaignNoCampaign 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_fromNoAd squad name or ID to copy targeting and placements from.

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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 performanceA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in.
date_rangeNoDefault LAST_30_DAYS (max 31 days).
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 PixelsC
Read-only
Inspect

Snap Pixels on the ad account with ID and status. Pixel goals (purchase, add to cart, sign-up, page view) need a pixel_id.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in.

TDQS

C2.3/5.0
Behavior3/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose2/5

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.

Usage Guidelines2/5

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 adA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in.
id_or_nameYes
confirm_nameNo

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 adC
Destructive
Inspect

Rename a campaign, ad squad or ad.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in.
new_nameYes
id_or_nameYes

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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 campaignA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
folderNoClient folder name.
statusYes
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in.
campaign_idYes

TDQS

A4.3/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 adA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
levelYescampaign, adsquad (ad set) or ad.
folderNoClient folder name.
statusYes
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in.
id_or_nameYes
include_childrenNoAlso set every ad squad and ad inside (campaign) or every ad inside (ad squad).

TDQS

A4.4/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 bidA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
bidNo
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
adsquadYes
confirmNo
languageNoLanguage of the card: the language the user is writing in.
bid_strategyNo

TDQS

A3.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 budgetA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
levelYes
budgetYes
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in.
id_or_nameYes

TDQS

A3.6/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 datesA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
confirmNo
end_timeNo
languageNoLanguage of the card: the language the user is writing in.
clear_endNo
id_or_nameYes
start_timeNo

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 targetingA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
osNoEmpty array = all devices.
folderNoClient folder name.
genderNo
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
adsquadYes
confirmNo
max_ageNo
min_ageNo
languageNoLanguage of the card: the language the user is writing in.
countriesNo
targetingNoFull replacement targeting object.
add_segmentsNo
remove_segmentsNo

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
urlNo
nameNo
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in.
media_idNo

TDQS

A4.1/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 spendA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoSnapchat ad account name or ID. Optional when only one is enabled.
campaignNoLimit to one campaign (name or ID).
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in.
date_rangeNoPreset period. Default LAST_14_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 groupsB
Read-only
Inspect

Ad groups with status, optimisation goal, budget, bid, placements, schedule and period performance. Filter by campaign.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
statusNo
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
campaignNoCampaign name or ID.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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 adsB
Read-only
Inspect

Ads with status (including review/rejection), ad text, call to action, landing page and period performance. Filter by campaign or ad group.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
statusNo
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
adgroupNo
campaignNo
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

B3.2/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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 audiencesC
Read-only
Inspect

Custom and lookalike audiences in the account with type, size and status.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

C2.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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 breakdownB
Read-only
Inspect

Break performance down by age, gender, country, platform (Android/iOS), network/connection or language. Optionally for one campaign.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
campaignNo
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
dimensionYes
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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 campaignsB
Read-only
Inspect

Campaigns with objective, status, budget, Smart+ flag and period spend/results. Use to find IDs before changes.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
statusNoDefault all (not deleted).
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
nameYes
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
adgroupYesAd group name or ID.
dry_runNo
form_idNo
ad_textsYes
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
video_idsYes
identity_idYes
identity_typeNo
call_to_actionNo
landing_page_urlNo

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
agesNo
goalYes
nameYes
eventNoPixel event to optimise for. Default purchase (sales) / submit_form (website leads).
budgetYesIn the account currency.
folderNoClient folder name.
genderNo
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
dry_runNo
form_idNoInstant form page_id for lead_destination=instant_form.
ad_textsNo
end_timeNoOptional 'YYYY-MM-DD HH:MM' in UTC; required for lifetime budgets.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
pixel_idNoPixel ID (numeric, from tiktok_tracking_audit). Required for sales and website leads.
countriesNoCountry codes, e.g. ["SA","AE"].
languagesNoLanguage codes, e.g. ["ar","en"].
targetingNoDefault automatic (TikTok's audience targeting, location still applies).
video_idsNoFrom tiktok_upload_video. TikTok rotates them automatically.
placementsNoDefault automatic.
start_timeNoOptional 'YYYY-MM-DD HH:MM' in UTC. Default now.
budget_typeNoDefault daily.
identity_idNoFrom tiktok_identities; needed to create the ad.
audience_idsNo
bid_cost_capNoOptional target cost per result (cost cap). Omit for maximum delivery.
budget_levelNocampaign = TikTok distributes it (default).
location_idsNoExtra location IDs from tiktok_search_locations.
identity_typeNo
call_to_actionNo
whatsapp_numberNoFor whatsapp: the WhatsApp Business API number in international format, e.g. +9665XXXXXXXX.
facebook_page_idNoFor messenger: the Facebook Page ID that receives the messages.
landing_page_urlNo
lead_destinationNoFor 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_idNoOptional messaging event set (from a TikTok Messaging Partner). With it the ad group optimises for conversations; without it, for clicks to chat.
excluded_audience_idsNo

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 insightsA
Read-only
Inspect

Rank ads by efficiency: best and worst creatives by cost per result and CTR, with video hook rate (2s views / impressions) and completion rate.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.8/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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 identitiesB
Read-only
Inspect

Identities (TikTok accounts or custom display names) the advertiser can run ads as. An identity is needed to create ads.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 formsC
Read-only
Inspect

Instant (lead) forms on the advertiser, needed for lead-generation campaigns that collect leads inside TikTok.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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 performanceA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoPreset period. Default LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 adA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
id_or_nameYes
confirm_nameNo

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 groupC
Destructive
Inspect

Rename a campaign or ad group.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
new_nameYes
id_or_nameYes

TDQS

C2/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness1/5

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.

Parameters2/5

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.

Purpose2/5

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.

Usage Guidelines2/5

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)B
Read-only
Inspect

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).

NameRequiredDescriptionDefault
levelYes
limitNo
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
metricsYes
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
dimensionsYes
start_dateNoYYYY-MM-DD (with end_date).
report_typeNoAUDIENCE for age/gender/country/platform dimensions.

TDQS

B3.4/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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 locationsA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
queryYes
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
countryNoCountry code to narrow results, e.g. SA.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 adA
Destructive
Inspect

Pause runs immediately. Activating starts spending: the first call returns a preview; ask the user, then call again with confirm=true.

NameRequiredDescriptionDefault
levelYes
folderNoClient folder name.
statusYes
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
id_or_nameYes

TDQS

A3.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines4/5

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 auditA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 bidA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
bidYes
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
adgroupYes
confirmNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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 budgetA
Destructive
Inspect

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.

NameRequiredDescriptionDefault
levelYes
budgetYes
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
confirmNo
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
id_or_nameYes

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

NameRequiredDescriptionDefault
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
media_idNoA file the user attached in the Go Shift chat (media_id from the [attachment …] marker). Use instead of the URL.
file_nameNo
video_urlNo

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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 spendA
Read-only
Inspect

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.

NameRequiredDescriptionDefault
detailNosummary (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.
folderNoClient folder name.
accountNoTikTok advertiser account name or ID. Optional when only one is enabled.
end_dateNoYYYY-MM-DD.
languageNoLanguage of the card: the language the user is writing in (ar for any Arabic dialect).
date_rangeNoDefault LAST_30_DAYS.
start_dateNoYYYY-MM-DD (with end_date).

TDQS

A3.7/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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
Vendor relationship
First-party · 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

Related MCP Servers

  • A
    license
    B
    quality
    C
    maintenance
    Enables 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.
    21
    MIT
  • A
    license
    Not graded
    quality
    F
    maintenance
    Connects Google Ads, Meta Ads, and LinkedIn Ads to AI assistants, enabling natural language ad campaign management, reporting, and optimization across platforms.
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables 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.
    106
    MIT
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources