Meta Ads MCP Server

Server Quality Checklist

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

Latest release: v1.5.1
Disambiguation5/5
Each tool targets a distinct resource and action, such as retrieving ads by account, adset, or campaign, and separate search tools for interests, behaviors, demographics, etc. There is minimal overlap or ambiguity.
Naming Consistency5/5
All tool names follow a consistent `meta_ads_<verb>_<object>` pattern, using lowercase and underscores. Variations like `meta_ads_get_ads_by_adaccount` and `meta_ads_search_interests` are predictable and uniform.
Tool Count2/5
With 35 tools, the count is well above the typical 15-25 range considered reasonable. While the domain is complex, the number feels excessive and could be streamlined.
Completeness2/5
The tool set is heavily read-oriented, covering listing, retrieving, and searching for various objects. However, it lacks essential write operations like create, update, or delete for campaigns, ad sets, ads, and creatives, which is a significant gap for typical advertising workflows.
Average 4.2/5 across 35 of 35 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the return structure (data array with metrics, paging object) and pagination behavior, including the need to use a sibling tool for fetching additional pages. This complements the readOnly and idempotent hints effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points, but it is verbose. It repeats parameter information already present in the schema, which makes it longer than necessary. While organized, the redundancy hurts conciseness.
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 (23 parameters, nested objects, no output schema), the description adequately covers the main purpose, return format, and pagination. It mentions time ranges, breakdowns, and attribution settings. The pagination note and reference to a sibling tool enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for all parameters (100% coverage). The description's 'Args' section adds common metric examples but does not significantly clarify meaning beyond the schema. The baseline of 3 is appropriate as the description does not compensate for any lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves performance insights for a Meta ad account, specifying metrics and features. However, it does not explicitly distinguish this tool from sibling insight tools like meta_ads_get_ad_insights or meta_ads_get_campaign_insights, which slightly reduces clarity for an agent deciding which tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus its siblings. It does not mention when to prefer account-level insights over campaign, adset, or ad-level insights. The pagination note is useful but does not cover tool selection. This leaves the agent without clear decision criteria.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds valuable behavioral context: it explains the return structure (data, paging), pagination (use meta_ads_fetch_pagination_url), and typical metrics. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, args, returns, note). It is moderately lengthy but each part serves a purpose. A minor reduction in redundant details could improve conciseness, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (23 parameters, no output schema), the description covers essential aspects: purpose, common metrics, pagination handling, and basic return structure. It does not explain all parameter interactions or edge cases, but provides sufficient context for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 23 parameters. The description lists some common fields but does not add substantial meaning beyond the schema. The docstring-style args repeat schema info without deeper insight, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves performance insights for a specific Meta ad campaign. It specifies the resource (campaign) and the action (retrieve insights). However, it does not explicitly differentiate from sibling tools like meta_ads_get_ad_insights or meta_ads_get_adset_insights, relying on the tool name for 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 explicit guidance on when to use this tool versus alternatives (e.g., meta_ads_get_ad_insights, meta_ads_get_adaccount_insights). It implies campaign-level focus but doesn't state exclusions or prerequisites, leaving the agent to infer 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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that it returns suggestions and takes a seed list, but does not elaborate on request limits or data behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action. No 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 no output schema, the description implies the return type (related suggestions). It is sufficient for a simple tool, though could mention if output is an array or other structure.
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?
Despite 0% schema description coverage, the description explains interest_list as 'Seed interest names' with an example and limit as 'Max suggestions'. This adds meaning beyond the schema's type and 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 returns related/suggested interests from a seed list. It distinguishes from siblings like 'meta_ads_search_interests' by specifying it takes a seed list for suggestions rather than searching by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., meta_ads_search_interests). The description does not specify context or exclusions.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, reducing the burden on the description. The description adds no further behavioral details beyond the limit parameter, which is acceptable but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no filler, and the most important information (what the tool does) is front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not explain the format or structure of the returned behavior options. For a list tool, this lack of return value details leaves some ambiguity, though the sibling tools similarly lack such details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the description adds meaningful context for the limit parameter: 'Max results (default 50)'. This clarifies the parameter's purpose and default value beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('behavior targeting options'). It distinguishes from sibling search tools like meta_ads_search_interests and meta_ads_search_demographics.
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 such as interest or demographic search tools. The description lacks contextual usage advice or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds that the tool lists options and defaults to 'demographics', but does not detail return format or pagination. Acceptable given annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no redundant words. Every sentence adds 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?
No output schema, description does not explain return values or pagination. For a simple list tool, the description is adequate but not fully complete given the lack of output details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 50% of parameters with descriptions; demographic_class is described with default and enum, limit lacks description. The description repeats the default and enum but adds no new info for limit, failing to compensate for the missing parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists demographic targeting options, with a specific verb and resource. It distinguishes from siblings by mentioning the demographic_class parameter that scopes results to 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to pass demographic_class to scope results and lists valid class values. It provides clear context but does not mention when not to use this tool or alternatives.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, so the description's statement 'Retrieve detailed information' adds minimal behavioral context beyond the structured data. No additional traits like rate limits, auth needs, or return format beyond 'Object'.
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, returns, and examples. It is front-loaded with the purpose. Each sentence adds value, though it could be slightly shortened while preserving clarity.
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 and no output schema, the description explains the return type as an object with requested fields, which is adequate. It covers the main usage patterns with examples. It lacks details on error handling but is sufficiently complete for a read-only tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists available fields and provides examples, but the schema already describes all parameters. The description does not add new meaning beyond what is in the schema for each param.
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 'Retrieve detailed information about a specific Meta ad creative,' which is a specific verb+resource. It distinguishes from sibling tools like meta_ads_get_adcreatives_by_adaccount (list) and meta_ads_get_ad_creatives_by_ad_id (different) by focusing on a single creative by ID.
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 concrete 'Use when' examples that illustrate typical scenarios (e.g., getting body text, call-to-action, thumbnail). It implies the tool is for retrieving a specific creative by ID but does not explicitly state when not to use it or what alternatives exist.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, providing safety context. The description adds behavioral details: pagination cursors, return structure (data array and paging), and mentions using meta_ads_fetch_pagination_url for more results. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a leading sentence, a bullet list of parameters, and a return section. For 9 parameters, it is appropriately sized without being verbose. Each parameter gets a concise line.
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 9 parameters (1 required), no output schema, and annotations covering safety, the description explains the return structure and pagination well. It mentions how to get more results using a sibling tool. It lacks error handling or rate limit info, but for a read-only tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description bullet list restates schema parameters with some additional examples (e.g., common fields for 'fields', operators for 'filtering'). However, it does not add significant new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve all ads belonging to a specific Meta ad set with filtering and pagination', which is a clear verb+resource+scope. It distinguishes from siblings like meta_ads_get_ads_by_adaccount and meta_ads_get_ads_by_campaign by specifying 'by adset'.
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 (when you have an ad set ID) but does not explicitly mention when to use this tool versus alternatives like meta_ads_get_ads_by_campaign or meta_ads_get_ads_by_adaccount. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, which the description respects. The description adds context by listing available fields and describing return format, but does not go beyond what annotations already indicate about safety.
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 (summary, Args, Returns, Examples) and front-loaded purpose. Every sentence adds value, though slightly verbose with redundant examples.
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?
Despite no output schema, the description explains the return format and lists available fields and date format options. It covers sufficient detail for a simple retrieval tool, leaving little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's parameter details largely duplicate the schema. It adds minor value by listing example values and default date format, but does not compensate significantly beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve detailed information about a specific Meta ad campaign,' specifying the verb and resource. It includes examples and distinguishes itself from siblings that retrieve campaigns by other criteria.
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 'Use when' examples, indicating clear usage context. However, it does not explicitly mention when not to use or suggest alternatives among the many sibling tools, though the sibling list implies differentiation.
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?
Annotations already indicate readOnly, non-destructive, idempotent, and openWorld. The description adds the specific API endpoints (delivery_estimate/reachestimate), confirming read-only behavior, and notes the return of 'estimated audience size bounds plus raw API response', providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with a clear purpose first, then a list of args. It is relatively short and to the point, though slightly redundant by mentioning endpoints and then args. Could be more structured with bullet points.
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 output schema, the description compensates by stating return value. It covers key inputs and outputs but lacks details on error cases, rate limits, required permissions, or prerequisites (e.g., user authentication, valid ad account). For a tool with openWorldHint, basic completeness is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all three parameters: act_id (prefixed with 'act_'), targeting (specifying common fields like geo_locations, age_min, etc.), and optimization_goal (optional, default REACH, common values). It adds meaning beyond the raw schema, though could be more specific about targeting subfields.
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 action ('Estimate audience size'), the resource ('targeting spec'), and even references the underlying Meta API endpoints. Among sibling tools, this is the only one focused on estimation, making it distinct.
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 parameter context (e.g., optimization_goal defaults, targeting spec fields) but does not explicitly state when to use this tool versus alternatives like direct ad creation or insights. No usage scenarios or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent. The description adds valuable context: default time range, return fields, and pagination. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose first, then args, returns, usage hint. Slightly verbose but maintains clarity. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Rich schema and annotations reduce burden. Description adds default time range, return field descriptions, and pagination hints. Missing output schema is compensated by return description. Complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds some extra context (e.g., time_range overrides since/until, lists available fields) but largely duplicates schema descriptions. Not significantly more informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the change history (activity log) for a Meta ad account, with specific examples of changes (status, budget, targeting). It distinguishes from sibling tool meta_ads_get_activities_by_adset by focusing on ad account level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: defaults to one week of data, examples of use cases ('Show me all changes', 'Who changed the budget'), and hints for pagination. Does not explicitly exclude alternative tools, but the scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context that the tool returns an object with an HTML embed body and encoded creative ID, and mentions it can be used before or after publishing. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for Args, Returns, and examples. It is somewhat lengthy due to the enum listing but remains readable and front-loaded with the main purpose. A slight trim could improve conciseness.
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 5 parameters, no output schema, but detailed annotations, the description covers the purpose, all parameters, return format, and provides usage examples. It lacks details on constraints like ad state or error conditions, but overall it is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description repeats the parameter descriptions largely verbatim from the schema (e.g., ad_format enum list, locale format) without adding significant new meaning or usage nuances beyond the schema itself.
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 generates preview links or embed HTML for a Meta ad across various formats and placements. It uses specific verbs (generate, preview) and distinguishes it from sibling tools that fetch data or perform other operations.
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 includes explicit usage examples (e.g., 'Use when: Show me how ad 23843211234567 looks on Instagram') that indicate when to use the tool. However, it does not provide explicit when-not-to-use guidance or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds behavioral context: filtering, pagination, return shape (data array + paging), and recommendation to use meta_ads_fetch_pagination_url. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with Args and Returns sections, uses clear bullet points. It is informative without being overly verbose. Could slightly reduce redundancy with schema but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, description covers essential aspects: parameter details, return shape, pagination, and cross-reference to pagination tool. Sufficient for most usage 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?
Schema coverage is 100%, but description provides additional practical details like example values for campaign_id, full list of effective_status options, filtering object structure with operator examples, and pagination cursor usage. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve all ads belonging to a specific Meta campaign' with specific verb and resource. Distinguishes from sibling tools that retrieve ads by ad account or adset.
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?
Description implies usage for retrieving ads per campaign but lacks explicit guidance on when to use this vs alternatives like meta_ads_get_ads_by_adaccount. No exclusion criteria or alternative tool references 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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds context about returning an object with requested fields and lists common fields, but does not disclose additional behavioral traits beyond what annotations imply. The bar is lower due to rich annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized and includes structured sections (Args, Returns, Examples). The 'Args' section largely duplicates the schema but adds practical examples. It is front-loaded with the main purpose, but could be slightly more concise by omitting redundant arg details.
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 low tool complexity, no output schema, and thorough annotations, the description adequately covers retrieval behavior. It specifies return format as an object with requested fields, and the examples cover common use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description enhances understanding by providing a list of common fields (e.g., id, name, budget) and examples of use, adding value beyond the schema's brief 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 retrieves detailed information about a specific Meta ad set. The verb 'retrieve' is specific, and the resource 'ad set' is well-defined. Among sibling tools like meta_ads_get_ad_by_id, this tool is distinctly focused on ad sets, making its purpose 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 two concrete 'Use when' examples, such as retrieving targeting and budget for a specific ad set. However, it does not explicitly state when not to use this tool or mention alternative tools for different purposes, which would improve guidance.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds transparency about pagination behavior and the return structure (data array and paging object), which is helpful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with a clear one-sentence summary, then lists parameters in a readable block. While the parameter list is long, it is necessary given the tool's complexity (9 parameters). No unnecessary sentences.
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?
Despite the absence of an output schema, the description explains the return format and pagination mechanism. It provides enough context for an agent to select and invoke the tool correctly, including how to get more results using a sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. However, the description adds value by providing common field examples, default values (e.g., limit default 25), and example filtering objects, which aids in understanding parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves all ad sets belonging to a specific campaign, with filtering and pagination. This distinguishes it from sibling tools like meta_ads_get_adsets_by_adaccount and meta_ads_get_adsets_by_ids.
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 explains how to use pagination (referencing meta_ads_fetch_pagination_url) and provides parameter details, but it does not explicitly mention when to use this tool versus alternatives or when not to use it.
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?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds detail that it returns the largest centered region fitting the source while matching aspect ratio, equivalent to Meta's "Original" crop with no content cut beyond the ratio. This enriches understanding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~150 words), well-structured with bullet points for valid keys, and front-loaded with the main purpose. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 parameters, no output schema), the description covers the key aspects: what it computes, valid inputs, and downstream use. It could optionally detail the return dict structure, but the information provided is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides a list of valid crop_keys with aspect ratios and placements, adding meaning beyond the schema. However, it does not explain the numeric parameters (image_width, image_height) beyond their role as source dimensions, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes image_crops coordinates for a source image, identifies the specific resource (image crops), and uses a specific verb "compute". It distinguishes from sibling tools by focusing on coordinate computation rather than estimation, fetching, or listing.
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 explicitly directs the user to pass the returned image_crops dict to meta_ads_create_ad_creative, providing clear downstream usage. It does not explicitly state when not to use this tool, but the context is clear for this computational task.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that it returns an object with requested fields, which is minimal additional transparency. No contradictions, but it could mention authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main sentence, Args, Returns, and Examples. It is concise with no extraneous text, and each section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the main functionality. However, it does not specify what default fields are returned if 'fields' is omitted, which 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 coverage is 100%, so baseline is 3. The description adds value by listing common field values (e.g., id, name, status) in the Args section, which goes beyond the schema's parameter 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 'Retrieve detailed information about a specific Meta ad' with the verb 'Retrieve' and resource 'specific Meta ad'. It distinguishes from sibling tools by focusing on a single ad by ID and provides examples like 'Get details for ad 23843211234567'.
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 'Use when' examples that indicate typical queries, such as 'What creative and status does this ad have?' This gives clear context, but it does not explicitly exclude alternative tools or specify when not to use it, so it's not a 5.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's job is to add beyond that. It does so by explaining that the tool returns an object with 'data' and 'paging', and explicitly instructs to use meta_ads_fetch_pagination_url for more results. This discloses pagination behavior and return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into 'Args' and 'Returns' sections, with each parameter explained concisely. It is front-loaded with the main purpose. While slightly lengthy, every sentence adds value, making it efficient for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 100% schema coverage, and annotations present, the description adequately explains the return value and pagination. It does not cover error handling or rate limits, but for a read-only idempotent tool, this is acceptable. The explanation of how to fetch more pages is particularly helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: examples for act_id prefix, common fields list, effective_status options, default limit of 25, and how to use pagination cursors (after/before). It also explains that date_preset is ignored if time_range is provided, and describes the return object structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Retrieve all ads from a specific Meta ad account with filtering and pagination', clearly stating the action (retrieve), resource (ads), and scope (by ad account). This distinguishes it from sibling tools like get_ads_by_adset or get_ads_by_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions filtering and pagination but does not explicitly guide when to use this tool over alternatives like get_ads_by_campaign or get_ads_by_adset. Usage context is implied but not explicit with when-not or direct comparisons.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description aligns and adds value by detailing pagination via meta_ads_fetch_pagination_url and parameter options. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with bullet points and sections, but it is relatively long. However, every section adds value (parameter details, return info). It could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 17 parameters, nested objects, pagination, and no output schema, the description covers all parameters, return format, and references the pagination tool. It is fully adequate for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond schemas by listing common fields, enumerating filter values, and explaining pagination cursors. This compensates for the high coverage baseline.
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 'retrieve', the resource 'campaigns', and the context 'from a specific Meta ad account'. It mentions filtering and pagination, distinguishing it from siblings like get_campaign_by_id (single campaign) or get_campaign_insights (insights).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing campaigns but provides no explicit guidance on when to use this tool versus siblings (e.g., get_campaign_by_id for a single campaign). No when-not-to-use or alternative comparisons are given.
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?
Annotations already indicate readOnly and idempotent; description adds value by detailing returned fields (CDN url, dimensions, name, status) and contextualizing hash origin. No contradiction.
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?
Short, front-loaded with main action, every sentence informative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and key return values. Lacks error handling or edge cases, but sufficient for a simple lookup tool given annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only act_id described). Description adds context for image_hash (where it comes from) but not for act_id. Partially compensates for missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Look up a single image... by hash,' specifying verb, resource, and key parameter. It distinguishes from siblings by focusing on single hash-based retrieval, contrasting with batch or other 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit use case when you have a hash and need the URL, referencing related functions like upload_ad_image. However, it doesn't explicitly state when not to use or mention alternatives like meta_ads_get_ad_images for multiple hashes.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds significant behavioral context: default time range, pagination details, and output structure, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, sections for Args and Returns, and examples. It is somewhat redundant with the schema but remains organized and front-loaded with key 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 9 parameters, nested objects, and no output schema, the description provides thorough details on return fields, pagination, and time range handling. It also directs to a sibling tool for pagination. Lacks error handling or permission notes, but overall completes the context well.
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 100%, so baseline is 3. The description adds value by clarifying default time range, parameter interactions (time_range overrides since/until), and providing example values, which enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the change history for a specific ad set, with examples. It differentiates from the sibling meta_ads_get_activities_by_adaccount by specifying the resource as an ad set, and lists the types of updates returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' examples and mentions default behavior (one week of data). It does not explicitly state when not to use or compare to alternatives, but it gives clear context for common use cases.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by disclosing the pagination mechanism (after/before cursors), the use of meta_ads_fetch_pagination_url for next pages, and the return format (Object with data and paging). No contradictions.
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: general description, use contexts, Args with bullet points, Returns, and Examples. It is moderately sized but front-loads the purpose. Could be slightly more concise by not repeating the full field list already present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema), the description adequately covers the main retrieval purpose, filtering options, pagination details, and return structure (data array + paging). It references a sibling tool for pagination, providing sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds meaning beyond the schema by grouping parameters (e.g., 'Fields to retrieve' list, 'Filter by status', 'Additional filter objects') and providing context like the example usage for filtering. It also gives a practical hint for pagination cursors.
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 explicitly states 'Retrieve all ad creatives belonging to a specific Meta ad account', clearly identifying the verb (retrieve), resource (ad creatives), and scope (by ad account). This distinguishes it from siblings like meta_ads_get_ad_creative_by_id and meta_ads_get_ad_creatives_by_ad_id.
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 includes explicit contexts such as 'auditing all creative assets, finding creatives by status, or reviewing creative content across the account' and provides example queries. However, it does not explicitly state when to avoid this tool in favor of alternatives like meta_ads_get_ad_creative_by_id for single creative retrieval.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds behavioral details beyond these: it explains the return structure (object with data and paging), pagination cursors, and date format behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args, Returns, and Examples sections, and the core purpose is front-loaded. However, the listing of available fields for the 'fields' parameter is lengthy but necessary. Overall, it's organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description adequately explains the return structure, pagination, and references a sibling tool for pagination. It covers date formats and provides a field list. The absence of output schema is compensated by clear return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining how to use the parameters, including examples for date_format and pagination cursors, and referencing meta_ads_fetch_pagination_url for pagination. This goes beyond simply repeating schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve the ad creatives') and the specific resource ('associated with a specific Meta ad'). It distinguishes from siblings like meta_ads_get_ad_creative_by_id (single creative) and meta_ads_get_adcreatives_by_adaccount (by account) by specifying 'by ad ID'.
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 two usage examples ('What creatives are used by ad...' and 'Get the image URLs...') that clarify when to use the tool. However, it does not explicitly state when not to use it or list alternative tools, though the sibling list provides 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?
Annotations already declare readOnly, nondestructive, idempotent, and open world hints. The description adds purpose and parameter details but does not elaborate on behavior beyond what annotations imply. It discloses that it returns location keys, which is useful but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a parameter list. The purpose is front-loaded, and every sentence adds value without redundancy or fluff.
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 search tool with no output schema, the description adequately states what is returned (location keys) and how to use them. It could mention the response structure (e.g., each location has key, name, type) but is sufficient for basic use.
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 explains all three parameters: q with examples, location_types with full enum list, and limit with default value. This adds significant meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Meta's geographic targeting catalog by query string and returns location keys. The verb 'Search' is specific to the resource 'geographic targeting catalog', and it distinguishes from sibling tools like search_interests and search_behaviors by focusing on geographic locations.
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 implies usage for finding geo locations to use in targeting, and the parameter details clarify how to use it. However, it does not explicitly state when not to use it or suggest alternatives, though the sibling tools provide natural alternatives for other targeting types.
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?
Annotations already indicate readOnly, destructive=false, idempotent, and openWorldHint. The description adds important behavioral detail: the tool returns pages bound to the user/token, not the ad account, explaining why act_id is unused. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief purpose statement, parameter details, and return format. All sentences add value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description covers purpose, the one parameter's role, and the return format. With no output schema, this is reasonably complete. Slightly more context about alternative tools would enhance it.
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 input schema has 0% description coverage, but the description thoroughly explains the act_id parameter: it is reserved for parity with the Python reference and currently unused because Meta returns pages by user/token. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Facebook pages reachable from the access token's user, and explicitly frames these as candidate page_id values for create_ad_creative. This verb+resource+usage combination distinguishes its purpose well.
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: it is used to get pages for ad creative creation. However, it does not explicitly state when not to use it or compare it to sibling tools like meta_ads_search_pages_by_name, which slightly limits guidance.
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?
Annotations already declare readOnlyHint and idempotentHint, so the description adds operational context like pagination, return structure, and filtering behavior. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for purpose, Args, Returns, and Examples. It is comprehensive but not overly verbose; each component serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 10 parameters and no output schema, the description covers return structure, pagination, and usage examples. It also references a sibling tool for pagination, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by clarifying usage (e.g., 'partial match' for name, example for hashes) and providing a structured Args list with practical details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves ad images for a Meta ad account, with specific use cases like auditing and filtering by hash/name. It distinguishes from sibling tools like meta_ads_get_image_by_hash by being the general listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit examples of when to use, such as 'List all images' or 'Find images with hashes', and notes its utility for auditing. It does not explicitly mention when not to use or alternatives, but the context is clear given sibling tools.
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?
Annotations already convey read-only, idempotent, and safe behavior. The description adds valuable context beyond annotations: the URL already contains the access token, and warns not to modify it. It also states the return format matches the original response.
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 highly concise and well-structured: a one-line summary, usage guideline, args/returns sections, examples, and a warning note. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description is complete: it explains the input, output (same format as original), and provides multiple usage examples and a critical security note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, providing baseline 3. The description adds meaningful context: the URL includes the access token and all necessary parameters, and explicitly advises not to add or modify the token, which is critical for safe usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool fetches the next or previous page from a Meta Graph API pagination URL, clearly distinguishing it from sibling tools that perform different operations (e.g., getting entities or insights).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('Use this tool whenever...') and concrete examples for specific preceding calls. It lacks an explicit when-not-to-use statement, but the sibling context makes it clear this is the only pagination tool.
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?
Annotations already indicate read-only and idempotent. The description adds pagination details, return structure, and how to request fields. No contradictions. It provides significant behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-organized with clear sections (purpose, args, returns, pagination note). Each sentence is informative and necessary. No fluff, achieves conciseness without sacrificing completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 23 parameters, the description covers key aspects: how to use date presets vs custom range, pagination, and return format. It references a sibling tool for pagination. No output schema, but description compensates adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by listing common fields, breakdowns, and examples (e.g., 'comma-separated list e.g. impressions, clicks'). Clearly explains key parameters like date_preset and time_range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves performance insights for a specific Meta ad. It distinguishes from sibling tools that operate at different levels (e.g., adaccount, adset) by specifying 'ad' level and naming the tool accordingly.
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: it fetches metrics for an individual ad and mentions pagination using a sibling tool. It defaults to last_30d and 'ad' level, indicating typical use. Lacks explicit when-not-to-use, but sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds significant behavioral context beyond annotations: it explains pagination (use meta_ads_fetch_pagination_url), lists filter operators and effective status options, mentions date presets and time ranges, and describes the return structure. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for a tool with 12 parameters. It is structured with Args and Returns sections, keeping the main purpose upfront. Each sentence contributes information; however, some details (e.g., common fields list) could be slightly abbreviated without losing value. No wasted words.
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 (12 params, nested objects, no output schema), the description covers most aspects: required parameter (act_id), filtering, pagination, date handling, status filtering, and a link to a pagination sibling tool. It lacks explanation of the response data structure in more detail (e.g., how fields map to ad set properties) and doesn't mention rate limits or limits on results per call beyond the limit parameter. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by providing common field examples (id, name, daily_budget, etc.), effective status enumeration details, a filtering example syntax (e.g., {field: 'daily_budget', operator: 'GREATER_THAN', value: 1000}), and explains pagination cursors. These go beyond the schema's parameter 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 retrieves all ad sets from a specific Meta ad account with filtering and pagination. The verb 'retrieve' and resource 'ad sets' are specific. It distinguishes from siblings like meta_ads_get_adsets_by_campaign by specifying the scope is all ad sets from an ad account, not filtered by campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (when needing ad sets from an ad account). It implies when not to use it (e.g., for a single ad set use get_adset_by_id, or for campaign-specific use get_adsets_by_campaign) but does not explicitly name alternatives or exclusions. The inclusion of pagination guidance and filtering examples further aids usage.
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?
Annotations already indicate readOnly, idempotent, nondestructive. The description adds that it returns an object keyed by ad set IDs, which is useful. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with primary purpose, and structured with Args and Returns sections. Every sentence provides value 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 no output schema, the description explains the return format. It covers inputs and usage examples. It does not address error handling or edge cases, but for a simple read tool this is adequate.
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 covers 100% of parameters with descriptions. The description adds concrete examples for adset_ids and fields list, plus explains date_format values. This adds significant clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves multiple Meta ad sets in a single call (batch lookup). It uses specific verb and resource, and distinguishes from sibling tools like meta_ads_get_adset_by_id (single) and meta_ads_get_adsets_by_adaccount (account-filtered).
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 says 'Efficient when you need data for several ad sets at once' and provides an example. It implicitly tells when to use it but does not explicitly exclude cases like needing a single ad set, though sibling tool names provide context.
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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds context about pagination and return format, enhancing transparency without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with separate sections for purpose, returns, and examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, read-only tool, the description fully covers what it does, the return structure, and pagination. No gaps given the existing annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description does not add parameter information, but none is needed. Baseline for zero params is 4.
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 lists all ad accounts for the authenticated user, with specific verb and resource. It is well-distinguished from sibling tools which focus on other entities like campaigns, ads, or insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage examples and mentions pagination handling. However, it does not explicitly state when not to use this tool or compare with alternatives, though the sibling context implicitly differentiates.
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?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint, so the safety profile is clear. The description adds context on how the results are used (in targeting.flexible_spec) and provides the return structure, including fields like id, name, audience_size. This adds value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a parameter list and return structure. It is front-loaded with the main purpose. Every sentence adds value, with no redundant or extraneous 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 annotations and schema, the description is quite complete. It explains the output format and usage. However, it does not mention pagination or error handling, which could be useful but are not critical for a simple search tool. Overall, it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema: it provides examples for the 'q' parameter ('baseball', 'cooking', 'travel') and specifies the default value for 'limit' (25). The schema only provides type and constraints; the description enriches understanding.
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 searches Meta's interest targeting catalog by keyword. It specifies the exact resource (interest catalog) and action (search). The tool name and description differentiate it from sibling tools like meta_ads_search_behaviors and meta_ads_search_demographics, which search other targeting catalogs.
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 explicitly states the output is suitable for use in an ad set's targeting.flexible_spec, indicating context. However, it does not provide explicit guidance on when not to use this tool versus alternatives, though the sibling tools' names imply differentiation.
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?
Annotations already indicate readOnly, non-destructive, and idempotent behavior. The description adds crucial details about client-side filtering and the lack of server-side name filter, going beyond annotations. It doesn't mention performance implications or output structure, but the added context is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences plus Args line) and front-loaded with the action. Every sentence adds value: what it does, how it works, and a key limitation. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only search tool, the description covers the main behavior and parameter. It could mention the return format (e.g., list of page objects) or potential performance concerns for large accounts, but it is generally adequate.
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 carries full burden. It clearly explains that search_term is a substring to match against page name or username, adding essential meaning beyond the type and minLength constraint.
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 searches user's pages by case-insensitive substring of name or username, using an active verb and specific resource, and distinguishes from siblings like meta_ads_get_account_pages which retrieves all pages without filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the internal mechanism (client-side filtering after fetching all pages) and the Graph API limitation, implying when this tool is appropriate. However, it does not explicitly state alternatives or when not to use it, though context from siblings is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false) align with the description, which adds pagination behavior and return format details. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args and Returns sections, but could be slightly more concise; still clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers usage, pagination, return format, and parameter guidance thoroughly, despite no output schema and many parameters.
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 100% schema coverage, the description still adds value by listing common fields, providing examples, and explaining pagination, effectively complementing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves performance insights for a specific Meta ad set, which distinguishes it from sibling tools for ads, campaigns, and accounts.
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?
Implies usage for ad set analysis and includes a pagination note directing to meta_ads_fetch_pagination_url, but does not explicitly compare to alternative insight tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral context: it explains the structure of the return object, the meaning of account_status codes (e.g., 1=ACTIVE), and that omitted 'fields' parameter defaults to a list of common fields. No contradictions with annotations.
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 concisely structured with a summary, Args, Returns, and Examples sections. Every sentence serves a purpose. It is not verbose, and the format makes it easy for an agent to parse quickly. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only tool without an output schema, the description provides complete context: purpose, parameters with format, return object explanation with key fields and status codes, and usage examples. It fully addresses the tool's complexity and leaves no gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, both parameters have descriptions. The description adds beyond the schema: it specifies the 'act_' prefix for act_id, lists the default fields for the optional 'fields' parameter, and provides the return object structure including key fields and their types. This significantly enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed information about a specific Meta ad account. It distinguishes from siblings like 'meta_ads_list_ad_accounts' (listing all accounts) and 'meta_ads_get_adaccount_insights' (insights). The verb 'Get' and resource 'detailed information about a specific Meta ad account' are precise.
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 two concrete 'Use when' examples, giving context for when to invoke the tool. However, it does not explicitly state when _not_ to use this tool or suggest alternative tools for listing all accounts or retrieving insights. This omission keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, etc. Description adds valuable behavioral context: how ad_id resolves to video_id via the creative, and that using act_id avoids permission errors #10/#33. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with return values, then usage notes. Every sentence earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and rich annotations, the description covers purpose, parameters, usage behavior, and error avoidance. No output schema needed as return fields are listed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description explains the meaning of each parameter: ad_id as alternative to video_id, and act_id to avoid errors. Fully compensates for 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?
Description clearly states 'Get video details (source URL, thumbnail, title, duration) for a Meta ad video', with specific verb and resource. No sibling tool retrieves video details, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use ad_id vs video_id, and recommends passing act_id to avoid permission errors. Provides actionable context for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/hashcott/meta-ads-mcp-server'

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