Meta Ads MCP

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clear domain prefix and a distinct verb-noun action, so even with 118 tools, purposes are unambiguous. The few overlapping tools like ads_get_ad_preview and creatives_preview differ by input (ad vs creative) and are well-described.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern, with domain prefixes (ads_, creatives_, ig_, pages_, etc.) providing a predictable structure. Verbs like list, get, create, update, delete, pause, and activate are used uniformly.
Tool Count1/5
At 118 tools, the server is far beyond the typical well-scoped range of 3–15 tools. While the breadth covers many Meta APIs, the sheer number is extreme and overwhelms the agent, matching the 'extreme mismatch' criterion.
Completeness5/5
The tool set provides comprehensive lifecycle coverage across all major domains: ads, ad sets, ads, creatives, audiences, billing, catalogs, Instagram, Pages, WhatsApp, pixels, and leads. Documented limitations have workarounds, and there are no obvious dead ends.
Average 3.4/5 across 98 of 118 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It lacks any detail about the destructive nature beyond the word 'delete', implications for sent messages, permission requirements, or the effect of the 'confirm' parameter. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, making it easy to parse. However, it is terse to the point of under-specification, lacking essential context that should accompany deletion tools. Still, given the low information content, it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description fails to explain the deletion process, the purpose of the confirm flag, or any constraints (e.g., template must exist, cannot be deleted if in use). This is far from complete for a potentially dangerous operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. Only 'template_name' is implicitly mentioned via 'by name'; 'waba_id' and especially 'confirm' are completely unexplained. The description adds no value beyond the schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and the resource (template), and specifies the key attribute (by name). It distinguishes from sibling tools like wa_create_template and wa_list_templates by being the delete operation, though it doesn't explicitly mention scoping to a WABA.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, ideal scenarios, or prerequisites. Although the tool name clearly indicates deletion, there is no explicit context about when deletion is appropriate (e.g., only for unused templates) or any mention of the confirm parameter's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'Two-step process' but doesn't explain what the steps are, prerequisites, side effects, or required confirmation. The 'confirm' parameter and its purpose are not disclosed. Minimal behavioral insight is provided.
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 short and to the point, but the 'Args:' section is incomplete and somewhat disorganized. It wastes no words but fails to provide enough structure or clarity, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no output schema, and no annotations, the description is highly inadequate. It doesn't explain the two-step process, return values, confirmation behavior, or any prerequisites. This is a publish action with potential side effects that needs more context to be safely used.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions media_type with allowed values, but not its meaning. The other five parameters (ig_account_id, video_url, caption, cover_url, confirm) are completely unexplained. The 'Args:' section is misleading as it lists only one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Publish a video/reel to IG', which is a specific verb+resource action. It distinguishes from siblings like ig_publish_image by indicating video/reel, though it doesn't explicitly compare to other publish tools. The 'Two-step process' adds a bit of context about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description does not mention ig_publish_image for images or any exclusions. The 'REELS (recommended)' note is parameter advice, not usage context. Usage is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Reply to an IG comment.' It does not disclose side effects, confirmation behavior (despite a confirm parameter), rate limits, or whether it is a read or write operation. The agent is left blind about the tool's behavior beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it essentially restates the tool name without adding context. It is under-specified rather than appropriately concise, missing important details about usage and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no annotations, and no output schema, the description is too sparse. It does not explain prerequisites (e.g., needs an existing comment), return values, or the confirm flag's purpose. This leaves significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention message, comment_id, or confirm. The description adds no meaning beyond the schema's parameter names, so the agent must guess what each parameter means and how they interact.
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 action (reply) and the target resource (an IG comment), which distinguishes it from hide/delete/list operations. However, it does not differentiate from pages_reply_to_comment, though 'IG' provides some context. Overall a clear purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like pages_reply_to_comment or other comment tools. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it merely states the action. It does not mention side effects, required permissions, the meaning of the 'confirm' parameter, or any error/response behavior, leaving the agent uninformed about crucial operational traits.
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, concise sentence with no redundant words, achieving maximum front-loading. It is appropriately terse for a simple action, though it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but critical context is missing: no distinction from Instagram's reply tool, no explanation of the 'confirm' parameter, and no mention of permissions or expected output. The presence of sibling tools like ig_reply_to_comment and pages_hide_comment highlights the need for more contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about any of the three parameters. The 'confirm' boolean is especially ambiguous, with no explanation of its purpose or effect, forcing the agent to guess.
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 core action ('Reply to a comment') with a specific verb and resource. However, it does not differentiate from sibling tools like ig_reply_to_comment or explicitly mention that it applies to Facebook Pages, relying on the tool name for context.
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 ig_reply_to_comment or pages_hide_comment. There are no preconditions, platform distinctions, or any contextual cues beyond the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but 'Pause an ad set' only states the action. It does not mention the confirm parameter, reversibility, side effects, or required permissions, leaving significant behavioral ambiguity for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five words with no redundancy, making it maximally concise. It is appropriately short for a simple pause operation, though it sacrifices informative detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, this minimal description leaves the agent without essential context about the confirm flag, operational effects, or usage prerequisites. It is adequate only as a basic identifier, not as a complete operational guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and parameters (adset_id, confirm) are entirely unexplained in the description. The description does not compensate by indicating which parameters are needed or how they affect the action, providing zero semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Pause an ad set' clearly states the action (pause) and the resource (ad set), which distinguishes it from sibling tools like ads_pause_campaign. However, it essentially restates the tool name with no additional context, so it's clear but not enhanced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ads_pause_campaign or ads_activate_adset. The description does not mention scenarios, prerequisites, or related tools, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states a read operation ('Get') and does not mention permissions, return format, side effects, or any other behavior beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, front-loaded with the verb and resource. It contains no redundant or extraneous information, making it highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the tool returns or any important behavior; it only states the function. For a simple getter, it lacks essential contextual details like return value structure or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'account_id' with no description (0% coverage), and the description does not explain its format or meaning. The agent receives no additional semantic help beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and resource 'configured spending limits for an ad account', clearly identifying the operation. However, it does not differentiate from sibling billing tools like billing_get_account_spend, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, and no prerequisites or conditions are mentioned. The description is purely functional without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only says 'get details' without addressing error handling, return format, permissions, or what 'details' includes. This is a significant gap for a tool with no structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and entirely focused on the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the lack of output schema and annotations means the description should provide more context about the return value or error behavior. It only states the basic action, leaving the agent without enough information to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no explanation of product_id semantics, format, or how to obtain the value. The description only mentions 'single product' without connecting it to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details for a single product, distinguishing it from sibling tools like catalog_list_products (plural) and catalog_get (catalog-level). The verb 'get' and resource 'product' are specific, though it does not explicitly mention the product_id parameter.
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 catalog_list_products or catalog_get. The description offers no exclusions or context about when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of disclosing behavior. It only says 'update', which implies mutation, but does not explain whether fields are merged or replaced, the purpose of the confirm flag, potential side effects, or required authorization. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, front-loading the core function. However, it is arguably under-specified for a tool with a nested fields object and a confirm parameter, making it slightly too terse to be fully helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter descriptions, the description is insufficient. It fails to explain return values, the effect of the confirm flag, the structure of the 'fields' object, or any side effects, leaving the agent guessing on key behaviors needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only mentions 'arbitrary fields', which gives some meaning to the 'fields' object but leaves product_id and confirm unexplained. The description does not add enough to make parameter use clear, especially given the nested object and confirmation boolean.
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 updates a product with arbitrary fields, using the specific verb 'update' and resource 'product'. It is straightforward and distinguishable from create/delete siblings, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other catalog tools, nor any prerequisites such as existing product checks or required permissions. The description is purely a statement of function without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions 'hide or unhide' and does not explain reversibility, permissions, side effects, or the role of the 'confirm' parameter. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no waste. It is front-loaded and efficient, though it sacrifices detail for brevity. Conciseness itself is good, but it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no annotations, and no output schema. The description fails to explain parameter semantics, return values, or when to use the tool. It is far from complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three parameters. The 'confirm' and 'hide' parameters are left completely unexplained, forcing the agent to guess their meaning. The description adds no value to parameter 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 action: hide or unhide an IG comment. It specifies the verb and resource, and distinguishes from sibling tools like ig_delete_comment (delete vs hide) and pages_hide_comment (Instagram vs Pages).
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. It does not mention that this is for Instagram comments only, nor does it point to pages_hide_comment for Facebook Pages. The usage context is only implied by the tool name and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the entire burden of behavioral disclosure. It implies a read-only status check but does not describe the return format, possible job states, error conditions, or any side effects. This minimal transparency leaves the agent with significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant information. It is front-loaded and efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the lack of output schema and absence of guidance on interpreting the status result or relating to sibling async report tools makes the description incomplete for effective agent use. The description covers only the most basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description fails to explain the report_run_id parameter. The description adds no meaning beyond the parameter name already visible in the schema, leaving the agent to guess the expected format or value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking the status of an async insights report job, using a specific verb and resource. However, it does not differentiate from sibling tools like insights_get_async_report or insights_fetch_async_report, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no mention of polling behavior or prerequisites, and no exclusions. It simply states what it does without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'Get detailed info' without specifying what fields are returned, whether authentication is required, or if this is a safe read-only operation. The lack of any behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, well front-loaded. However, it is perhaps too terse, missing valuable context that could be added without excessive length. Still, it earns high marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no additional context, the description leaves the user guessing about the return format and content. For a simple get operation it is marginally adequate, but completeness is low given the absence of behavioral or return-value 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 description coverage is 0%, so the description must compensate. It does not explain the page_id parameter beyond its name, leaving the format, source, or any constraints undocumented. The param name is self-explanatory but the description adds no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the purpose as retrieving detailed information about a Page, with a specific verb and resource. It distinguishes from siblings like pages_get_post and pages_get_insights, though 'detailed info' is somewhat generic.
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 vs alternatives. It does not mention that this is for page metadata, nor does it reference sibling tools like pages_list or pages_get_post for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the tool can both hide and unhide, implying reversibility, but it does not explain the side effects, the meaning of the 'confirm' parameter, or whether confirmation is required for irreversible actions. This leaves significant ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words, front-loading the core action. However, it is overly terse and could have included parameter semantics or usage nuances without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters but only one is required, and the description does not explain when the optional parameters should be used or what the default behavior is. Given the absence of annotations and output schema, the description is insufficient for an agent to understand the full scope of the tool, especially the 'confirm' flag and the toggle behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-specific information. While 'comment_id' and 'hide' are inferable from context, the 'confirm' parameter is left completely unexplained. The description fails to indicate that the 'hide' boolean toggles between hide/unhide or the role of 'confirm' in the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('hide or unhide') and resource ('a comment from a post'), which accurately reflects the tool's function and distinguishes it from reply/delete operations. However, it does not explicitly differentiate from sibling tools like ig_hide_comment, relying on the 'pages_' prefix for that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as pages_reply_to_comment or ig_hide_comment. It only describes the action without any context about prerequisites, platform-specific constraints, or scenarios that warrant hiding vs deleting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states a read operation but omits any behavioral details such as pagination, ordering, or whether nested replies are included. The description adds minimal value beyond what the tool name already implies.
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, concise sentence with no filler. It is front-loaded with the verb and resource, making it easy to scan. However, it sacrifices some useful detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is quite thin. It lacks information about output format, pagination, auth requirements, or any edge-case behavior. With no annotations or output schema, the description alone is insufficient for an agent to fully anticipate the tool's behavior.
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?
The schema has two parameters (post_id, limit) with zero description coverage. The description only mentions 'a post', which hints at post_id, but does not explain the limit parameter or provide any syntax or meaning beyond the schema's basic titles.
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 action (list) and resource (comments on a post), distinguishing it from other comment-related tools like pages_reply_to_comment or pages_hide_comment. However, it doesn't explicitly specify that this applies to Facebook Page posts, though the tool name implies it.
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 alternative comment-listing tools like ig_list_comments. There are no mentioned prerequisites, permissions, or context for when this tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'permanently' discloses irreversibility, which is useful. However, with no annotations, the description fails to mention role of the confirm parameter (likely to prevent accidental deletion), the behavior when confirm is false, or any permission requirements. This is a destructive operation and needs more behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, one short sentence with no fluff. It adequately states the core purpose, though it could include more detail without becoming verbose. It earns its place but is slightly under-specified in favor of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete tool with no annotations, no output schema, and two parameters (one required, one with default), this description is incomplete. It doesn't explain the behavior of the confirm flag, possible errors, return format, or any consequences beyond 'permanently'. The agent would be left guessing about safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions neither ad_id nor confirm. The confirm boolean's meaning (e.g., whether it's required to actually delete) is completely unaddressed. The description adds no value beyond the schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (a single ad), and the scope (permanently). It effectively distinguishes from sibling tools like ads_pause_ad or ads_activate_ad, and the 'single ad' qualifier differentiates it from ads_delete_campaign or ads_delete_adset.
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 about when to use this tool versus alternatives. It doesn't mention that this is for permanent removal as opposed to pausing/adjusting, nor does it explain any prerequisites or the purpose of the confirm parameter. Sibling tools like ads_pause_ad exist, so explicit alternatives would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Pause a single ad,' which merely restates the core action. It does not disclose side effects, the need for confirmation (despite a 'confirm' parameter in the schema), or what happens to the ad's status.
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 clear sentence with no wasted words. It is front-loaded with the action and resource. However, it may be under-specified given the tool's simplicity and missing parameter info, but conciseness itself is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and two parameters with zero schema descriptions. The description does not explain the purpose of the confirm flag, how to identify an ad, or what response to expect. For a mutation tool with safety considerations (pausing), this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameters. The schema shows ad_id (required) and confirm (optional boolean), but the description does not explain what these mean, what format ad_id should be, or the role of confirm. The agent is left with no semantic hints beyond type/name.
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 'Pause a single ad' uses a specific verb ('pause') and resource ('ad'), clearly distinguishing it from sibling tools like ads_pause_campaign and ads_pause_adset. The qualifier 'single' reinforces that it operates on one ad at a time.
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 usage guidance is provided. The description does not mention when to use this tool over alternatives (e.g., pausing a campaign or adset), nor does it mention the confirm parameter or any prerequisites. Context must be inferred entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only says 'Get', implying a read operation, but does not state permissions, rate limits, response shape, or what happens if the account is not a Business account.
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?
One sentence, no fluff, front-loaded with the verb. Efficient and appropriately sized for the simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param tool without annotations or output schema, the description is too sparse. It doesn't explain the return value ('profile info' is not defined), nor does it provide context about account prerequisites or error conditions.
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?
The schema lists a single parameter ig_account_id with no description. The tool description does not explain what this ID is, how to obtain it, or its format. The parameter name is somewhat self-explanatory, but the description adds no additional semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get profile info for an IG Business account' with a specific verb and resource. It distinguishes from sibling tools like ig_get_account_insights and ig_list_accounts by focusing on profile info rather than insights or account lists. However, 'profile info' is somewhat vague regarding the exact fields returned.
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. It does not mention that for media or insights one should use other tools, nor any prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states 'Get Page insights metrics' and lists examples, but does not disclose pagination, rate limits, required authentication, or behavior with invalid parameters. This is minimal beyond the tool's name.
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, front-loaded with a clear one-line summary, followed by a compact Args section. Every element serves a purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is insufficiently complete. It omits key parameters, return format, and handling of date ranges, leaving significant ambiguity for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful examples for 'metrics' and enumerates valid values for 'period', but only 2 of 6 parameters are covered. Required 'page_id' and optional 'since', 'until', and 'date_preset' are undocumented, and schema coverage is 0%, so the description only partially compensates.
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 Page insights metrics, with examples of metrics and period values. It distinguishes this from other insights tools by specifying 'Page' context, though it doesn't explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ig_get_insights or insights_get_account_summary. The description implies usage for Facebook Page insights but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states 'Duplicate a single ad' without disclosing side effects, confirmation behavior, or what happens to the copied ad. The 'confirm' parameter suggests a required confirmation, but this is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the operation, with no filler. It is appropriately front-loaded and concise, earning its place without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no annotations or output schema, yet the description only says 'Duplicate a single ad.' It fails to explain parameter behavior, return values, or any side effects, leaving the agent without sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the four parameters (ad_id, confirm, status_option, rename_options). The description adds no meaning beyond the schema's bare parameter names, leaving all parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'duplicate' and resource 'ad', clearly distinguishing it from sibling tools like ads_duplicate_campaign and ads_duplicate_adset. It matches the tool name and leaves no ambiguity about the operation.
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 about when to use this tool versus alternatives like ads_create_ad or ads_update_ad. The description only states the action, with no context on prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It identifies the action as creation but does not mention the 'confirm' parameter's role, required permissions, potential side effects, or any limitations. The presence of a confirm boolean suggests a confirmation step may be needed, but this is left unexplained.
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 brief and front-loaded, starting with the primary action and resource. The 'Args:' note efficiently enumerates the vertical parameter's valid values. However, the brevity omits critical details, though the structure is otherwise clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return values, confirmation semantics, prerequisites, or how to handle the 'confirm' parameter. An agent would not fully understand the creation flow or success criteria from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It explicitly covers 'vertical' with examples of acceptable values, and implicitly implies 'business_id' and 'name' via the phrase 'under a Business Manager,' but 'confirm' is entirely unaddressed. This partial coverage does not fully compensate for the complete lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and clearly identifies the resource ('a new product catalog') and its scope ('under a Business Manager'). This clearly distinguishes it from sibling tools like catalog_get, catalog_list, and catalog_create_product.
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 implies use when creating a new catalog but provides no explicit guidance on when to prefer this tool over alternatives, nor any prerequisites or exclusions. Sibling tools like catalog_create_product suggest related but distinct actions, but no comparative usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose that the operation is destructive, irreversible, or might require confirmation via the 'confirm' parameter. Given the tool's nature, more behavioral context is needed.
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 clear sentence with no filler. It is concise but lacks important contextual details, though it earns points for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with a confirm parameter and no annotations or output schema, the description is too sparse. It omits any mention of confirmation, permanence, or side effects, making it incomplete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters. While product_id is self-explanatory from its name, the 'confirm' boolean's meaning and requirement are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'delete' and clearly identifies the resource as 'product from the catalog'. This differentiates it from sibling tools like catalog_create_product or catalog_update_product, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor on preconditions or consequences. The description is a bare statement without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It only states the action and gives no information about return format, pagination, sorting, error behavior, or permissions. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, clear sentence that is front-loaded and contains no wasted words. It is concise and immediately comprehensible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with no output schema and no annotations, this description is too thin. It omits expected details such as pagination via the limit parameter, what product fields are returned, or how the catalog_id identifies the catalog. An agent would struggle to use it correctly beyond the obvious call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate for the two parameters. It adds only the vague context 'in a catalog' for catalog_id and says nothing about limit. While parameter names and schema titles provide some obvious clues, the description fails to offer meaningful semantic enrichment.
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 'List products in a catalog' uses a specific verb and clearly scopes the resource to a catalog. It distinguishes from siblings like catalog_get_product (single product) and catalog_list (list catalogs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or when a sibling like catalog_get_product would be more appropriate. Usage context is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must convey behavioral details, but it only states the action and lists common metrics. It does not disclose whether this is a safe read-only operation, how date range and period parameters behave, or any pagination/response characteristics.
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 brief and front-loaded with the core purpose, and the metrics list is useful without being verbose. It avoids redundancy, though formatting could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no annotations, no output schema, and a rich sibling context, the description is too sparse. It omits parameter values/ranges, account ID format, and return structure, so an agent would likely need additional information to invoke the tool successfully.
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?
The schema provides zero descriptions for parameters, and the description only adds meaning for the 'metrics' parameter by listing common metric names. It does not explain the meaning of ig_account_id, since, until, or period, leaving most parameters ambiguous.
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 account-level insights for an IG Business account, using a specific verb and resource. The 'account-level' qualifier distinguishes it from sibling tools like ig_get_insights, which likely target media-level insights.
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 choose this tool over related insight tools such as ig_get_insights, insights_get_account_summary, or pages_get_insights. It also doesn't mention prerequisites like having a linked IG Business account or required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List comments' and doesn't mention pagination, return format, required permissions, or any other operational details, leaving the agent without critical context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no extraneous words, making it appropriately concise. However, it could have packed more useful information (e.g., parameter hints) without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, no output schema, and no annotations, the description is too sparse to be complete. It doesn't mention response structure, pagination, or any edge cases, leaving significant gaps for an agent.
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?
The schema has 0% description coverage, and the description does not explain the parameters media_id or limit. It only implies that media_id refers to the media post, but it doesn't clarify the limit parameter or the meaning of the values.
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 resource (comments on an IG media post), using a specific verb and noun. It distinguishes itself from sibling tools like ig_list_media and pages_list_comments by targeting Instagram media specifically.
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 pages_list_comments or other Instagram tools. The description lacks context about use cases, exclusions, or relationships to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'Fetch results' and does not describe response format, error behavior for incomplete reports, pagination, auth requirements, 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 a single, front-loaded sentence containing only the essential action and object. There is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description is too sparse. It does not clarify what 'results' are, how limit works, or what happens if the report is still processing. The sibling tool names provide some context, but the description itself is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to report_run_id or limit. The schema provides only names, types, and a default, leaving the agent to guess how these parameters affect the fetch.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and a clear resource 'results of a completed async insights report,' making the core purpose evident. It is distinguishable from sibling tools like insights_check_async_report (status checking) and insights_get_async_report, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'completed' implies this tool should be used after an async report has finished, but the description does not explicitly state when to use it versus alternatives or what to do if the report is not ready. No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states the operation and does not mention pagination, ordering, return format, authentication requirements, or the meaning of the 'limit' parameter. This is a significant gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the purpose. There is no filler or unnecessary detail; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks essential context: no output schema is provided, so the description should describe the return value (e.g., list of post IDs vs. full post objects), but it does not. It also lacks guidance on pagination or limits, making the description insufficient for an agent to fully understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It does not explain what page_id identifies or how limit behaves (e.g., max/page size). With two parameters and no meaning added, the agent is left to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'published posts of a Page', which distinguishes it from sibling tools like pages_get_post (single post), pages_publish_post (create), and pages_delete_post (delete). The scope is precise and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that pages_get_post retrieves a single post or that pages_list_comments handles comments. The agent must infer usage from the name and context, which is insufficient given the large sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation but does not disclose potential errors (e.g., not found), authentication requirements, or response format. The lack of any behavioral context falls short of what a minimal description should provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It communicates the core action and resource clearly, earning its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one parameter and no output schema, the description is minimally adequate. However, it does not specify what 'details' includes, nor does it address error/edge cases, leaving some ambiguity for the agent. Sibling tools like catalog_list_products and catalog_get_diagnostics indicate more specific detail tools, but this is not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention 'catalog_id' at all. The single parameter rests entirely on the schema's field name, which is self-explanatory, but the description adds no meaning beyond the schema and fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a single catalog' uses a specific verb (Get) and resource (catalog) with clear scope (single catalog). This distinguishes it from siblings like catalog_list (multiple catalogs) and catalog_get_product (a product within a catalog).
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 gives no guidance on when to use this tool versus alternatives. It simply states the function without mentioning exclusions, prerequisites, or referencing sibling tools like catalog_list or catalog_get_product.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists videos, implying a read-only operation, but doesn't disclose pagination, ordering, or response structure. The behavior is minimal but not misleading.
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 one short sentence with no wasted words, clearly front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, the description is too minimal to be fully complete. It doesn't explain the limit parameter or the shape of the response, which is important for an agent to handle results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no information about account_id or limit parameters beyond what the name implies. The account_id can be inferred from 'account's video library,' but limit is completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'videos' and scope 'account's video library,' clearly indicating the tool's function. It doesn't explicitly distinguish between sibling tools like creatives_list_images, but the resource is unique enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like creatives_list or creatives_list_images. The description only states what it does, not when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose the key behavioral trait that deletion is permanent, but it omits other important details such as whether confirmation is required, whether deletion cascades to associated data, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. However, it is overly terse given that it omits essential parameter information, so it does not fully earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a minimally described confirm parameter, the description leaves significant gaps. The agent cannot fully understand the deletion workflow or the role of the confirm flag from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. The post_id is somewhat inferable from 'post', but the critical 'confirm' boolean parameter is completely unexplained, leaving the agent without guidance on how to invoke the deletion safely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name is pages_delete_post and the description 'Delete a post permanently' clearly specifies the verb (delete), resource (post), and scope (page post, inferable from name). It is not easily confused with sibling tools like pages_publish_post or pages_get_post.
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 when-to-use or when-not-to-use guidance is provided. The description implies the tool is for deleting a post, but it does not mention alternatives, prerequisites, or the need for confirmation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only mentions 'including diagnostics' without explaining what diagnostics entails, return format, or any safety considerations. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loaded with the action and resource. It is concise with no redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, the description is too sparse. It doesn't specify what detailed info is returned, how diagnostics are structured, or any potential error conditions. A one-line description for a getter with no other metadata is insufficient.
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?
The schema has one parameter (pixel_id) with 0% description coverage, and the description does not explicitly explain the parameter's meaning or format beyond the name. It only implies that pixel_id identifies the pixel, adding minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed info about a single pixel', using a specific verb and resource. It distinguishes from siblings like pixels_list by emphasizing 'single pixel', though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need information about one specific pixel, as opposed to pixels_list or pixels_get_stats. However, there is no explicit mention of when not to use it or reference to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects, requirements (e.g., the 'confirm' parameter), or post-condition state. The description is too terse to qualify as transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It efficiently conveys the core purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description provides minimal context but omits critical operational details such as what the 'confirm' boolean does, any prerequisites, or expected outcomes. The lack of annotations and output schema makes this incomplete for an AI agent to invoke correctly with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention 'campaign_id' or 'confirm' at all, leaving the purpose of 'confirm' especially ambiguous. The description adds no semantic value over the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Activate (resume) a paused campaign' clearly states the specific action (activate/resume) and the target resource (a paused campaign). It effectively distinguishes itself from sibling tools like 'ads_pause_campaign' and 'ads_activate_adset' by specifying the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a paused campaign' implicitly indicates that this tool is for resuming previously paused campaigns, providing some usage context. However, it does not explicitly mention when to use this over alternatives like 'ads_activate_adset' or any conditions/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions the deep copy option but fails to disclose that the duplicated ad set is paused by default (status_option), that confirmation may be required (confirm), or that rename options exist. It does not describe side effects on the source ad set or required permissions. This is minimal disclosure for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the main action, but it is under-specified for a tool with five parameters. While the sentence is efficient, it does not cover essential aspects like defaults or options, making it too terse rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must be self-sufficient. It is far from complete: it omits explanations of most parameters, the default behavior (e.g., PAUSED status), the need for confirmation, and any return values. For a mutation tool with this complexity, the description is inadequate.
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?
The schema has 0% coverage for parameter descriptions, so the description must compensate. It only clarifies one parameter (deep_copy) via 'optionally including all ads inside it', leaving confirm, adset_id, status_option, and rename_options unexplained. The description adds minimal value beyond the schema's raw parameter names and does not help the agent understand what these parameters control.
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 ('Duplicate an ad set') and the resource (ad set), and it differentiates from sibling tools like ads_duplicate_campaign and ads_duplicate_ad by mentioning the optional inclusion of ads. The verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a copy of an ad set), and the phrase 'optionally including all ads inside it' suggests a key decision point. However, it does not explicitly state when not to use it, prerequisites (e.g., needing an existing adset_id), or how it compares to alternatives like ads_duplicate_campaign or ads_create_adset. No explicit exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns a preview, implying a read-only operation, but does not disclose permissions, side effects, or whether it modifies the ad. For a tool with no annotations, more behavioral context is needed.
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 two sentences that are front-loaded and directly to the point. The ad_format list is relevant and compact, making every sentence count without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple preview tool, the description conveys the core functionality and provides useful ad_format constants. However, with no output schema, it does not explain the return format (e.g., HTML string vs URL), and it lacks comparison to related tools, leaving some context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully lists common ad_format values, adding meaning to that parameter. However, it does not elaborate on ad_id beyond the schema, and the ad_format list is given as 'common' rather than exhaustive, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('a renderable HTML preview of an ad'), using the specific term 'preview' to distinguish from sibling tools like ads_get_ad which fetches ad details. It lacks an explicit comparison, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 ads_get_ad or creatives_preview. The description only lists common ad_format values, which is parameter-level guidance, not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'full details' with no information about response format, error behavior, rate limits, or permissions. A get operation implies read-only, but the description doesn't even confirm that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is front-loaded with the verb and resource, earning its place effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and minimal description, the agent is left guessing what 'full details' includes. There's no mention of edge cases, such as nonexistent campaign IDs, or what fields are returned. The description is too sparse to be fully useful.
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?
The schema has 0% description coverage for campaign_id, and the description does not compensate. It says 'single campaign' but doesn't explicitly explain that campaign_id is the identifier, how to obtain it, or its format. The parameter name is self-descriptive, but the description adds little meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('campaign'), and specifies 'single' to distinguish from listing tools like ads_list_campaigns. It unambiguously identifies this as a retrieval operation for one campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that ads_list_campaigns should be used to find campaigns first, nor any prerequisites or exclusions. The usage is only implied by the tool name and required parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must fully disclose behavioral traits. It only states 'Create', which implies a mutation, but does not mention permissions, side effects, return values, or any validation conditions. This is insufficient for an agent to understand the operational impact.
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 exceptionally concise, consisting of two sentences with no redundancy. The critical card structure is front-loaded, and every word contributes to the tool's purpose. It is appropriately sized given its sparse content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (9 parameters, 6 required, no output schema, no annotations), the description is far from complete. It only covers a fragment of the cards parameter and omits essential information about other parameters, return behavior, and usage conditions. An agent would struggle to invoke this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially documents the 'cards' parameter with a structure (link, image_hash, name, description), but leaves it vague with ellipses and entirely ignores the other 8 parameters, including required ones like account_id and page_id. This does not adequately compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Create' and a specific resource 'multi-card carousel creative', clearly distinguishing it from related tools like creatives_create_link_ad. The purpose is unambiguous: this tool creates carousel ads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any use cases, exclusions, or alternative tools. The tool name implies carousel usage, but the description itself offers no explicit or implied context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does reveal that the output is rendered HTML, which is a useful behavioral detail beyond the schema. However, it does not disclose side effects, permission requirements, error cases, or the meaning of 'any ad format', leaving the behavior only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key information. Every word contributes value, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description provides the core purpose and return format. However, it lacks guidance on alternatives, parameter details, and error behavior, making it only minimally viable. The sibling ads_get_ad_preview suggests missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'any ad format' which adds some meaning to ad_format, and implicitly refers to creative_id, but it does not explain the valid formats, the default value, or how the required creative_id should be used. This is minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Preview') and resource ('a creative'), and clarifies the output format ('returns rendered HTML'). It is clear, but it does not explicitly differentiate from sibling tools like ads_get_ad_preview, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention ads_get_ad_preview or any other potential substitute, nor does it provide context on prerequisites or exclusions. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses irreversibility via 'permanently' but fails to mention the confirm parameter's role, permissions, or effects on associated data like replies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the tool's purpose with no wasted words. It is appropriately concise for a simple deletion tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations or output schema and only a minimal description, the tool lacks critical context for a destructive operation. The confirm parameter is essential but unexplained, and no return/effect information is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds zero explanation for comment_id or confirm. The confirm flag's meaning is left entirely to inference, making the tool risky to invoke incorrectly.
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 'Permanently delete an IG comment' uses a specific verb (delete), resource (IG comment), and a qualifier (permanently) that clearly distinguishes it from sibling tools like ig_hide_comment and ig_reply_to_comment.
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 word 'permanently' implies this tool is for irreversible deletion versus temporary hiding, but no explicit when-to-use or alternative guidance is provided. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether the operation is read-only, what fields are returned, or any permissions/rate limits. The description simply restates the function name without adding behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should explain return values, error behaviors, or access requirements. It does not, leaving an agent with insufficient information to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not mention the media_id parameter at all, nor does it provide any format or example. It fails to compensate for the schema's lack of semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get details' and resource 'single IG media post', clearly distinguishing it from sibling tools like ig_list_media which lists multiple posts.
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 word 'single' implies use when fetching one specific post, but there is no explicit guidance on when to use this tool versus alternatives like ig_list_media or ig_publish_image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation by using 'Get', but does not explicitly state the return format, error behavior, or any side effects. The only added behavioral insight is that the response includes the question schema, but this is minimal and does not cover other relevant details like rate limits or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary purpose and is free of extraneous information. It is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is incomplete. It mentions the question schema but does not clarify what other details are included in the response, nor does it address potential questions about lead form ownership or access. For a simple read tool, this might be acceptable, but the lack of return-field documentation leaves gaps for an agent trying to predict the tool's output.
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?
The input schema has one required parameter, form_id, but schema description coverage is 0%. The description does not explain what form_id is, how to obtain it, or its format. While the parameter name is somewhat self-explanatory, the description fails to provide meaningful context beyond the schema, so it does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of a single lead form, using the specific verb 'Get' and resource 'single lead form'. It also mentions 'including its question schema', which distinguishes it from sibling tools like leads_list_forms (which lists forms) and leads_get_lead (which retrieves a lead). This is a specific and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as leads_list_forms or leads_get_lead. It does not mention any prerequisites or context, leaving the agent to infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must fully disclose behavior. 'Get full data' implies a read-only operation, but does not explain what fields constitute 'full data', potential errors, pagination, or any side effects. This is a significant gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words; the description is well front-loaded and immediately states the primary action. However, extreme brevity borders on under-specification, so it does not achieve a perfect score.
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?
Tool complexity is low (one parameter, no output schema), and the description adequately conveys the core purpose. However, it lacks return-value details, usage guidance, and any mention of data scope, making it only minimally sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the lead_id parameter beyond the schema's type/name. It only says 'single lead', which implicitly references the identifier but fails to provide source, format, or usage details needed to disambiguate.
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 uses specific verb 'Get' and resource 'full data for a single lead', clearly distinguishing from sibling list tools like leads_list_from_form and leads_list_from_ad which return collections. It unambiguously describes a single-record retrieval by identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as leads_list_from_form or leads_list_from_ad. The only implicit cue is 'single lead', but no explicit context, prerequisites, or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the simple retrieval action. It does not mention pagination, rate limits, or whether the returned leads are ordered, and the phrase 'all leads' contradicts the existence of a limit parameter without clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose without unnecessary words or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description lacks essential context: no usage guidance, no behavioral details, and no explanation of return values (since there is no output schema). The presence of similar sibling tools heightens the need for additional context, which is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the ad_id or limit parameters. The names are somewhat self-explanatory, but the description fails to add any meaning about parameter usage, such as how limit affects results or what format ad_id must take.
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 'Retrieve all leads generated by a specific ad' clearly states the action (retrieve), the resource (leads), and the scope (by a specific ad). It distinguishes from sibling tools like leads_list_from_form and leads_get_lead, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as leads_list_from_form or leads_get_lead. It does not mention preconditions, typical use cases, or exclusions, leaving the agent to infer based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only says 'List', which implies read-only. It does not mention pagination, rate limits, or any side effects, and the word 'all' could be misleading if results are paginated due to the `limit` parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core purpose directly and efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description is too sparse. It does not explain the return structure, how to use `limit`, or the tool's role in the broader page management workflow, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the `limit` parameter at all. It does not explain that limit controls page size or that pagination may be needed, so it adds no semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List', identifies the resource 'Facebook Pages', and specifies the scope 'System User can access'. This clearly distinguishes the tool from sibling tools like pages_get (single page) and ig_list_accounts (Instagram accounts).
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 enumerating pages accessible to the System User but does not explicitly state when to prefer this over alternatives or mention that it might be a prerequisite for other page tools. No exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' clearly implies a read-only operation, and the mention of 'users/system users' adds specificity about what is returned. However, it does not disclose authentication requirements, response shape, pagination, or whether system users require special permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb, and contains no redundant or filler words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and no output schema. The description states the core purpose but omits return-value details, permission requirements, and any caveats. It provides minimum viable context but leaves gaps for a complex integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only references 'this pixel' without explaining the pixel_id format or where to obtain it. The single parameter is self-explanatory from its name, but the description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource: 'users/system users assigned to this pixel.' This distinguishes it from sibling tools like pixels_get (pixel details) and pixels_get_stats (statistics), though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not state prerequisites, context for use, or any exclusions. The usage context must be inferred entirely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not explain what 'share' entails, whether the confirm parameter is mandatory, or any side effects such as revoking access or requiring permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is appropriately concise for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with three parameters and no annotations. It fails to explain the confirm flag, the impact of sharing, or the expected result, making it incomplete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on any parameters. While pixel_id and business_id are self-explanatory, the confirm parameter's purpose and necessity are left ambiguous.
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 ('Share'), the resource ('a pixel'), and the target ('another Business Manager'). It is specific and distinguishes itself from sibling pixel tools like pixels_list and pixels_get.
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, nor any prerequisites, edge cases, or exclusions. The description only states the core action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions the public URL requirement but does not disclose potential side effects, authorization needs, irreversibility of sending a message, or error conditions. The tool appears to create a message, but this behavioral impact is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the primary purpose. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters, no annotations, and no output schema, the description contains only a minimal statement of intent. It does not explain required parameters, behavior, or return values, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only clarifies the image_url parameter ('from a public URL'). It does not explain phone_number_id, to, caption, or confirm, leaving these parameters semantically underdocumented for an agent.
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 ('Send an image'), the resource ('image'), and the channel ('via WhatsApp'), with the important constraint that the image comes from a public URL. This distinguishes it from sibling tools like wa_send_text_message and wa_send_template_message by message type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as wa_send_text_message or wa_send_template_message. It implies usage for sending images but provides no explicit context, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a significant side effect (changing objective restarts learning and may force-unpublish ad sets), which is valuable. However, it does not mention other potential behaviors such as permission requirements, reversibility of changes, or effects of updating other fields, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that state the purpose and a critical warning. It is front-loaded with the core action and avoids redundancy. Every sentence earns its place, making it highly efficient for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, no output schema, no annotations, zero parameter descriptions), this description is insufficient. It covers only the general purpose and one side effect, omitting details about parameter formats, return values, required permissions, or handling of optional fields. Agents would face significant ambiguity when invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter explanations. It only hints at the 'objective' parameter's consequences but does not describe any of the other 12 parameters (e.g., pacing_type, bid_strategy, spend_cap_cents). The schema provides only titles, so the description adds minimal semantic value beyond what is already self-evident.
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 'Update fields on an existing campaign,' which specifies the verb (update), resource (campaign), and scope (existing). It distinguishes from sibling tools like create/delete/pause/activate by focusing on field-level updates. The purpose is explicit, though it doesn't enumerate the exact fields, relying on the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying campaign fields and includes a warning about changing objective, which serves as a caution for when not to blindly update. However, it does not explicitly state when to use this tool versus alternatives like pause/activate or create/delete, nor does it mention any exclusions beyond the objective side effect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Get' implying read-only but does not disclose return format, field coverage, or other behavioral traits. 'Full detail' is vague.
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?
Single sentence with no redundant words; front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is minimally adequate but does not explain what 'full detail' includes or how the ID is obtained, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the custom_audience_id parameter at all. It adds no meaning beyond the schema's name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the resource ('full detail of a single custom audience'), clearly distinguishing it from sibling tools like audiences_list_custom and audiences_get_saved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need details of one custom audience by ID) but does not explicitly state when to use it vs. alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'list', implying a read operation, but does not mention pagination (despite a limit parameter), sorting, filtering, or what fields are returned. No additional behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is front-loaded and every word contributes to the meaning. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool with no output schema, this is minimally viable. It states the primary purpose and implies the return of a list, but lacks details on pagination, response shape, or how the limit parameter behaves. The lack of output schema makes this description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only hints that 'for an ad account' relates to account_id. The limit parameter is not described at all. The description fails to compensate for the lack of schema-level documentation, leaving parameter purpose and usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction: 'List saved audiences for an ad account.' It clearly identifies the action (list) and the target (saved audiences), and the scope (ad account) distinguishes it from similar tools like audiences_list_custom and audiences_get_saved.
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 usage context is provided. The description does not explain when to choose this over siblings (e.g., audiences_get_saved for a single saved audience) or mention any preconditions. It merely states the action with no guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description alone must disclose behavioral traits. It mentions 'Create' but does not explain that the 'confirm' parameter (default false) may control whether creation is final, nor does it describe any side effects or irreversibility. The behavior is too opaque for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single opening sentence followed by an Args list. Each bullet adds concrete value without any fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters (11 required), no output schema, and no annotations. The description covers only 5 parameters and says nothing about return values, confirmation behavior, or prerequisites. It is not sufficient for an agent to invoke the tool reliably without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful semantics for 'retailer_id' (internal SKU), 'price' (cents with example), 'currency' (ISO 4217), and enumerates allowed values for availability and condition. However, with 0% schema description coverage, it omits several required parameters (catalog_id, name, description, brand, image_url, url) and the optional confirm/extra_fields, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a single product in a catalog' with a specific verb and resource. It clearly distinguishes from siblings like catalog_create (creates a catalog) and catalog_update_product (modifies an existing product).
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, nor any prerequisites such as the catalog existing or the meaning of the 'confirm' parameter. Only the basic action is stated, leaving the agent without contextual decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. While 'Get' strongly implies a read-only operation, the description does not explicitly state safety, permissions, or what the response contains. It lacks details about potential side effects, rate limits, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that clearly communicates the tool's purpose without wasted words. Every part of the sentence adds meaning, and it is front-loaded with the core action.
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 low complexity (one required parameter, no output schema), the description is minimally adequate. However, it omits details about the return structure of diagnostic issues, any prerequisites (e.g., catalog existence), and how results might inform ad eligibility remediation. No annotations are available to fill these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. The only parameter, catalog_id, is self-explanatory from its name, but the description fails to add any value beyond the schema, such as format expectations or how the ID is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('diagnostic issues') and its scope ('catalog quality and ad eligibility'). This distinguishes it well from sibling tools like catalog_get, which likely retrieves basic catalog details rather than diagnostic issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as catalog_get or catalog_list_products. No exclusions or contextual hints are provided, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It indicates a read operation but omits details about pagination, how the 'limit' parameter behaves, return format, or potential errors. This leaves significant behavioral ambiguity.
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, concise sentence with no wasted words and is front-loaded with the core purpose. However, it is somewhat too terse given the missing behavioral details, making it less complete than optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description needs to explain what the response looks like. It does not describe the return format, pagination behavior, or error responses, leaving the agent without enough context to confidently use the tool.
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?
With 0% schema description coverage, the description must explain both parameters. It only alludes to business_id via 'owned by a Business Manager' and provides no explanation of the 'limit' parameter, leaving the agent without adequate parameter 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 action ('List') and the resource ('product catalogs') with a specific scope ('owned by a Business Manager'). This distinguishes it from sibling tools like catalog_list_products and catalog_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'all product catalogs' implies the tool retrieves everything for a given business, but it does not explicitly contrast with alternatives or mention when not to use it. Usage context is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims to list 'all' creatives, but the schema includes a default limit of 50, suggesting pagination or partial results may occur. No mention is made of pagination behavior, rate limits, or that the default limit may prevent fetching all creatives in one call. With no annotations, the description carries the full burden, and this omission is misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the core action and resource, which is ideal for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits important context such as the meaning of the limit parameter, pagination behavior, and how this tool relates to more specific list siblings. The claim of 'all' is ambiguous given the limit default. Enough for a basic list, but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only indirectly references account_id ('in an account') and ignores the limit parameter entirely. No additional meaning is provided beyond the parameter names in 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 uses a specific verb ('List') with a clear resource ('ad creatives') and scope ('in an account'). It distinguishes itself from sibling tools like creatives_list_images and creatives_list_videos by indicating it lists all creatives, not just a specific type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as creatives_list_images or creatives_list_videos. The description only states what it does, not the context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates 'recent' (implying ordering) but does not state whether the operation is read-only, how pagination works, what fields are returned, or any rate limits. This is insufficient for a tool with no annotation safety signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word earns its place, and it is appropriately sized for the tool's simplicity.
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?
There is no output schema, so the description should explain return values; 'List recent posts' implies a list but does not elaborate on contents or behavior. For a simple list tool it is minimally adequate but lacks parameter context and annotation coverage, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. It fails to explain that ig_account_id identifies the account or that limit controls the number of posts returned, leaving the agent to rely solely on parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('recent posts (media)') and scope ('from an IG account'). This distinguishes it from sibling tools like ig_get_media (singular) and ig_list_comments (comments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the action, leaving the agent to infer its relationship to ig_get_media or other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It discloses scheduling behavior (if scheduled_publish_time set, post is scheduled and published=False), but it omits other behavioral aspects like the effect of confirm, permission requirements, side effects, or reversibility. The overall behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the primary action stated first and the parameter note appended efficiently. It earns its place without fluff, though it omits important details that would make it more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no output schema, and no annotations, the description is incomplete. It does not cover the confirm parameter, expected return value, or full behavior of published/scheduled_publish_time interplay. The tool's complexity warrants a more thorough description.
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?
With 0% schema description coverage, the description must compensate, but it only explains scheduled_publish_time and its relationship with published. Other parameters (page_id, message, link, confirm) receive no semantic explanation, leaving the agent to infer their meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool publishes a 'text/link post to a Page,' which is a specific action and distinguishes it from sibling tools like pages_publish_photo. The verb 'publish' and resource 'Page' are explicit, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'text/link post' rather than photo, suggesting when to use this tool over pages_publish_photo. However, it lacks explicit alternatives, exclusions, or context such as prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action, omitting mutation effects, whether confirmation is required (despite a 'confirm' parameter), permission needs, or irreversible consequences.
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, front-loaded sentence with no waste. It is efficiently structured but could include additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 3 parameters, no output schema, and no annotations, this description is inadequate. It omits what the tool returns, the role of the confirm flag, and any required permissions or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. 'Under an ad account' hints at account_id's purpose, but name and confirm are not explained at all. The description does not add meaning for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and clearly identifies the resource ('pixel') and context ('under an ad account'). This distinguishes it from sibling pixel tools like pixels_list or pixels_get_stats.
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 it is used to create a pixel but provides no explicit guidance on when to use it versus alternatives, prerequisites (e.g., a valid ad account), or exclusions. The context is clear but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning whether it's read-only, rate limits, required permissions, or any side effects. This is a significant gap for a tool that likely performs analytics queries.
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 short and front-loaded with the core purpose. The Args section is concise, though the list format is a bit terse. It earns its place without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers the aggregation options but lacks details about the return format, time ranges, or any filtering constraints. It is adequate for basic understanding but missing output expectations.
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 schema has no parameter descriptions (0% coverage), so the description's list of valid aggregation values (event, browser_type, etc.) adds meaningful context. However, it does not explain the semantics of each aggregation value or describe the pixel_id parameter beyond its schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get fired-event statistics for a pixel' with a specific verb and resource. It distinguishes itself from sibling pixel tools like pixels_get, pixels_list, and pixels_send_capi_event by focusing on statistics.
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 vs alternatives. It does not mention any exclusions or complementary tools, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without mentioning the 'confirm' parameter, any irreversible effects, or required ad state, leaving significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words or unnecessary detail. It is appropriately brief for a simple action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and an unexplained 'confirm' parameter, the description is too sparse to support reliable understanding of activation behavior, state requirements, or return values.
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?
The description adds minimal parameter meaning: 'a single ad' implies ad_id, but the 'confirm' parameter is completely unexplained. With 0% schema description coverage, the description should compensate but falls short.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Activate (resume)' with a clear resource 'a single ad', which distinctly differentiates it from sibling tools like ads_activate_campaign and ads_activate_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 word 'resume' implies this is for re-activating a paused ad, but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action but fails to mention that the operation is a mutation, whether confirmation is required (the 'confirm' parameter), or any side effects or prerequisites. This is insufficient transparency for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action verb. It is efficient and easy to parse, with no unnecessary words, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter coverage, the description is too sparse to be contextually complete. It omits the purpose of the 'confirm' parameter, any prerequises, and what happens after activation. Minimal viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. It doesn't explain the role of 'adset_id' or the 'confirm' flag, leaving the agent without meaningful guidance on how to use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool activates (resumes) a paused ad set, using a specific verb and resource. It distinguishes from sibling tools like ads_pause_adset and ads_activate_campaign, despite a minor typo ('reses' instead of 'resume').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Activate (resume) a paused ad set' gives clear context of when to use the tool (when an ad set is paused and needs resumption). However, it doesn't explicitly mention alternatives or exclusions, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states the basic function and does not mention pagination behavior, return format, ordering, authentication requirements, or any other operational details that would help an agent understand what to expect when invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains zero extraneous information. It is appropriately concise for the tool's simple function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the low complexity, the description is incomplete given the absence of annotations and output schema. It does not explain the limit parameter, the shape of the returned list, or any behavioral nuances, leaving an agent without sufficient context to use the tool effectively beyond the basic call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly maps 'for an ad account' to the account_id parameter, but it does not explain the 'limit' parameter at all, leaving its meaning and effect (e.g., pagination or maximum number of items) undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'custom audiences' with a scope 'for an ad account', clearly distinguishing it from sibling tools like audiences_list_saved or audiences_get_custom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to list custom audiences for a given ad account, but it does not explicitly state when to use this tool versus alternatives such as audiences_list_saved or audiences_get_custom. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It exposes a caveat about additional permissions and possible empty results based on payment configuration. However, it does not mention pagination, return structure, or other operational behaviors, leaving gaps for the agent.
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, front-loaded with the main purpose, and includes a necessary note in a single additional sentence. No unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and parameter descriptions. The description only states the purpose and one caveat, without explaining return values, pagination, or parameter specifics. This is insufficient for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of parameters (business_id, limit). It does not compensate for the missing schema descriptions, leaving the agent to infer meaning from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('invoices/billing documents for a Business Manager'). It distinguishes itself from sibling tools like billing_get_invoice, which implies a singular retrieval versus a listing operation.
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—list invoices for a Business Manager—but does not explicitly compare with alternatives like billing_get_invoice. It provides a note about permissions and emptiness, offering some contextual guidance, but no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'List' implies a read operation, the description does not mention pagination, ordering, default limits, or what constitutes a product set. This is minimal behavioral information, similar to the TDQS 2.9 example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently states the action, resource, and a usage hint. Every word contributes to understanding, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple 2-parameter tool with no output schema and no annotations, the description should cover parameter behavior and usage guidelines. It only covers purpose, leaving behavioral and semantic gaps. This is inadequate for a complete understanding, especially when an agent must decide between this and tightly related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. The description only uses the word 'catalog' indirection, but does not explain the catalog_id format or the limit parameter's behavior. It adds no value beyond the schema's basic type/title information.
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 'List' and the resource 'product sets within a catalog', which is specific and distinguishes from siblings like catalog_list_products (products) and catalog_list_feeds (feeds). The parenthetical adds a usage context (Advantage+ Catalog campaigns), further clarifying the tool's purpose.
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 a clear context by noting the tool is 'used for Advantage+ Catalog campaigns', implying when this tool is relevant. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It states the upload action and return hash, but does not disclose prerequisites, side effects, permission requirements, or the purpose of the 'confirm' parameter. The behavioral surface is only partially revealed.
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 front-loaded: two sentences stating purpose and one parameter detail. No filler or redundancy, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and three parameters, the description is underspecified. It covers only one parameter and provides no usage context, behavioral caveats, or clarification of the output hash's role. This is minimal for a tool in a broader creative workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only documents image_path (absolute path, allowed formats), but omits account_id and confirm entirely. This leaves two parameters unexplained, failing to provide adequate semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Upload an image to an ad account's image library.' It uses a specific verb (upload) and resource (image library), and mentions the return value (image hash). This distinguishes it from siblings like creatives_upload_video (uploads videos) and creatives_list_images (lists images).
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 uploading images but does not explicitly state when to choose this tool over alternatives, nor does it mention any exclusions or prerequisites. It lacks guidance about when not to use it (e.g., for videos or link ads).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only explains the date range parameter format and does not describe the return format, data scope, permissions, rate limits, or any side effects. The agent cannot infer what 'insights' means operationally or what the output looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the main purpose in the first sentence. The 'Args' section is focused and adds necessary detail about the period structure. It is efficient and every part has value, though it could be slightly more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with 5 parameters and nested objects, no output schema, and no annotations. The description only addresses the period parameters, leaving the meaning of entity_id, level, fields, and the overall behavior unclear. This is insufficient for an agent to confidently invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful structure for period_a and period_b (the 'since'/'until' format with YYYY-MM-DD), which is not present in the schema. However, it does not explain entity_id, level, or fields, which remain completely unspecified. Since schema coverage is 0%, this partial explanation is helpful but insufficient for full parameter 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 uses a specific verb ('Compare') and resource ('insights') with a clear scope ('between two date ranges side-by-side'). This distinguishes it from sibling insights tools like insights_get or insights_get_account_summary, which don't focus on period comparison.
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 intended use case (comparing two date ranges) is implied by the tool name and description, but no explicit guidance is given about when to prefer this over other insights tools, nor are any exclusions or alternatives mentioned. The usage is clear from context but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action without explaining side effects, permissions, or the meaning of the confirm and published parameters. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the core purpose, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is incomplete. It fails to explain key behaviors such as what confirm does, what happens when published is false, and what the return value or success criteria are.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter semantics. The 'confirm' parameter is ambiguous and unexplained, while page_id, image_url, caption, and published are only minimally self-explanatory from their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'publish' with the object 'photo to a Page' and source 'from an external URL', clearly distinguishing this tool from siblings like pages_publish_post (text posts) and ig_publish_image (Instagram).
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 the tool: publishing a photo to a Page from an external URL. However, it does not explicitly mention alternatives or exclusions, such as messages to use pages_publish_post for text posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'List all pixels' but does not mention pagination, the effect of the 'limit' parameter, or that 'all' may be capped by the default limit. This is a notable transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is front-loaded with the verb and resource, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description does not mention what fields are returned, pagination behavior, or how it differs from other pixel tools. The claim of 'all pixels' conflicts with the existence of a limit parameter, leaving the agent with an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for both parameters. It clarifies that account_id is used to filter pixels by ad account, but it does not explain the 'limit' parameter or that it controls pagination/max results. The semantics of 'limit' are left to the agent's inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'pixels (datasets)' owned by an ad account. It distinguishes from sibling tools like pixels_get (likely fetches a single pixel) by emphasizing the plural 'all pixels' and the ownership scope.
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 use for listing all pixels for a given ad account, but it does not explicitly mention alternatives or when not to use it. With many sibling pixel tools (e.g., pixels_get, pixels_get_stats), explicit exclusions would be helpful, but the core usage is still clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'Get details' without mentioning error behavior, required permissions, or what 'details' include. No context about read-only nature, rate limits, or response format is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, with no filler or repetition. It is appropriately sized for a simple getter and front-loads the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, and the description does not convey what 'details' are returned or any other contextual information. For a simple read tool, this is minimal but lacks completeness regarding the expected response or additional requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add meaning to the 'phone_number_id' parameter. It vaguely refers to 'specific WhatsApp phone number' but does not clarify the ID format, source, or how it relates to the parameter beyond the parameter's name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('details for a specific WhatsApp phone number'), distinguishing it from sibling wa_list_phone_numbers which lists all numbers. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when details for a specific phone number are needed, but it does not explicitly mention alternatives or when not to use this tool. No reference to sibling tools like wa_list_phone_numbers, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds 'including creative' as a return detail, but does not disclose other behavior such as response structure, error cases, or access requirements. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool, the description is adequate but leaves gaps: no output schema and no annotations mean the agent does not know the full set of returned fields beyond 'creative', nor error behavior. It does not fully specify the context needed for confident invocation.
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?
The schema description coverage is 0%, and the description does not mention the ad_id parameter or its format. The schema's title 'Ad Id' is self-explanatory, but the description fails to compensate for the low coverage, providing no additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full details of a single ad including creative.' It uses a specific verb ('Get') and resource ('ad'), and the qualifier 'single' differentiates it from list or preview sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like ads_list_ads or ads_get_ad_preview. The mention of 'single ad' implies it is for retrieving one ad, but no alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the scope (System User's access) and the return fields (name, account_id, status, currency, owning business), which is helpful. However, it does not explicitly state read-only behavior, pagination, or error conditions, leaving some behavioral aspects implicit from the verb 'List'.
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 two concise sentences: the main action first, followed by the return fields. There is no redundant or filler content, and the structure efficiently conveys the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers the core purpose and return fields but omits any explanation of the `limit` parameter and pagination behavior. An agent would not know how to control the number of results or whether additional pages exist, making the description incomplete for full usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, `limit`, with no description, and the tool description never mentions it. With 0% schema description coverage, the description does not compensate, so the agent must infer the parameter's meaning solely from its name and default value. No additional semantics are provided.
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 'List all ad accounts the System User can access,' providing a specific verb (list), resource (ad accounts), and scope (all accessible to System User). It distinguishes from sibling tools like ads_get_ad_account by emphasizing 'all' versus a single account, and enumerates the return fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for enumerating all accessible ad accounts but does not explicitly say when to use it over alternatives such as ads_get_ad_account or mention any exclusions. The context is clear but lacks explicit guidance on when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing behavior. It indicates a read operation via 'Get', but provides no additional context such as error handling, required permissions, or response structure. This is minimal and leaves important behavioral aspects unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core purpose and is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward get-by-ID tool with a single parameter and no output schema, the description is adequate but not comprehensive. It does not describe the return fields or error scenarios, but given the low complexity, the gap is not severe.
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?
The schema has one required parameter, creative_id, but no description coverage (0%). The tool description mentions 'a single ad creative' but does not explicitly map to the creative_id parameter or explain its format. The description adds little beyond what the parameter name already implies.
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 'full details of a single ad creative', using a specific verb ('Get') and resource ('ad creative'). It effectively distinguishes from sibling tools like creatives_list (which lists multiple) and creatives_delete (which removes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single ad creative needs to be fetched by ID, but it does not explicitly state when to prefer this over alternatives or mention any exclusions. While the purpose is obvious, there is no explicit guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It confirms the read-only nature ('List') but omits other behavioral details such as pagination (despite a limit parameter), ordering, or what image metadata is returned. It does not contradict any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no fluff or repetition. It efficiently conveys the core function in minimal words, which is appropriate for a straightforward listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with only two parameters and no output schema, the description gives a basic understanding but lacks details such as pagination behavior and the structure of the returned list. It is sufficient for basic selection but not fully informative for an agent needing to anticipate response format or limits.
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?
The schema has 0% description coverage, and the description only hints at the required account_id through 'an account's image library.' The optional limit parameter is not mentioned at all, leaving users to infer its purpose solely from the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('images uploaded to an account's image library'), making the tool's purpose immediately obvious. This also distinguishes it from sibling tools like creatives_list_videos, which focus on videos.
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 a use case (retrieving a catalog of images for an account) but provides no explicit guidance on when to choose this tool over alternatives such as creatives_list or creatives_list_videos. No when-not-to-use conditions or alternative names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it returns aggregated metrics but does not mention that it's a read-only operation (implied by 'get'), any permission requirements, date range behavior, or response format. The brevity leaves significant behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core value proposition ('top-line') and the scope. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description conveys the return value and scope, but with no annotations, no output schema, and 0% schema coverage, it leaves gaps such as date_preset semantics and response details. It is minimally adequate but not complete.
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?
The schema has 0% coverage, so the description must compensate for the two parameters. It clarifies account_id by stating 'entire account,' but it does not explain the date_preset parameter, its default, or how it affects the results. This partial compensation is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb implied by 'get' and clearly states the resource ('entire account') and the metrics ('spend/impressions/clicks'). 'Top-line' distinguishes it from more detailed insights sibling tools like insights_get or insights_compare_periods, making its purpose clear.
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 quick, high-level account summaries ('Quick top-line'), but it does not explicitly state when to use this over alternatives like insights_get or insights_compare_periods, nor does it mention exclusions or prerequisites. The context is clear but not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only says 'List', implying a read-only operation, but fails to disclose pagination behavior, the presence of a limit parameter, rate limits, or the response structure. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. It is front-loaded with the action and resource, and every word contributes value. Nothing is bloated or irrelevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description is minimally adequate, but it leaves gaps: no output schema, no parameter details, and no mention of pagination. The absence of behavioral and parameter context makes it less complete than it could be, though the core purpose is clear.
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 descriptions are completely absent, and the description does not explain either parameter. The phrase 'attached to a Page' vaguely maps to page_id, but the limit parameter is entirely unaddressed. The description fails to compensate for the 0% schema coverage.
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 the verb 'List', the resource 'lead generation forms', and the scope 'attached to a Page'. This distinguishes it from sibling tools like leads_list_from_form (which lists leads from a form) and leads_get_form (which retrieves a single form).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when needing forms for a specific page, but it does not explicitly state when to prefer it over alternatives or mention any exclusions. No alternative tools are referenced, so usage guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the template is submitted for review, implying an approval workflow, and lists category options. However, it does not mention side effects, authentication/authorization needs, or the meaning of the 'confirm' parameter, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with a clear purpose line and a compact parameter list. There is no redundant or filler content, though it could be more comprehensive without becoming unwieldy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no annotations, no output schema, and 0% schema coverage, the description is incomplete. It fails to explain the required waba_id, language, and confirm parameters, and does not describe the review/approval process in enough detail for an agent to confidently invoke the tool.
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?
The input schema has 0% description coverage for 6 parameters. The description adds value for category (allowed values) and components (header/body/footer/buttons), but it completely ignores name, waba_id, language, and especially confirm, which is non-obvious from a boolean type.
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 'Submit a new message template for review,' identifying the specific action (submit) and resource (message template). This distinguishes it from sibling tools like wa_list_templates, wa_delete_template, and wa_send_template_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the phrase 'new message template for review' and the parameter list, but there is no explicit statement of when to use this tool versus alternatives or any exclusions. It does not name alternatives like wa_list_templates or wa_delete_template.
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?
It discloses cascading, which is a critical side effect. However, it omits the confirm parameter's role, reversibility, and other potential side effects, leaving gaps given no annotations are provided.
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 two short sentences, direct and front-loaded, with no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with a confirmation flag, the description fails to explain the confirm behavior, what happens if confirm is false, or what the return value is. This is incomplete for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It implies adset_id but does not mention confirm at all, leaving the agent uncertain about its purpose and whether it affects deletion.
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 'Delete an ad set' with a specific verb and resource, and adds 'Cascades to all ads under it' which distinguishes it from related tools like delete_campaign or pause_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 cascade warning implies a consequence, but there is no explicit guidance on when to use this versus alternatives like pausing or editing. It also doesn't mention 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?
With no annotations provided, the description carries the full burden of disclosure. It explicitly states the operation is permanent and cascades to all child objects (ad sets and ads), which are key behavioral traits. However, it does not mention the confirm parameter's role or any permission/precondition requirements, so transparency is not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action, no filler. Every word earns its place, and the structure is ideal for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core effect is captured, the description omits parameter semantics, usage guidance, and any mention of the confirmation flow or result behavior. With no output schema or annotations, the agent is left with critical gaps for a destructive operation, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to either parameter. The confirm boolean is likely a safety confirmation but its behavior is completely undocumented, leaving the agent to guess whether setting it to true is required. This is a significant gap for a destructive tool.
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 ('Delete a campaign permanently') and adds a critical distinguishing detail ('Cascades to all ad sets and ads under it'), which differentiates it from non-destructive siblings like ads_pause_campaign or ads_activate_campaign and from delete tools targeting other resources.
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 permanent and cascading nature implies destructive use, but the description does not explicitly say when to choose this over alternatives like pausing or activating. It lacks direct comparison or when-not-to-use guidance, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation and mentions 'spending and limits' but does not disclose return format, any required permissions, rate limits, or what 'detailed info' includes beyond those two items. For a simple get, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that starts with the verb, names the resource, and specifies key output content. No wasted words and efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description is modest but covers the core purpose. It is insufficient to fully understand the return structure or any behavioral nuances, but for a simple get on a single account, it provides a minimal viable explanation. The lack of annotations increases the need for more detail, so it is not a 4 or 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides one parameter (account_id) with only a type, and the description adds that it refers to an ad account. This is some added meaning, but it does not explain the format (e.g., 'act_...' prefix) or any other details. Given the parameter is self-explanatory and schema coverage is 0%, this is an adequate but not rich contribution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource 'detailed info for a single ad account' with explicit content 'including spending and limits'. This clearly distinguishes it from sibling tools like ads_list_ad_accounts, since it is about a single account rather than a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a single ad account' implies the need to already have an account_id and suggests using this when a single account's details are needed, not when listing accounts. However, it does not explicitly state when to use this over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core update action but omits important behavioral details such as the confirm parameter (default false), potential side effects of swapping creative, permission requirements, or reversibility. The presence of a confirm flag in the schema is not addressed, leaving a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential action without unnecessary words. It is appropriately concise and every word adds value, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is too sparse. It covers the main fields but omits critical context such as the need for confirmation, interaction with pause/activate sibling tools, and the required ad_id. The overall picture is incomplete for an agent to invoke this tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists name, status, and creative, which maps to name, status, and creative_id parameters, but it does not mention the required ad_id, the confirm parameter, or clarify status values. The confirm parameter is completely absent from the description, and the meaning of 'swap its creative' is not explained technically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an ad's name, status, or creative, using a specific verb and resource. This distinguishes it from sibling tools like ads_update_campaign or ads_update_adset, and the mention of 'swap its creative' adds a unique, concrete action.
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 when to use this tool: when updating an ad's name, status, or creative. However, it does not explicitly mention alternatives like ads_pause_ad or ads_activate_ad for status changes, nor does it provide exclusions or prerequisites. Clear context but no explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses permanence (irreversible) and a gating limitation, but it fails to disclose the role of the `confirm` parameter, which is critical for a destructive operation. This is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and the limitation note adds valuable context without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should indicate expected results or side effects, but it does not. It also omits the confirm behavior, making it incomplete for a destructive tool with 2 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. While 'saved_audience_id' is implicitly the target, the `confirm` boolean is entirely unexplained, leaving the agent uncertain about whether it must be set to true.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('delete') with a clear resource ('saved audience') and qualifies it as 'permanently', distinguishing it from sibling tools like audiences_update_saved and audiences_list_saved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the verb and resource—use this tool to permanently remove a saved audience. However, there is no explicit guidance about alternatives or when not to use it, nor any mention of prerequisite conditions beyond the note about the write capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and gives a filter_spec example, but fails to mention side effects, permissions, or the purpose of the 'confirm' parameter (which has a default of false). As a mutation tool, this lacks critical information about confirmation requirements or potential impact.
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: one sentence plus an example. Every word earns its place, and the example is valuable for understanding the filter_spec format. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, this description must fully explain the tool's context. It falls short by not addressing the 4 parameters (especially confirm), any behavioral nuances, or what the response contains. The tool's complexity (nested object) suggests more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It only provides an example for filter_spec, giving it some meaning, but name, catalog_id, and confirm remain completely unexplained. This is insufficient for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a product set defined by a filter expression,' which specifies a distinct action and resource. This differentiates it from sibling tools like catalog_create (creates a catalog) and catalog_create_product (creates a product). The example filter_spec further reinforces the specific purpose.
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 a clear context for when the tool is used: creating a product set. The included example filter_spec offers practical guidance on how to invoke the tool. However, it does not explicitly mention alternatives or when not to use this tool, though no direct sibling alternative exists for creating product sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It provides useful context (returns video ID, large videos not supported), but omits important behavioral details such as the role of the 'confirm' parameter, permission requirements, or whether duplicate uploads are allowed.
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 two concise sentences: the first states the purpose and return value, the second highlights a critical limitation. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is too thin. It leaves out input format expectations, the meaning of 'confirm', failure behavior for large files, and prerequisites like existing ad account/video library. The large-video note is helpful but not sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It does not explain any of the five parameters (account_id, video_path, name, description, confirm) beyond what their names imply. The only indirect hint is 'ad account' for account_id and 'video' for video_path.
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 a specific verb ('upload'), resource ('video'), and destination ('ad account's video library'), and notes the return value (video ID). It distinguishes this tool from siblings like creatives_upload_image and creatives_list_videos by the action and resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The core use case is clear, and the note about large videos (>1GB) provides a useful exclusion. However, it does not explicitly say when to choose this over alternatives, nor does it name the chunked upload tool that should be used for large videos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but it does not disclose potential errors (e.g., invalid post_id), authentication requirements, or limitations on the returned details. This minimal disclosure is not misleading but lacks richness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the key action and object. There is no redundancy or irrelevant information, making it appropriately sized for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and annotations, the description should clarify what 'details' includes or what response format to expect. It does not, leaving the agent uncertain about the return value or potential edge cases. For a simple tool, this is a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the post_id parameter. It merely says 'single post,' which indirectly references the parameter but gives no guidance on the format, source, or meaning of post_id beyond the schema's type definition. The description adds essentially no value for parameter 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 'Get details of a single post' clearly states the action (get) and the resource (a post), distinguishing it from sibling tools like pages_list_posts and pages_delete_post. It precisely conveys the intended operation without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The description implies use when you need details of a specific post, but it does not mention alternatives, exclusions, or prerequisites like finding the post_id first. The usage context is only minimal and not clearly differentiated from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly notes that changing budget, bid, targeting, or optimization restarts learning, and that day-parting requires lifetime budget and pacing_type. This is valuable context, but it omits other important behaviors such as permission requirements, the meaning of the 'confirm' parameter, or whether changes are reversible.
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 compact: a main sentence plus two concise caveat notes. It is front-loaded and each sentence provides actionable information without redundancy. It could be slightly more structured, but it is appropriately sized for the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 19 parameters, no output schema, and no annotations, this description is incomplete. It covers the core function and critical caveats, but does not explain optional-field semantics, the purpose of `confirm`, expected return behavior, or operational prerequisites. The high parameter count and zero schema coverage demand much more contextual detail.
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?
The schema has 0% description coverage, so the description must compensate. It explains special requirements for `adset_schedule` and identifies fields that trigger learning restart. However, with 19 parameters, the vast majority (name, status, start_time, bid_strategy, etc.) are left semantically unexplained, leaving significant gaps for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Update fields on an existing ad set.' This clearly distinguishes the tool from siblings like ads_create_adset, ads_get_adset, ads_delete_adset, and ads_pause_adset. It also mentions an alternative tool for day-parting, reinforcing the specific scope.
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 gives clear context for use: it targets existing ad sets and highlights when special constraints apply (learning restart, day-parting requirements). It explicitly names ads_set_adset_schedule as an ergonomic alternative for day-parting. However, it does not broadly discuss when to avoid this tool in favor of other update tools beyond the schedule case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get details' suggests a read-only operation, which is clear, but it does not disclose any additional behavioral aspects such as required permissions, error conditions, or return format. For a simple get, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence (7 words) that starts with the action and clearly states the scope. There is zero waste, and it is appropriately brief for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get with no output schema, the description is minimally sufficient but lacks specifics about what 'details' include or any prerequisite steps. Given the low complexity, it is adequate but leaves room for more contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the invoice_id parameter beyond what the schema already provides. It also does not mention how to obtain an invoice_id (e.g., via billing_list_invoices), leaving the parameter semantics underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the target resource ('a single invoice'), distinguishing it from sibling billing tools like billing_list_invoices, which handles multiple invoices. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a single invoice's details, but it does not explicitly state when to use this instead of billing_list_invoices or provide alternative guidance. The usage context is implied by the singular 'single invoice'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It correctly indicates a read-only list operation and clarifies feed types, but it does not disclose pagination behavior, response format, or whether feeds of all types (CSV and XML) are always included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no redundancy. The verb and resource are front-loaded, making it highly scannable and information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool, this description provides the essential operation and scope. However, the lack of any mention of pagination/limit behavior and return shape leaves gaps, especially given there is no output schema to clarify the response.
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?
With 0% schema description coverage, the description must compensate. It adds meaningful context for catalog_id via 'attached to a catalog' and clarifies the feed types, but it does not explain the 'limit' parameter's semantics or behavior, leaving it under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a precise resource ('product feeds (CSV/XML uploads)') and scope ('attached to a catalog'), clearly distinguishing it from sibling tools like catalog_list_products and catalog_list_product_sets. It is unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: call it with a catalog_id to retrieve feeds for that catalog. However, it does not explicitly state when to prefer this tool over catalog_list_products or mention any exclusions such as filtering capabilities or pagination behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It implies read-only via 'Retrieve' and explains the after_cursor pagination field, but does not disclose authentication requirements, rate limits, or return format. The pagination context adds some value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The Args section adds a small structured element. It is appropriately concise, though it could organize parameter details more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotation support, and only one of three parameters is described. The description does not explain the required form_id, the role of limit, or pagination behavior beyond the cursor field. It leaves significant gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains after_cursor ('Pagination cursor from a previous response (paging.cursors.after)'), while form_id and limit remain undocumented. This is insufficient for the parameter-heavy tool.
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 actual leads submitted to a form' with a specific verb and resource. It clearly distinguishes from sibling tools like leads_list_from_ad (leads from an ad) and leads_list_forms (list forms).
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 usage context is clear: this tool retrieves leads for a specific form. However, it does not explicitly mention exclusions or compare with leads_list_from_ad, so it lacks full when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It signals a read-only operation via the verb 'List' but does not disclose return format, pagination, rate limits, or any side effects. For a tool with no output schema, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the core action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is too minimal. It omits what the response contains, whether listing is paginated, or any constraints. Without an output schema, the agent has no expectations for the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required parameter waba_id with no description (0% coverage). The tool description mentions 'WhatsApp Business Account', providing context that waba_id is the account identifier, but it does not explicitly define the parameter or explain how to obtain the ID. Partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (phone numbers), and the scope (attached to a WhatsApp Business Account). This distinguishes it from siblings like wa_get_phone_number (retrieves a single number) and wa_list_business_accounts (lists 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?
The description implies when to use the tool: when you need to list phone numbers for a given WhatsApp Business Account. However, it does not explicitly mention alternatives or prerequisites, such as first using wa_list_business_accounts to obtain the waba_id, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates this is a read-only operation by using the verb 'list', but does not disclose pagination behavior (the limit parameter) or whether the result includes all statuses beyond approved/pending. There is no mention of rate limits or output structure.
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?
One sentence with no wasted words, directly states the tool's function. It is appropriately sized for a simple list operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only 2 simple parameters and no output schema, so the description is somewhat sufficient. However, it gives no information about what the response contains, how pagination works, or how limit affects results. For an agent selecting the tool, this is minimally viable but leaves some uncertainty.
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?
The schema has 0% description coverage, so the description must compensate. It clarifies that 'waba_id' refers to a WABA (WhatsApp Business Account), which adds some meaning. However, it does not mention the 'limit' parameter at all, leaving it undefined apart from the schema's type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'message templates' and scope 'approved/pending', and specifies the context 'for a WABA'. This clearly distinguishes it from sibling tools like wa_create_template, wa_delete_template, and wa_list_phone_numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives. The purpose is implied: use when you need to see approved/pending WhatsApp message templates. However, it doesn't mention any exclusions or prerequisites, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description explains deep_copy, status_option, and rename_options behaviors, including a recommended PAUSED status and a dict example. However, the 'confirm' parameter is not disclosed, and there is no info about side effects or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact docstring with a front-loaded purpose line and an Args block. Every sentence adds relevant detail without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations or output schema, the description covers the core options but misses 'confirm' and any information about return values or campaign state after duplication. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It adds semantics for deep_copy, status_option, and rename_options, but omits 'confirm' and doesn't elaborate on campaign_id. The rename_options example is useful but partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Duplicate a campaign with optional deep copy of all ad sets and ads' – a specific verb and resource, clearly distinguishing from sibling duplicate tools for adsets/ads. The scope is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to choose this vs ads_duplicate_adset or ads_duplicate_ad. The description implies usage by naming the operation and options, but doesn't specify exclusions 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?
No annotations are provided, so the description is the only source of behavioral disclosure. It explicitly mentions included details (targeting, dayparting) which adds context about the response, and the verb 'Get' implies a read-only operation. However, it does not explicitly state that it is non-destructive or mention any side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, and then adds valuable specificity about targeting and dayparting. 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?
For a simple one-parameter get tool with no output schema, the description adequately indicates the return value ('full details') and highlights key fields. It could mention alternative tools or edge cases, but given the simplicity, it is mostly complete.
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?
The input schema has no description coverage (0%), and the description does not compensate by explaining the adset_id parameter beyond the obvious 'single ad set'. For example, it doesn't specify where the ID comes from or any formatting requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly specifies the resource as 'full details of a single ad set'. It differentiates from sibling tools like ads_list_adsets (which lists many) and ads_get_adset_schedule (which focuses only on schedule).
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 ('Get full details of a single ad set') but does not explicitly state when to use it versus alternatives like ads_list_adsets or ads_get_adset_schedule. No exclusions or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the listing action and parameter descriptions, but fails to mention pagination behavior, default status filter, return format, or error handling. This leaves significant behavioral ambiguity.
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 and well-structured, starting with the primary action and then listing arguments. Every sentence adds value without redundancy, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description covers the core purpose and key parameters, but it lacks details on return fields, pagination, or status filter options. Given no annotations and no output schema, the description is adequate but leaves gaps that could affect agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for parent_id by specifying the format (act_ for ad account vs campaign/adset ID) and for status_filter by clarifying it is an effective_status filter. However, the limit parameter is not mentioned in the description, and status_filter allowed values are not specified, so it is not a perfect compensation for the schema's 0% coverage.
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 lists ads under an ad account, campaign, or ad set, with a specific verb and resource. This distinguishes it from sibling list tools like ads_list_campaigns and ads_list_adsets.
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 when to use the tool (list ads under a parent), but it does not explicitly discuss alternatives or when not to use it. There is no mention of sibling tools or exclusions, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the critical media-source constraint and the prerequisite upload workflow, which is valuable. However, it does not mention permissions, reversibility, or what the tool returns after creation, leaving significant behavioral aspects undisclosed.
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 three sentences long, front-loaded with purpose, and every sentence adds useful guidance. There is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters, no schema descriptions, no annotations, and no output schema, the description is too sparse. It addresses the media prerequisite but does not explain the role of most required fields, the broader workflow, or what the operation produces, making it incomplete for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that image_hash and video_id are mutually exclusive and tied to upload tools, but it leaves the other 10 parameters—including required fields like account_id, page_id, link, and message—completely unexplained. This is only partial semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create a single-image or single-video link ad creative.' This clearly identifies what the tool does and distinguishes it from the sibling tool creatives_create_carousel_ad, which creates a different creative type.
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 mandatory either/or requirement for image_hash and video_id, and directs the agent to use creatives_upload_image / creatives_upload_video to obtain those values first. It does not explicitly compare against other creative creation tools like creatives_create_carousel_ad, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal a key failure condition (fails if active ads reference it), which is valuable. However, it omits other significant behaviors such as the effect of the 'confirm' parameter, whether deletion is permanent, or any required permissions. This is a clear gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action. Every word contributes meaning—'Delete an ad creative' is direct, and the second sentence adds a critical constraint. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is the only source of context. It covers the primary purpose and one failure condition, but fails to explain the 'confirm' parameter, return values, error behavior, or any prerequisites. This is inadequate for a tool with two parameters and no other documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter meaning. It does not explain the 'creative_id' parameter (though implied) nor the 'confirm' parameter, which has a default of false and an unclear purpose. The description adds no information 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 verb ('Delete') and resource ('ad creative'), which precisely distinguishes it from sibling tools like creatives_get and creatives_list. It also exactly matches the tool name, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting that deletion will fail if any active ads still reference the creative, implying a prerequisite for usage. However, it does not explicitly name alternatives (e.g., ads_delete_ad) or state when not to use this tool, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two behavioral traits: it returns a flat list of all data items, and it stops at max_pages to prevent runaway calls. Since there are no annotations, these are useful but incomplete; it doesn't mention that it makes multiple HTTP calls or how errors are handled.
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, the first stating the core purpose and the second providing a safety guarantee. No extraneous information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse. It doesn't describe the shape of the returned items, how pagination is handled beyond max_pages, error behavior, authentication requirements, or potential side effects like multiple network calls. This is insufficient for a generic utility.
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?
The description gives no explanation of the 'params' parameter, which is an optional object for query parameters. It only indirectly mentions max_pages (as a limit) and 'endpoint' (as GET endpoint). With 0% schema description coverage, this leaves a significant gap in parameter 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 opens with 'Auto-paginate a GET endpoint' which clearly identifies the verb (auto-paginate), resource (GET endpoint), and output (flat list of all data items). This distinguishes it from siblings like graph_call which likely returns a single response.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'GET endpoint' implies this tool is for paginated GET requests, providing clear context for when to use it. However, it doesn't explicitly state alternatives or when not to use it (e.g., for POST endpoints).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose more about behavior. It reveals that accounts come from Pages the user has access to, but it doesn't state whether it's read-only, what the response contains, or any pagination/authorization details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema, placing the burden on the description. It covers the basic purpose and access source, but lacks explicit information about the return format or any additional behavior, leaving it minimally viable but not 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?
Since there are zero parameters, the schema is trivially complete. The description adds contextual information about the source of accounts, which aligns with the baseline of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'Instagram Business accounts' and clarifies the access path 'via Pages the user has access to,' which distinguishes it from sibling tools like ig_list_media and pages_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the tool is used to enumerate Instagram Business accounts accessible through Pages, but it doesn't explicitly mention when to use it over ig_get_account or prerequisites. No alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals the two-step process (create container, publish) and adds the URL reachability constraint. However, it omits the purpose of the 'confirm' parameter and whether the two steps are always performed or require user confirmation, leaving ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and key requirement. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and 4 params. The description covers only the image_url constraint and the two-step flow. It doesn't mention the confirm parameter, account ID requirements, expected response, failure modes, or required permissions. For a publishing tool, this is a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter semantics. It only explains image_url ('must be publicly reachable'). It says nothing about ig_account_id, caption, or the ambiguous 'confirm' boolean. Given four params and no schema descriptions, this is insufficient.
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 publishes a single image to IG and distinguishes it from siblings like ig_publish_video (video) and pages_publish_photo (Page). The verb 'publish' and resource 'single image' are specific and actionable.
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 a key prerequisite: 'image_url must be publicly reachable (Meta will fetch it).' This gives clear usage context. It doesn't explicitly name alternatives, but the tool name and sibling list make it obvious this is for IG images, not videos or Page posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly explains the async nature, that the tool returns a report run ID rather than the data, and that subsequent polling/fetching is required. This is key context for an agent. It doesn't mention error handling or timeouts, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action and purpose, and follows with a concise workflow. Every word earns its place; there is no repetition of schema or annotations. It is an exemplar of efficient description writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the async workflow and return value, but the tool has 6 parameters with no semantic explanations and no output schema. The description does not compensate for the parameter ambiguity, leaving the agent under-informed about what values to provide for fields like breakdowns or date_preset. For a complex tool, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description does not mention any of the 6 parameters. While the schema provides names and types, it lacks semantic meaning. The description also doesn't clarify what fields like 'level', 'breakdowns', 'time_range', or 'date_preset' represent, so the agent must infer their purpose from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Submit an async insights job for large reports.' It specifies the verb (submit), resource (insights job), and distinctiveness (async, large reports), and indicates the return value (report run ID). This distinguishes it from synchronous insights_get and the related async check/fetch 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?
The description provides an explicit workflow: use insights_check_async_report(report_run_id) to check status, then insights_fetch_async_report(report_run_id) to get data. It also states the tool is for 'large reports,' implying when to use it over synchronous alternatives. It doesn't explicitly name the alternative for small reports, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses a key behavioral trait: PII fields are auto-hashed with SHA-256 before sending, adding 'Meta requires this' for rationale. This is valuable transparency beyond what the schema shows. However, it does not mention response format, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The 'Args:' section is structured and provides examples without excessive verbosity. It earns its place, though the Args list could be considered redundant with the schema, but the examples add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 18 parameters and no output schema, the description is incomplete. It omits required parameters like pixel_id (though schema marks it required) and many optional but important ones (fbc, fbp, user details, client IP, user agent). It does not explain return values or error conditions. The description covers only 5 of 18 parameters, leaving a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to several parameters (event_name, action_source with enumerated values, custom_data with a concrete example, event_id and test_event_code with usage context). However, schema description coverage is 0% and 18 parameters exist; many are completely undiscussed, such as pixel_id (required), fbc/fbp, user fields, event_time, client_ip_address, and client_user_agent. Partial compensation, not sufficient for the breadth.
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 'Send a server-side conversion event via Conversions API' with a specific verb and resource. It distinguishes itself from sibling tools like pixels_create and pixels_get, which handle other pixel operations. This is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for server-side event tracking but does not explicitly compare with alternative tools or state when not to use it. It provides some contextual guidance, such as 'event_id' for deduplication against client-side events and 'test_event_code' for development, but lacks a clear 'use when... vs. when not...' directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds key behavioral context: the message must be pre-approved and there is no 24-hour restriction. However, it does not disclose other important behaviors such as error conditions, fallback handling, or what happens if the template is invalid.
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, consisting of one sentence and a focused example for a single parameter. Every word adds value with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has six parameters, no schema descriptions, no annotations, and no output schema. The description covers only one parameter and the basic purpose, leaving substantial gaps around required fields like template_name and language_code, as well as expected return values and possible failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains the 'components' parameter with an example. The parameters 'to', 'confirm', 'language_code', 'template_name', and 'phone_number_id' are not described, leaving the agent to guess their meaning. This is insufficient given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Send'), a clear resource ('pre-approved template message'), and the parenthetical '(works any time, no 24h window)' distinguishes it from regular messaging tools. This makes its purpose unambiguous and distinct from siblings like wa_send_text_message.
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 notes that this tool works without the 24-hour window, which is a clear indication of when to use it. It does not name alternatives directly, but the context strongly implies it is for template messages when a standard message cannot be sent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool usually fails with code=3 unless the App has Advanced Access, which is critical context, and suggests a workaround. It does not detail success responses, side effects, or other prerequisites, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states purpose, the second adds a critical limitation and workaround. No redundant wording, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no annotations and no output schema, the description covers core purpose and a major failure mode, but lacks detailed parameter semantics and behavior on success/failure. It is useful but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It mentions name, description, and targeting as updatable fields, but leaves 'confirm' completely unexplained and doesn't clarify the nature of saved_audience_id beyond naming. This is insufficient for all five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('a saved audience') with specific fields (name/description/targeting). This distinguishes it from sibling tools like audiences_create_saved and audiences_delete_saved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a KNOWN LIMITATION and a workaround using audiences_apply_to_adset(), giving useful contextual guidance. However, it doesn't explicitly state when to use this tool versus alternatives beyond the limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It correctly implies a read-only, aggregate operation, but does not explain what 'summary' includes (e.g., per-account breakdown vs total), how the date range is interpreted, or any required permissions. It is minimally transparent but not misleading.
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 only two sentences, with the primary action front-loaded and no redundant wording. The second sentence adds a practical use case without unnecessary elaboration, making it efficient and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is serviceable but incomplete. It lacks parameter-level details and explicit guidance on when to choose this over alternatives like billing_get_account_spend or insights_get_account_summary. It covers the basic purpose but not enough for fully informed selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description fails to mention the date_preset parameter by name. The phrase 'for a date range' hints at the parameter but provides no details on values, defaults, or formatting, leaving the agent without adequate guidance for a parameter that has no 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?
The description clearly states the core function: 'Get a spend summary across ALL accessible ad accounts for a date range.' The verb 'Get' and the explicit scope of 'ALL accessible ad accounts' make the tool's purpose unmistakable and differentiate it from per-account billing tools like billing_get_account_spend.
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 sentence 'Useful for dashboards / quick agency-wide visibility' provides a clear use context. It implies this tool is intended for cross-account overview scenarios, which helps distinguish it from account-specific alternatives, though it does not explicitly name 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It adds the prerequisite of an existing creative and implies a mutation, but does not mention status defaults, the confirm parameter, side effects, or permission requirements. This is limited but slightly helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading: the purpose is stated first, followed by the workflow. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and 0% parameter coverage, the description is insufficient. It clarifies the workflow but omits details about the status default, confirm behavior, return values, and tracking_specs format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only indirectly explains creative_id ('pass its ID here') and adset_id. The meaning of status, confirm, tracking_specs, and account_id is left to the agent, and parameter names are insufficient for ambiguous fields like confirm and tracking_specs.
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 the tool creates an ad within an ad set, referencing an existing creative. The verb 'Create' and resource 'ad inside an ad set' are specific, and mentioning the creative reference distinguishes it from ads_create_campaign and ads_create_adset.
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?
It provides an explicit workflow: build a creative using creatives_create_* tools first, then pass its ID. This tells the agent when to use this tool (after creative creation) and distinguishes it from tools that create campaigns or ad sets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source. It discloses the return format (raw + decoded), the behavior when no day-parting block exists (enabled: False), and implies read-only nature. This adds useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the purpose, then details. Every sentence adds 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?
For a simple read tool with one parameter and no output schema, the description covers the return values and an edge case. It lacks error handling details, but those are not essential for a straightforward read operation.
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?
The schema provides only a string type for adset_id with no description, and the description does not explain the parameter's meaning or usage. With 0% schema coverage, the description should compensate, but it doesn't address the parameter at all.
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 verb 'Read' clearly specifies the action, and the resource 'ad set's day-parting schedule' is precise. It also distinguishes from the sibling 'ads_set_adset_schedule' by being the read counterpart and mentions decoding.
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 reading schedules, but does not explicitly state when to use it over alternatives or mention exclusions. The 'Read' verb makes it clear, but it lacks explicit guidance about when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses a known limitation (Meta returns code=3 unless Advanced Access is granted), which is a significant behavioral detail beyond the basic 'create' operation. It doesn't mention return values or other side effects, but the critical limitation is well-documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, front-loading the purpose in the first sentence and then clearly labeling the limitation. Every sentence contributes to understanding the tool, especially the critical error warning and workaround. It is concise without omitting essential caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool creates a saved audience with a complex targeting object, but the description is silent on parameter semantics, success returns, and other operational details. While the known limitation is helpful, it doesn't compensate for the lack of guidance on constructing inputs or interpreting outcomes. For a create tool with high complexity, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about any of the five parameters (account_id, name, targeting, confirm, description). The meaning of 'confirm' is particularly unclear, and the targeting object structure is undefined. The description adds no value beyond the raw schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'Create a saved audience.' This identifies the exact verb and resource, and distinguishes it from sibling tools like audiences_update_saved or audiences_apply_to_adset by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using audiences_apply_to_adset() as an alternative when a known error (code=3) occurs due to lack of Advanced Access, and warns that most MCP deployments lack this capability. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of indicating behavior. It clarifies the return content (full detail, including targeting JSON), implying a read operation, but does not disclose error handling, auth requirements, or behavior for nonexistent IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no unnecessary words. Every element earns its place by conveying the operation, the resource, and the key detail (targeting JSON).
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-by-ID tool with one parameter and no output schema, the description sufficiently covers the main behavior and the notable return detail. It lacks edge-case and permission context, but the low complexity reduces the need for more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the saved_audience_id parameter format, source, or how it relates to other audience IDs. The parameter name is self-explanatory, but the description adds no parameter-specific guidance beyond what the schema already shows.
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 a specific verb ('Get'), resource ('a single saved audience'), and scope ('full detail ... including targeting JSON'), which distinguishes it from list-level audience tools and other get-by-ID sibling 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?
The wording implies this is for retrieving one saved audience by ID, and the 'single' qualifier provides context for when to use it rather than a list tool. However, it does not explicitly name alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses that not all metrics apply to all media types, which is useful, but does not describe error behavior, rate limits, or response format. The metric compatibility note adds value beyond a simple 'get' statement.
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 two short sentences plus a list, all front-loaded with the core purpose. Every line adds value: the metrics list and the media-type caveat are useful, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema. The description covers the input semantics reasonably well but does not explain the response structure or what happens when unsupported metrics are requested. Given the lack of annotations, some additional context (e.g., return format) would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, so the description must compensate. The list of common metrics adds meaning to the 'metrics' parameter, but the 'media_id' parameter is not explained (though its name is self-explanatory). The description does not define exact metric formats or constraints beyond examples.
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 insights for an IG media post, using a specific verb and resource. It distinguishes from sibling tools like ig_get_account_insights (account-level) and insights_get by explicitly specifying media post context.
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 for IG media post insights, listing common metrics and noting that different media types support different metrics. This implies when to use the tool, though it does not explicitly name alternative tools or state 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?
With no annotations, the description carries the burden of behavioral disclosure. It does provide useful constraints, such as 'date_preset: ... Mutually exclusive with time_range' and 'fields: ... Defaults to a comprehensive standard set.' However, it omits details about response format, pagination, rate limits, authentication, or potential side effects, which are relevant for a data-fetching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a clear one-line purpose and then uses a structured 'Args:' block to document all 11 parameters. Each line is information-dense and uses examples. While it is somewhat long, the format is excellently organized and avoids fluff, earning a high score for structure even if not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no output schema, and no annotations, so completeness is challenging. The description covers parameter semantics thoroughly but lacks guidance on when to use this tool versus its siblings and does not describe the return value structure or pagination behavior. Since no output schema exists, the omission of return format is a notable gap.
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 fully compensates by explaining each parameter with concrete examples. It clarifies entity_id format ('act_... for an ad account, OR a campaign/adset/ad ID'), enumerates date_preset options, gives JSON examples for time_range and filtering, and lists acceptable values for time_increment and sort. This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get insights for any entity (account, campaign, ad set, or ad).' It uses a specific verb ('Get') and resource ('insights') with an explicit scope covering all entity levels. This differentiates it from sibling tools like insights_get_account_summary (which is account-specific) and the IG/pages insights tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing supported entity types and the 'level' parameter ('account, campaign, adset, or ad'), which tells the agent what kinds of entities it can query. However, it does not explicitly say when to choose this tool over sibling tools like insights_get_account_summary or insights_compare_periods, nor does it mention exclusions or alternative conditions.
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?
The phrase 'accessible to the user' provides useful authorization context, and the verb 'List' implies a read-only operation. However, without annotations, the description does not disclose return format, pagination, or whether any other behaviors exist, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains no unnecessary words. It is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description is adequate but minimal. It does not mention what the response structure looks like or how the data might be used with related WhatsApp tools, so it is not fully 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?
The tool has 0 parameters and schema coverage is 100% (vacuously). Per the rubric baseline, a score of 4 is appropriate since there are no parameters for the description to explain.
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 identifies the action 'List' and the resource 'WhatsApp Business Accounts (WABAs)', with the scope 'accessible to the user'. This distinguishes it from sibling tools like wa_list_phone_numbers, which list a different resource.
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 purpose is clear but there is no explicit guidance on when to use this tool versus alternatives. It also doesn't mention how the returned WABA IDs might be used with other WhatsApp tools, leaving the usage context implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses some behavioral traits: account_id accepts with or without 'act_' prefix, status_filter defaults to all, and limit has a max of 100 with cursor pagination. However, it does not describe auth requirements, error behavior, return format, or other side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a one-line purpose sentence followed by a clear Args list. Each parameter explanation is concise and informative. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should cover return values and edge cases. While the parameter semantics are well handled, the description does not state what the response contains (e.g., list of campaign objects, fields included) nor error conditions. It is adequate for basic usage but incomplete for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description compensates excellently by explaining each parameter with practical details. It clarifies the account_id prefix handling, lists possible effective_status values, and specifies the limit max and pagination mechanism. This goes well beyond the schema's minimal type and default 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 'List campaigns of an ad account', using a specific verb ('List') and resource ('campaigns') with a defined scope ('ad account'). This distinguishes it from siblings like ads_get_campaign (singular) and ads_list_adsets (different entity).
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 does not explicitly state when to use this over alternatives or what not to use it for. No explicit exclusions or comparisons are made, so guidance is limited to the inherent meaning of the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that pausing stops delivery and preserves learning, which are meaningful behavioral traits beyond the schema. It does not mention confirmation requirements, but the core effects are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and includes a useful parenthetical. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the confirm parameter is a potential gate that is not explained. An agent might call with only campaign_id and the default confirm=false could prevent the pause. Without describing this, the description is incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. While campaign_id is inferable from context, the confirm parameter (default false) is not described, leaving ambiguity about whether confirmation is needed to execute the pause. The description adds no param semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pause') with a clear resource ('a campaign') and explains the effect ('stops delivery, preserves learning'), distinguishing it from siblings like activate/update/delete.
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 by indicating the tool pauses a campaign and preserves learning, implying temporary halt rather than deletion. However, it does not explicitly mention 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?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states 'Returns metadata only — no sensitive details (card numbers, etc.)', which is valuable context beyond what the name or schema conveys, informing the agent that this is a read-only tool with limitations on output content. It does not disclose error handling or authentication requirements, but for a simple getter this is reasonable.
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, consisting of two short sentences. The first sentence states the primary purpose, and the second adds a clear limitation. Every word earns its place, with no redundancy or ambiguity.
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 tool with one parameter, no annotations, and no output schema, the description is reasonably complete. It tells the agent what the tool does and what it returns (metadata only), which is sufficient for selection and invocation. It does not describe the exact return structure or error scenarios, but the low complexity makes this 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?
The only parameter, account_id, is not described beyond the schema's terse 'Account Id'. The description references 'an ad account', which implicitly ties the parameter to that entity, but it does not explicitly explain the parameter's meaning or format. With schema description coverage at 0%, the description does not fully compensate, though the single parameter is straightforward.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get info about the configured funding source on an ad account.' It uses a specific verb ('Get') and identifies the resource ('configured funding source on an ad account'), which effectively distinguishes it from sibling billing tools like billing_get_invoice or billing_get_account_spend.
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 a clear context (retrieving funding source info for an ad account) but offers no explicit guidance on when to use this tool versus alternatives, and it does not mention exclusions or prerequisites. Since it's a simple getter, usage is implied rather than explicitly stated.
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?
Since no annotations are provided, the description bears the full burden. It proactively discloses the key behavioral distinction between lifetime and date-filtered spend, and mentions that spend is aggregated from insights. It doesn't cover error cases or currency, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action. No redundant text and every sentence adds meaningful behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist, so the description must explain return behavior and parameters. It does explain the lifetime vs period return shapes, but it omits details about date_preset and does not describe the response structure beyond the field name 'amount_spent'. For a low-complexity tool, it's adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the high-level semantic of including or excluding date params, but it never names the specific parameters (since, until, date_preset) or explains their formats. The account_id parameter is also not described. This is helpful but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'total amount spent by an ad account'. This distinguishes it from sibling tools like billing_get_invoice (invoice details) and billing_summary_all_accounts (summary across 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?
The description implicitly defines usage by explaining behavior: without date params it returns lifetime spend, with date params it aggregates spend for a period. It does not explicitly mention alternatives or exclusions, but the use case is clear and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the critical 24-hour window limitation and the need to use templates outside that window. However, it does not mention potential costs, authorization requirements, or message delivery/error behavior, which prevents a perfect score.
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 brief and well-structured: a one-sentence purpose, a clearly highlighted NOTE about the 24-hour window, and a compact Args section. Every sentence adds necessary value with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the helpful 24-hour context, the description is incomplete for a 5-parameter tool with no annotations and no output schema. It fails to document the required 'phone_number_id' and 'text' parameters, the 'confirm' flag semantics, or any return value/error information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the 'to' parameter with formatting guidance. It completely omits 'text', 'phone_number_id', 'confirm', and 'preview_url', leaving required parameters like 'phone_number_id' unexplained and 'confirm' ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Send a free-form text message to a WhatsApp number.' It clearly distinguishes itself from sibling tools like wa_send_template_message and wa_send_image_message by emphasizing 'free-form text message.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when the tool is appropriate: only within the 24-hour customer service window after the user messages you. It also names the alternative path ('use a template') outside that window, giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It explains important constraints such as lifetime budget requiring end_time and day-parting requiring a lifetime budget, but it does not mention the confirm parameter's side effects, the status default of PAUSED, or what the tool returns after creation.
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: it starts with a clear one-sentence purpose, followed by a bulleted list of parameters with concise, actionable explanations. Every sentence contributes value, and the format makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 20-parameter tool with nested objects and no output schema, the description covers the majority of parameters and key dependencies. It includes a helpful pointer to a sibling tool, but it misses a few parameters and does not describe the response or error behavior, so it is not fully 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?
The schema has 0% description coverage, and the description compensates well by explaining the meaning and constraints of most parameters, including enum-like values for optimization_goal and the detailed structure of adset_schedule and targeting. However, it omits several parameters (name, status, confirm, bid_strategy, bid_amount_cents), leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create an ad set under a campaign,' which is a specific verb+resource statement that clearly distinguishes this tool from sibling tools like ads_create_campaign and ads_create_ad. It also clarifies the hierarchical relationship to parent objects.
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 practical usage context, including budget exclusivity rules and a tip recommending ads_set_adset_schedule for day-parting setup. However, it does not explicitly state when to use this tool versus alternatives (e.g., updating an ad set with ads_update_adset).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains that parent_id can be either an ad account ID (act_...) or a campaign ID, which is critical behavior not evident from the schema. It also clarifies status_filter as an optional effective_status filter. No contradictory traits are mentioned.
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 two concise sentences plus an args list. Every sentence adds value: the first states the action and scope, the second elaborates on parameter semantics. No filler or 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?
For a simple listing tool with no output schema, the description is sufficiently complete. It covers the polymorphic parent_id and the optional status filter, which are the main behavioral nuances. It does not mention pagination or return format, but these are typical for list tools and the limit parameter is present in the schema. Overall, the description is adequate for an agent to select and invoke 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 description coverage is 0%, so the description must compensate. It adds meaningful semantics for parent_id (explaining the two accepted ID types) and status_filter (effective_status filter). The limit parameter is not explained, but it is self-explanatory and has a default value in the schema, so the missing explanation is minor.
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 ad sets'), the resource ('ad sets'), and the scope ('under an ad account or under a specific campaign'). It distinguishes this list operation from related tools like ads_get_adset (single get) and ads_create_adset (create).
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 the tool: when you need to list ad sets under either an ad account or campaign. It does not explicitly name alternatives or exclusions, but the context is unambiguous and implied by the 'list' verb. There is no misleading 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?
Without annotations, the description carries the full burden. It discloses several behavioral traits: the version prefix is added automatically, confirm is required for POST and DELETE, and it distinguishes between params (query string) and data (body). It does not mention error handling or rate limits, but the provided details are meaningful and go beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It opens with a clear one-line purpose, then logically groups parameter explanations, and ends with three concrete examples. Every sentence adds value, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-level API caller with no output schema, the description provides sufficient invocation detail: methods, endpoint format, parameter types, and confirmation requirement. It lacks explicit mention of return values or pagination, but the standard behavior of a raw API call is implied, and the presence of graph_paginate as a sibling covers that gap somewhat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains every parameter: method (GET/POST/DELETE), endpoint (path after version prefix with a key exclusion), params (query dict), data (body dict), and confirm (required for writes). Examples illustrate usage effectively, fully compensating for the schema silence.
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 'Call any Graph API endpoint directly,' which clearly identifies it as a generic, low-level API caller. This distinguishes it from specialized sibling tools like ads_pause_campaign or pages_publish_post, which target specific 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 clearly implies this tool is for direct Graph API calls beyond the specialized high-level tools. It explains the context (call any endpoint) but does not explicitly state 'use specialized tools when available' or list exclusions, so it lacks explicit when-not 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?
No annotations are provided, so the description carries the full burden. It adds a crucial behavioral guarantee: it inspects without 'exposing the raw token'. This goes beyond simply stating 'inspect' and conveys a safety property important for an access-token tool. It doesn't detail other behaviors like network calls or error handling, but for a simple read-only debug tool, the main concern is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and each sentence provides distinct value (what is inspected and why it's useful). No wasted words or repetition.
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?
Despite having no output schema, the description tells the user what fields will be inspected (scopes, expiry, app, type) and the use case (debugging permission issues). For a zero-parameter, read-only introspection tool, this is complete guidance. The safety note about not exposing the token adds important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the baseline for 0 params is 4. The description adds no parameter details because none exist, and the schema already fully documents this (empty properties). This is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects the currently loaded access token and lists specific attributes (scopes, expiry, app, type). This distinguishes it from sibling tools like ads or insights. The verb 'inspect' plus resource 'access token' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the tool is 'useful for debugging permission issues', giving a clear when-to-use scenario. However, it does not mention when not to use or list alternative tools, so it lacks explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that campaigns default to PAUSED for safety, that confirm must be true to actually create, and explains budget units with an example. It does not disclose rate limits or error behavior, but for a create tool, the key safety and confirmation behaviors are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured as a purpose statement followed by a compact Args list. Every line adds unique value—no fluff or repetition. The front-loaded purpose and the clear parameter breakdown make it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, no output schema), the description is remarkably complete. It explains all parameters, default behaviors, safety mechanisms, and budget semantics. The only minor gap is lack of return-value description, but that is not required when no output schema exists and the rest is so thorough.
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 fully compensates by explaining every parameter: objective enum values, special_ad_categories options, budget meaning with an example, bid_strategy choices, buying_type default, and the confirm flag's role. This goes far beyond the schema's bare properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new campaign' with a specific verb and resource. It distinguishes itself from sibling tools like ads_update_campaign and ads_pause_campaign by focusing on creation, and adds the safety default of PAUSED, reinforcing its purpose.
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: it is for creating new campaigns, not updating or pausing. It also includes critical usage guidance like 'confirm: Required True to actually create' and the default PAUSED status. However, it does not explicitly name alternatives or state when not to use it, so it misses a full 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?
With no annotations, the description carries the full transparency burden. It discloses the non-obvious behavior that pacing_type is auto-set to ['day_parting'] unless overridden, and mentions the Meta API requirement. It does not cover error cases or effects of invalid inputs, but the disclosed behaviors are significant and useful.
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 dense but well-structured with bullet-like sections. The main action, format options, aliases, requirements, behavioral note, and example are each clearly separated. No sentences are wasted; every part adds necessary information for the tool's complexity.
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 absence of both annotations and an output schema, the description is remarkably complete. It covers purpose, input format examples, accepted aliases, prerequisites, a behavioral side effect, a removal case, and a full usage example. This is more than sufficient for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage, leaving the description to fully document the parameters. It explains the schedule object structure in detail (raw Meta format vs friendly format), day aliases, timezone_type default, and the meaning of pacing_type. This exactly compensates for the schema's lack of detail.
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 begins with a clear verb+resource pair: 'Set day-parting on an ad set'. This distinguishes it from siblings like ads_get_adset_schedule (getter) and other ads mutation tools. The phrase 'with an ergonomic format' further clarifies the tool's specific value proposition.
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 strong contextual guidance including the required LIFETIME budget (with 'Convert first if needed'), the automatic setting of pacing_type, and the special case of passing an empty list to remove dayparting. It does not explicitly name alternative tools, but the usage context is clear. The absence of explicit when-not-to-use constraints keeps this just below 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?
With no annotations, the description carries the full disclosure burden. It is transparent about the destructive nature: 'adset targeting WILL be rewritten' and the confirm parameter 'must be True' as a safety gate. It also explains merge semantics ('replace' overwrites entirely, 'merge' preserves adset keys not overridden) and the effect of overrides. This goes well beyond the schema, which has no descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-sentence purpose, followed by a brief rationale and a well-structured Args section with bullet points. Every sentence adds value; there is no redundancy or fluff. The length is justified by the complexity of the merge and override semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, merge logic, overrides, safety confirm), the description covers all aspects: purpose, the workaround context, complete parameter semantics, and behavioral warnings. It lacks an output schema and annotations, but the description provides everything an agent needs to invoke the tool correctly and understand its effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does. Each of the 5 parameters is explained with examples, defaults, and behavior: saved_audience_id with example, adset_id as target, merge with two modes and their effects, overrides with a usage example, and confirm with a warning. This is exemplary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Copy targeting from a saved audience to a live adset.' This clearly distinguishes it from sibling tools like audiences_update_saved (which updates the saved audience itself) or ads_update_adset (which directly edits adset settings). The workaround context further clarifies its unique role.
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 when to use the tool: it is the workaround for the saved_audiences write capability gate, and explains the mechanism (pull targeting from saved audience, POST on adset). It doesn't explicitly name alternative tools, but the context implies that direct saved-audience writes are not available, making this the intended alternative. This meets the 'explicit when' criterion, though it could more directly name excluded alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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