Meta Ads MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries between resource types (ads, ad sets, campaigns, creatives) and actions (create, get, update, search). However, some potential confusion exists between 'get_ad_details' and 'get_ad_creatives', and between 'search' and 'search_ads_archive', as their descriptions overlap slightly in scope.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with clear conventions: create_*, get_*, update_*, search_*, estimate_*, fetch, upload_*. All tools use snake_case consistently, making the naming scheme predictable and easy to understand.
Tool Count3/5
With 33 tools, this is a large set that feels heavy for typical MCP usage. While Meta Ads is a complex domain, many tools could potentially be consolidated (e.g., multiple get_* tools for different resource types). The count borders on overwhelming for agents to navigate efficiently.
Completeness5/5
The tool surface provides comprehensive coverage of the Meta Ads domain, including full CRUD operations for all major resources (campaigns, ad sets, ads, creatives), targeting research tools, insights retrieval, authentication helpers, and image management. No obvious gaps exist for core advertising workflows.
Average 3.5/5 across 33 of 33 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
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 are provided, so the description carries the full burden. It states it 'gets detailed information,' implying a read-only operation, but doesn't disclose behavioral traits like authentication requirements (beyond the optional access_token), rate limits, error handling, or what 'detailed information' includes. The description is minimal and lacks crucial context for safe and effective use.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly. The 'Args' section and example are relevant but could be more integrated. There's minimal waste, though the example is somewhat redundant with the args explanation.
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 has an output schema (which likely defines the return structure), the description doesn't need to explain return values. However, with no annotations, 2 parameters (one optional), and 0% schema coverage, the description is incomplete: it lacks behavioral context (e.g., auth, errors) and doesn't fully document parameters. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds some semantics: it explains 'adset_id' as 'Meta Ads ad set ID' and 'access_token' as 'Meta API access token (optional - will use cached token if not provided).' This clarifies the token's optionality and caching behavior, but doesn't fully compensate for the coverage gap (e.g., no format or constraints for adset_id).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a specific ad set.' It specifies the verb ('Get') and resource ('ad set'), and distinguishes it from sibling tools like 'get_adsets' (which likely lists multiple) by focusing on a single specific ad set. However, it doesn't explicitly contrast with 'get_ad_details' or other detail-retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_adsets' (for listing) or 'get_ad_details' (for ad-level details), nor does it specify prerequisites or contexts where this tool is preferred. The example only shows how to call it, not when.
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 mentions that 'access_token' is optional with caching behavior and 'search_term' is optional with fallback to returning all pages, which adds some behavioral context. However, it lacks details on permissions, rate limits, pagination, error handling, or what 'matching pages' entails (e.g., format, fields). For a search tool with no annotations, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The 'Args' and 'Returns' sections are structured clearly, though slightly verbose. Every sentence adds value, but it could be more streamlined (e.g., combining optional explanations).
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 no annotations, 3 parameters with 0% schema coverage, and an output schema exists (so return values are documented elsewhere), the description is moderately complete. It covers the basic purpose and parameter semantics but lacks behavioral details like error cases, rate limits, or sibling tool differentiation. For a search tool in this context, it's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for all three parameters: 'account_id' is explained as 'Meta Ads account ID (format: act_XXXXXXXXX)', 'access_token' as optional with caching, and 'search_term' as optional with fallback behavior. This provides useful semantics beyond the bare schema, but doesn't fully cover validation rules or examples. Baseline is 3 due to moderate compensation.
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: 'Search for pages by name within an account.' It specifies the verb (search) and resource (pages by name), but doesn't explicitly differentiate from sibling tools like 'get_account_pages' or 'search' (which might have broader scope). The purpose is clear but lacks sibling distinction.
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. It doesn't mention sibling tools like 'get_account_pages' (which might list all pages without search) or 'search' (which might search across different resources). There's no context about prerequisites, timing, 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?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions the access token is optional and will use a cached token if not provided, which is useful. However, it lacks details on permissions needed, rate limits, error handling, or what 'detailed information' entails, leaving significant gaps for a tool that fetches 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 front-loaded with a clear purpose statement, followed by concise parameter explanations in a structured 'Args:' section. Every sentence adds value without redundancy, making it efficiently sized and well-organized.
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 has an output schema (which should cover return values) and no annotations, the description is moderately complete. It explains the purpose and parameters but lacks usage guidelines and sufficient behavioral context (e.g., auth requirements beyond token caching). For a data-fetching tool with 2 parameters, it's adequate but has clear gaps in guiding the agent.
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 adds meaning by explaining 'ad_id' as a 'Meta Ads ad ID' and 'access_token' as optional with caching behavior, which clarifies beyond the schema's basic types. However, it doesn't cover format specifics (e.g., ad_id structure) or other potential constraints, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about a specific ad'), making the purpose evident. It distinguishes from siblings like 'get_ads' (which lists multiple ads) by specifying retrieval of details for a single ad, though it doesn't explicitly name alternatives.
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 is provided on when to use this tool versus alternatives like 'get_ads' or 'search_ads_archive'. The description only states what it does, not when it's appropriate or what distinguishes it from similar tools in the sibling list.
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 for behavioral disclosure. It mentions 'optional filtering' and default values, but doesn't describe important behaviors like pagination, rate limits, authentication requirements beyond the token parameter, error conditions, or what happens when no ads match filters. For a read operation with 5 parameters, this leaves significant gaps in understanding how the tool behaves.
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 opening sentence followed by a parameter breakdown. Each parameter explanation is concise and directly relevant. There's no wasted text, though the formatting with 'Args:' and bullet-like structure could be slightly more polished. Overall, it's efficiently sized for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, but does have an output schema, the description is moderately complete. The parameter explanations are strong, but behavioral aspects are under-specified. The output schema existence means return values don't need description, but other contextual factors like authentication flow, error handling, and sibling tool relationships are missing. For a read operation with filtering, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides excellent parameter semantics despite 0% schema description coverage. It explains each parameter's purpose, format requirements for account_id, optional nature of access_token with fallback behavior, default value for limit, and filtering purpose for campaign_id and adset_id. This fully compensates for the lack of schema descriptions and adds meaningful context beyond just parameter names.
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 resource ('ads for a Meta Ads account'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_ad_details' or 'search_ads_archive', which might also retrieve ad information. The description is specific about the target system (Meta Ads) but lacks sibling distinction.
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. With many sibling tools like 'get_ad_details', 'search_ads_archive', and 'get_ad_creatives', there's no indication of when this list/filter tool is appropriate versus more specific retrieval tools. The optional filtering is mentioned but without context about when filtering is useful.
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 the full burden of behavioral disclosure. While it states the tool updates an ad (implying mutation), it doesn't describe permissions needed, whether changes are reversible, rate limits, error conditions, or what the response contains. The mention of 'optional - will use cached token if not provided' for access_token adds some context but is minimal.
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 and appropriately sized. It starts with a clear purpose statement, followed by a bullet-point-like list of parameters with explanations. Each sentence adds value without redundancy, though the formatting as a single block could be slightly improved for readability.
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 (6 parameters, mutation operation) and lack of annotations, the description is moderately complete. It explains parameters well but lacks behavioral details like error handling or output format. The presence of an output schema mitigates some gaps, but more context on usage and constraints would be beneficial for a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains each parameter's purpose and format (e.g., 'ad_id: Meta Ads ad ID', 'bid_amount: Bid amount in account currency (in cents for USD)'), clarifying semantics that the schema alone doesn't provide. However, it doesn't cover all nuances like valid status values beyond examples.
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 with new settings.' It specifies the verb ('update') and resource ('ad'), making the function unambiguous. However, it doesn't explicitly differentiate this tool from sibling tools like 'update_ad_creative' or 'update_adset', which would require 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'update_ad_creative' or 'update_adset', nor does it specify prerequisites, exclusions, or appropriate contexts for use. The only implicit guidance is that it updates existing ads, but this is insufficient.
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 the full burden of behavioral disclosure. It states the tool retrieves 'detailed information,' which implies a read-only operation, but doesn't specify what kind of information (e.g., account settings, billing details, performance metrics) or behavioral traits like rate limits, authentication requirements beyond the optional token, error handling, or response format. This leaves significant gaps for a tool interacting with an external API like Meta Ads.
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 appropriately sized and front-loaded: the first sentence clearly states the purpose, followed by a concise 'Args' section that explains parameters without unnecessary detail. Every sentence earns its place, and there's no redundant or verbose content, making it efficient for an AI agent to parse.
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 complexity (a tool for fetching account info from Meta Ads API), the description is moderately complete. It benefits from an output schema (implied by 'Has output schema: true'), so it doesn't need to explain return values. However, with no annotations and only basic parameter semantics, it lacks details on authentication behavior, error cases, or API-specific constraints, which could hinder an agent's ability to use it effectively in real-world scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for both parameters: it specifies that 'account_id' is a 'Meta Ads account ID' with a format example ('act_XXXXXXXXX'), and 'access_token' is a 'Meta API access token' with usage guidance ('optional - will use cached token if not provided'). Since schema description coverage is 0% (no descriptions in the schema), this compensates well by providing essential context beyond the bare schema, though it doesn't cover all potential nuances like token scopes or validation rules.
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: 'Get detailed information about a specific ad account.' This specifies the verb ('Get') and resource ('ad account'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_ad_accounts' (which likely lists accounts) or 'get_ad_details' (which focuses on ads rather than accounts), so it doesn't reach the highest level of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_ad_accounts' (for listing accounts) or 'get_account_pages' (for pages associated with accounts), nor does it specify prerequisites or contexts where this tool is appropriate. The agent must infer usage from the name and description alone.
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 the full burden of behavioral disclosure. It mentions that the access token is optional and will use a cached token if not provided, which adds some context. However, it lacks details on authentication requirements, rate limits, error handling, or what the JSON response structure entails, leaving significant gaps for a tool that interacts with an external API.
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 and concise, with a clear purpose statement followed by Args and Returns sections. Each sentence adds value without redundancy, making it easy to parse and understand quickly.
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 that there is an output schema (which handles return values), the description does not need to detail the JSON response. However, for a tool with no annotations and external API interaction, it lacks sufficient context on authentication, error cases, or behavioral constraints, making it only minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'account_id' is a Meta Ads account ID with a specific format (act_XXXXXXXXX) and that 'access_token' is optional, clarifying usage that isn't evident from the schema alone. This compensates well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get pages associated with a Meta Ads account.' It specifies the verb ('Get') and resource ('pages'), but does not differentiate from sibling tools like 'search_pages_by_name' or explain how this differs from general account information tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention sibling tools like 'search_pages_by_name' or 'get_account_info', nor does it specify prerequisites or contexts for usage beyond the basic parameters.
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 the full burden of behavioral disclosure. It mentions optional caching for the access token and a default limit, which adds some context, but it doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements beyond the token, or error handling. For a tool with parameters and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with a clear purpose statement followed by a bullet-point list of parameters with concise explanations. Every sentence earns its place, with no redundant or verbose 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 tool has 3 parameters, no annotations, and an output schema (which reduces the need to describe return values), the description is moderately complete. It covers parameter semantics well but lacks behavioral context and usage guidelines. For a tool with no annotations, it should do more to explain operational aspects like safety or performance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for all three parameters beyond what the input schema provides (which has 0% coverage). It explains that 'access_token' is optional with caching, 'user_id' can be 'me' for the current user, and 'limit' has a default of 200. This compensates well for the lack of schema descriptions, though it doesn't detail format constraints or validation rules.
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 with a specific verb ('Get') and resource ('ad accounts accessible by a user'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_account_info' or 'get_account_pages', which might also retrieve account-related information, so it doesn't fully differentiate from alternatives.
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. It doesn't mention any prerequisites, context for usage, or comparisons to sibling tools like 'get_account_info' or 'search', leaving the agent to infer usage based on the name alone.
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 the full burden of behavioral disclosure. It mentions the tool 'get, download, and visualize' an image and that the access_token is optional with caching, but fails to describe authentication requirements, rate limits, error handling, or what 'visualize' entails (e.g., format, size). This leaves significant gaps for a tool with two parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement, parameter explanations, and return value note. Every sentence adds value, though the 'useful to see the image in the LLM' could be more precise, slightly reducing efficiency.
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 no annotations, 0% schema coverage, and no output schema, the description provides basic purpose and parameter semantics but lacks details on behavior (e.g., authentication, visualization format), error cases, or output specifics. It's minimally adequate for a simple tool but has clear gaps in 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?
With 0% schema description coverage, the description compensates by explaining both parameters: 'ad_id' as the 'Meta Ads ad ID' and 'access_token' as optional with caching behavior. This adds meaningful context beyond the bare schema, though it doesn't cover format details (e.g., ad_id structure) or token scope, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('get, download, and visualize') and resource ('Meta ad image'), distinguishing it from sibling tools like 'get_ad_details' or 'get_ads'. However, it doesn't explicitly differentiate from 'upload_ad_image' or other image-related tools, which prevents a perfect score.
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 provides implied usage context ('useful to see the image in the LLM') and mentions the optional nature of the access_token parameter. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_ad_details' for metadata or 'upload_ad_image' for uploads, and doesn't specify prerequisites 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, so the description carries the full burden. It mentions that the tool requests a 'specific set of fields' and notes the Meta API offers additional fields, which adds some behavioral context about data scope. However, it doesn't disclose critical traits like whether this is a read-only operation, rate limits, authentication requirements beyond the token parameter, or error handling. For a tool with no annotations, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized: a clear purpose statement, a note on field behavior, and a parameter section. Every sentence adds value, though the note about additional fields could be more concise. It's front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, but an output schema exists, the description is moderately complete. It covers purpose and parameters adequately but lacks behavioral details (e.g., safety, performance). The output schema reduces the need to explain return values, but more context on usage and limitations would improve 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?
Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for both parameters: 'campaign_id' is explained as 'Meta Ads campaign ID', and 'access_token' is described as optional with caching behavior. This adds value beyond the bare schema, though it doesn't detail format constraints (e.g., ID structure).
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: 'Get detailed information about a specific campaign.' It specifies the verb ('Get') and resource ('campaign'), but doesn't explicitly differentiate from sibling tools like 'get_campaigns' (plural) or 'get_ad_details' (different resource). The purpose is clear but lacks sibling distinction.
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 context through the note about field selection and the optional access token, but doesn't explicitly state when to use this tool versus alternatives like 'get_campaigns' for listing or 'get_ad_details' for ad-level info. Guidelines are implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the tool returns 'matching record IDs' and searches across multiple entity types, but doesn't disclose important behavioral traits like whether this is a read-only operation, authentication requirements beyond the optional access_token, rate limits, pagination, error handling, or what format the record IDs take. The description provides basic functionality but lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, parameter explanations, return information, and relevant examples. It's appropriately sized at 7 sentences, though the example usage section could be more concise by combining similar queries. Most sentences earn their place by adding value.
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 has 2 parameters, no annotations, and an output schema exists (so return values don't need explanation), the description is moderately complete. It covers basic purpose and parameters but lacks behavioral context like authentication details, search scope limitations, or error scenarios. For a search tool with multiple sibling alternatives, more guidance would be helpful.
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 must compensate. It provides clear semantics for both parameters: 'query' is explained as a 'search query string to find relevant Meta Ads records' with example queries, and 'access_token' is described as 'Meta API access token (optional - will use cached token if not provided)'. This adds meaningful context beyond the bare schema, though it doesn't detail query syntax or token requirements.
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 through Meta Ads data and returns matching record IDs, specifying the verb 'search' and resource 'Meta Ads data'. It distinguishes from some siblings like 'search_ads_archive' or 'search_interests' by mentioning it searches across multiple entity types (ad accounts, campaigns, ads, pages, businesses), but doesn't explicitly differentiate from all search-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'to find relevant records based on the provided query' and example queries, suggesting it's for general Meta Ads searches. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_ads_archive' or 'search_pages_by_name', nor does it mention any prerequisites 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, so the description carries the full burden. It mentions that 'access_token' is optional with caching behavior, which adds some behavioral context. However, it lacks critical details such as rate limits, authentication requirements beyond the token, error handling, or whether this is a read-only operation (implied by 'search' but not explicit). For a tool with no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by a bulleted list of parameters with explanations, and ends with return information. Every sentence adds value without redundancy, making it easy to scan and understand.
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 moderate complexity (4 parameters, no annotations, but has an output schema), the description is reasonably complete. It covers all parameters and the return format, and the output schema handles return values. However, it lacks context on integration with sibling tools or broader usage scenarios, which slightly reduces 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?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all four parameters: 'query' (search term examples), 'access_token' (optional with caching), 'location_types' (options list and default behavior), and 'limit' (default value). This adds substantial meaning beyond the bare schema, though it could benefit from more detail on parameter interactions 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's purpose: 'Search for geographic targeting locations.' It specifies the verb ('search') and resource ('geographic targeting locations'), which is more specific than just the tool name. However, it doesn't explicitly differentiate from sibling tools like 'search_interests' or 'search_demographics' beyond the geographic focus.
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. It doesn't mention sibling tools like 'search' or 'search_ads_archive', nor does it specify use cases, prerequisites, or exclusions. The only implied context is geographic targeting, but this is insufficient for clear usage differentiation.
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 the full burden of behavioral disclosure. It states it's an update operation but doesn't mention permissions needed, whether changes are reversible, rate limits, error conditions, or what happens to unspecified fields. The description adds minimal behavioral context beyond the basic action.
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 structured with clear sections (purpose, Args, Returns) but is verbose with detailed parameter explanations. While informative, it could be more front-loaded with critical usage information. The parameter documentation is thorough but makes the description lengthy.
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 complexity (11 parameters, 0% schema coverage, no annotations), the description does well by documenting all parameters thoroughly and mentioning the return format. However, it lacks behavioral context (permissions, side effects) and usage guidelines compared to siblings. The output schema exists, so return value explanation isn't needed.
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 provides extensive parameter documentation in the 'Args' section, explaining the purpose and constraints of all 11 parameters. With 0% schema description coverage, this fully compensates by adding crucial semantic information like mutual exclusivity rules ('cannot be used with headlines'), requirements ('Required when using lead generation CTAs'), and parameter purposes.
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 existing ad creative with new content or settings.' It specifies the verb ('update'), resource ('ad creative'), and scope ('new content or settings'). However, it doesn't explicitly differentiate from sibling tools like 'update_ad' or 'create_ad_creative', which would require 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'update_ad' or 'create_ad_creative', nor does it specify prerequisites, exclusions, or contextual triggers for choosing this tool over others.
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 the full burden of behavioral disclosure. While it mentions that targeting 'will replace existing targeting' (which is valuable behavioral information), it doesn't address critical aspects like: whether this is a destructive operation, what permissions are required, whether changes are reversible, rate limits, or error handling. For a mutation tool with 11 parameters and no annotation coverage, this represents significant gaps in behavioral 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-structured with a clear purpose statement followed by detailed parameter documentation. While comprehensive, it's appropriately sized for a tool with 11 parameters. Every sentence earns its place by providing necessary parameter context. The only minor improvement would be front-loading more critical behavioral information before the parameter details.
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 (11 parameters, mutation operation, no annotations) and the presence of an output schema, the description is moderately complete. The parameter documentation is excellent, but there are significant gaps in behavioral context (permissions, side effects, error conditions) and usage guidance. The output schema existence means the description doesn't need to explain return values, but other critical contextual information is missing for a mutation tool of this complexity.
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 provides excellent parameter semantics beyond what the input schema offers. With 0% schema description coverage, the description compensates fully by explaining each of the 11 parameters with clear examples and context. For instance, it clarifies that bid_amount is 'in cents for USD', targeting 'will replace existing targeting', and provides concrete examples for frequency_control_specs, bid_strategy, and targeting. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update an ad set with new settings including frequency caps and budgets.' This specifies the verb ('update'), resource ('ad set'), and scope ('new settings including frequency caps and budgets'). However, it doesn't explicitly differentiate from sibling tools like update_ad or update_campaign, which prevents a perfect score.
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. With sibling tools like update_ad, update_ad_creative, and update_campaign available, there's no indication of when this specific ad set update tool is appropriate versus those other update operations. The description also lacks information about prerequisites or constraints.
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 but provides minimal behavioral context. It states this updates an existing campaign but doesn't disclose important traits: what permissions are needed, whether changes are reversible, rate limits, error conditions, or what happens when partial updates fail. The description mentions 'May not always be updatable' for objective but doesn't explain when or why.
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 appropriately sized for a 13-parameter tool. It uses a clear two-part structure: purpose statement followed by parameter documentation. Every sentence adds value, though the parameter section could be more front-loaded with critical information about required vs optional parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, mutation operation, no annotations) and existence of an output schema, the description is partially complete. It excels at parameter semantics but lacks behavioral context and usage guidelines. For a mutation tool with many parameters, it should provide more about error handling, constraints, and typical use 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?
The description provides extensive parameter documentation beyond the 0% schema coverage. It explains 12 parameters with practical details: currency units (cents), special values (empty string to remove budgets), examples (status values like 'ACTIVE'), and behavioral notes (use_adset_level_budgets removes campaign-level budgets). 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.
Purpose4/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' - a specific verb (update) and resource (campaign). It distinguishes from siblings like 'create_campaign' by specifying 'existing campaign', but doesn't explicitly differentiate from other update tools like 'update_ad' or 'update_adset' beyond the resource 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, constraints, or compare with other campaign-related tools like 'get_campaign_details' for reading or 'create_campaign' for creation. The agent must infer usage from the tool name alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the optional access_token parameter and caching behavior ('will use cached token if not provided'), which adds useful operational context. However, it doesn't address important behavioral aspects like rate limits, authentication requirements beyond the token, error conditions, or whether this is a read-only operation (though 'Get' implies it).
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 (Args, Returns) and uses bullet-like formatting. Each sentence adds value: the purpose statement, parameter explanations, and return format description. It's appropriately sized for a tool with 3 parameters and output documentation, though the formatting could be slightly more polished.
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 has an output schema (though not shown here), the description appropriately documents the return format. With 3 parameters and no annotations, the description provides good coverage of parameter semantics and basic behavioral context. The main gap is the lack of usage guidelines relative to sibling tools, but otherwise it's reasonably complete for a read-oriented suggestion 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?
The schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all three parameters: clarifies that interest_list contains 'interest names' with an example, explains the optional nature and caching behavior of access_token, and specifies the default value and purpose of limit. This adds substantial value beyond the bare schema, though it doesn't fully document parameter constraints or validation rules.
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: 'Get interest suggestions based on existing interests.' It specifies the verb ('Get') and resource ('interest suggestions'), and the 'based on existing interests' phrase adds useful context. However, it doesn't explicitly differentiate this from sibling tools like 'search_interests' or 'search_behaviors' that might also find interests.
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. With sibling tools like 'search_interests' and 'search_behaviors' available, there's no indication of when this suggestion-based approach is preferable to direct search methods. The description only explains what the tool does, not when it should be selected.
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 for behavioral disclosure. It mentions the optional access token and default name behavior, but lacks critical details: required permissions, rate limits, file size/format constraints, error handling, or whether the operation is idempotent. For a mutation tool with zero annotation coverage, this leaves significant gaps.
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 (purpose, args, returns) and front-loaded core functionality. Every sentence adds value, though the parameter explanations could be slightly more concise. No redundant or wasted 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 5 parameters, no annotations, but an output schema exists, the description is moderately complete. It covers parameter semantics well and mentions the return format, but lacks behavioral context (permissions, limits) and doesn't fully compensate for the missing annotations. The output schema reduces need for return value details, but other gaps remain.
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 provides meaningful context for all 5 parameters: clarifies account_id format, explains access_token fallback behavior, specifies file/data URL formats, distinguishes image_url as a fetch source, and notes name's default behavior. This adds substantial value beyond the bare schema, though some details like exact base64 requirements remain unspecified.
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 specific action ('Upload an image') and resource ('to use in Meta Ads creatives'), distinguishing it from sibling tools like 'get_ad_image' (which retrieves) or 'create_ad_creative' (which uses uploaded images). The verb+resource combination is precise and unambiguous.
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. It doesn't mention prerequisites (e.g., needing an active ad account), compare with similar tools like 'get_ad_image', or specify scenarios where direct upload is preferred over other methods. Usage context is implied but not explicit.
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 for behavioral disclosure. It states this is a creation tool (implying mutation), but doesn't mention permissions needed, whether creation is reversible, rate limits, or what happens on success/failure. The description adds some context about default status and optional parameters but lacks critical behavioral information 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the core purpose, but the parameter documentation section is lengthy (18 items). While each parameter explanation earns its place given the 0% schema coverage, the overall structure could be more streamlined with grouping or categorization of related parameters.
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 (18 parameters, mutation operation, no annotations) and the existence of an output schema, the description provides substantial context. It thoroughly documents parameters and includes practical examples and usage notes. The main gap is lack of behavioral context around permissions, side effects, and error handling that would be expected 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?
With 0% schema description coverage for 18 parameters, the description provides extensive parameter semantics that fully compensate. It explains each parameter's purpose, format requirements, examples, and special conditions (e.g., 'required for mobile app campaigns', 'use targeting_automation.advantage_audience=1', 'default: PAUSED'). This adds 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 creates a new ad set in a Meta Ads account, specifying both the verb ('create') and resource ('ad set'). It distinguishes from siblings like create_ad, create_campaign, and update_adset by focusing specifically on ad set creation rather than other ad objects or updates.
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 update_adset or create_campaign. While it mentions the tool creates ad sets within campaigns, it doesn't specify prerequisites, dependencies, or scenarios where this tool is appropriate versus other creation tools in the sibling list.
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 mentions optional access_token caching and default limit behavior, which adds some context. However, it lacks critical details: whether this is a read-only operation, potential rate limits, authentication requirements beyond the token, pagination for results beyond the limit, or error handling. For a tool with 4 parameters and no annotation coverage, this 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 front-loaded with the core purpose in the first sentence, followed by a structured Args section that efficiently explains each parameter. Every sentence earns its place with no redundant or vague language, making it easy to scan and understand.
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 4 parameters, 0% schema coverage, no annotations, but an output schema exists, the description does well by explaining all parameters and the tool's purpose. However, it lacks behavioral context (e.g., read-only nature, rate limits) and doesn't hint at output structure, though the output schema mitigates the latter. For a retrieval tool with sibling alternatives, more usage guidance would improve 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?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 4 parameters: account_id (format specified), access_token (optional with caching behavior), limit (default and purpose), and campaign_id (filtering role). This adds significant value beyond the bare schema, though it doesn't detail format constraints beyond account_id or explain empty string default for campaign_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'ad sets for a Meta Ads account' with optional filtering by campaign. It distinguishes from siblings like 'get_adset_details' (specific ad set) and 'get_campaigns' (different resource), but doesn't explicitly contrast with 'get_ads' or 'search' tools that might also retrieve ad-related data.
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 through the optional campaign filtering parameter, suggesting this tool is for retrieving ad sets, possibly filtered. However, it doesn't explicitly state when to use this vs. alternatives like 'get_adset_details' (for a specific ad set) or 'search' (for broader queries), nor does it mention prerequisites beyond the required account_id.
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?
With no annotations provided, the description carries full burden. It discloses that it returns a JSON string with specific fields (id, name, etc.) and mentions optional token caching, but lacks details on rate limits, error handling, or authentication requirements beyond the optional token. It adequately describes the output format but misses broader behavioral traits.
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 sections for Args and Returns, using bullet-like formatting without markdown. Every sentence adds value: the purpose, parameter semantics, and return format. It's front-loaded and efficiently conveys necessary information without 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?
Given 2 parameters, 0% schema coverage, no annotations, and an output schema present, the description is fairly complete. It explains the tool's purpose, parameters, and return values, though it could benefit from more context on usage scenarios or error cases. The output schema reduces the need to detail return values, but some behavioral aspects remain uncovered.
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 adds meaning by explaining that access_token is optional with caching fallback and limit has a default of 50, which clarifies beyond the schema's basic types and titles. However, it doesn't detail format constraints or usage examples for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'behavior targeting options', specifying it retrieves 'all available' options. It distinguishes from siblings like search_interests or search_demographics by focusing on behaviors, though it doesn't explicitly compare them.
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 is provided on when to use this tool versus alternatives like search_interests or search_demographics. The description mentions what it returns but not the context or prerequisites for usage, leaving the agent to infer based on tool name alone.
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 for behavioral disclosure. While it mentions the tool 'gets' data (implying read-only) and describes the return format, it doesn't address authentication requirements beyond the optional access_token parameter, rate limits, error conditions, or whether this is a cached/live data source. The description provides basic behavioral information but leaves significant gaps.
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 efficiently structured with a clear purpose statement followed by organized 'Args' and 'Returns' sections. Every sentence adds value: the opening statement defines the tool's function, parameter explanations provide necessary context, and the return format description helps the agent understand output structure. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage and an output schema exists, the description does an excellent job explaining parameters and return format. However, as a data retrieval tool with no annotations, it could better address authentication requirements, rate limits, and differentiation from sibling targeting tools. The presence of an output schema reduces the need to fully describe returns, but some behavioral context is still missing.
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 value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose: access_token as 'Meta API access token', demographic_class with its 7 specific options and default, and limit as 'maximum number of results'. This completely compensates for the schema's lack of descriptions and provides essential context for parameter usage.
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 resource 'demographic targeting options', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_behaviors' or 'search_interests' which also retrieve targeting options, leaving some ambiguity about when to choose this particular demographic search tool.
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_behaviors', 'search_interests', or 'search_geo_locations'. It doesn't mention prerequisites, use cases, or comparison with sibling tools, leaving the agent to infer usage context from tool names alone.
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 for behavioral disclosure. While it mentions the tool creates something (implying mutation), it doesn't disclose important behavioral aspects like required permissions, rate limits, error conditions, or whether the operation is idempotent. The description provides basic functional information but lacks critical operational context 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 clear sections for Args and Returns. Each parameter explanation is concise and focused. While comprehensive, some explanations could be more streamlined (e.g., the repeated 'cannot be used with' phrasing). Overall, the structure supports readability with minimal wasted text.
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 (15 parameters, mutation operation) and the presence of an output schema (which handles return values), the description provides substantial context. It thoroughly documents parameters and their relationships. However, it lacks behavioral context about permissions, errors, and operational constraints that would be important for a mutation tool with no annotations.
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 provides extensive parameter documentation beyond the 0% schema coverage. It explains the purpose of each parameter, format requirements (e.g., 'act_XXXXXXXXX'), optionality, mutual exclusivity rules (headline/headlines, description/descriptions), and conditional requirements (lead_gen_form_id required with certain CTAs). 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 the verb 'Create' and resource 'new ad creative', specifying it uses 'an uploaded image hash'. This distinguishes it from sibling tools like 'create_ad' (which creates ads) and 'update_ad_creative' (which updates existing creatives).
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 is provided on when to use this tool versus alternatives. While the description mentions 'cannot be used with' constraints for headline/headlines and description/descriptions, these are parameter-level exclusions rather than tool-level usage guidelines. There's no mention of when to choose this over other creative-related tools like 'get_ad_creatives' or 'update_ad_creative'.
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 for behavioral disclosure. It states the tool creates a budget schedule and returns an ID or error, but lacks critical details: whether this is a destructive/mutative operation (implied by 'create'), permission requirements, rate limits, error handling specifics, or how the schedule integrates with existing campaign budgets. The description adds minimal behavioral context beyond basic function.
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 purpose statement, usage context, and detailed parameter explanations. It's appropriately sized for a 6-parameter tool with no schema descriptions. Minor improvements could include bolding key terms, but overall it's efficient with minimal 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?
Given the tool's moderate complexity (6 parameters, mutation operation) with no annotations but an output schema (implied by 'Returns' statement), the description is reasonably complete. It covers purpose, parameters, and return values, though it lacks behavioral details like side effects or error conditions. The output schema reduces need for return value explanation, but more context on tool behavior would enhance 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?
The description provides comprehensive parameter semantics in the 'Args' section, explaining each parameter's purpose and constraints (e.g., 'Unix timestamps,' 'ABSOLUTE or MULTIPLIER,' optional token behavior). With 0% schema description coverage in the input schema (titles only, no descriptions), this fully compensates by adding meaning beyond the bare schema, making all parameters clearly understandable.
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 as 'Create a budget schedule for a Meta Ads campaign' with the specific function of 'scheduling budget increases based on anticipated high-demand periods.' This distinguishes it from sibling tools like create_campaign or update_campaign that handle different campaign aspects. However, it doesn't explicitly differentiate from all budget-related tools (none exist in siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('based on anticipated high-demand periods') and mentions an alternative for the access_token parameter ('will use cached token if not provided'), but lacks explicit guidance on when to use this tool versus alternatives like update_campaign for budget adjustments or other scheduling tools. No when-not-to-use scenarios or sibling tool comparisons are 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about pagination ('after' cursor usage), default values (limit default: 25), and API-specific behavior (Meta API allows higher limit values). However, it doesn't cover important aspects like rate limits, authentication requirements beyond the optional token, error handling, or whether this is a read-only operation (though 'Get' implies reading).
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 purpose statement followed by detailed parameter explanations. While lengthy due to the comprehensive parameter documentation, every section earns its place by adding necessary context. It could be more front-loaded with usage guidance, but the information density is appropriate for an 8-parameter tool with complex options.
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 (8 parameters, no annotations, but with output schema), the description provides substantial context. It thoroughly documents parameters and their semantics, though it lacks guidance on when to use this versus siblings. The presence of an output schema reduces the need to describe return values, but additional behavioral context (like rate limits or error cases) would improve 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?
The description provides extensive parameter documentation beyond the schema, which has 0% description coverage. It explains each parameter's purpose, format options, valid values (especially for 'breakdown' with detailed categories), and behavioral implications. For example, it clarifies that 'time_range' accepts either preset strings or date dictionaries, and 'action_attribution_windows' affects output fields. This fully compensates 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.
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: 'Get performance insights for a campaign, ad set, ad or account.' It specifies the verb ('Get') and resource ('performance insights') with the target objects. However, it doesn't explicitly differentiate from sibling tools like 'get_ad_details' or 'get_campaign_details' which might also provide insights, though those seem more focused on metadata rather than performance metrics.
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. It doesn't mention sibling tools or explain scenarios where this is preferred over other data retrieval tools like 'get_ad_details' or 'search'. The only implied usage is for performance insights, but no explicit context or exclusions are 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 carries the full burden. It mentions the resource ('Facebook Ads Library archive') and includes an example with API details, which adds some behavioral context. However, it lacks critical information like rate limits, authentication requirements beyond the optional token, error handling, or pagination behavior, leaving gaps for a mutation-free search 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 a clear purpose statement, parameter explanations, and an example. It's appropriately sized for a tool with 6 parameters. However, the example usage is lengthy and could be more concise, and some sentences (like the curl command) are verbose without adding essential guidance.
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 (6 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers all parameters in detail and includes an API example, which helps contextualize usage. The presence of an output schema reduces the need to explain return values, but more behavioral context (e.g., rate limits) would enhance 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?
The description adds significant value beyond the input schema, which has 0% description coverage. It explains each parameter's purpose (e.g., 'search_terms: The search query for ads'), provides examples (e.g., country codes, ad types), and clarifies optionality (e.g., access_token caching). This fully compensates 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.
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: 'Search the Facebook Ads Library archive.' It specifies the verb ('Search') and resource ('Facebook Ads Library archive'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search' or 'search_pages_by_name', which prevents a perfect score.
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. With many sibling tools available (e.g., 'search', 'search_interests', 'get_ads'), there's no indication of context, prerequisites, or exclusions. The example usage is helpful but doesn't address 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that invalid objectives 'will cause a 400 error' and explains budget dependencies, but lacks details on permissions, rate limits, or what the creation actually entails beyond parameter documentation.
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 appropriately front-loaded with the core purpose, but the extensive parameter documentation makes it lengthy. While each parameter entry is useful, the overall structure could be more streamlined for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 15-parameter creation tool with no annotations, the description provides comprehensive parameter semantics and error information. The presence of an output schema reduces the need to explain return values, making this reasonably complete despite the lack of usage guidelines.
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?
Given 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all 15 parameters, including format requirements, valid values, dependencies, and default behaviors. It adds substantial 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 specific action ('Create a new campaign') and resource ('in a Meta Ads account'), distinguishing it from sibling tools like update_campaign or get_campaigns. It precisely defines the verb and target resource without ambiguity.
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 update_campaign or create_adset, nor does it mention prerequisites or contextual constraints. It simply lists parameters without usage context.
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 discloses that it returns interest data with specific fields (id, name, audience_size, path) and mentions optional token caching, which adds some behavioral context. However, it lacks details on rate limits, error handling, authentication requirements beyond the token, or pagination behavior, leaving gaps for a search 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 well-structured and front-loaded with the core purpose, followed by clear sections for Args and Returns. Every sentence adds value: the first states the purpose, and the subsequent bullet points efficiently document parameters and return values without 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?
Given the tool's moderate complexity (3 parameters, 1 required), no annotations, and the presence of an output schema (implied by the Returns section), the description is fairly complete. It covers purpose, parameters, and return values, but could improve by addressing behavioral aspects like error cases or usage guidelines relative to siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains that 'query' is for search terms like 'baseball', 'access_token' is optional with caching behavior, and 'limit' has a default of 25. This compensates well for the schema's lack of descriptions, though it could provide more examples 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's purpose: 'Search for interest targeting options by keyword.' It specifies the verb ('search'), resource ('interest targeting options'), and mechanism ('by keyword'). However, it doesn't explicitly differentiate from sibling tools like 'search_behaviors' or 'search_demographics' that also search for targeting options but for different categories.
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 searching for interests (e.g., for ad targeting), but doesn't explicitly state when to use this tool versus alternatives like 'search_behaviors' or 'search_demographics'. It provides no guidance on prerequisites, exclusions, or specific contexts beyond the general search function.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: the note about Meta API field limitations (default subset, extra fields not exposed) and pagination handling ('after' parameter). However, it doesn't cover critical aspects like rate limits, authentication requirements beyond the optional token, error handling, or response format details. The description provides some behavioral insight but leaves gaps for 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, important note, and detailed parameter documentation. It's appropriately sized for a tool with 6 parameters and no annotations. Every sentence earns its place by providing essential information, though it could be slightly more front-loaded by moving the note about field limitations to a separate section for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, but with output schema), the description is largely complete. It covers purpose, parameter semantics thoroughly, and key behavioral notes (field limitations, pagination). The output schema exists, so return values needn't be explained. However, it could improve by addressing authentication fallbacks or error scenarios more explicitly, given the lack of annotations.
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 fully. It does so effectively: each parameter is documented with clear semantics, including format ('act_XXXXXXXXX'), defaults, examples, and usage notes (e.g., 'effective_status' mapping to API array, JSON formatting handled). The description adds substantial meaning beyond the bare schema, making parameters understandable and actionable.
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: 'Get campaigns for a Meta Ads account with optional filtering.' This specifies the verb ('Get'), resource ('campaigns'), and scope ('Meta Ads account'). It distinguishes from siblings like 'get_campaign_details' (detailed view) and 'create_campaign' (write operation), though it doesn't explicitly name these alternatives. The purpose is clear but could be more specific about differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context through the mention of optional filtering and the note about field limitations, suggesting when to use this tool for basic campaign listing. However, it lacks explicit guidance on when to choose this over siblings like 'get_campaign_details' (for detailed info) or 'search' (for broader queries). No exclusions or prerequisites are stated, leaving usage decisions to inference.
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 of behavioral disclosure. It mentions that the access token is optional and will use a cached token if not provided, which adds useful context about authentication behavior. However, it doesn't disclose other traits like rate limits, error handling, or what 'creative details' includes (e.g., format, fields). The description doesn't contradict any annotations, but it's incomplete for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a usage tip and parameter explanations. Every sentence earns its place with no wasted words, making it efficient and easy to parse.
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 complexity (2 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers the tool's purpose, usage tip, and parameter semantics. Since an output schema exists, it doesn't need to explain return values. However, for a tool with no annotations, it could benefit from more behavioral context like error cases or performance hints.
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 schema description coverage is 0%, so the description must compensate. It adds meaning by explaining both parameters: 'ad_id: Meta Ads ad ID' and 'access_token: Meta API access token (optional - will use cached token if not provided).' This clarifies the purpose and optionality of each parameter beyond the schema's basic types. However, it doesn't provide examples or format details (e.g., expected ID format), so it's not fully comprehensive.
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: 'Get creative details for a specific ad.' This is a specific verb ('Get') and resource ('creative details for a specific ad'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_ad_details' or 'get_ads', which might also retrieve ad-related information, so it doesn't fully distinguish from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Best if combined with get_ad_image to get the full image.' This gives a positive guideline on when to use this tool in conjunction with another. However, it lacks explicit alternatives or exclusions, such as when to use 'get_ad_details' instead, and doesn't mention prerequisites beyond the optional access token.
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 mentions that the access token is optional and will use a cached token if not provided, which adds useful behavioral context. However, it doesn't disclose other important traits like authentication requirements, rate limits, error conditions, or what the 'clickable resource link' actually contains (e.g., URL format, expiration).
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 and concise. It starts with the core purpose, provides critical usage notes, then lists parameters and returns in a clear format. Every sentence adds value without redundancy, and it's appropriately sized for 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 tool has an output schema (which handles return values), no annotations, and only one parameter with good description coverage, the description is reasonably complete. It covers purpose, usage guidelines, parameter semantics, and return type. However, it could benefit from more behavioral details like authentication flow or link characteristics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the single parameter: 'access_token: Meta API access token (optional - will use cached token if not provided).' This explains the parameter's purpose, type, and optional behavior beyond the schema's basic title. With 0% schema description coverage, the description fully compensates for the single parameter.
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: 'Get a clickable login link for Meta Ads authentication.' It specifies the verb ('Get') and resource ('login link'), and the target system ('Meta Ads authentication'). However, it doesn't explicitly differentiate from sibling tools, which are mostly about ad management rather than authentication.
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 usage guidelines: 'This method should only be used if you're using your own Facebook app. If using Pipeboard authentication (recommended), set the PIPEBOARD_API_TOKEN environment variable instead.' It clearly states when to use this tool (with own Facebook app) and when not to (with Pipeboard authentication), including an alternative approach.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool uses Meta's API and provides some implementation details, but doesn't cover important behavioral aspects like rate limits, authentication requirements beyond the optional token, error handling, or whether this is a read-only operation. The description adds value but leaves significant behavioral gaps.
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 (purpose, args, returns) and front-loaded key information. While comprehensive, some sentences could be more concise (e.g., the targeting example is detailed but necessary). Overall, most content earns its place in explaining this 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 (6 parameters, no annotations, 0% schema coverage), the description does a good job explaining parameters and return values. With an output schema present, the description doesn't need to detail return structure. However, it could better address behavioral aspects given the lack of annotations, leaving some gaps in 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 for all 6 parameters, the description provides excellent parameter semantics. It explains each parameter's purpose, provides examples (like the targeting specification), indicates required vs optional status, marks deprecated parameters, and gives default values. 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 the tool's purpose: 'Estimate audience size for targeting specifications using Meta's delivery_estimate API.' It specifies the verb ('estimate'), resource ('audience size'), and implementation method ('Meta's delivery_estimate API'), distinguishing it from sibling tools like search_interests or get_insights which serve different functions.
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 clear context about when to use this tool: for 'comprehensive audience estimation for complex targeting combinations' and 'backwards compatibility for simple interest validation.' However, it doesn't explicitly state when NOT to use it or name specific alternative tools from the sibling list for different use cases.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation ('fetch', 'retrieves') and specifies the return format, but doesn't mention error conditions, rate limits, authentication requirements, or whether the operation is idempotent. It provides basic behavioral context but lacks depth.
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 sections (purpose, args, returns, examples), front-loaded with the core functionality, and every sentence earns its place. The example usage section provides concrete value without being verbose.
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 (single parameter, no annotations but has output schema), the description is mostly complete. It explains the purpose, parameter semantics, and return format. However, it could benefit from mentioning error cases or limitations. The output schema existence reduces the need to fully document returns, but some behavioral context is still missing.
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% description coverage, so the description must fully compensate. It provides excellent parameter semantics: explains the 'id' parameter's purpose, format requirements with specific examples ('type:id'), and multiple concrete usage examples showing different record types. This adds substantial 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's purpose with specific verb ('fetch', 'retrieves') and resource ('complete record data by ID'), distinguishing it from siblings like search tools or creation/update tools. It explicitly mentions fetching by ID rather than other filtering methods.
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 clear context for when to use this tool ('by ID' for 'specific record'), but doesn't explicitly state when not to use it or name specific alternatives. It implies this is for fetching individual records rather than lists or searches, but lacks explicit 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 provided, the description carries full burden and does well by disclosing: 1) This is a creation/mutation operation (implied by 'Create'), 2) Authentication behavior (access token optional, will use cached), 3) Error conditions (dynamic creative requirements and specific error code). It doesn't mention rate limits or whether the operation is idempotent, but covers the essential behavioral aspects.
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 (Args, Note) and front-loaded purpose. Every sentence earns its place by providing essential information. It could be slightly more concise by combining some parameter explanations, but overall it's efficient and well-organized.
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 this is a mutation tool with 8 parameters, 0% schema coverage, no annotations, but with an output schema, the description provides excellent coverage of inputs, behavioral constraints, and prerequisites. The output schema will handle return values, so the description appropriately focuses on creation logic and requirements. It could mention sibling relationships more explicitly for 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 providing: 1) Clear parameter explanations with format requirements (account_id format), 2) Default values (status default: PAUSED), 3) Optional vs required indication, 4) Units (bid_amount in cents), 5) Concrete examples (tracking_specs). This adds substantial 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 specific action ('Create a new ad') and resource ('with an existing creative'), distinguishing it from sibling tools like create_ad_creative (which creates creatives) and update_ad (which modifies existing ads). The verb+resource combination is precise and unambiguous.
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 clear context about when to use this tool (creating ads with existing creatives) and includes an important note about dynamic creative requirements. However, it doesn't explicitly state when NOT to use it or name specific alternatives like create_ad_creative for when you need to create both ad and creative.
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:

[![pipeboard-co__meta-ads-mcp.36128861 MCP server](https://glama.ai/mcp/servers/swesmith-repos/pipeboard-co__meta-ads-mcp.36128861/badges/card.svg)](https://glama.ai/mcp/servers/swesmith-repos/pipeboard-co__meta-ads-mcp.36128861)

Score Badge

Copy to your README.md:

[![pipeboard-co__meta-ads-mcp.36128861 MCP server](https://glama.ai/mcp/servers/swesmith-repos/pipeboard-co__meta-ads-mcp.36128861/badges/score.svg)](https://glama.ai/mcp/servers/swesmith-repos/pipeboard-co__meta-ads-mcp.36128861)

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/swesmith-repos/pipeboard-co__meta-ads-mcp.36128861'

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