Meta Ads MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.119
Disambiguation4/5
Most tools have clearly distinct purposes, but there is potential confusion between get_ad_creatives and get_creative_details, and between search and search_ads_archive. The descriptions help clarify, but an agent could still misselect.
Naming Consistency4/5
Tools follow a consistent verb_noun pattern (create_, get_, update_, search_, etc.) with only minor deviations like 'fetch' and slight plural/singular inconsistency (get_ad_accounts vs get_account_info).
Tool Count3/5
With 36 tools, the set is on the higher side. While the domain of Meta Ads is complex and many tools are justified, the count exceeds the typical well-scoped range. Some tools like fetch and search could be merged without loss.
Completeness4/5
Core CRUD operations for campaigns, ad sets, ads, and creatives are present, along with thorough targeting search tools. However, deletion tools are missing, and there are no tools for custom audiences or pixel management, which are common needs.
Average 4.1/5 across 36 of 36 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 5 of 13 community issues answered or closed in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It does not disclose behavioral traits: no mention of read-only nature, what 'detailed information' includes, or any side effects/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?
Description is brief and front-loaded with purpose. Includes an example, though slightly redundant. Still efficient with no superfluous 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?
Given the presence of an output schema and only two simple params, the description is adequate but lacks context on output structure or limitations. It could benefit from mentioning what 'detailed information' includes.
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?
Description explains adset_id and access_token, noting that access_token is optional and caching behavior. This adds value beyond the schema alone. However, it doesn't specify the expected format of adset_id (e.g., numeric).
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 states 'Get detailed information about a specific ad set.' This provides a clear verb and resource. However, it doesn't differentiate from sibling tools like get_adsets which might list all adsets, lacking specificity.
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 tool versus alternatives like get_adsets or get_campaign_details. The example shows invocation format but does not clarify context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the full burden. It mentions that access_token is optional and cached tokens may be used, which is useful. However, it lacks details on side effects, rate limits, pagination, or guarantees of idempotency, which are important for a searching 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 structured as a docstring with Args and Returns sections, making it easy to parse. It is relatively concise, though some sentences are longer than necessary. Overall 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?
The description mentions an output schema (JSON response with matching pages) but does not elaborate on the structure or fields. Given the sibling tools and simplicity of the tool (3 params, no enums), the description provides a minimum viable context but leaves room for clarification on the return format and error handling.
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 0%, but the description adds meaning beyond the schema by explaining each parameter's format and optionality (e.g., account_id format act_XXXXXXXXX, access_token optional, search_term optional). This is basic and does not provide deeper semantics like allowed values or constraints.
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 states the tool searches for pages by name within an account, with a specific verb and resource. It distinguishes from siblings like get_account_pages (which likely lists all pages) by specifying the search by name aspect, though it could be more explicit about the return type.
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 tool versus alternatives such as get_account_pages or the general search tool. The description only states what it does but does not provide context for when to prefer it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses token caching behavior but omits authentication requirements, error handling, and effects of invalid inputs. Minimal transparency.
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 plus a parameter list with no redundancy. Every part is essential and front-loaded. Highly 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 simple lookup tool with output schema, the description is minimally adequate. However, amid many sibling tools, it lacks comparative context to guide selection.
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 0%, so the description adds needed context: ad_id is a Meta Ads ID, access_token is optional and cached. This compensates well, though further specifics like ID format would improve.
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 states the tool retrieves detailed information about a specific ad, using a specific verb and resource. It distinguishes from list tools like get_ads but could be more precise about what 'detailed information' includes.
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 tool versus alternatives like get_creative_details or get_ad_creatives. The description only lists parameters without context on selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool gets information (implying a read operation) and notes that the access_token is optional (using cached token). However, it does not disclose rate limits, error conditions, or the exact behavior when the token is missing. Additional details about the optional token behavior help but could be more thorough.
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 description is relatively concise but includes a verbose note about Meta API fields and code modifications. This adds useful context but sacrifices brevity. The key information is front-loaded in the first sentence, but the note could be streamlined.
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?
Given the tool's simplicity (2 params, 1 required) and the presence of an output schema, the description adequately covers the basic functionality. It explains the parameters and the optional token behavior. The hint about adding fields is a bonus. However, it does not mention pagination or response structure, but the output schema may cover that.
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 0% schema description coverage, the description must compensate. It explains that campaign_id is a Meta Ads campaign ID and access_token is optional with caching behavior. This adds meaning beyond the raw schema (which only specifies 'string' and 'null'). However, it does not describe constraints like ID format or token scope, 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?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific campaign'. The tool name and description align well, distinguishing it from siblings like 'get_campaigns' (list) and 'get_ad_details'. However, it does not explicitly differentiate from all siblings, which would warrant 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?
The description provides minimal usage guidance. It mentions that the function requests a specific set of fields and hints at extensibility, but it does not specify when to use this tool versus alternatives like 'get_campaigns' (for listing) or update tools. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'get detailed information,' implying a read operation, but does not explicitly state it is read-only, mention authorization requirements beyond an optional token, or describe side effects. The minimal description is insufficient for a safe agent decision.
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 description is concise: one sentence for purpose, then a clean parameter list. It is front-loaded with the main action and wastes no words. Every sentence serves a purpose.
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?
Given the presence of an output schema, return values need not be described. However, the description lacks behavioral context (e.g., error conditions, rate limits, permissions). With no annotations, this is a significant gap for a simple tool. The description feels incomplete and fails to provide a complete picture.
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 0%, so the description must compensate. It lists parameters with brief labels ('creative_id: Meta Ads creative ID (required)', 'access_token: Meta API access token (optional)'), adding basic meaning beyond the schema types. However, it lacks details on formats, constraints, or examples, so it provides marginal added value.
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 'Get detailed information about a specific ad creative by its ID,' which clearly identifies the action (get), resource (ad creative), and scope (specific, by ID). This distinguishes it from siblings like 'get_ad_creatives' that list creatives or 'get_ad_details' for ads.
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 description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage when a creative ID is known, but fails to mention when not to use it or suggest siblings like 'create_ad_creative' or 'update_ad_creative.' No exclusion criteria or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior but only states it returns record IDs. It does not mention read-only nature, pagination, rate limits, or authentication details beyond a cached token option.
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 description is concise and well-structured, with a clear purpose statement, Args and Returns sections, and example usage. No superfluous content exists.
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?
The description is adequate for basic use but lacks details on pagination, scope limitations, and handling of large result sets. The presence of an output schema partially mitigates the need for return value explanations.
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?
Given 0% schema description coverage, the description adds value by explaining both parameters: query as a search string and access_token as optional with fallback to cached token. This compensates for the schema's lack of documentation.
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 states the tool searches Meta Ads data and returns matching record IDs across multiple resources. However, it does not differentiate this general search from more specific sibling tools like search_ads_archive or search_interests, leaving ambiguity about when to use which.
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 description lacks guidance on when to use this tool versus alternatives. No explicit conditions or exclusions are provided, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It notes that changing creative_id alters the ad's image/content, but it does not mention idempotency, side effects, required permissions, or whether other parameters cause authoritative updates. Overall, behavioral depth is insufficient.
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 description is a concise paragraph followed by a bulletized list of parameters. It is front-loaded with the main purpose, and every sentence/line adds value without redundancy or fluff.
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?
Given 7 parameters, no schema descriptions, and no annotations, the description covers parameter meanings adequately. However, it lacks information on return values (output schema exists but unmentioned), error handling, prerequisites (e.g., ad existence), and potential side effects on other ad components. It is moderately complete but could be richer.
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 0% schema description coverage, the description compensates by explaining all 7 parameters. It adds meaningful context: ad_id type, name as new name, status examples, bid_amount unit (cents for USD), tracking_specs purpose, creative_id effect, and access_token fallback. This is helpful, though tracking_specs could be more precise.
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 clearly states 'Update an ad with new settings,' specifying the verb (update) and resource (ad). It distinguishes from sibling tools like create_ad (creation) and update_ad_creative (creative-specific), providing clear purpose.
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 description lists updatable fields but offers no guidance on when to use this tool versus alternatives such as update_ad_creative or when not to use it. No context on prerequisites or decision criteria is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions that access_token is optional and uses a cached token, which adds clarity. However, it does not state whether the operation is read-only, potential side effects, rate limits, or error behaviors.
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 concise: a single sentence defining the purpose followed by structured Args/Returns sections. It is well-organized and front-loaded, though the Returns line is somewhat 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?
The output schema exists, so describing return fields is not necessary. However, the description lacks context on pagination, error handling, or how the account_id relates to other tools. It is sufficient but incomplete for a tool with no annotations.
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 0%, but the description adds meaningful parameter details: account_id format (act_XXXXXXXXX) and access_token behavior (optional, uses cached token). This goes beyond the schema's type and required constraints.
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 clearly states the tool retrieves pages associated with a Meta Ads account. The verb 'Get' and resource 'pages' are specific, and it distinguishes itself from siblings like 'get_account_info' and 'search_pages_by_name' which target different resources.
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 description provides no guidance on when to use this tool versus alternatives like 'search_pages_by_name' or 'get_account_info'. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination behavior, ordering, or side effects. It only describes the basic operation (read) without clarifying limits or error handling, which is insufficient given the absence of 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?
The description is concise with a single sentence summary followed by a structured Args block. It is front-loaded and every sentence provides useful information, though the Args block slightly repeats schema info without being verbose.
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?
Given the tool simplicity and existence of an output schema, the description covers basic functionality and parameters. However, it lacks context on edge cases (no results), error messages, or rate limits, leaving it minimally complete for a production setting.
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 0%, so the description compensates by explaining account_id format ('act_XXXXXXXXX'), access_token optionality with cached token note, limit default, and campaign_id optionality. This adds value beyond the schema, though it could detail limit behavior or filter semantics more.
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 clearly states 'Get ad sets for a Meta Ads account with optional filtering by campaign.' It specifies the verb 'Get', the resource 'ad sets', the context 'Meta Ads account', and an additional feature. This distinguishes it from siblings like get_ads (different resource) and get_adset_details (specific ad set).
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 mentions optional filtering by campaign but does not explicitly state when to use this tool vs alternatives like get_adset_details or get_ads. There is no guidance on prerequisites or use cases, leaving the agent to infer context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It only mentions that amount_spent and balance are in currency units, but fails to disclose pagination behavior, error cases, token permission requirements, or data freshness. This is insufficient for a tool that likely returns a list of sensitive financial 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 description is extremely concise: first sentence states purpose, then a note about behavior, then the parameter list. No filler words. The parameter list uses a clear 'name: explanation' format. Front-loaded with key 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 tool with 3 optional parameters and an output schema, the description covers the basic semantics and a behavioral note (currency units). However, it omits important context like whether results are paginated, how to handle errors, or what happens when no ad accounts are available. The output schema exists but the description should still provide enough context for an agent to decide whether to call the tool.
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 0%, so the description must compensate. It explains all three parameters: access_token (optional, cached), user_id (default 'me'), limit (maximum accounts, default 200). This adds value beyond the schema's type annotations, but could be improved by clarifying the format of access_token or user_id.
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 clearly states 'Get ad accounts accessible by a user', which is a specific verb and resource. It distinguishes itself from sibling tools like get_ads and get_campaigns by focusing on ad accounts and user accessibility. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when listing ad accounts for a user, but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or when-not scenarios. The presence of similar sibling tools (e.g., get_account_info) suggests differentiation is needed, but none is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits such as authentication requirements (beyond an optional token), rate limits, or side effects. The description is minimal and does not add significant context beyond the obvious.
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 description is concise and well-structured: a one-line purpose, then each parameter with description, and a return value description. Every sentence is informative with no wasted words.
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?
Given the absence of annotations and low schema coverage, the description covers input parameters and return format adequately but lacks context on prerequisites, error scenarios, or how this tool fits among siblings. It is minimally complete.
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 0%, so the description must compensate. It explains that access_token is optional and defaults to null, with caching behavior noted, and limit has a default of 50 and a description. This adds meaningful value beyond 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?
The description clearly states the tool retrieves 'all available behavior targeting options', with a specific verb ('Get') and resource ('behavior targeting options'). It distinguishes from sibling search tools like search_demographics and search_interests by specifying 'behavior'.
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 lacks explicit guidance on when to use this tool versus alternatives. No 'when not to use' or comparison to similar sibling tools is provided; the name alone differentiates it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds value by explaining optional token caching, default fields, and a critical nuance for prepaid account balance calculation. However, it does not disclose read-only status, required permissions, or rate limits, leaving some behavioral aspects opaque.
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 starts with a clear one-line purpose, then lists parameters in a structured format. The prepaid account explanation is valuable but adds length; overall it is reasonably concise without unnecessary redundancy.
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?
The description covers purpose, parameter semantics, and a key edge case (prepaid balance). With an output schema present, return value documentation is not needed. It does not discuss prerequisites or error handling, but is generally adequate for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully explains all three parameters: account_id format (act_XXXXXXXXX), access_token caching behavior, and fields parameter with default list and prepaid account note. This exceeds the baseline and compensates for the missing schema descriptions.
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 clearly states 'Get detailed information about a specific ad account,' specifying both the action (get) and resource (ad account). This clearly distinguishes it from sibling tools like get_ad_accounts (which lists accounts) and get_insights (analytics).
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 description provides no guidance on when to use this tool versus alternatives, such as when to use get_ad_accounts for listing or get_campaign_details for campaign-specific info. It lacks explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions caching behavior for access_token but lacks disclosure of rate limits, pagination, or read-only nature. Adequate but not thorough.
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 well-structured with a summary, Args list, and example. It is reasonably concise but the curl example is somewhat lengthy, though useful for developers. Front-loaded with primary purpose.
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?
Given the output schema exists, the description does not need to explain return values. It covers all parameters and provides an example. However, it lacks pagination details and rate limit notes, but for a search tool with six parameters, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds essential meaning for all 6 parameters. It provides clear explanations, examples (e.g., country codes), and optionality details, fully compensating for missing schema descriptions.
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 clearly states 'Search the Facebook Ads Library archive', using a specific verb and resource. It distinguishes from sibling tools like generic 'search' by specifying it's for the Facebook Ads Library.
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 explicit guidance on when to use this tool versus alternatives like 'search' or other ad-related tools. The description does not mention when not to use it or provide context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses many behavioral traits: warnings about immutable fields, deprecated parameters, field requirements, and optional token usage. It notes that certain changes require creating a new ad set. However, it does not mention the return value or side effects like overwriting existing settings.
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 structured with line breaks separating parameters, and the purpose is front-loaded. Despite its length (22 parameters), each entry is concise and informative. Some repetition could be avoided (e.g., similar warnings for different fields), but overall it is well-organized for a complex 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?
Given the tool's complexity (22 parameters), the description covers all necessary details including constraints and warnings. An output schema exists but is not referenced; describing the return value (e.g., 'returns the updated ad set') would improve completeness. Nevertheless, the description is thorough and handles edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so excellently by providing detailed semantics for each parameter: examples, valid values, interdependencies, requirements, and warnings. For bid_strategy, it lists all valid options and notes; for bid_constraints, it gives a concrete example. This far exceeds the schema's bare information.
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 states the tool's purpose: 'Update an ad set with new settings including frequency caps and budgets.' The verb 'Update' and the required adset_id parameter indicate modification of an existing ad set, but it does not explicitly differentiate from sibling tools like create_adset or update_campaign beyond the 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?
The description provides minimal usage guidance. It includes specific warnings (e.g., is_dynamic_creative is immutable, attribution_spec unsupported) but lacks general guidance on when to use this tool versus alternatives like create_adset or update_ad. No explicit exclusions or context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the creation action and a specific failure case (dynamic creative error) but omits details like permission requirements, side effects (e.g., ad status transitions), or success response format (though an output schema exists). The description provides some transparency but lacks completeness 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?
The description is concise with a clear first sentence stating the purpose, followed by a well-structured parameter list and a relevant note. Every sentence adds value without redundancy.
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?
Given the tool's complexity (8 parameters, 4 required) and the presence of an output schema, the description adequately covers parameter details but lacks overarching context. It does not differentiate from sibling tools like create_adset or update_ad, nor does it mention typical preconditions (e.g., adset must be in draft status). The dynamic creative note is useful but insufficient for full contextual completeness.
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 input schema has 0% description coverage, so the description compensates well. It explains the format of account_id (act_XXXXXXXXX), default status, and optional bid_amount. It provides a concrete example for tracking_specs and notes access_token optionality. However, some parameters like name and adset_id lack additional explanation, but their names are self-evident.
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 'Create a new ad with an existing creative.' This clearly identifies the tool's action (create) and resource (ad) with a specific constraint (existing creative). It distinguishes from sibling tools like create_ad_creative (which creates the creative itself) and update_ad (modifies an existing 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?
The description lists parameters but does not explicitly state when to use this tool versus alternatives (e.g., when a creative already exists). The note about dynamic creative provides a constraint but not a usage guideline. Minimal guidance on prerequisites or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It mentions that access_token is optional and will use a cached token, which adds some transparency. However, it does not disclose whether the operation is destructive, idempotent, or requires specific permissions, leaving 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, bullet-like Args list, and Returns. While verbose, every sentence is informative. It is appropriately sized for the tool's complexity, though some repetition (e.g., 'budget schedule' twice) could be trimmed.
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?
Given 6 parameters with comprehensive descriptions and an output schema present, the description covers input semantics well. However, it lacks behavioral context (e.g., idempotency, error handling), which prevents a higher score. Returns are mentioned but not detailed, though output schema likely compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter: campaign_id, budget_value (as increase amount), budget_value_type (ABSOLUTE or MULTIPLIER), time_start and time_end as Unix timestamps, and access_token as optional. This adds significant meaning beyond the schema's type definitions.
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 clearly states the tool creates a budget schedule for a Meta Ads campaign and explains its purpose for scheduling budget increases based on anticipated high-demand periods. This distinguishes it from sibling tools like 'create_campaign' or 'create_adset' which create different entities.
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 usage for scheduling budget increases but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or comparisons with sibling tools are provided, leaving the agent with limited guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explains optional token caching and default limit but omits behaviors like pagination, error handling, or whether only active ads 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?
The description is well-structured with bullet points and front-loaded purpose. Minor verbosity (e.g., 'optional - will use cached token if not provided') could be trimmed, but overall efficient.
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?
Given 5 parameters, required account_id, and presence of output schema, the description covers all necessary aspects. It lacks mention of pagination or result scope (e.g., active vs. all ads), but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing each parameter: account_id format, access_token optionality, limit default, and filter fields. Adds significant meaning beyond 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?
The description clearly states 'Get ads for a Meta Ads account with optional filtering,' specifying the verb, resource, and context. It distinguishes from sibling tools like get_adsets or get_campaigns.
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 lists optional filters but does not explicitly guide when to use this tool versus alternatives like search or get_campaigns. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It mentions caching behavior for access_token ('optional - will use cached token if not provided') and defaults, but does not disclose rate limits, authentication requirements beyond the token, or any non-obvious side effects. The read-only nature is implied but not explicitly stated.
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 well-structured with Args and Returns sections. It is concise, with each sentence serving a purpose. However, the main verb 'Get demographic targeting options' could be more prominent at the top. The description is slightly longer than necessary but not wasteful.
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?
Given the tool has 3 optional parameters, no annotations, and an output schema exists, the description covers the purpose, parameter details, and return format (JSON string with fields). It provides enough context for an agent to invoke the tool correctly without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates fully. It explains access_token's caching behavior, demographic_class with explicit options list, and limit's default value. This adds essential meaning that the schema lacks, making the tool usable.
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 clearly states the tool retrieves demographic targeting options. It specifies the purpose with a verb+resource structure and distinguishes from sibling tools like search_interests by detailing the demographic_class parameter with options such as 'life_events' and 'industries'.
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 usage by listing parameters and defaults but does not explicitly state when to use this tool over siblings like search_behaviors or search_geo_locations. No when-not-to-use or alternative guidance is provided, leaving the agent to infer based on parameter options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses behavioral traits like optional access_token caching, default limit, and output format. However, it does not mention rate limits or side effects, but for a read-only tool it is fairly transparent.
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 description is concise, well-structured with a brief purpose followed by clear bullet-like parameter explanations. Every sentence adds value with no redundancy.
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?
The description covers parameters, return, and optional behavior. However, it lacks context about the source of suggestions (e.g., Meta's ad targeting taxonomy) and potential input limitations. Overall fairly complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by providing clear semantics for each parameter: interest_list examples, access_token optionality and caching, limit default. The return value is also described.
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 clearly states the tool's function with a specific verb ('Get') and resource ('interest suggestions'), and differentiates from siblings like search_interests by specifying it is 'based on existing interests.'
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 usage when the agent has a list of interests and wants related suggestions, but does not provide explicit when-not-to-use instructions or mention alternatives among siblings like search_interests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses access_token caching behavior and return format (JSON string with hierarchy). No annotations, but description adequately covers read-only search behavior.
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?
Structured docstring with Args/Returns, but could be slightly more concise. Every sentence adds value.
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?
Covers all parameters, return type, and behavior. Output schema exists, so return details are sufficiently described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description adds full meaning for all 4 parameters: query purpose, access_token optionality, location_types enum list, limit default.
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?
Description clearly states 'Search for geographic targeting locations' with specific verbs and resource. Distinct from sibling tools like search_interests or search_behaviors.
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?
No explicit when-to-use or when-not-to-use guidance. Context implies usage for geo location searches but no exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains that the tool returns a campaign id, warns about start_time limitation, legacy objectives, and bid strategy implications for child ad sets. It does not cover permissions or rate limits.
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 well-structured with a clear overview, a note section, and an args list. It is front-loaded with purpose. However, it could be slightly more concise; some details like the full list of ODAX objectives are repeated.
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?
Given the high parameter count (15) and no annotations, the description covers many aspects: hierarchy context, warnings, return value. It does not address error handling, pagination, or rate limits, but these are not critical for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed explanations for all parameters, including account_id format, objective enums with usage warnings, budget units, bid strategy enums, conditional usage of daily_budget/lifetime_budget, and an example for ab_test_control_setups.
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 clearly states that it creates a Facebook or Instagram ad campaign, specifies it as the first step in the campaign hierarchy, and lists alternative names. It distinguishes from sibling tools by defining its role as the entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (first step of hierarchy) and includes a note about start_time and objective mapping. However, it lacks explicit guidance on when NOT to use this tool versus alternatives like update_campaign or create_adset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description adds one behavioral trait (cached token fallback) but lacks disclosure on side effects, rate limits, or error handling.
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 description is extremely concise (3 sentences + Args) with no redundancy, front-loading the core purpose.
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 2-parameter tool with output schema, the description adequately covers prerequisites and token handling, though it omits potential errors or response details.
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 0% schema description coverage, the description compensates by explaining ad_id as a Meta Ads ad ID and access_token caching behavior, though parameter details remain minimal.
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 clearly states the verb 'Get' and the resource 'creative details for a specific ad', distinguishing it from siblings like get_creative_details.
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?
Explicitly notes the requirement for ad_id, warns against using account_id, and directs users to use get_ads first to obtain ad IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It explains what the tool does (retrieve and visualize image), that access_token is optional, and input formats. However, it does not specify return type (binary, URL, base64) or clarify if 'download' implies side effects.
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?
Well-structured with a clear one-line summary, usage context, and parameter list. The parameter descriptions are concise but informative. A minor redundancy is the note about access_token being optional repeated in the list.
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 specify the return format (binary, base64, URL). It only says 'ready for direct visual analysis', which is vague. It covers parameters and usage context adequately but lacks output details.
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 0%, so description adds value by explaining that account_id accepts 'act_XXXXXXXXX or bare numeric', image_hash is the hash, and access_token is optional with fallback to cached token. This clarifies usage beyond the bare 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?
The description clearly states the action ('Get, download, and visualize') and the resource ('a Meta ad image by its hash'). It distinguishes from sibling tool get_ad_image by specifying when to use each.
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?
Explicitly tells when to use this tool ('when you have an image_hash without an ad') and when to use an alternative ('prefer get_ad_image(ad_id)'). Provides concrete examples of image hash sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the function as a search returning JSON with specific fields. However, it does not disclose any required permissions or potential side effects beyond being a read 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?
The description is concise and well-structured with a one-line summary, clear Args block, and Returns section. Every sentence provides useful information without redundancy.
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?
Given the tool has 3 parameters (1 required) and an output schema, the description covers all essential aspects: parameter explanations, default values, and return format summary. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant value: explains query with examples ('baseball', 'cooking'), mentions access_token is optional and uses cached token, and specifies limit default (25) and purpose.
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 clearly states 'Search for interest targeting options by keyword,' specifying a unique verb and resource. Sibling tools like search_behaviors and search_demographics have distinct names, so this tool stands out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (searching for interests by keyword) but does not explicitly mention when not to use it or suggest alternatives. The context is clear, but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses that it calls Meta's API, handles authentication caching, and returns a JSON string. It also flags deprecated parameters. Lacks details on rate limits or side effects, but for a read-only operation, this is adequate.
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?
Description is well-structured with a one-line summary, then detailed args in a list. Slightly verbose in args section but front-loaded with purpose. Could tighten but still efficient.
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?
Given 6 parameters and presence of output schema, description covers all parameters, usage scenarios, deprecated features, and return format. No gaps noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaning for all 6 parameters: access_token (optional, cached), account_id (required for comprehensive, format), targeting (example JSON), optimization_goal (default, options), and deprecated parameters. This significantly aids correct usage.
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?
Description clearly states it estimates audience size for targeting specifications using Meta's delivery_estimate API. It specifies the verb 'estimate' and the resource 'audience size', and differentiates from sibling tools like search_interests by focusing on estimation rather than searching.
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?
Description provides clear context for when to use comprehensive estimation (with account_id) versus simple interest validation (deprecated parameters). However, it does not explicitly list when not to use this tool or suggest alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the default field subset, optional token handling, pagination via 'after', and filtering behavior. It does not mention rate limits or destructive actions, but adequately explains the read operation.
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 well-structured with sections and bullet points, but slightly verbose. Every sentence adds value; however, some details like valid objectives could be condensed. Still, it is clear and front-loaded.
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?
Given 6 parameters, no schema descriptions, no annotations, and presence of an output schema, the description is remarkably complete. It covers all parameters, default behavior, pagination, and filtering nuances, making it fully self-contained for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds thorough meaning: explains account_id format, access_token optionality, limit default, status_filter mapping and array handling, objective_filter valid values and examples, and after for pagination. This fully compensates for the schema gap.
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 clearly states it retrieves campaigns for a Meta Ads account with optional filtering, using specific verbs and resources. It distinguishes from sibling tools like get_campaign_details, get_ads, etc.
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?
Provides clear context on when to use, explains the default field behavior and the limitation of not exposing all fields. It indirectly suggests when not to use (if all fields needed) but does not explicitly enumerate alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses critical behaviors: campaign cannot use start_time, CBO→ABO migration mechanics with atomicity, deprecation of use_adset_level_budgets, and that objective may not always be updatable. This is exemplary transparency.
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 well-organized with a purpose statement, informative note, migration section, and parameter list. While lengthy, every part earns its place. Could be slightly more concise, but clarity is prioritized over brevity.
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?
Covers all parameters, includes migration guidance, deprecation info, and a key constraint. An output schema exists so return values are assumed covered. Missing mention of errors or rate limits, but given complexity this is acceptable.
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 has 0% description coverage, so description must explain all 14 parameters. It provides meaningful descriptions for each, including units, examples for adset_budgets, and notes on optional vs required. Some parameters like bid_strategy lack possible values, but overall adds significant value beyond schema titles.
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 clearly states 'Update an existing campaign in a Meta Ads account.' This directly conveys the tool's action and resource, distinguishing it from sibling tools like create_campaign or get_campaign_details.
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?
Provides clear context: start_time note, migration details, and deprecation warning. However, it does not explicitly state when to use this tool versus create or get tools, though the name and first line are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the algorithm (largest centered region matching aspect ratio, equivalent to 'Original' crop) and notes validation for invalid keys. It does not mention rate limits or auth, but those are likely standard and not hidden.
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 description is well-structured with clear Args and Returns sections, is concise, and includes examples. Every sentence adds value with no redundancy.
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?
Given the tool has 3 parameters, an output schema, and is a preparatory helper, the description fully explains the input, output format, and usage. It mentions validation and provides a ready-to-use result, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning for all parameters. It does: image_width/height are pixels with examples, crop_keys is optional and defaults to all 6 keys with explanations. This fully compensates for the lack of schema descriptions.
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 clearly states it computes crop coordinates for a source image of given dimensions, using the specific verb 'compute' and explicitly linking the output to 'create_ad_creative' or 'bulk_create_ad_creatives'. This distinguishes it from sibling tools like those that actually create ads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent to use this tool before creating ad creatives to get the crop coordinates. It implies it is a preparatory step but does not explicitly state when not to use or mention alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description fully handles behavioral disclosure. Explains two methods for image input (file vs image_url), optional access_token, default name behavior, and details return object structure including image_hash and images list. No mention of destructive actions or limits, but behavior is well-covered.
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?
Description is concise with a one-line summary followed by clearly labeled Args and Returns sections. No extraneous information; every sentence contributes to understanding.
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?
Given 5 parameters, no annotations, and presence of an output schema (which is compensated by the description's return section), the description is complete. It explains input, output, and ties to other tools (create_ad_creative, get_image_by_hash). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description adds full meaning for each parameter: account_id format 'act_XXXXXXXXX', file as data URL or base64, image_url as direct URL, access_token optional with fallback, name defaults to filename. This compensates fully for the schema's lack of descriptions.
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?
Clearly states 'Upload an image to use in Meta Ads creatives.' Identifies the specific resource (image) and action (upload), distinguishing it from retrieval tools like get_ad_image and creative-building tools like create_ad_creative.
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?
Provides context on when to use (for ad creatives) and how output image_hash ties into create_ad_creative and get_image_by_hash. Lacks explicit 'when not to use' but implies the tool is for uploading, not for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the critical API limitation on content fields and notes that many parameters may be rejected. However, it omits potential behaviors like rate limits or authentication requirements beyond the optional access token, which could be relevant for agents.
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 well-structured with a clear title, an important note, and an organized Args list. However, it is lengthy and could be more concise by grouping some content fields under a single note to reduce repetition without losing clarity.
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?
Given the tool's complexity (15 parameters, 1 required, no enums), the description covers the key limitations, parameter behaviors, and provides a Returns section. It fully compensates for the lack of schema descriptions and gives enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the input schema has no descriptions (0% coverage), the description's Args section provides essential meaning for all 15 parameters. It distinguishes between single and plural variants, notes which ones are likely to be rejected, and explains the usage of ad_formats and creative_features_spec. This goes well beyond the schema's scope.
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 clearly states the tool updates an existing ad creative's name or optimization settings, specifying the verb 'update' and the resource 'ad creative'. It distinguishes itself by noting the limitation on content fields, which differentiates it from other tools like create_ad_creative or update_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?
The description explicitly states that the Meta API does not allow updating content fields, so this tool should only be used for name and optimization settings. It provides an alternative workflow: create a new creative and update the ad reference via update_ad. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavioral traits: error codes (error_subcode=1487390, error 1885800), video processing delays with retry logic, Meta silently collapsing multiple image_hashes in DOF mode, auto-handling of ad_formats for videos, and quirks like link_url requirement for asset customization. It goes beyond basic expectations.
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 very long but well-structured with sections for creative modes, parameter details, and examples. It front-loads the purpose and modes, then uses bullet points and clear headings. Some redundancy exists (e.g., asset_customization_rules explained twice), but the structure supports the tool's complexity.
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?
Given the high complexity (35 parameters, multiple modes, error handling) and minimal output schema, the description covers interactions, constraints, and behavioral notes comprehensively. However, the return value description is minimal ('JSON response with created creative details'), lacking details about typical response fields or status codes, which could be improved for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by detailing each of the 35 parameters: formats (e.g., account_id as 'act_XXXXXXXXX', instagram_actor_id as string), constraints (e.g., 'cannot be used with image_hash'), nested structures (e.g., messages as string or dict, asset_customization_rules format), and caveats (e.g., phone_number E.164 format and internal handling). The description adds significant meaning beyond the raw 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?
The description clearly states 'Create a new ad creative' and lists six distinct creative modes (existing post, simple image/video, multi-variant copy, placement customization, dynamic creative, FLEX/Advantage+). It distinguishes the tool from siblings like create_ad and compute_image_crops by focusing on creative creation.
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?
The description provides explicit guidance on when to use each creative mode and how to combine parameters, including mutual exclusivity rules (e.g., image_hash vs video_id vs object_story_id) and prerequisites (e.g., link_url required for asset customization even for lead ads). It also warns about common errors and suggests alternatives like using compute_image_crops before image_crops.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden. It discloses many behaviors: frequency_control_specs immutability after creation, promoted_object cannot be added via update, bid_adjustments requires allowlisted capability, error subcodes, and the need for DSA fields for EU targeting.
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 description is well-structured with each parameter on a new line, but it is very long and verbose. It could be more concise by summarizing some lists (e.g., valid optimization_goal values) or linking to external documentation. However, it is well-organized and front-loaded with the purpose.
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?
Given the complexity of the tool (26 parameters, no annotations, no schema descriptions), the description is exceptionally complete. It covers budget inheritance, bid strategies, targeting defaults, regulatory fields, and even error subcodes. An agent can confidently invoke this tool with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates with detailed explanations for each of the 26 parameters. It provides valid values, formats, examples, constraints, and relationships. For example, optimization_goal lists all valid values per destination_type, bid_strategy specifies which require bid_amount, and frequency_control_specs gives an example and immutability note.
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 clearly states 'Create a new ad set in a Meta Ads account.' This provides a specific verb (create) and resource (ad set). It distinguishes itself from sibling tools like update_adset and create_campaign.
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?
The description provides extensive when-to-use and when-not-to-use guidance, e.g., CBO budget inheritance ('Do NOT set this if the parent campaign already has a budget'), bid_amount requirements per bid strategy, and valid optimization_goal combinations per campaign objective. It also warns against using invalid values like 'LOWEST_COST' and 'ON_AD' for OUTCOME_ENGAGEMENT.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While no annotations exist, the description discloses the read-only nature (get/download) and that it returns the currently serving image. Could mention if any side effects or rate limits, but adequate overall.
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?
Concise: main action in first sentence, alternate usage in second, then Args/Returns. No wasted words.
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 simple retrieval tool, the description covers purpose, input, output, and alternatives. No output schema needed given the simple return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains both parameters: ad_id as Meta Ads ad ID, access_token as optional with caching behavior, adding significant value beyond the bare 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?
The description clearly states the tool gets, downloads, and visualizes the image attached to an existing Meta ad, distinguishing it from get_image_by_hash which is for image hash lookups.
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?
Explicitly states when to use (have ad ID) and when to avoid (only have image hash), and provides the alternative get_image_by_hash.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure responsibility. It thoroughly explains behavior: polling for video status, error prevention by waiting for 'ready' status, and the advantage of providing account_id to avoid API errors. The video_status field values ('processing', 'ready') are clearly documented.
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 description is well-structured with two paragraphs and a bulleted list. It is concise yet comprehensive, with each sentence adding value. The front-loaded purpose statement is immediately clear.
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?
Given the tool has 4 optional parameters, no enums, and an output schema, the description covers all necessary aspects: purpose, parameters, usage context (polling, error avoidance), and behavioral details. An agent can correctly select and invoke this tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates excellently. It explains each parameter's purpose: ad_id auto-extracts video, video_id for direct use, account_id enables advideos edge, and access_token is optional. This provides critical context beyond the bare 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?
The description clearly states the tool's purpose: 'Get video details and source URL for a Meta ad video creative.' It lists specific outputs (source URL, thumbnail, status, metadata) and distinguishes from sibling tools like get_ad_image by focusing on video-specific data and polling usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool, particularly for polling after bulk_upload_ad_videos. It explains the relationship with create_ad_creative and the importance of waiting for 'ready' status. However, it does not explicitly list alternatives or when not to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it returns a clickable link and uses cached token if no access_token provided. Without annotations, it provides good behavioral context, though could mention prerequisites like prior authentication setup.
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?
Concise, well-structured with a note on usage, parameter description, and return value. Front-loaded with purpose.
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?
Given the simple tool (one optional param, output schema present), the description covers purpose, usage guidelines, parameter semantics, and return type completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds full meaning: 'access_token: Meta API access token (optional - will use cached token if not provided)' clarifies parameter role and behavior.
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 clearly states it 'Get a clickable login link for Meta Ads authentication,' using a specific verb and resource. Among sibling tools focused on ad operations, this authentication tool is distinctly different.
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?
Explicitly tells when to use (own Facebook app) and when not (recommended Pipeboard authentication with environment variable). Also advises on parameter usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully discloses behavior: it only returns cached records, does not make direct API calls, and returns 'Record not found' if not cached. This is comprehensive.
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 well-structured with clear sections (main statement, limitations, alternatives, args, returns). It is front-loaded and every sentence adds value, though slightly verbose in the limitations part.
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 single-parameter tool with an output schema (implied), the description covers the essential constraint (caching requirement) and return behavior. It is complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema: it specifies the required format ('type:id') and the constraint that the ID must have been returned by a previous 'search' call. Since schema coverage is 0%, this fully compensates.
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 tool clearly states its purpose: 'Fetch a record previously returned by the 'search' tool in the same session.' It specifies the verb (Fetch), resource (cached record), and distinguishes from siblings by listing alternative tools for direct lookups.
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?
Explicit guidance is provided: when to use (after a 'search' call), when not to use (for direct lookups by ID), and alternatives are named (get_campaign_details, get_adset_details, etc.). This meets the highest standard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: fixed field return, auto-handling of platform_position and media_type breakdowns, restrictions on unsupported fields, pagination details, and the impact of the compact parameter. This provides complete transparency for an AI 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?
The description is long but well-organized with clear sections and bullet points. While every sentence adds value, the length could be slightly reduced for quicker scanning. However, given the tool's complexity, the structure earns a high score.
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?
Given the tool's high parameter count (14), lack of schema descriptions, and complex behaviors, the description covers all necessary context: parameter details, constraints, auto-behaviors, and even alternative tool recommendations. The output schema exists, so return value explanation is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description exhaustively explains each parameter: object_id aliases, time_range presets with examples, breakdown valid values with notes and auto-applied behaviors, level, limit, after, attribution windows, action_breakdowns, and compact. This adds immense meaning beyond the bare 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?
The description clearly states the tool retrieves performance insights for campaigns, ad sets, ads, or accounts. It distinguishes itself from sibling tools like get_ad_details by focusing on aggregated insights rather than individual entity details.
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?
The description provides explicit guidance on when to use this tool versus alternatives, such as recommending bulk_get_insights for large result sets or when only specific metrics are needed. It also clarifies limitations like fixed field sets and potential response size issues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![meta-ads-mcp MCP server](https://glama.ai/mcp/servers/pipeboard-co/meta-ads-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pipeboard-co/meta-ads-mcp)

Score Badge

Copy to your README.md:

[![meta-ads-mcp MCP server](https://glama.ai/mcp/servers/pipeboard-co/meta-ads-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pipeboard-co/meta-ads-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pipeboard-co/meta-ads-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server