meta-ads-mcp-patched

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.3.2
Disambiguation4/5
Most tools have clear, distinct purposes, but there is overlap among lead-related tools (get_campaign_leads, get_adset_leads, get_form_leads, get_lead) and between get_creative vs create_creative vs update_creative. Descriptions help disambiguate, but the sheer number of tools increases the chance of selecting the wrong one.
Naming Consistency4/5
The naming generally follows a consistent verb_noun pattern (list_, get_, create_, update_, delete_). Minor deviations exist, such as get_campaign_adsets vs list_adsets, and add_to_block_list vs add_users_to_audience, but these are understandable and do not significantly hinder predictability.
Tool Count1/5
With 134 tools, this server is massively over-scoped. The rubric states that 50+ tools is an extreme mismatch, and this server far exceeds that threshold. The tool count alone makes the server difficult to navigate and operate.
Completeness4/5
The server covers a very broad range of Meta Ads operations, including campaigns, ad sets, ads, creatives, audiences, catalogs, leads, insights, business management, and more. Minor gaps exist (e.g., no delete_catalog, no delete_feed, no get_block_list), but overall the surface is impressively complete for the domain.
Average 3.6/5 across 134 of 134 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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 status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure, but it only reveals the default PAUSED status. It omits details about return values, required permissions, error conditions, or the side effects of creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the action. However, the incorrect 'budget' requirement taints the content, preventing a perfect score.
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 15 parameters and no output schema, the description is too terse. It doesn't mention what the API returns (e.g., ad set ID), potential validation errors, or any additional context needed for successful 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 100%, so baseline is 3, but the description does not add value beyond the schema. Worse, it incorrectly states that budget is required when it is not in the schema, actively misleading the agent and lowering the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action and resource: 'Create a new ad set.' This distinguishes it from update/delete/copy siblings. However, it lists 'budget' as required, which the schema does not require, creating a slight ambiguity about the tool's exact contract.
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. It does not mention that update_adset should be used for modifying existing ad sets, nor does it provide context on prerequisites 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, yet it only restates the basic purpose. It does not mention output format, data scope, permission requirements, rate limits, or any side effects, offering no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is concise and front-loaded with the core purpose. While it is minimal, it does not waste words and is appropriately sized for a simple read operation, though it could benefit from a bit more 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?
This tool has 8 parameters, no output schema, and no annotations, making it fairly complex. The description only states the basic action and does not explain what 'performance insights' includes, how to construct time ranges, or what the response will look like, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides thorough descriptions for all 8 parameters, including default fields and valid date presets, giving 100% coverage. The description adds no additional meaning to the parameters, landing at the baseline score for strong schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves performance insights for a specific ad set, using the verb 'get' and the resource 'ad set'. It is clear what the tool does, but it does not explicitly differentiate from sibling tools like get_campaign_insights or get_ad_insights, though the name and 'specific ad set' provide some 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 get_campaign_insights or get_ad_insights. It does not mention excluded use cases or recommend other tools for different aggregation levels, leaving the agent to infer usage solely from the name.
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, the description carries the full burden of disclosing behavior. It merely restates the tool's name ('Get performance insights') without adding any contextual details such as return format, permission requirements, or how the tool handles the various optional parameters. This is essentially a tautology and fails to give the agent any behavioral insight.
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 sentence with no fluff, but it is under-specified for a tool with 8 parameters and no output schema. It lacks substance and does not convey enough information to justify calling it appropriately sized; it is more minimal 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 the tool's complexity (8 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain what insights are returned, how the parameters interact, or what the output looks like. This would leave an AI agent without enough context to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting performance insights for a specific campaign. It uses a specific verb and resource, and the focus on 'campaign' distinguishes it from sibling tools like get_account_insights, get_adset_insights, and get_ad_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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any use cases, exclusions, or references to sibling tools such as get_ad_insights for ad-level insights.
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 that the tool returns metrics, but does not disclose any side effects (though it's likely read-only), default date ranges, pagination, permission requirements, or how parameters like level or time_range affect behavior. This is a significant gap for a complex insights 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 sentence with no redundant words, making it concise and front-loaded with the core purpose. However, it could have included more useful context (e.g., 'aggregate at account level') without becoming verbose, so it stops short of a perfect score.
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 seven optional parameters, no output schema, and no annotations, the description is too sparse to allow an agent to confidently invoke this tool. It does not explain aggregation levels, date range handling, breakdowns, or the difference from sibling insight tools. This is comparable to a mid-tier description that leaves major questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter descriptions, so the schema already documents all seven parameters. The description's mention of metrics like impressions, clicks, spend, and reach aligns with the 'fields' parameter but adds no additional meaning or syntax guidance beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('performance insights for the ad account'), which distinguishes it from sibling tools that target campaign, adset, or ad-level insights. However, it does not explicitly contrast with those siblings, relying on the name and the phrase 'ad account' to imply scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_campaign_insights or get_ad_insights. It does not mention whether to use it for account-level reporting, nor does it specify any exclusions or 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 present, so the description carries the full burden. It merely states 'Get details,' implying a read operation, but does not disclose default fields, response format, permissions, or how the 'fields' parameter affects the output. The agent is left to infer 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, front-loading the action and resource with no extraneous words. It is efficient, though it could incorporate a bit more contextual detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with full parameter schema, the description is minimally adequate. However, with no output schema and no annotations, it lacks information about the return value structure, what 'details' includes, and when to use this tool over siblings, which is a notable 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 input schema provides descriptions for both parameters (adset_id and fields), achieving 100% schema coverage. The description adds little beyond reinforcing the 'by ID' aspect, so it does not compensate for any gaps in schema semantics.
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 resource ('ad set'), specifying that it targets a specific ad set by ID. It does not explicitly differentiate from sibling tools like list_adsets or get_campaign_adsets, but 'specific' and 'by ID' imply a single-entity fetch.
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 list_adsets or get_campaign_adsets. The description lacks context about prerequisites or typical use cases, leaving the agent without 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 carries the full burden of behavioral disclosure. It only states the basic action, adding no context about read-only nature, potential status values, response format, or any prerequisites. This is a significant gap for a status-checking 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, clear sentence with no redundant information. It is appropriately sized and front-loaded, earning its place without wasting 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?
Given the lack of an output schema and the absence of annotations, the description is too sparse to be complete. It does not explain what 'status' information is returned, what possible statuses exist, or any edge cases. The tool is simple, but still requires more context to be fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'handle' and 'catalog_id' documented. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check the status of a catalog batch operation.' It uses a specific verb ('check') and a clear resource ('status of a catalog batch operation'). While it doesn't explicitly distinguish itself from siblings, the sibling list contains batch_products (the initiating operation), making the purpose sufficiently distinct.
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 that a handle from batch_products is required, nor does it describe the typical workflow (e.g., call batch_products first). The schema hints at this, but the description itself offers no 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?
With no annotations provided, the description shoulders the full burden of disclosing behavior. It fails to mention that results are paginated (via 'after' and 'limit'), that field selection is possible, or that a page-specific access token may be required (as hinted by the schema's page_id note). The description is a bare action statement and offers no insight into return format, errors, or operational nuance.
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 filler words. It earns its place by stating the primary action and resource, but it is almost too terse—missing the opportunity to include critical usage context in the same concise style. Still, given its short length, it is efficient and readable.
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 5 parameters and no output schema, so the description should compensate by explaining what the tool returns and any special behaviors. It does not cover pagination, field selection, or the access token nuance described in the schema for page_id. The description is sufficient for the simplest interpretation but incomplete for a tool that supports these options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 5 parameters, so the schema already provides parameter meaning. The description adds no parameter-level detail, but according to the rubric, a baseline of 3 is appropriate when the schema covers all parameters. No extra value was added to explain how form_id, after, limit, fields, or page_id 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 uses the specific verb 'Get' and identifies the resource as 'leads' submitted through a lead generation form. This clearly distinguishes it from sibling tools like get_campaign_leads and get_adset_leads, which retrieve leads via different scopes. The absence of an explicit platform name is minor given the schema references Facebook Page IDs, but it still slightly weakens the clarity.
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 get_campaign_leads or get_adset_leads. It does not mention exclusions, prerequisites, or conditions under which another tool would be more appropriate. Only the core purpose is stated, leaving the agent without context for selecting among related lead-retrieval 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Get details' without explaining any behavior such as authentication requirements, possibility of partial field selection, error conditions (e.g., Meta error #190 mentioned in schema), or response format. The schema's page_id description provides some context, but the tool description itself adds minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff or redundancy. It is front-loaded, clearly stating the verb and object, and every word earns its place. No unnecessary details are included.
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 a simple getter, but with no output schema and no annotations, the description must provide context about what 'details' entails. It does not explain the return structure, whether fields can be selected, or how it relates to similar tools like get_form_leads. The schema parameter descriptions help with input but not output completeness. Thus, the description is insufficiently informative for an agent 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all three parameters (fields, form_id, page_id) having descriptions. The tool description itself adds no parameter-level information, but per the baseline rule for high schema coverage, a score of 3 is appropriate. The description does not enhance or clarify parameter usage beyond what the schema already provides.
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 tool's action ('Get details') and resource ('a specific lead generation form'), which is specific enough to distinguish from sibling tools like list_lead_forms. However, it does not explicitly differentiate from similar getters such as get_lead or get_form_leads, so it lacks the sibling differentiation that would merit a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It simply states the purpose without mentioning use cases, exclusions, or specific scenarios (e.g., retrieving a single form vs. listing forms or fetching leads). No alternative tools are referenced, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'update' with no information about partial vs. full updates, side effects, error handling, or permissions. 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, front-loaded sentence with no wasted words. It is concise, but slightly under-specified; however, for such a simple tool, this length is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema. The description does not explain what happens when updating, whether only the name is updatable, or what fields are affected. For an agent to use it safely, much more context is needed.
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 already provides 100% coverage with descriptions for both parameters ('New catalog name' and 'Product catalog ID'). The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and the resource (existing product catalog), distinguishing it from create_catalog or list_catalogs. However, it doesn't explicitly contrast with sibling tools like update_product_set or include details about what fields can be updated, which slightly limits differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites like needing an existing catalog_id. It only implies that existing catalogs are updated, but there is no explicit 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 exist, so the description carries the full burden of behavioral disclosure. It mentions 'Update' but does not explain side effects, irreversibility, authentication requirements, or partial update behavior. 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 extremely concise with a single sentence that states the core function. It is front-loaded and without fluff, though it could be slightly richer 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?
Given the tool's simplicity (3 flat params, no output schema) and lack of annotations, the description is thin. It does not provide enough context for an agent to understand edge cases, return values, or relationship to sibling product set tools. A mutation tool typically requires more behavioral detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (100% coverage), so the description does not need to explain them. Since the description adds no additional parameter context, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('existing product set'), clearly identifying the tool's function. It does not explicitly differentiate from sibling tools like update_product, but the resource name is distinct enough that an agent can likely disambiguate.
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, prerequisites, or alternatives. The description only states what it does, leaving the agent to infer usage context 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?
With no annotations available, the description must carry the behavioral transparency burden. It only says 'Update', implying mutation, but gives no details about permissions, whether the update is partial or full, side effects, or reversibility. This is insufficient for a mutation tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no filler or redundancy. It is appropriately front-loaded, though it may be too brief given the tool's complexity, which prevents a perfect score.
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 a mutation with 6 parameters and no output schema or annotations, yet the description only states its basic purpose. It does not explain update semantics (e.g., whether omitted fields are retained), what the response contains, or any prerequisites like rule_id. This is incomplete for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 6 parameters, including rule_id, name, status, schedule_spec, execution_spec, and evaluation_spec. The description adds no extra meaning beyond the schema, so it meets the baseline but does not improve parameter understanding.
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 'Update an existing automated rule.' clearly states the action (update) and resource (automated rule), and the word 'existing' distinguishes it from create operations. However, it doesn't explicitly differentiate from sibling update tools or describe the scope of what can be updated, so it is clear but not maximally specific.
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 like create_rule, delete_rule, or get_rule. No context, prerequisites, or exclusions are provided. The description simply states what the tool does without helping the agent choose it appropriately.
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 full responsibility for disclosing side effects. It fails to mention whether the upload is asynchronous, whether it requires an existing feed, what the response contains, 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 fluff. The phrase 'Upload/trigger' is slightly redundant, but it remains short and 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?
For a simple upload tool with no output schema, the description is incomplete. It does not explain the upload lifecycle, how to check status, or what constitutes successful execution, leaving the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (feed_id and url) with 100% coverage. The description adds no extra meaning beyond what the schema states, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Upload/trigger a feed file upload for a product feed' clearly states the action (upload/trigger) and the resource (feed file). It is specific enough to distinguish from list/read feed tools, though it does not explicitly contrast with create_feed.
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 create_feed or get_feed_uploads. There is no mention of prerequisites, typical scenarios, 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?
The description provides no behavioral context. With annotations absent, the description carries full responsibility for disclosing side effects (e.g., experiment creation, potential irreversibility, required permissions). It only states the action without any additional behavioral details.
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 redundant words, making it concise and front-loaded. However, it is extremely brief and could include additional value 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 creation tool with six parameters, no annotations, and no output schema, the description is insufficiently complete. It does not explain what happens after creation, how results are returned, or any required context such as prerequisites. The schema covers parameter formats, but the description lacks operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 100% of parameter descriptions, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides, so no bonus is warranted.
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' with a clear resource 'A/B test experiment (ad study)', making the tool's purpose unambiguous. It distinguishes from sibling tools like get_experiment, update_experiment, and list_experiments by explicitly indicating a creation 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 on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or cases where update_experiment or list_experiments would be more appropriate. Usage is only implied by the verb 'Create'.
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. It discloses that the output is an HTML iframe for rendering, but omits any information about side effects, authentication requirements, whether the preview is static or live, or any limitations. Minimal behavioral transparency beyond the return type.
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 earns its place, with 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 two-parameter tool, the description provides the essential purpose and return type. However, it lacks any broader context, such as typical use cases, prerequisite conditions, or potential edge cases, leaving some gaps for a complete understanding.
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?
Both parameters (ad_id, ad_format) are fully described in the input schema with 100% coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a preview of an ad in a specified format, with a concrete return type (HTML iframe). It is specific about the verb and resource, though it does not explicitly distinguish itself from the sibling tool 'generate_preview'.
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 generate_preview or get_ad. There are no conditions, exclusions, or context for appropriate usage.
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 mention whether this is a read-only operation, what permissions are required, or any limitations of the estimate (e.g., based on targeting settings). It only states what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the purpose and key output in a clear, front-loaded manner. It contains no filler or redundant 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?
The tool is relatively simple with two parameters and no output schema. The description mentions the return value (daily reach and cost), which is useful, but it lacks usage guidance and does not describe edge cases or important behavioral context. For a simple read tool, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (ad_id and optimization_goal). The description adds minimal context by mentioning 'daily reach and cost' but does not explain the role of optimization_goal beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a delivery estimate for an ad, specifying it includes estimated daily reach and cost. This is a specific verb+resource combination that distinguishes it from sibling tools like get_reach_estimate, 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 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 get_reach_estimate or get_ad_preview. The description gives no context for choosing this tool or when it would be inappropriate.
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 only states a basic listing action and does not disclose pagination behavior, required permissions, rate limits, or what the returned roles/permissions look 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?
A single, focused sentence that efficiently conveys the core purpose. It is front-loaded and without unnecessary words, though it could have included more guidance 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 is simple but has no output schema or annotations, so the description should cover return values and usage context. It only gives a bare statement, missing pagination details and how roles/permissions are presented, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions (100% coverage) for all three parameters (after, limit, fields), so the baseline is 3. The description adds no extra parameter context, but the schema already handles this.
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 specific resource 'users who have access to the ad account', adding detail about roles and permissions. This distinguishes it from siblings like list_business_users or list_system_users.
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 list_business_users or list_system_users. There are no exclusions, prerequisites, or scenario examples.
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 carries the full burden. It only states the basic action and does not disclose pagination behavior (despite 'after' and 'limit' parameters), authentication needs, or whether the operation is read-only. This lack of context is a gap for a tool with pagination parameters.
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 that efficiently states the tool's purpose. It is not verbose, and while it could include more detail, it earns its place without 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?
Given the moderate complexity (4 parameters, pagination, no output schema, no annotations), the description is incomplete. It does not explain what the response looks like, how pagination works, or how to use the 'fields' parameter effectively. More context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with meaningful descriptions for all four parameters. The tool description adds no extra parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'product sets' with the scope 'within a catalog'. This clearly distinguishes it from sibling tools like list_products or get_product_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_product_set or list_products. There is no mention of use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Create a new Instant Experience' and lists required parameters, but does not mention side effects, permissions, idempotency, or what happens after creation. For a mutation tool, 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 concise sentences, immediately states the core purpose, and includes only essential parameter requirements. No filler or redundant 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?
While parameters are well documented in the schema, there is no output schema and the description does not explain the return value (e.g., a canvas ID) or any authentication requirements. For a create operation, this missing information makes the description incomplete for an agent 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds 'JSON array defining the canvas layout' for body_elements, which is consistent with the schema but does not provide significant new meaning beyond it.
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 new Instant Experience (Canvas) on a Facebook Page.' This clearly states the action and target, and distinguishes it from sibling tools like get_canvas, list_canvases, and delete_canvas.
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 about when to use this tool versus alternatives like get_canvas or list_canvases. The description only mentions required parameters ('Requires page_id and body_elements') but does not provide usage context, exclusions, or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not mention required permissions, whether the operation is destructive, what happens after creation, or any side effects. The description only describes the payload structure, not the behavior of 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 two sentences with no filler. It front-loads the primary action and then provides a brief, relevant explanation of the core parameter. 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 a creation operation with no output schema and no annotations. The description does not mention what the response contains (e.g., creative ID), prerequisites like ad account access, or how object_story_spec should be structured beyond a cursory note. This is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds slight value by clarifying that object_story_spec defines ad content and the Facebook Page, but it does not elaborate on url_tags or asset_feed_spec beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'new ad creative', and specifies the key input 'object_story_spec' with its content types (link, photo, or video) and the associated Facebook Page. This distinguishes it from sibling tools like create_ad or create_dynamic_creative.
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 such as create_dynamic_creative, create_ad, or update_creative. The description implies usage for static creatives via object_story_spec but does not state exclusions or 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?
With no annotations provided, the description carries the full burden but only states the core action. It does not disclose side effects, required permissions, idempotency, or error conditions. For a write operation, this is insufficient 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 clearly communicates the action without unnecessary 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?
The description lacks context about return values, prerequisites (e.g., existing catalog ID), or filter format details. Since no output schema exists, the agent gets no indication of what to expect after creation, which is a notable gap for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter description coverage. The tool description adds no additional parameter context beyond what is already in the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' with a clear resource 'product set' and context 'within a catalog', which distinguishes it from sibling tools like update_product_set or list_product_sets.
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 that this is for creating a new set while update_product_set modifies existing ones, leaving the agent to infer usage from 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 provided, so the description carries full burden. It only says 'create,' implying a mutating operation, but does not disclose side effects, permission requirements, idempotency, or what happens on success/failure. This is a significant transparency gap for a creation 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 front-loaded sentence with no filler or redundancy. It efficiently communicates 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 has 4 parameters with complex behavioral meaning (evaluation, execution, schedule), no annotations, and no output schema. The one-sentence description does not cover prerequisites, return values, the format of the spec JSON strings, or any operational context, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all four parameters, so the baseline is 3. The description adds no additional parameter semantics beyond the schema's brief descriptions of the JSON spec fields.
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 'create' and the resource 'automated rule' with scope 'for the ad account,' which distinguishes it from sibling rule tools like list_rules, get_rule, update_rule, and delete_rule. It is specific and not a tautology.
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 given on when to use this tool versus alternatives. It lacks context on prerequisites (e.g., needing an ad account ID or existing rule specs) and does not mention exclusions or cases where other rule tools would be more appropriate.
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 states the action ('check status and retrieve results') without explaining whether the call blocks, what statuses exist, how to interpret not-ready states, or error behavior. This is a significant gap for an async 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 concise sentence that is front-loaded with the main purpose. No wasted words; it earns its place perfectly.
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 an async report getter with no output schema and no annotations. The description omits crucial details about the async polling flow, such as whether it returns partial data, how to interpret status fields, or what happens if the report is not ready. For a 2-parameter tool, it is under-specified.
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 descriptions cover 100% of parameters, so the baseline is 3. The description adds no additional meaning beyond what the schema provides, but the schema itself is clear (report_run_id from create_async_report, fields as comma-separated).
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 checks status and retrieves results of an async insight report, using specific verb+resource language. It distinguishes itself from siblings like create_async_report and get_account_insights by explicitly focusing on the async report lifecycle.
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 it should be used to poll after creating an async report, nor does it discuss any preconditions or fallback options.
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 merely says 'Get details' without specifying what details are returned, the effect of the 'fields' parameter, or any prerequisites like authentication. This is minimal and under-disclosing for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is well-structured and front-loaded with the 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?
For a tool with no output schema and no annotations, the description is too sparse. It does not explain the return format, the purpose of the 'fields' parameter, or any context about catalogs, leaving the agent with insufficient information to fully predict the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both 'catalog_id' and 'fields' have clear descriptions. The tool description adds no extra meaning beyond implying the use of an ID for a specific catalog, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving details for a specific product catalog. The verb 'Get' and resource 'specific product catalog' make it distinct from siblings like 'list_catalogs' (which lists all) and 'update_catalog' (which modifies).
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 usage when a known catalog_id exists but provides no explicit guidance on when to use this over alternatives. It does not mention list_catalogs for enumeration or explain when to use the 'fields' parameter, leaving usage context ambiguous.
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 says 'Search' without indicating read-only nature, error handling, response format, or any side effects. This minimal disclosure is insufficient for the agent to understand the tool's behavior beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose. It contains zero wasted words and is appropriately sized for a simple search 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?
The tool has no output schema and no annotations, so the description needs to compensate by explaining return values or potential limitations. It does not mention what the search results look like, how many results are returned (beyond the schema's default), or any restrictions on query format. This leaves the agent without critical operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already provides detailed descriptions for all three parameters. The overall description adds only the purpose ('for ad targeting') but does not add any new meaning to the parameters themselves, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search') and the resource ('geographic locations') with specific examples (countries, regions, cities, zip codes). It conveys a specific purpose ('for ad targeting'), but it does not explicitly differentiate from sibling tools like search_targeting or search_targeting_map, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for ad targeting' implies the context of use, giving some guidance on when this tool is relevant. However, there is no mention of alternatives or exclusions, such as 'use search_targeting for broader criteria', so it only provides implied usage context rather than explicit 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?
With no annotations, the description must disclose behavioral traits but only says 'update', implying mutation without details on partial vs. full update, authentication needs, or side effects. It fails to inform the agent about how unspecified fields 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?
A single efficient sentence that is front-loaded with the action, containing no 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 description is too sparse for a mutation tool with seven parameters and no output schema or annotations. It lacks information about update semantics, return values, and required context, making it insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All seven parameters have schema descriptions, so the schema covers attribute semantics; however, the description adds no additional parameter-related 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 tool updates an existing product, using a specific verb and resource. It distinguishes from read-only siblings like get_product and list_products.
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. It does not mention prerequisites, exclusions, or alternate methods for product management.
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 states the action 'create' and mentions subtype, but does not disclose side effects, required permissions, or any prerequisites. For a mutation tool, this lacks essential 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 two sentences, front-loaded with the primary action and followed by a concise explanation of the subtype parameter. Every word is relevant and there is no 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 tool has four parameters and no output schema, the description is incomplete. It does not explain what the tool returns, which subtypes require additional parameters like customer_file_source, or how this fits with related tools such as create_lookalike_audience. More context is needed for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that subtype determines the audience source and listing examples, which clarifies the role of this parameter beyond the schema's enum list.
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 creates a new custom audience with a specific verb and resource. It mentions subtype as a key differentiator, but does not explicitly distinguish from the sibling tool create_lookalike_audience, which could cause ambiguity since LOOKALIKE appears as a subtype.
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 that subtype determines the audience source, giving some context on how to use the tool. However, it does not provide explicit when-to-use vs alternatives or any exclusions, leaving room for interpretation.
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 for behavioral disclosure. It only states the creation action, but doesn't mention any required permissions, side effects, idempotency, or response behavior. For a mutation tool, this is minimal disclosure, though 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, concise sentence that states the essential purpose without any fluff. It is front-loaded with the verb and resource, making it instantly scannable.
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 creation tool with complete parameter schema, the description provides the basic purpose but omits any information about return values, usage context, or potential side effects. Since there is no output schema, the description should ideally mention what the response contains, which is absent. However, the simplicity of the tool and full schema coverage keeps this at a moderate score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'name' and 'description' parameters explicitly described in the schema. The description adds no extra parameter-level meaning beyond saying it's an 'offline conversion data set,' so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action with a specific verb ('Create') and resource ('new offline conversion data set'). It distinguishes the tool from siblings like list_offline_event_sets (listing) and send_offline_event (sending events), 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 provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, limitations, or exclusions, leaving the agent to infer usage solely from the tool name and context. 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 of behavioral disclosure. It mentions the required env var, but does not disclose permissions, idempotency, conflict handling, or side effects beyond the creation itself. 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 two short sentences that front-load the action and scope, then state a key requirement. No filler or redundant wording; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with fully documented parameters, the description covers essential purpose and a prerequisite. However, it omits expected return behavior, potential duplicate-name errors, and does not clarify how it differs from similar user-creation tools, leaving some uncertainty for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters (name and role) described inline. The description adds no additional parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'new system user', and scopes it to 'the configured business'. This distinguishes it from sibling tools like add_business_user, which likely targets business users rather than system users.
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 given on when to use this tool versus alternatives like add_business_user or list_system_users. The only contextual clue is the META_BUSINESS_ID env var requirement, but there is no explicit when-to-use or what-not-to-use 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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It states only the destructive action ('Delete') without mentioning irreversibility, side effects, authorization requirements, or consequences. This is minimal and largely restates the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. For a simple delete operation, this level of conciseness is appropriate 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 one-parameter, simple delete tool, the core action is communicated adequately. However, the lack of any indication about permanence, response behavior, or failure conditions leaves some contextual gaps, especially given the complete absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter rule_id, so the schema already documents it. The description adds no extra meaning beyond confirming the target of deletion, matching the baseline of 3.
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 resource ('automated rule'), clearly distinguishing it from siblings like create_rule, update_rule, get_rule, and list_rules. It states exactly what the tool does with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The usage context is only implied by the tool name and description, 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 carries the full burden. It only says 'Get details' without disclosing return format, pagination, or any side effects. Since this is a read operation, the lack of behavioral context (e.g., what fields are available via the optional 'fields' parameter) leaves the agent guessing.
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 short sentence, front-loaded with verb and target. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 2 parameters, so a minimal description might be acceptable. However, with no output schema, the description should at least hint at the response shape or how 'details' are scoped. The lack of any guidance on the 'fields' parameter and no linkage to related business tools makes it minimally 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 descriptions already fully define both parameters: business_id (required) and fields (comma-separated). The description adds no additional semantics beyond what the schema provides. Baseline 3 is appropriate since schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'Get details' and the resource 'a specific business by ID'. It distinguishes well from sibling list_businesses by specifying a single entity look-up. However, it doesn't specify the type of details or how this differs from other business-related getters, so not quite a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you have a specific business ID) but provides no explicit context or exclusions. It doesn't contrast with list_businesses or any related tools, leaving the agent to infer the appropriate scenario. This meets the 'implied usage' standard.
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 carries the full burden for behavioral disclosure. It merely states 'Get details' without describing what details are returned, the effect of the 'fields' parameter, error behavior, or any permissions needed. This adds minimal 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 sentence of eight words, front-loaded with the verb 'Get', with no redundant or filler content. Every word contributes to the meaning.
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 and parameters are fully described in the schema, but there is no output schema and no annotations. The description does not clarify what the response contains or how it differs from get_experiment_results, leaving a notable gap in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters documented (experiment_id and fields). The description adds no extra parameter meaning, but the schema already provides adequate semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific experiment (ad study)' clearly states the action (get), resource (experiment/ad study), and specificity (a single experiment). It distinguishes from sibling tools like list_experiments (list vs. specific) and get_experiment_results (details vs. results).
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. There is no mention of list_experiments for browsing or get_experiment_results for results, nor any exclusions. Usage must be inferred from the 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 provided, the description must own behavioral disclosure. It conveys a read-only 'get' operation but does not mention return format, permissions, rate limits, or potential errors. This leaves the agent without essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant text. Every word contributes to communicating the core purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description is adequate but incomplete. It does not explain what 'details' includes, how the 'fields' parameter interacts with the response, or any security/visibility constraints. Without an output schema or additional context, an agent may struggle 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (rule_id and fields) with clear descriptions. The tool description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'details of a specific automated rule,' making it unambiguous that this retrieves a single rule by ID. This distinguishes it from list_rules which would list all rules, and from other get_* tools that focus on different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 list_rules or get_campaign. The word 'specific' implies an ID is needed, but there is no explicit mention of prerequisites, exclusions, or related 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?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention pagination via 'after', the default 'limit' of 25, the effect of 'fields', or the return structure. The description adds little beyond restating 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 a single concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description identifies the resource and scope, but it omits details such as how the ad account is determined (no account ID parameter) and what the response contains. Given the simple list operation and parameter coverage, it is minimally adequate but could benefit from a note on pagination or default behavior.
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?
All three parameters (after, limit, fields) have descriptive entries in the schema, so the schema coverage is complete. The tool description adds no extra meaning about these parameters, warranting the baseline score of 3.
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 names the resource 'ad creatives' with a scope 'ad account', clearly distinguishing it from tools like get_creative (single creative) and create_creative. The function is immediately obvious.
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 get_creative for a single creative or create_creative for creating. It does not mention prerequisites, pagination usage, or 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 provided, the description carries the full burden of behavioral disclosure. It only states the action and scope, omitting pagination behavior, read-only confirmation, rate limits, or whether results include all fields. This is insufficient for a tool with no annotation support.
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, direct sentence with no wasted words. It is concise and front-loaded, stating the action and scope clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description captures the core purpose but lacks contextual details such as pagination, default field sets, and return format. Given the absence of an output schema and annotations, this leaves some gaps, but for a straightforward list tool it remains minimally viable.
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 does not mention any parameters, but the input schema has 100% coverage with descriptions for 'after,' 'limit,' and 'fields.' Since the schema fully documents parameters, the description adds no extra meaning, meriting the baseline score.
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' and identifies the resource 'custom audiences' with clear scope 'in the ad account.' This distinguishes it from sibling tools like list_saved_audiences, which target a different audience 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 get_audience or list_saved_audiences. There is no mention of exclusions, prerequisites, or recommended 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?
No annotations are provided, so the description carries the full burden. It only states the listing action without disclosing pagination behavior, default limit, field selection, or read-only nature. The verb 'list' implies read-only, but no explicit behavioral detail is given.
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 word contributes to the purpose, making it highly 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 list tool with no output schema, the description covers the scope but omits behavioral details like return format or pagination. The schema parameters hint at pagination, but the description itself provides minimal context beyond the basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter (after, limit, fields) described clearly. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'ad images' and scope 'uploaded to the ad account'. This clearly distinguishes it from sibling tools like get_image (singular) and list_videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as get_image for a single image or upload_image for adding images. No context on typical use cases or filtering options beyond the 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention that the operation is read-only, nor does it disclose any pagination behavior, field selection consequences, or potential errors. The verb 'List' implies a read operation, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, focused sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to scan.
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 a simple list operation with three optional parameters and no output schema. The description is sufficient for basic understanding but lacks context on what is returned (e.g., fields, pagination cursors) and how it fits into the offline events workflow. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its three parameters (after, limit, fields), so the schema describes them adequately. The description adds no additional parameter guidance, but per the rubric, a high coverage baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('offline conversion data sets'), and the scope ('for the ad account'). This distinguishes it from sibling list tools such as list_custom_audiences or list_catalogs, as the resource type is uniquely identified.
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 information is provided about when to use this tool versus alternatives. The description is a bare statement of function without context on prerequisites, exclusions, or relation to other offline event tools like create_offline_event_set or send_offline_event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'List automated rules' implying a read operation, but does not detail pagination behavior, default result count, authentication requirements, or any side effects. The presence of 'after' and 'limit' parameters hints at pagination, but the description itself adds no 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, concise sentence that is front-loaded with the main action and resource. It is efficient and contains no wasted words, making it easy 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 tool, the description is adequate but lacks completeness. It does not explain what 'automated rules' contain, what the response format is (no output schema), or whether the results are paginated by default. Given the sibling tools and parameter schema, the agent can infer some context, but the description alone leaves gaps in understanding the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions (100% coverage), so the schema already explains their purpose. The description adds no extra meaning about parameters, such as what fields are available or how pagination works. Thus, it meets the baseline for good schema coverage but adds no additional 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 uses a specific verb 'List' with a clear resource 'automated rules for the ad account,' which distinguishes it from sibling tools like get_rule (single rule) and create_rule. It clearly states the scope (ad account) and the action, leaving no ambiguity 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 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 conditions like needing to view all rules, nor does it contrast with get_rule or other listing tools. The context is minimal and implied only by the tool's name and 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 must disclose behavioral traits. It only states the removal action and payload format reference, without mentioning irreversibility, required permissions, side effects, or whether the removal is permanent. 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 two short sentences with no fluff, effectively front-loading the main action. It earns efficiency points, though it sacrifices depth that could improve behavioral transparency.
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 and no output schema, the description is too minimal. It does not explain side effects, prerequisites, or when to prefer this over sibling tools. The schema covers parameters, but contextual and behavioral aspects are left entirely unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with detailed descriptions for both parameters, including payload structure and SHA-256 hashing requirement. The description adds only a cross-reference to add_users_to_audience for format, which is helpful but not essential given the schema already carries the details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove users') and the target resource ('a custom audience'). It distinguishes from siblings like add_users_to_audience by using the verb 'Remove' and also references the payload format to link with the add tool, 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 the action verb and indicates the payload format matches add_users_to_audience, but it does not explicitly state when to use this tool vs alternatives or any exclusions. There is no contextual guidance beyond the basic action.
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 carries the full burden of behavioral disclosure. It does not mention side effects, permissions, rate limits, or what happens on success/failure, leaving the agent without critical operational context for a mutation-like action.
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, efficient sentence with no filler or redundant information. It is appropriately sized and front-loaded with the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a simple two-parameter tool, with the schema covering parameter details. However, the lack of annotations and absence of differentiation from the similarly named sibling leaves some gaps in operational context, preventing a higher score.
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 covers 100% of parameters with clear descriptions ('JSON array of offline events' and 'Offline event set ID'). The tool description adds no additional meaning or context beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send') and the target ('offline event set'), with the word 'offline' distinguishing it from the sibling tool send_conversion_event. 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 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 the similar send_conversion_event sibling. The description only states the action without any contextual usage or exclusion criteria.
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 context but only states the basic action. It does not mention permissions, idempotency, duplicate handling, or return values, which are significant gaps for a create operation. The phrase 'new' implies non-overwrite, but richer 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 a single, front-loaded sentence without any fluff. It efficiently conveys the essential purpose and scope, 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.
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 no usage guidelines, the description is incomplete for an agent. It does not explain what the tool returns (e.g., block list ID) or when to choose this over related tools, leaving gaps in the operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear 'name' parameter description. The tool description does not add any additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'create' with a clear resource 'publisher block list' and scope 'for the ad account'. It distinguishes itself from sibling tools like delete_block_list and add_to_block_list, 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 for creating a new block list, but does not explicitly state when to use this tool versus alternatives like delete_block_list or add_to_block_list. No exclusions or alternative recommendations are provided, leaving the agent to infer from sibling names.
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 states the creation action and does not disclose side effects, required permissions, validation behavior, or return value. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that gets straight to the point with no filler. Front-loaded with the 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?
The description is too sparse for a create operation with no output schema or annotations. It does not explain what constitutes a feed, how file_url and schedule relate, or what the response looks like. There is also no mention of prerequisites like an existing catalog.
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 already describes all four parameters with 100% coverage. The description adds no additional meaning beyond the parameter names, so it relies entirely on the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new product feed for a catalog, using a specific verb and resource. It is differentiated from related feed operations like upload_feed or list_feeds by the explicit 'create' action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as upload_feed or update_catalog. The context implies creation of a new feed, but there are no explicit exclusions or conditions.
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 input types, but does not mention return values, whether the operation is synchronous, if an ID is created, required permissions, or any side effects. 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 that directly states the purpose and hints at key parameters. Every word earns its place; there is no fluff.
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 tool with 6 required parameters and no output schema, the description is too brief. It does not explain what the response contains, how to retrieve the created prediction, error scenarios, or any follow-up steps. Given the low complexity of the input schema, a bit more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds minimal value by restating that target_spec is a JSON string and budget is in cents, but does not explain any parameter relationships or expected values beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a new reach & frequency prediction.' The verb 'Create' is specific and distinguishes it from sibling tools like list_rf_predictions, get_rf_prediction, and delete_rf_prediction.
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 word 'Create' – use when you need a new prediction. However, there is no explicit guidance on when to use it versus alternatives, no prerequisites, or context about how it relates to other rf_prediction 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, and the description adds almost no behavioral context. It only states 'Get performance insights' without disclosing return format, pagination, rate limits, or any side effects. This is a minimal, read-only-like description that does not compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single eight-word sentence that is perfectly concise and front-loaded. Every word contributes to stating the tool's primary 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?
Given the tool has 8 parameters, no annotations, and no output schema, the description is far too sparse. It does not mention the tool's capabilities around filtering, breakdowns, date ranges, or the types of insights returned, leaving the agent to infer almost everything from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all eight parameters. The description does not add any parameter-level meaning beyond what the schema provides, and the baseline for high coverage is 3.
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'), identifies the resource ('ad'), and specifies the scope ('specific'), clearly distinguishing it from sibling tools like get_campaign_insights or get_adset_insights. It explicitly targets a single ad's performance insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need performance insights for a specific ad. However, it does not explicitly mention when not to use it or alternatives, such as using account-level or campaign-level insights, despite having several sibling insight 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?
With no annotations provided, the description carries full burden. It indicates the tool converts a targeting spec into readable sentences, but it does not disclose whether it fetches the ad set, returns plain text, or has any side effects. The behavior is somewhat transparent but lacks safety and boundary 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 two concise sentences that are front-loaded with the action and resource. The second sentence clarifies the first without excessive redundancy, making it efficiently worded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the self-explanatory nature of the output (a human-readable sentence), the description is sufficiently complete. It does not explain return structure but that is not critical here.
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 describes the single parameter adset_id with a simple 'Ad set ID' description, giving 100% coverage. The tool description adds no extra meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 a human-readable targeting description for an ad set and converts the targeting spec into readable sentences. This distinguishes it from sibling tools by its unique function of generating descriptive text rather than raw data.
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 compared to alternatives. It does not mention whether to prefer this over get_adset or search_targeting, nor does it specify any prerequisites or contexts where it is not appropriate.
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 carry the behavioral disclosure burden. It only says 'Get results/cells' without detailing return format, pagination, field filtering behavior, or any side effects. The safety profile is only implied by the verb 'get', which is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It is front-loaded with the verb and resource. However, it is extremely terse and could profitably include a note about the 'fields' parameter or return format without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (2 params, no nested objects) but no output schema, so the description must explain return values. 'Results/cells' vaguely indicates what is returned but lacks detail on structure or filtering. The description is minimally adequate for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has full descriptive coverage: experiment_id is 'Experiment (ad study) ID' and fields is 'Comma-separated fields to return'. The description adds no additional meaning beyond this schema, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'results/cells of an experiment (ad study)'. This distinguishes it from sibling tools like get_experiment, which likely fetches experiment metadata, 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 when to use the tool (when you need experiment results/cells) but provides no explicit guidance on alternatives or exclusions. It does not mention when to use get_experiment instead, leaving usage context to be inferred from 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 provided, so the description must convey behavioral traits. It only states the action without disclosing pagination, sorting, response format, or any constraints beyond the feed_id. The schema's parameter descriptions cover mechanics, but the description adds no 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, short sentence that is front-loaded and contains no waste. It is appropriately sized for a simple retrieval operation, though it sacrifices depth 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?
With no output schema and no annotations, the description is insufficiently complete for a tool with four parameters and pagination. It fails to mention pagination behavior, return structure, or the significance of the 'after' cursor. The schema fills some gaps, but the description alone leaves the agent guessing about the result format.
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?
All four parameters are described in the schema with 100% coverage, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides. It remains neutral, neither enhancing nor detracting.
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 tool as retrieving upload history for a product feed, using a specific verb ('Get') and resource ('upload history'), which distinguishes it from sibling tools like list_feeds or get_feed. It is unambiguous and tells the agent exactly 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 is minimal and only implies usage when you need upload history for a specific feed (feed_id). It does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or preferred contexts. No reference to sibling tools is made in the 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 must disclose behavioral traits, but it only states the basic list operation. It does not mention pagination behavior, authentication requirements, rate limits, or the structure of the returned data, leaving the agent without critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 appropriately sized and front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with 3 optional parameters and no output schema, the description provides the core purpose. However, it lacks explicit mention of pagination behavior and return format. Given the schema covers parameters and sibling tools provide context, this is nearly complete but has minor 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 100%, so all three properties (after, limit, fields) are already described. The description adds no additional parameter semantics beyond the schema, which is the baseline case.
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 'Instant Experience (Canvas) creatives' within the ad account, distinguishing it from singular tools like get_canvas and mutation tools like create_canvas/delete_canvas.
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 list_creatives or get_canvas. There are no explicit exclusions or context about selecting this tool.
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 that the tool lists forms, without mentioning read-only nature, pagination behavior, permissions, or any side effects. The term 'List' implicitly suggests non-mutation but lacks explicit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core functionality without redundancy. Every word contributes to clarity, and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with well-documented parameters, the description adequately covers the core purpose. It does not mention return format or pagination behavior, but the schema provides parameter details, and the listing nature makes the return type inferable. A longer description may be unnecessary given the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (page_id, after, limit, fields) having a clear description. The tool description adds no extra semantic meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('List'), resource ('lead generation forms'), and scope ('for a Facebook Page'). It distinguishes this list operation from sibling tools like get_lead_form (single form) and get_form_leads (leads from forms), which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention sibling tools, exclusions, or specific scenarios where listing forms is appropriate beyond the generic purpose.
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 provides minimal behavioral detail beyond the action. It does not mention pagination, filtering capabilities, response structure, or any operational considerations. With no annotations, the agent is left without information about rate limits, access requirements, or the potential size of response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the core function. 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 tool with five parameters and no annotations, the description is under-specifying. It fails to mention pagination (after/limit), filtering (filter), and field selection (fields), all of which are key behaviors. It also does not explain the return format, which is especially important without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents all five parameters, so the description adds no additional semantic value. It does reinforce the meaning of catalog_id by noting the products are within a catalog, but this is directly derivable from the parameter name and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and specifies the resource 'products within a catalog', clearly distinguishing it from sibling tools like get_product (single product) and list_catalogs. It leaves no ambiguity about the tool's function.
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 it is for enumerating products in a catalog, but does not explicitly contrast with get_product or mention when not to use it. The agent must infer this from the schema and sibling names.
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 only says 'Search' and 'Useful for competitive research and transparency,' which implies read-only, but it does not explicitly affirm read-only behavior, mention authentication/authorization requirements, rate limits, pagination, or what data is returned. 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?
Three short sentences, front-loaded with the core purpose, followed by supporting detail and use case. No redundancy or filler—every sentence 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?
Given no output schema, the description should explain what the response contains (e.g., ad fields, creative, impressions), but it is silent on return value structure. It also lacks mention of pagination behavior, result count defaults, or error scenarios. The tool has 7 parameters and no output schema, so this is a meaningful 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 input schema has 100% description coverage, with all seven parameters individually described. The description adds no new semantics beyond restating that searching is possible by keywords, countries, and ad type, which maps to search_terms, ad_reached_countries, and ad_type but adds no syntax, format, or usage nuance. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Search the Meta Ad Library for ads.' It clearly states the function and distinguishes it from sibling tools like list_ads or get_campaign_ads, which deal with the user's own ad objects. The added detail (keywords, countries, ad type) further clarifies 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?
'Useful for competitive research and transparency' provides some context, implying a public-search use case, but it does not explicitly state when to prefer this tool over alternatives or mention exclusions (e.g., not for retrieving your own campaign ads). There is no direct comparison with 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?
No annotations are provided, so the description carries the full burden. It only mentions the env var requirement and doesn't disclose behavior for edge cases (e.g., duplicate user, invalid role), side effects, or return values. 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?
Two short, direct sentences with no filler. The description is front-loaded with the action and includes a critical prerequisite in the second sentence.
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 with fully described schema, the description covers the main operation and prerequisite. However, the lack of any behavioral or return details makes it merely adequate rather than thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already documents email and role. The description adds minor context (configured business, by email) but does not go beyond the schema for parameter 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 ('Add') and the resource ('a user to the configured business') with a specific method ('by email'). It distinguishes itself well from sibling tools like remove_business_user and list_business_users.
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 prerequisite (META_BUSINESS_ID env var) but does not explicitly contrast with alternatives or state when to use this tool over others. Usage is implied by the clear action and sibling context, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the action (copy/duplicate) and what is copied, but does not mention side effects such as whether the original is modified, required permissions, cost implications, or the return value (e.g., new campaign ID). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It leads with the core action and follows with key details, making it highly efficient 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?
Given the tool has 4 parameters and no output schema, the description should explain the return value and side effects. It covers the main functionality but omits what is returned (e.g., new campaign ID) and whether the original is untouched. It is adequate for basic understanding but incomplete for a copy operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal context by mentioning 'optional name override' and 'copies structure including ad sets and ads', which loosely maps to the name and deep_copy parameters. It does not provide additional syntax or formatting details beyond the schema, hence the baseline score.
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 copies an existing campaign, with a specific verb and resource. It also distinguishes from sibling copy tools by noting it copies structure including ad sets and ads, making its scope 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: it is for copying an entire campaign, not just an ad set or ad. However, it does not explicitly mention alternatives like copy_adset or copy_ad, nor does it provide when-not-to-use guidance. The context is clear but not contrasted with other copy 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 create action without additional context like permissions, side effects, or response behavior, leaving a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource, containing no filler or redundant 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?
The tool is simple with two parameters, but the description references 'ad account' which is not represented in the schema, and no output schema exists to explain return behavior. Adequate but leaves ambiguity about the ad account context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'name' and 'vertical' described in the schema. The description adds no extra parameter details, but the high coverage warrants a score of 3.
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?
Clear verb 'Create', specific resource 'product catalog', and scope 'ad account'. It distinctly identifies the tool's action and resource, distinguishing it from sibling create 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 for creating a new catalog but does not explicitly state when to use it versus alternate operations like listing or updating catalogs, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that deletion is irreversible, a critical behavioral trait. However, with no annotations, it doesn't mention other potential consequences (e.g., impact on associated ads) or permission requirements, leaving some 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 two short sentences with no redundancy. The irreversibility warning is meaningful and earns its place, making it highly 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 one-parameter delete operation, the description and schema cover basic invocation, but the lack of any context about when deletion is appropriate or cascading effects leaves some gaps. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no meaning beyond the schema's 'Ad set ID to delete'. The parameter is fully documented, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an ad set' with a specific verb and resource, distinguishing it from sibling delete operations like delete_campaign or delete_ad. The irreversibility note adds clarity about the action's nature.
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 update_adset or delete_campaign. There are no prerequisites, conditions, or exclusions mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the action is irreversible, which is a critical behavioral trait. However, with no annotations provided, it does not disclose other potential consequences like cascading deletion of associated adsets/ads or permission requirements. It covers the most obvious risk but leaves other behaviors unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the verb and resource, and the second sentence about irreversibility adds meaningful value without waste. It is appropriately 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 is simple (one parameter, no output schema), and the description states its primary purpose and its irreversible nature. However, given the absence of annotations, it does not address potential side effects on related objects or expected response on success/failure, leaving some ambiguity for a destructive operation.
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 includes a single required parameter `campaign_id` with a description, and the schema coverage is 100%. The tool description adds nothing about the parameter's meaning beyond what the schema already specifies, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Delete') and resource ('a campaign'), clearly distinguishing it from other campaign-related tools like get_campaign or update_campaign. The resource 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?
The description provides no guidance on when to use this tool versus alternatives such as update_campaign (to change status) or delete_adset. It lacks any contextual cues about prerequisites or when deletion is appropriate.
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 that the action is irreversible, which is valuable behavioral context. However, with no annotations, it fails to mention potential cascading effects, such as what happens to ads referencing the video, or whether special permissions are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no fluff. It states the action and the critical caveat in an efficiently structured manner.
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 delete tool, it covers the key trait (irreversibility) but lacks details about dependent resources, success/error responses, or prerequisites. Given there is no output schema, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for video_id with the description 'Video ID to delete'. The tool description adds no meaningful parameter semantics beyond implying the video is an ad video, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with a clear resource ('an ad video'), making it immediately obvious what the tool does. It distinguishes itself from sibling delete tools like delete_ad or delete_image by specifying 'video'.
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. There are many delete tools among siblings (e.g., delete_ad, delete_image), and this description does not clarify when delete_video is the appropriate choice 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 exist, so the description carries the full burden of disclosing behavior. It mentions a configuration requirement but does not state what the exchange does beyond the token conversion, whether it is a read-only operation, what the response contains, or any side effects. This is a significant gap for an authentication-related 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, each serving a purpose: one states the core function, the other notes a necessary configuration. There is no redundancy or filler, making it appropriately 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?
For a simple single-parameter tool, the description covers the main action and a key requirement. However, it omits information about the returned token, potential errors, and the broader context of when to use this exchange. Since there are no annotations or output schema, the description could be more complete, earning a mid-range score.
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 describes the parameter 'short_lived_token' fully (100% coverage), and the description's phrase 'short-lived access token' aligns with the schema. The description does not add extra semantic details about the parameter beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Exchange') and the specific resources ('short-lived access token' to 'long-lived token'), making the tool's purpose unmistakable. It is specific enough to distinguish from related token tools like refresh_token and debug_token, even though alternatives aren't named.
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 (when you have a short-lived token and need a long-lived one) and provides a key prerequisite (META_APP_ID and META_APP_SECRET configured). However, it does not explicitly mention when to use this tool versus refresh_token or debug_token, nor 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 must disclose behavioral traits itself. It mentions the content of the activity log, but it does not disclose pagination behavior, rate limits, or explicitly state that this is a read-only operation. The tool has pagination parameters ('after', 'limit') that are not explained in the description.
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 main purpose. The second sentence adds specific detail without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple read tool, but it omits mention of pagination and what fields are returned by default. Given the absence of an output schema and annotations, the description could be more complete, though it is not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already documented. The description adds no additional meaning about the parameters (e.g., how to use 'after' or 'fields'), so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('activity log for the ad account'), and clearly states the scope ('changes made to campaigns, ad sets, ads, etc.'). This distinguishes it from all sibling tools, none of which are activity-log 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 naming what it does, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. With many sibling tools, some explicit guidance would improve clarity.
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 for behavioral disclosure. It does not mention that this is a read-only operation, nor does it explain pagination (via 'after' and 'limit'), the meaning of 'all' relative to pagination, or any response structure. The description is too sparse to set expectations 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 a single sentence with no filler, front-loading the core purpose. It is appropriately sized for the tool's simplicity, though it could benefit from more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-type tool with a simple 4-parameter schema and no output schema, the description is minimally acceptable but leaves gaps. It fails to mention that results are paginated (despite the 'all' wording), which could mislead the agent into expecting a single unbounded response. The schema helps, but the description should complement it with behavioral notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (adset_id, after, limit, fields) are already documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, aligning with the baseline of 3.
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 resource 'ads' with scope 'belonging to a specific ad set', clearly distinguishing it from sibling tools like get_campaign_ads or list_ads. It is concise 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 you have an ad set ID and need its ads, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. No alternative tools are referenced, so guidance is minimal but not misleading.
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 bears the full burden of behavioral disclosure. It only states the basic purpose and does not mention pagination, response format, rate limits, or any side effects. Since the tool likely returns paginated results (given 'after' and 'limit' parameters), this omission is significant.
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 of eight words. It wastes zero words and immediately conveys the action and target, making it highly 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 listing tool with fully documented parameters and no output schema, the description is minimally adequate. However, it fails to mention that results are paginated or how to retrieve all ads across pages, which is important contextual information for a user expecting 'all ads' in a single response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides, but it doesn't need to because all four parameters (campaign_id, after, limit, fields) are already described 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 'Get all ads belonging to a specific campaign' uses a specific verb ('Get'), clearly identifies the resource ('ads'), and scopes it by campaign. This distinguishes it from sibling tools like list_ads (all ads) and get_adset_ads (ads by adset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need ads for a specific campaign, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. There is no mention of related tools like get_campaign_leads or get_adset_ads, leaving guidance implicit.
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 states this is a read operation ('get') and scopes it to a campaign, but it does not mention pagination behavior despite the presence of 'after' and 'limit' parameters, nor does it clarify that 'all' may be subject to pagination. This lack of detail leaves important 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?
A single, clear sentence delivers the core purpose with no redundancy. It is perfectly sized and front-loaded, earning a top 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?
The tool is simple, but the description lacks details about pagination (especially the 'after' cursor and 'limit' parameter) and how 'all' adsets are returned. Since there is no output schema, the description should have mentioned these behavioral aspects to be fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds only minimal context (the 'specific campaign' maps to campaign_id) and does not enhance understanding of fields, pagination, or limits beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving all ad sets for a specific campaign. The verb 'get' and resource 'ad sets' with scope 'belonging to a specific campaign' effectively distinguishes it from siblings like list_adsets or get_campaign_ads.
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 (use when you need all adsets for a campaign) but does not explicitly mention when to use this tool over alternatives such as list_adsets or get_campaign_ads. No exclusions or alternative tool references are provided, 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.
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 restates the tool's name ('Get details of a specific product') and offers no additional context such as required permissions, error behavior, or return format. The description adds no behavioral information beyond what the name already conveys.
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 of six words with no filler or repetition. It is front-loaded and every word contributes to the meaning, making it appropriately sized for such a simple read 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 tool with full schema coverage and no output schema, the description is minimally sufficient. However, it lacks guidance on when to use the tool (beyond what is implied), and it does not describe the return value format or any edge cases. It is a viable but sparse description that leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (product_id and fields), so the baseline is 3. The description does not mention or elaborate on the parameters, relying entirely on the schema. It adds no extra meaning beyond the structured field 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 specific product' uses a specific verb ('Get') and resource ('a specific product'), clearly indicating a single-product retrieval operation. It distinguishes itself from sibling tools like 'list_products' by emphasizing 'specific', which implies retrieval by ID rather than listing.
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 wording 'a specific product' implies usage for retrieving one product, contrasting with list operations, but there is no explicit guidance on when to use this tool versus alternatives or any exclusion criteria. The tool name and description imply the use case, but no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states 'Get details' without disclosing behavior such as default return fields, handling of the 'fields' parameter, error cases, or whether the operation is read-only. This is minimal and does not go beyond the action itself.
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 highly 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 get-by-ID tool with two parameters, the description gives the essential purpose but does not elaborate on return format, defaults for 'fields', or error behavior. Given there is no output schema, slightly more context would improve completeness, but the simplicity keeps it adequate.
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 description coverage is 100%, as both 'set_id' and 'fields' have descriptions. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('product set') with a qualifier ('specific') that distinguishes it from list_product_sets. It is unambiguous and identifies the exact 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 for retrieving a single product set when the ID is known, but it does not explicitly mention when to use it over alternatives like list_product_sets. No exclusions or alternative tools are referenced, leaving usage context somewhat implicit.
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 details' without disclosing behavioral traits such as whether fields parameter is supported, what happens for invalid IDs, or any error behavior. Minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. No wasted words, and it is easy 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?
The tool is simple (get by ID) with no output schema or annotations. The description covers the core purpose but does not mention return format or any edge cases. Given the simplicity, it is adequate but could be improved with a note on the fields parameter or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (video_id and fields) are already documented. The description adds no additional semantic meaning beyond the schema, matching the baseline for high 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 the action ('Get'), the resource ('ad video'), and the identifier ('by ID'). This distinguishes it from sibling tools like list_videos or delete_video.
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 this tool—when you have a specific video ID—but does not explicitly mention alternatives or exclusions. The context is clear but there is no guidance on choosing between this and list_videos or other related 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 carries the full burden. It does not disclose behavioral traits beyond the literal 'list' action, such as pagination behavior, default fields returned, permissions, rate limits, or response format. The description merely restates the tool's name and mentions filters already present in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action and resource, followed by optional filter conditions. Every word earns its place with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, and there are no annotations. The description covers the core function (listing ad sets) and optional filters, but it does not explain pagination behavior or what data is returned, nor does it differentiate from the closely related get_campaign_adsets tool. It is adequate for a simple list operation but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions in the schema. The description adds minimal contextual value by noting that filters are optional, but it does not elaborate on how to use the pagination cursor, the limit parameter, or the fields parameter beyond what is 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 clearly states the action ('List ad sets') and resource ('in the ad account'), with optional filters by campaign or status. This distinguishes it from sibling tools like list_ads, list_campaigns, and get_adset, and the scope is explicit.
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 (listing ad sets with optional filters) but provides no explicit alternatives or exclusions. It does not mention when to use get_campaign_adsets or other related tools, so usage 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.
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 listing action and scope, omitting details like pagination behavior, return format, read-only nature, or any access requirements. For a simple list operation, this is acceptable but not 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 states the essential purpose without redundancy. Every word earns its place, and it is easily scannable for an agent.
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, the schema is complete, but there is no output schema and no behavioral notes. The description explains what the tool does but not what the response looks like or how pagination/fields are handled beyond schema hints. This is minimally viable for a list operation.
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 100% coverage with clear descriptions for all three parameters (after, limit, fields). The description adds no parameter-specific meaning, which is acceptable given thorough schema documentation. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('product catalogs') scoped to 'the ad account', clearly distinguishing it from sibling tools like get_catalog, create_catalog, and update_catalog. It is immediately obvious what action is performed on which 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 context by specifying 'for the ad account', but it does not explicitly state when to choose this over alternatives such as get_catalog or list_product_sets. There are no exclusions or alternative tool mentions, so guidance is present but minimal.
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 basic action and does not mention pagination, field selection, default limit, or explicitly confirm read-only behavior. While 'list' implies read-only, the description lacks any additional context about side effects or operational 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, short sentence with no redundant or irrelevant content. It is front-loaded and highly scannable, earning maximum conciseness.
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 with a well-documented schema, the description is minimally adequate. However, given the absence of annotations and an output schema, it does not clarify what the response contains or any explicit behavioral nuances, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters (100% coverage), so the description adds no extra meaning beyond restating that feeds belong to a catalog. The baseline is 3 due to high schema coverage, and the description does not elevate it.
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 ('product feeds') with a specific scope ('for a catalog'), effectively differentiating it from sibling tools like list_catalogs or list_products. It is a specific and unambiguous statement of purpose.
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 usage is implied by the description: one would use this tool to enumerate feeds for a given catalog. However, it does not explicitly mention when to prefer it over alternatives (e.g., get_feed_uploads) or provide any exclusion criteria, leaving the decision to the agent's inference.
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 for behavioral disclosure. It only states the basic list operation and does not mention that it's read-only, any permission requirements, pagination behavior, or what the return payload contains. The safe-read nature is implied but not explicitly 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 two concise sentences, with the first stating the core function and the second adding valuable context. There is no redundancy or wasted wording.
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 a simple list with optional parameters and no output schema. The description explains what saved audiences are and the listing scope, but it does not mention what fields are returned by default or any edge-case behavior. For a straightforward list tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for all three parameters (after, limit, fields). The description adds no additional parameter-level insight, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List saved audiences in the ad account' with a specific verb, resource, and scope. It also adds defining context ('Saved audiences are reusable targeting presets') that distinguishes this from other audience-related tools in the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing saved audiences but does not explicitly tell when to use this versus alternatives like `get_saved_audience` or `list_custom_audiences`. There are no explicit exclusions or alternative references, so the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It only says 'Remove' without mentioning whether this is reversible, what happens to URLs not in the list, required permissions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the key verb and resource. 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 relatively simple with only two parameters and no output schema. However, the description lacks any guidance on expected behavior, return values, or error handling. It is minimally adequate but leaves room for improvement, especially given it is a mutation with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully describes both parameters (urls, list_id). The description adds no extra meaning beyond what the schema provides, hence a baseline of 3.
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 ('Remove'), the target resource ('publisher URLs'), and the context ('from an existing block list'). It distinguishes itself from sibling tools like add_to_block_list (opposite operation) and delete_block_list (deletes entire 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 description implies use when you need to remove specific URLs from a block list, but it does not explicitly state when to use this vs. alternatives (e.g., when to use delete_block_list instead) or mention prerequisites like the list must exist.
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 the action (sending an event) but omits behavioral context such as the need for authentication, external API call implications, potential side effects, rate limits, or failure behavior. It does not contradict any annotations, but it 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the core action and channel. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the description is modestly complete, but it lacks guidance on event formatting, required fields within the JSON, and expected behavior. The schema provides some structure, but the description does not supplement it with important context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a descriptive parameter definition for 'events'. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a server-side conversion event via the Conversions API (pixel). It specifies the verb ('Send'), resource ('conversion event'), and method ('server-side'), which distinguishes it from sibling tools like send_offline_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (server-side pixel events) but provides no explicit guidance on when to use this tool versus alternatives like send_offline_event. There are no stated exclusions or references to other 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and does not reveal any behavioral traits such as whether the update is partial or full, required permissions, side effects, or return value format. For a mutating 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 sentence with no extraneous words. It is front-loaded with the action and resource, making it highly scannable. Every part of the sentence contributes to the purpose, earning a perfect conciseness 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?
The tool is simple (3 parameters, all described in schema), but there is no output schema or annotations. The description is minimal and leaves out important context such as usage guidelines, behavioral details, and what to expect after the update. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all three parameters, each with a description. The tool description itself adds no additional parameter semantics, but since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update an existing experiment (ad study).' The verb 'update' is specific, the resource is 'experiment', and the parenthetical clarifies that 'experiment' refers to an ad study, distinguishing it from other experiment-related tools like create_experiment or get_experiment.
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 via the word 'existing' (i.e., update an already-created experiment, not create one), but it does not explicitly state when to use it versus alternatives like create_experiment or get_experiment. No exclusions or alternative tools 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 must disclose side effects. It states 'Creates a duplicate' but omits critical behaviors such as deep_copy defaulting to true (copying internal ads) and status defaulting to PAUSED, which significantly affect the operation's outcome.
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 redundant terms. It efficiently communicates the core action and key option.
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 5 parameters, no output schema, and no annotations, yet the description only covers the basic purpose. It does not explain important behavioral defaults like deep copy or paused status, leaving an agent without critical information for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as every parameter has a detailed description including defaults and behavior ('If omitted, copies to same campaign'). The tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Copy'), a resource ('ad set'), and a key variable ('same or different campaign'), clearly distinguishing it from sibling tools like copy_campaign and copy_ad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when duplicating an ad set and clarifies the same/different campaign option, but does not explicitly state when not to use it or mention alternatives like create_adset.
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 side effects, required permissions, whether it is idempotent, or what the response looks like. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and to the point. It wastes no words and adequately indicates the tool's primary 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?
For a create operation with no output schema and no annotations, the description should provide more context about the budget schedule concept, lifecycle, or what happens upon success. The current description is minimal and lacks this context, making it insufficient for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameters. The description adds no additional meaning beyond what the schema already provides, making the baseline score of 3 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 'Create a new ad budget schedule for the ad account' clearly states the action (create), the resource (budget schedule), and the scope (ad account). It differentiates from sibling tools like update_budget_schedule and delete_budget_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new budget schedule is needed, as opposed to listing or updating existing ones. No explicit alternatives are mentioned, but the 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, the description carries the full burden of behavioral disclosure. It adds a meaningful permission requirement (pages_manage_ads), but it does not discuss operation side effects, return values, or any destructive/reversible aspects. The 'create new' wording implies mutation, but additional context would be needed for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no fluff. The permission note is valuable and earns its place, making the entry highly 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?
For a tool with 9 parameters, no output schema, and no annotations, the description is too thin. It does not mention what the tool returns (likely an ID), the state of the created form (draft vs. active), or any additional prerequisites beyond the permission. The description 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with thorough descriptions for all 9 fields, so the schema already explains parameter semantics. The description adds no extra param details, but none are necessary given the schema quality.
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 ('Create'), the resource ('lead generation form'), and the location ('on a Facebook Page'). It distinguishes itself from sibling tools such as get_lead_form and list_lead_forms 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a new lead generation form is needed, but it does not explicitly state when to use it versus alternatives or provide exclusions. The permission requirement is a prerequisite, not usage 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 must disclose behavioral traits itself. It does state that the action is irreversible, which is a critical trait, but omits other relevant behaviors such as required permissions, potential cascading deletions, or success/error responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences and no wasted words. The primary action is front-loaded, and the irreversibility warning is placed efficiently.
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 delete operation, the description covers the essential action and irreversibility. It is almost complete, though it could mention what happens to associated data or the return value, but this is a minor gap given the tool's simplicity.
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 100% coverage for the single parameter, with ad_id described as 'Ad ID to delete'. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete an ad') with a specific verb and resource, distinguishing it from sibling tools like get_ad, update_ad, and copy_ad. The added warning about irreversibility further reinforces the 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?
No explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. While deletion intent is implied by the verb, the description does not mention that this is for permanent removal or advise using update_ad for modifications.
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 'Get details' without mentioning authentication requirements, response shape, potential errors, or any side effects. The description essentially restates the tool's purpose without adding meaningful behavioral context beyond what the name and schema already imply.
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 conveys the essential purpose without any extraneous words. It is appropriately sized and front-loads the core action, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (get by ID) and the presence of a complete schema, the description is adequate for successful invocation. However, the absence of an output schema and annotations means the description could have added return format or usage caveats, but for a standard get-by-ID operation, the current level is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters (lead_id and fields). The description adds no extra semantic value beyond the schema, mentioning only 'by ID' which repeats the lead_id parameter. Since the schema already explains the parameters clearly, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'details of a specific lead by ID', which precisely identifies the tool's function. It distinguishes itself from sibling tools like get_form_leads or get_campaign_leads by emphasizing the singular 'specific lead by ID', making its scope 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 a specific lead ID is known, but it does not explicitly discuss when to prefer this tool over alternatives (e.g., get_form_leads, get_campaign_leads). There is no mention of exclusions or scenarios where other tools should be used, so the context is clear but lacks explicit guidance on 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?
With no annotations, the description partially carries the transparency burden by specifying that the payload must be hashed and formatted as a JSON string with a schema. However, it does not disclose side effects, prerequisites (e.g., audience must exist), idempotency, or error behavior, leaving significant gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action front-loaded and the payload constraint stated in a single additional sentence. There is no filler or redundancy, making it maximally efficient for its length.
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 mutation tool, the description covers the core action and essential payload format, but omits details like response behavior, whether the audience must pre-exist, and handling of duplicate users. Given no annotations or output schema, a slightly richer description would be expected for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented. The description adds a concrete example of schema values (EMAIL, PHONE, FN, LN) that supports but mostly repeats the schema's payload description. It does not introduce new semantic meaning beyond highlighting the hashing requirement, which is already 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 ('Add') and names both the resource ('users') and target ('custom audience'), making the tool's function immediately obvious. It also distinguishes this from sibling tools like remove_users_from_audience and create_custom_audience by showing it adds to an existing audience.
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 (adding users to an audience) but provides no explicit guidance on when to use this tool versus alternatives, such as create_custom_audience or update_audience. There are no stated exclusions or conditions, so the usage context is only implied by the tool name and action.
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 batch limit and upsert support, but omits crucial details such as whether operations are atomic, error handling, authentication requirements, or the asynchronous nature (given the sibling get_batch_status).
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 deliver the essential information without redundancy. It is front-loaded with the core function and immediately adds limits and upsert behavior, making every word useful.
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 involves batch mutations and there is a sibling tool get_batch_status, but the description doesn't mention that results might be retrieved separately or how errors are reported. It covers limits and upsert but leaves out lifecycle details, which are significant for a batch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with clear descriptions (requests format, catalog_id, allow_upsert). The description only reinforces the upsert behavior already captured in allow_upsert, adding no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: batch create, update, or delete products in a catalog. It distinguishes from single-product siblings by emphasizing batch capability and includes concrete limits (5,000 items) and upsert behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the batch variant for product operations, but it doesn't explicitly compare to single-product tools or feed upload alternatives. It doesn't state when NOT to use it or mention alternative tools, so guidance is implicit rather than explicit.
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 mentions the core behavior (creates a duplicate) but does not disclose nuances like whether all fields are copied, the independence of the copy from the source, or permission requirements. It's adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the primary purpose and the key variation (same/different ad set). Every word earns its place, with no redundancy or unrelated 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 copy tool with fully documented parameters, the description covers the main action and scope. However, it lacks any mention of return values (e.g., new ad ID) or side effects, and with no output schema, this leaves a gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description does not add semantic meaning beyond the schema. The adset_id parameter's behavior (same/different ad set) is already documented in the schema, so the tool description adds no extra value here.
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 action ('Copy an existing ad') with a specific resource, and adds scope ('within the same or different ad set') that differentiates it from create/update/delete ad tools. It's a specific verb+resource pairing.
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 usage is implied by the description — copying an ad when you want a duplicate. However, there is no explicit guidance on when to prefer this over create_ad or update_ad, nor any alternatives mentioned.
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 the critical behavioral fact that deletion is irreversible, but with no annotations available, it does not cover other important aspects like permissions, side effects, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and the irreversibility warning is concise and relevant. 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?
For a simple delete tool with one parameter, the description covers the action and key warning, but lacks details on return values or prerequisites, and there is no output schema or annotations to fill the 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?
The input schema already documents the canvas_id parameter with a description, and the tool description does not add any additional parameter-level information. Since schema coverage is 100%, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the specific resource (Instant Experience/Canvas), which distinguishes it from sibling tools like get_canvas and create_canvas.
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 deletion but does not provide explicit guidance on when to use this tool vs alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that this is a preview generation (not a mutation) and that it operates without an existing ad, which implies a read-only nature. However, it does not mention response format, permissions, or potential failure modes, leaving some behavioral 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 two sentences, front-loaded with the primary purpose, and contains no wasted words. It efficiently communicates the core functionality and key differentiator.
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 covers the main purpose and usage context. However, because there is no output schema, the description does not clarify what the preview output looks like (e.g., image URL, JSON), which leaves some incompleteness. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters, so the description adds no additional semantic value beyond what the schema gives. The description's mention of 'creative spec' and 'ad format' simply restates the parameter names without enriching 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 ('Generate an ad preview') and the unique resource ('without needing an existing ad'). It explicitly distinguishes itself from the sibling tool get_ad_preview by emphasizing that it works directly from a creative spec, 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 phrase 'without needing an existing ad' implies when to use this tool (when you don't have an ad yet) and indirectly contrasts with alternatives like get_ad_preview. However, it does not explicitly name alternatives or provide when-not-to-use guidance, so 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral requirement: 'Requires leads_retrieval permission,' which is valuable since no annotations are provided. However, it doesn't mention pagination (despite after/limit parameters), return format, or rate limits, so it only partially covers the transparency burden.
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, front-loaded sentence that states the core purpose and a necessary permission note. Every word is meaningful, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, so the description must carry more weight. It covers the core purpose and permission, but doesn't explain what the response contains (e.g., a list of leads) or pagination behavior, leaving some gaps for an agent to infer. For a simple read operation with comprehensive parameter schemas, this is minimally 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 input schema covers all four parameters with descriptions, meeting the 100% coverage baseline. The description adds no extra parameter-level information beyond reinforcing that the tool targets a specific ad set, so it neither improves nor detracts from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get leads') and the resource ('a specific ad set'), which precisely differentiates it from sibling tools like get_campaign_leads. It is specific, uses a strong verb, and leaves no ambiguity about the tool's 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 phrase 'a specific ad set' implies the use case and distinguishes from campaign-level leads, but it doesn't explicitly mention alternatives or when-not-to-use conditions. There is no guidance on choosing between this and similar tools like get_form_leads, leaving the context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 disclosing behavioral traits. The verb 'Get' clearly indicates a read operation, but it does not explicitly state read-only status, authentication requirements, or behavior on missing IDs. For a benign read tool this is acceptable, but it lacks richer 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, tightly worded sentence that immediately states the tool's purpose. There is zero wasted text, and the structure is direct 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?
For a simple read tool, the description is adequate but minimal. It does not explain what 'details' includes, nor does it mention error handling or return format, especially with no output schema present. It lacks the richness needed for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (audience_id and fields) with 100% coverage. The description adds no extra parameter meaning beyond reinforcing 'by ID', which is already in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and resource ('specific custom audience by ID'), making it easy to understand. It also distinguishes from sibling tools like list_custom_audiences and get_saved_audience by specifying 'custom audience' and 'by ID'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 for a single custom audience by ID, but it does not explicitly contrast it with alternatives like listing audiences or getting audience health. No when/when-not guidance is provided beyond the basic read scenario.
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' implies a read-only operation, and the permission note is useful, but the description does not explicitly state non-destructive behavior, return format, pagination behavior, or rate limits. It adds some context beyond the schema but omits important behavioral 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?
Two concise sentences, no fluff, front-loaded with the main action. The permission note is relevant and efficiently stated. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with 100% parameter coverage and no output schema, the description is adequate but leaves gaps. It states what it does and a permission requirement, but does not describe what the response looks like, how pagination works, or any exclusions. Given no output schema, the description should have provided a bit more clarity on return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning to parameters beyond 'specific campaign' mapping to campaign_id, which is already stated in the schema. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Get leads generated by a specific campaign.' It distinguishes itself from sibling tools like get_campaign_ads (ads, not leads), get_adset_leads (leads at adset level), and get_form_leads (form-specific leads) by scoping to campaign. The permission requirement adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('specific campaign') but does not explicitly state when to use this tool versus alternatives like get_adset_leads or get_form_leads. It provides a prerequisite (permission) but no alternatives or exclusions. Usage guidance is implied, not explicit.
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 convey behavioral traits. 'Get' clearly signals a read-only operation, but it does not disclose other aspects such as return format, pagination, or error handling. The description is minimal and does not enrich the safety profile beyond the obvious read nature.
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 directly states the action and resource. No wasted words, ideal for a simple getter.
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 get-by-ID tool, the description is mostly adequate, but without an output schema or any description of what 'details' includes, the agent may not know what fields are returned by default. The 'fields' parameter hints at configurability, but the description does not clarify the default return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters (audience_id and fields), so the tool description adds no additional parameter context. Baseline of 3 applies as the schema does the heavy lifting and the description does not conflict.
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), the resource (saved audience), and the qualifier (specific by ID). This distinguishes it from list_saved_audiences (which lists multiple) and other audience-related 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 when a single saved audience ID is known, but it does not explicitly state when to use this tool over alternatives like list_saved_audiences or get_audience. No explicit when-not-to-use guidance is provided, but the purpose is clear enough to infer the primary use case.
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 transparency. It only states 'List ads' and the optional filters, which are already evident from the schema. It does not disclose pagination behavior, default field selection, or any other behavioral traits beyond the obvious read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose and then mentions optional filters. Every word earns its place, with no fluff 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?
For a list tool with 6 parameters and no output schema, the description is adequate but incomplete. It does not mention pagination (despite 'after' and 'limit' parameters) or explain the return format. However, the schema covers the parameters, so the description is not critically deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the filter parameters (campaign, ad set, status) but adds no new meaning beyond what the schema already provides for each parameter.
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 'ads' and defines scope as 'in the ad account.' It also mentions optional filters (campaign, ad set, status), which helps distinguish it from sibling tools like get_campaign_ads or get_adset_ads that target specific entities.
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 indicates when to use this tool: to list ads in the ad account, with optional filtering by campaign, ad set, or status. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select this tool for account-level listing.
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 on its own. It only mentions a prerequisite (META_BUSINESS_ID env var) and does not state that this is a read-only operation, describe pagination behavior, or note any required permissions. This is a significant gap for a tool with no annotation safety hints.
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, direct sentence that conveys the core purpose and a key requirement. No unnecessary words or redundant information. It is exemplary in conciseness.
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 (3 optional parameters, no output schema), and the description covers the basic purpose. However, since there is no output schema, the description could have mentioned the return structure (e.g., paginated list, fields included) to help the agent understand expected results. For a list tool, this is a modest 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 input schema provides full descriptions for all three parameters (after, limit, fields), so the schema already covers parameter semantics. The description adds no additional value beyond the schema, which is acceptable per the baseline scoring.
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 (ad accounts), and the scope (owned by the configured business). This distinguishes it from sibling tools like list_ad_accounts and get_ad_account, providing an 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates a specific context: it lists ad accounts owned by the configured business, and the META_BUSINESS_ID env var requirement clarifies when this tool is applicable. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'List' indicates a read-only operation, and 'for the ad account' scopes the action. However, it doesn't disclose pagination behavior (beyond 'after' param) or any other side effects. It adds some context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence that is front-loaded with the key action and resource. No wasted 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 is simple with no output schema, and the description gives the essential purpose. However, it doesn't explicitly state the return format or further detail on pagination/fields, which could be useful. It's a minimally viable description for a list operation.
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 covers all three parameters with descriptions, providing 100% coverage. The description adds resource context but no additional parameter-specific details, matching the baseline score for high 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 specifies the action (List), the resource (A/B test experiments/ad studies), and the scope (ad account). It clearly distinguishes from sibling tools like get_experiment (singular) and create_experiment.
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 stating it lists experiments for the ad account, but it does not explicitly mention alternatives (e.g., use get_experiment for a single experiment) or provide when-not-to-use guidance. It's a clear but minimal usage statement.
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 the partial-update behavior, which is a useful non-obvious trait, but it omits other behavioral aspects like return value, validation errors, or dependencies between fields (e.g., DSA payor/beneficiary 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, 11-word sentence that front-loads the verb and resource. It avoids redundancy and every word contributes to the meaning, making it highly 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 an update tool with 11 parameters and no output schema, the description covers the core partial-update behavior but leaves out potential constraints like mutual exclusivity of daily vs lifetime budget, conditional DSA requirements, and what the tool returns. It is adequate for basic selection but not fully complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage, including descriptions for all 11 fields, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides, such as budget units or targeting format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing ad set' with a specific verb and resource, distinguishing it from sibling tools like create_adset, delete_adset, and copy_adset. The additional phrase 'Only provided fields will be modified' clarifies the scope of the update 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 verb 'update' implies the tool is for modifying existing ad sets, and 'Only provided fields will be modified' gives operational guidance for partial updates. However, there is no explicit mention of when to prefer this over alternatives or any exclusions, such as not being usable for deleted ad sets.
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 explains the effect of ratio (closeness to source), but fails to mention permissions, return value, whether the operation is synchronous, or any side effects beyond creation. For a mutation tool with zero annotation coverage, this is 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 two sentences, front-loaded with the main action and key parameter concept. No fluff or redundancy. 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 a create operation with 3 parameters, no output schema, and no annotations. The description does not mention what the tool returns, any prerequisites (like ad account), or error scenarios. Given the calibration example of update_drive with a similar profile, a score of 2 is appropriate for a mutation tool that leaves critical context undisclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context for the 'ratio' parameter by explaining it determines how closely the new audience resembles the source, which goes beyond the schema's 'lookalike percentage' wording. This extra conceptual explanation justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a specific resource ('lookalike audience'), clearly distinguishing it from sibling tools like create_custom_audience. It also provides a key distinguishing detail (ratio determines closeness). This is exactly what a purpose statement should do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the tool is for creating a lookalike from an existing custom audience, which is clear context. However, it doesn't explicitly state when not to use it or mention alternatives, such as create_custom_audience for non-lookalike audiences. Still, the context is clear and no exclusions are needed.
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 of behavioral disclosure. It mentions the credential requirement (META_APP_ID and META_APP_SECRET) and indicates what the tool inspects (properties, permissions, expiration, validity). However, it does not explicitly state whether the operation is read-only, potential side effects, or response format, leaving some 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 two sentences long, front-loaded with the core purpose, and the credential requirement is presented succinctly. Every sentence earns its place, and there is no unnecessary elaboration.
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?
Although there is no output schema, the description specifies what information the tool provides ('properties, permissions, expiration, and validity'), which effectively covers the return content. It also notes the required credentials. For a simple one-parameter, read-only tool, this is reasonably complete, though it could explicitly mention response format or error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'input_token' with description 'Access token to debug/inspect'. The description does not add any additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Debug an access token to inspect its properties, permissions, expiration, and validity.' This is a specific verb with a clear resource and scope, and it distinguishes itself from sibling token tools like exchange_token and refresh_token by focusing on inspection rather than token lifecycle management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its purpose ('Debug an access token...'), but it does not explicitly state when to use compared to alternatives like exchange_token or refresh_token. It provides a prerequisite ('Requires META_APP_ID and META_APP_SECRET') but lacks explicit 'when to use' or '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 must carry the full behavioral burden. It discloses a key trait—irreversibility—which is critical for a delete operation. However, it does not mention permissions, effects on linked resources, or what happens if the schedule is in use, leaving some 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.
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 every word is purposeful. The irreversibility warning is concise yet meaningful, achieving maximum clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers the essential purpose and a key consequence. It does not explain what a budget schedule is or prerequisites, but the sibling tools provide enough context to infer usage. Minor omissions like the return value or not-found behavior prevent a higher score.
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 already provides 100% coverage of the single parameter (schedule_id) with a clear description. The tool description adds no additional semantics about the parameter, so it meets the baseline but does not enhance 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 ('Delete') and a clear resource ('budget schedule'), making the tool's purpose immediately obvious. It also adds the caveat 'irreversible' for emphasis, distinguishing it from create/update/list siblings without confusion.
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 (delete when you want to remove a budget schedule) but does not explicitly state when to use it versus alternatives or provide prerequisites. The irreversibility warning is a caution, not a usage guideline, so it falls short of clear context with 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 provided, the description carries the full burden of behavioral disclosure. It adds a key warning that the action is irreversible, which is significant. However, it does not disclose other potential side effects, error handling, or permissions, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose, the second adds a critical warning. There is no redundant information, and it is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential information: what it does and that it is irreversible. It is complete enough for an agent to understand the tool's function, though it could mention prerequisites or side effects for full comprehensiveness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter (prediction_id) as 'Prediction ID to delete'. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the specific resource ('reach & frequency prediction'). It unambiguously distinguishes this tool from sibling tools like list_rf_prediction, create_rf_prediction, and get_rf_prediction.
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 reach & frequency prediction needs to be permanently removed, but it does not explicitly mention when-not to use it or name alternative tools. The context is clear but no exclusions or alternatives 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 transparency burden. It indicates a read operation ('Get') and lists the fields returned, but does not disclose additional behavior such as how the configured account is determined, error scenarios, or whether any non-read side effects exist. For a simple getter, 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 front-loaded sentence that uses a specific verb ('Get') and resource, and efficiently lists the key data points. Every word earns its place, with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is reasonably complete for a simple getter with one optional parameter and no output schema. It names the key fields and clarifies the scope ('configured ad account'), though it does not explicitly explain how the account is configured or how this relates to multi-account scenarios (e.g., list_ad_accounts). This minor gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'fields' parameter with a clear description and default value. The tool description does not add extra semantic meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of the configured ad account, listing specific data points (status, balance, currency, timezone, spend info). This distinguishes it from related tools like list_ad_accounts (which lists all accounts) and update_ad_account (which modifies).
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 the default/configured account but does not explicitly state when to use this tool versus alternatives like list_ad_accounts. No exclusions or alternative tool mentions are provided, making the guidance implicit rather than explicit.
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. It discloses the fields shown (match rate, size, operation status), which adds behavioral context about the response. However, it does not explicitly state that the operation is read-only, mention required permissions, or describe any potential side effects or freshness. 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, front-loaded sentence that states the purpose and key outputs with no redundant filler. Every word contributes meaning.
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 getter with no output schema, the description is largely complete: it explains what the tool returns (match rate, size, operation status) and identifies the resource as a custom audience. It could mention error conditions or permission details, but these are not essential for basic use, making it slightly above the minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (audience_id is described as 'Custom audience ID'), so the baseline is 3. The description does not add any extra meaning beyond the schema, but the schema already fully documents the parameter, so no deduction is needed.
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 action ('Get health status and delivery readiness') and resource ('custom audience'), and lists the key outputs (match rate, size, operation status). This distinguishes it from sibling tools like get_audience which would focus on general audience details, not health status.
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 checking audience health and delivery readiness, but does not explicitly contrast with alternatives such as get_audience or list_custom_audiences, nor does it state when not to use it. There is no direct guidance on scenario selection, so it remains at the 'implied usage' level.
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 states a read operation ('Get') but does not disclose response format, error handling, or any side effects. For a simple get operation, this is minimal but lacks explicit confirmation of read-only behavior or details on the 'fields' 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, focused sentence with no redundant information. It front-loads the action and resource.
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 retrieval tool with full schema coverage and no output schema, the description is adequate but could mention the optional 'fields' parameter or the return format. It doesn't, but the schema covers the parameters, so it remains mostly 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 input schema already describes both parameters fully (100% coverage). The description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the target resource ('a specific ad image'), scoped by 'by ID'. This distinguishes it from sibling tools like list_images (listing) and upload_image/delete_image (mutations).
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 the intended usage: when you have an image ID and need details. It distinguishes from list_images by specifying 'by ID', but it doesn't explicitly mention alternatives or exclusion criteria. Given the clear context, this warrants a 4.
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?
There are no annotations, so the description carries the full burden. The verb 'get' implies a read-only operation, and the description does not disclose additional behavioral traits such as output format or side effects. This is adequate for a simple read tool but lacks explicit confirmation of non-mutating behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and then add a use case. It contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description provides the essential purpose and context. It does not detail the return value, but the simple nature of the operation makes it adequately 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 input schema has 100% coverage for the single parameter, with a description matching the tool description. The tool description adds no additional meaning beyond restating 'targeting specification.' Thus the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets estimated audience reach for a targeting specification, using a specific verb and resource. However, it does not explicitly differentiate from similar sibling tools like get_delivery_estimate, which may also estimate reach.
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 use case: planning campaigns before creating them. It does not mention alternatives or exclusions, but the context is sufficiently clear for when 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose that results are paginated, which is a key behavioral trait. However, it does not explicitly state that the operation is read-only (though 'list' implies it), nor does it mention any potential side effects, authentication requirements, or error handling. The pagination note adds value, but overall behavioral transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action verb and resource. Every word earns its place, with no unnecessary detail or repetition of schema fields. It is exceptionally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no output schema and full parameter descriptions, the description is adequate. It identifies the resource, scope, and pagination behavior, which covers the essential context. It could optionally mention what a block list contains or whether results are ordered, but these are not critical gaps given the tool's simplicity.
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 description coverage is 100%, with each parameter (`after`, `limit`, `fields`) already described in the input schema. The description does not add additional meaning beyond that, but the baseline of 3 is appropriate since the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists publisher block lists for the ad account, using the specific verb 'List' and identifying the resource ('publisher block lists') and scope ('ad account'). This distinguishes it from sibling tools like create_block_list or delete_block_list, which perform different operations.
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 naming the operation (list) and scope, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. For example, there is no mention of 'use this to view all block lists' or 'for creating, use create_block_list instead.' Thus, usage guidance is implied but not clearly articulated.
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 transparency burden. It discloses pagination ('Returns paginated results') and conveys read-only intent through 'list', but does not mention authentication requirements, potential side effects, or how the ad account is determined. The 'for the ad account' phrase is vague about which account is used.
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 action and resource, with no filler or redundant information. The description is efficiently structured and immediately understandable.
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 list tool with no output schema and no annotations, the description covers the core purpose and pagination behavior. It lacks details about default returned fields or response structure, but the schema handles parameter semantics. Overall, it is reasonably complete for an experienced agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters (after, limit, fields) with descriptions, so the baseline is 3. The description's mention of pagination adds minimal semantic value beyond the schema's own descriptions of 'after' and 'limit'.
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 ('ad budget schedules') scoped to 'the ad account', distinguishing it from sibling tools like create_budget_schedule, update_budget_schedule, and delete_budget_schedule. It also mentions 'Returns paginated results', adding a key behavioral detail.
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 no explicit guidance on when to use this tool versus alternatives. Usage is implied by the verb 'list' and the resource, but no exclusions, alternative references, or specific contexts are mentioned beyond 'for the ad account'.
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 for behavioral disclosure. It states the primary function but does not mention pagination behavior, default limits, whether deleted videos are included, or any other operational characteristics beyond what the schema already indicates.
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, highly concise, and front-loaded with the core operation. No unnecessary words or redundant information are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with three optional parameters and no output schema, the description is adequately complete. It does not explain return format or pagination nuances, but the schema and the straightforward nature of listing videos make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the three optional parameters (after, limit, fields), and their descriptions are provided. The tool description adds no extra meaning about how these parameters interact or influence results, so it meets the baseline but does not enhance 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 resource (ad videos uploaded to the ad account), making the tool's purpose unambiguous. It also distinguishes from sibling tools like get_video, delete_video, and upload_video by focusing on the listing behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a listing use case but does not explicitly state when to use this tool versus alternatives like get_video for a single video or upload_video for adding videos. No exclusionary guidance is given, so usage is inferred from the name and description 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 burden. It discloses the return value ('Returns a new long-lived token') but does not mention whether the old token is revoked, any rate limits, or authentication requirements. It is not misleading but could be more 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 two short sentences, front-loaded with the verb 'Refresh', and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the purpose and return value, which is essential. It does not discuss caveats or differentiate from related token tools, but the provided information is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter long_lived_token is fully described in the schema). The description references the parameter but adds no additional format or syntax details beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (refresh) and resource (long-lived access token), and specifies the outcome (extend expiration, return new token). It does not differentiate from sibling tools like exchange_token or debug_token, so it is clear but lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 a long-lived access token needs its expiration extended. However, it does not mention exclusions or alternatives such as exchange_token, so it lacks explicit 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 behavioral disclosure. It discloses a key behavior: 'Only provided fields will be modified,' indicating a partial-update semantic. However, it does not mention side effects, permission requirements, or response behavior, leaving some opacity for a mutation tool. This is a modest improvement over a bare 'update' but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and resource. Every clause earns its place: the second sentence adds a critical behavioral nuance without redundancy. Ideal conciseness.
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 update tool with 5 parameters and no output schema, the description covers the core purpose and partial-update behavior. However, it omits any mention of the required identifier (ad_id) or likely response/error behavior. Since the schema provides detailed parameter descriptions, the description is adequate but not exceptional; more context on return values or side effects would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful parameter semantics by clarifying that only provided fields will be modified, which directly informs how the optional parameters should be used. This goes beyond what the schema states about each individual field, providing a holistic behavioral contract.
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 action (update) and resource (existing ad). It distinguishes from siblings like create_ad and delete_ad by specifying the update operation on ads. However, it does not elaborate on scope or differentiate among other update tools, unlike the high-caliber example that explicitly names alternatives.
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 'Update an existing ad' provides clear context for when to use this tool—when modifying an existing ad. It implicitly excludes creation, deletion, or retrieval. It does not explicitly mention alternatives or when-not-to-use scenarios, but the context is unambiguous enough for an agent to select this tool correctly.
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 disclosing behavior. It mentions the input sources and return value, but does not state that this is a write operation creating a video resource, nor any side effects, permissions, or rate limits. The description is not misleading but lacks depth beyond the obvious 'upload' action.
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 action ('Upload an ad video'), and every sentence adds value. It is concise 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?
The description is incomplete because it does not clarify that either file_url or file_path must be provided (even though no parameters are required in the schema). It also omits any caveats about what happens if both are provided, or the lack of an output schema beyond the stated return value. For a tool with 4 parameters and no annotations, this leaves a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already provides detailed descriptions for file_url and file_path, including that file_path is sent as multipart bytes. The description adds no new parameter meaning beyond reinforcement of the two source options.
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 ad video from a public URL or a local file path.' It names the specific verb (upload), resource (video), and distinguishes it from siblings like upload_image and delete_video. The return value is also specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to upload ad videos for use in ad creatives. It implicitly distinguishes from alternatives like upload_image by specifying video, but does not explicitly name alternatives or exclusion criteria. 'Returns video ID for use in ad creatives' gives a clear use 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?
The description discloses that new ads default to PAUSED status, which is a useful behavioral trait. With no annotations provided, it does not mention potential side effects, required permissions, or error behavior, leaving some gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the action ('Create a new ad'), and each sentence adds essential information (required params, creative format, default status). There is no fluff or redundancy, making it highly 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?
The description covers the essentials: purpose, required parameters, creative format, and default status. However, without an output schema, it omits any mention of the return value (e.g., created ad ID) and does not state prerequisites like ad set ownership or account context. This leaves some contextual gaps for a create tool.
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?
Since the input schema provides 100% description coverage for all parameters, the description only repeats the required fields and clarifies that creative is a JSON object_story_spec, which the schema already states. This adds no new meaning beyond the structured data, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new ad' with a specific verb and resource, distinguishing it from sibling tools like get_ad, update_ad, and delete_ad. It also mentions the required parameters (name, adset_id, creative), which further disambiguates it from other create 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 implies when to use this tool by requiring an adset_id, suggesting it should be used when creating an ad within an existing ad set. However, it does not explicitly state exclusions or alternative tools, so it lacks the explicit comparative guidance of a 5.
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 discloses the default PAUSED status and required fields, which is useful. However, it omits what the tool returns (e.g., campaign ID), any conditional requirements beyond the schema, or side effects like which ad account is used. It provides some transparency but not comprehensive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and no filler. Every sentence adds relevant information: creation, default status, required fields, and budget-level flexibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and no annotations, the description is brief. It covers the essentials (default status, required fields, budget placement) but does not explain expected return value, conditional parameter interactions (e.g., bid_strategy vs bid_amount), or how it fits into the broader campaign/adset/ad workflow. The thorough schema compensates partially, but the description alone is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters. The description adds only high-level guidance (name and objective required, budget placement) which is also present in the schema. This meets the baseline but does not meaningfully enrich 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 'Create a new ad campaign' with a specific verb and resource, and adds key distinctions such as defaulting to PAUSED status and requiring name/objective. This differentiates it from sibling tools like create_adset and create_ad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage context: requires name and objective, and notes that budget can be set at campaign or ad set level. This implies when to use campaign-level vs ad-set-level budgeting, but it does not explicitly exclude alternatives or mention 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 provided, the description carries the full burden of behavioral disclosure. It does disclose the key behavior (Meta automatically combines images, videos, titles, bodies, and CTAs), which adds context beyond the tool name. However, it does not mention any side effects, permission requirements, rate limits, or what the return value contains, which is important for a mutation tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first states the purpose with a clear verb and resource, and the second explains the automatic combination behavior. Every word serves a purpose with no 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 description explains the core functionality, but it does not mention what the tool returns (no output schema), prerequisites such as needing to upload assets first, or how to reference those assets in asset_feed_spec. While the schema covers fields, operational details are missing. The context is adequate for a simple create operation, but falls short of complete guidance.
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 description coverage is 100%, with both parameters already documented in detail. The tool description adds a sentence about how the asset_feed_spec arrays (images, videos, titles, bodies, CTAs) are used, complementing the schema but not adding new syntax or parameter-level details. Baseline 3 is appropriate given high 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 clearly states the verb 'Create' and specific resource 'dynamic creative' with the required 'asset_feed_spec'. The second sentence explains what makes it dynamic (Meta auto-combines assets to find best performers), distinguishing it from sibling tools like create_creative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for creating dynamic creatives where Meta automatically tests combinations. However, it does not explicitly state when to use this over create_creative or other alternatives, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the action is irreversible, which is a critical behavioral trait for a delete operation. It does not mention permissions or cascade effects, but for a simple 1-parameter delete, this is sufficient.
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 with no filler. The primary purpose is front-loaded, and the irreversibility warning adds necessary context without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description is complete. It states the action and its irreversible nature, which is all the agent needs to know for correct invocation. The lack of sibling differentiation is a minor gap but does not affect the core completeness for this straightforward delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the single parameter list_id ('Block list ID to delete'), giving 100% schema coverage. The tool description adds nothing beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('publisher block list'), clearly distinguishing it from sibling operations like create_block_list, add_to_block_list, and remove_from_block_list. It also adds the irreversibility warning, further clarifying the action.
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 such as remove_from_block_list. The description only states what the tool does, not the context or exclusions. The irreversibility warning implies caution but does not provide usage direction.
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 verb 'Get' implies a read-only operation, but with no annotations, the description carries the full burden. It does not disclose what fields are returned by default, error behavior, or that it returns a single object. No side effects are mentioned, but the verb suggests none.
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 words. It is appropriately concise for a simple getter 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 is simple with well-documented parameters, but the description lacks context about what 'details' includes, how the fields parameter affects the response, and how it differs from sibling getters like get_campaign_ads. Without an output schema, the description could be more explicit about the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for both parameters (ad_id and fields), so the description need not repeat them. It adds no extra meaning beyond the schema, such as examples or constraints, but the baseline is 3 given the high 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 clearly states the action ('Get'), the resource ('details of a specific ad'), and the identifier ('by ID'). It distinguishes this from sibling list tools like list_ads and get_campaign_ads by emphasizing a single ad lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific ad ID and need its details, which is clear context. However, it does not explicitly mention alternatives or when not to use it, such as using list_ads for multiple ads. No 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?
Discloses pagination and the scope of accessible accounts, but with no annotations, it omits details like authentication requirements, rate limits, or default fields returned. The mention of pagination adds some behavioral context beyond what the schema hints.
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, front-loaded sentences with no wasted words. The key verb and resource appear immediately, and pagination is noted without 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 list tool with no output schema, the description covers the basic purpose and pagination, but doesn't explain the return object structure or differentiate from similar list tools like list_business_ad_accounts. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters (after, limit, fields). The tool description adds no additional semantic meaning beyond what the schema already states.
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 resource ('ad accounts'), and clarifies scope ('accessible by the current user'), distinguishing it from siblings like get_ad_account or list_business_ad_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?
Clearly states the context (all ad accounts accessible by the current user) and that results are paginated, but does not explicitly mention when to use this over 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.
Behavior3/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 the environment variable prerequisite, which is valuable. However, it does not elaborate on return format, pagination behavior, or any access/rate-limit concerns. The disclosure 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 two sentences, front-loads the core purpose, and includes the prerequisite. Every word earns its place with no fluff or repetition.
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 a simple list operation with no output schema. The description explains the purpose and prerequisite, but it does not mention what fields are available via the 'fields' parameter or what the response structure looks like. This is a moderate gap for a tool that supports arbitrary field selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (after, limit, fields) are already well-documented in the schema. The description adds no additional parameter guidance, which is acceptable given the schema coverage. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource combination: 'List Instagram accounts owned by the configured business.' It clearly distinguishes this from sibling tools like list_business_ad_accounts or list_business_pages by naming Instagram accounts explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (when you need Instagram accounts for the configured business) and a crucial prerequisite (requires META_BUSINESS_ID env var). It does not explicitly mention alternatives or when not to use it, but the resource type is specific enough to infer.
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 must carry behavioral disclosure. It does state a configuration dependency and implies a read-only operation via the verb 'list', but it does not describe pagination behavior, default output fields, or error conditions. The schema defines pagination parameters, so the description adds limited additional transparency beyond the verb and prerequisite.
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, immediately states the action, and wastes no words. It includes the essential prerequisite in a compact second sentence, achieving high information density without 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 list tool, the description covers the core purpose and prerequisite, but lacks any indication of the return value structure since there is no output schema. It also does not reference sibling tools or special behaviors like automatic pagination. The schema covers parameters well, but the overall completeness is moderate for an agent needing to understand what it will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 is appropriate. The tool description does not add any parameter-specific meaning beyond what the schema already provides for 'after', 'limit', and 'fields'. Since the schema fully documents the parameters, the description does not need to compensate, but it also adds no extra 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 uses a specific verb 'List' and identifies the resource as 'users of the configured business', making the tool's purpose unmistakable. It distinguishes this from sibling tools like list_account_users by scoping to the business context. The mention of META_BUSINESS_ID further clarifies the target resource.
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 a clear prerequisite (META_BUSINESS_ID env var) which informs when the tool can be used. However, it does not explicitly state when to prefer this over list_account_users or other list tools, nor does it mention situations where an alternative would be more appropriate. The context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses partial update behavior ('only provided fields will be modified'), which is useful, but omits permissions, error handling, and response format, leaving some 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?
Two sentences, front-loaded with purpose, with no wasted words. Efficiently conveys the core function and update semantics.
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 3 params and no output schema. The description covers purpose and partial update behavior, but lacks usage guidance, validation, or error context. Adequate for the low complexity, but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by clarifying that only provided fields are updated, which is not evident from the schema alone and helps the agent understand optional parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing custom audience', distinguishing it from create/delete/get audience tools. 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 when to use the tool (to update an existing audience) but provides no explicit guidance on when not to use it or when to prefer alternatives. The context is clear but no 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 full burden. It discloses the key behavior of partial updates ('only provided fields will be modified'), but does not mention permissions, side effects, or return values. This is a useful but incomplete disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose. The second sentence adds valuable behavioral context 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 9-parameter update tool with no output schema and no annotations, the description provides the core purpose and partial-update behavior. However, it lacks guidance on permissions, return values, or edge cases like status changes to DELETED. Adequate but with 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 100%, so parameters are already well-documented. The description adds general partial-update context but no parameter-specific detail beyond that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing campaign', distinguishing it from create_campaign, delete_campaign, and copy_campaign. The second sentence clarifies partial-update semantics, which further differentiates it from other campaign-related 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 phrase 'existing campaign' clearly implies the tool is for modifying already-created campaigns, and the partial-update note implies it is not for full replacement. However, it does not explicitly name alternatives like create_campaign or delete_campaign or state 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?
With no annotations, the description carries the burden. 'Add... to an existing block list' clearly indicates a mutation, but it does not disclose side effects, idempotency, whether duplicates are allowed, or if changes are reversible. This is minimal but not misleading; it provides the core behavioral trait (adding URLs) but lacks deeper 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, clear sentence with no filler or redundancy. It fully captures the action and scope without 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 two-parameter mutation, the description is adequately complete: it names the action, the resource, and the precondition ('existing'). No output schema is present, so return details are not required. The sibling tools provide additional context for list management, but the description itself is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds extra meaning by specifying 'publisher URLs' (not just any URLs) and 'existing' block list (not creation). This goes beyond the schema's generic 'Block list ID' and 'URLs to block', enriching the semantic context.
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 'Add' and clearly states the resource: 'publisher URLs to an existing block list.' This distinguishes it from sibling tools like create_block_list (new list), remove_from_block_list (removal), and list_block_lists (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing block list' implies the tool is for modifying an already-created list, which gives some context. However, it does not explicitly mention alternatives or when not to use this tool (e.g., use create_block_list if the list doesn't exist). Sibling names provide hints but the description itself offers no direct guidance beyond the implied precondition.
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. It explicitly states the action is irreversible, which is a critical behavioral trait beyond what the schema provides. However, it could mention side effects or authorization requirements, but for a simple delete this is sufficient.
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 with no redundant information. Every word earns its place, making it concise and well-structured.
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 delete operation with one parameter and no output schema, the description covers the essential purpose and the key caveat (irreversibility). While it could mention what happens to related data, the simplicity of the tool makes this adequate.
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 covers the single parameter (audience_id) with a clear description. The tool description adds no additional parameter semantics, but the baseline of 3 applies given 100% 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 clearly states the action ('Delete') and the resource ('a custom audience'), distinguishing it from sibling tools that create, get, list, update, or manage audiences. 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 for when deletion is needed, but does not explicitly state when to use it versus alternatives or provide exclusions. The irreversibility warning hints at caution but does not give context like 'use only if you no longer need the audience'.
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 explicitly notes that the action is irreversible, which is a critical behavioral trait for a destructive operation, especially with no annotations present. However, it omits other behavioral details such as required permissions, behavior if the image is in use, or response/error outcomes, leaving partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the purpose and the irreversible nature of the action, making it maximally concise and well-structured.
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 single-parameter delete operation, the description adequately states the action, the identifier method, and the key consequence (irreversibility). The schema fully documents the parameter, and while no output schema exists, the absence of return details is acceptable for a straightforward delete tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter described as 'Image hash to delete', and the description's 'by hash' simply reiterates this without adding new meaning. Since the schema already documents the parameter clearly, the description adds no extra semantic value, warranting the baseline score.
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 'delete' with the resource 'ad image' and the identifier method 'by hash', clearly distinguishing it from sibling tools like delete_video and delete_canvas. The scope is unambiguous and matches the tool name.
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 that this tool is for deleting ad images by hash, which implicitly excludes videos, canvases, and other resources. However, it does not explicitly name alternatives or state when not to use it, but for a targeted delete operation this is sufficient.
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 convey behavior. It implies a read-only operation but doesn't disclose response format, default fields, or potential errors. The statement is straightforward but minimal, providing basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It states the verb, resource, and differentiator without unnecessary words, 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.
Completeness4/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 with only two parameters and no output schema, the description covers the core need. It lacks extra context like error handling or field selection details, but the low complexity means this is mostly sufficient. A slightly richer description would push it to 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 input schema already provides descriptions for both parameters (campaign_id and fields), so there is 100% coverage. The tool description adds no additional detail about parameter meaning or usage, so the baseline of 3 applies given the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'campaign' and a unique identifier 'by ID'. It immediately distinguishes this from list_campaigns and other get_campaign_* tools (e.g., get_campaign_ads) by focusing on a single campaign's details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is for fetching a single campaign by ID, which implies when to use it versus list_campaigns. However, it doesn't explicitly name alternatives or state when not to use it, so it's clear but lacks formal 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 provided, the description carries the full burden. 'Get details' clearly implies a read-only, non-destructive operation, which is a useful behavioral signal. However, it does not disclose the response format, error behavior (e.g., if the ID is invalid), or any permission requirements. For a simple getter, this is minimal but acceptable, though it leaves some 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 a single, tightly worded sentence that fully conveys the tool's purpose in eight words. It is well front-loaded and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple getter with only two parameters, both fully described in the schema, and no output schema to explain. The description is adequate for an agent to select and invoke it, but it could be slightly more complete by mentioning that 'fields' is optional or that the returned details can be customized. Overall, it is complete enough for its simplicity.
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 description coverage is 100%: both 'fields' and 'creative_id' have explicit descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get details' and the specific resource 'ad creative' with the qualifier 'by ID.' This distinguishes it from sibling tools like 'list_creatives' (which lists all creatives) and 'create_creative'/'update_creative' (which write). 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by ID' clearly implies this tool should be used when a specific creative ID is known, and it contrasts with list-type tools. However, it does not explicitly name alternatives or exclusions like 'use list_creatives to see all creatives,' so it provides clear context but no explicit 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?
No annotations are provided, so the description carries the behavioral disclosure burden. However, for a simple getter, the behavior is straightforward and no side effects or special conditions are expected. The description adds no further context (e.g., error handling, rate limits), but this is not a significant gap for a read-only fetch-by-ID 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 a single, front-loaded sentence that directly states the action and scope. No unnecessary words or repetition. It is exactly as concise as needed.
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 get-by-ID tool with two well-documented parameters and no output schema, the description is sufficient to convey the core functionality. It does not detail the returned fields, but the term 'details' reasonably covers that, and the simplicity of the operation makes additional context unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema; 'by ID' simply restates the prediction_id parameter, and the fields parameter's effect on output is not elaborated, but the schema covers its syntax.
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 resource ('a specific reach & frequency prediction') with an explicit method ('by ID'). It distinguishes this tool from siblings like list_rf_predictions (which lists all predictions) and create_rf_prediction/delete_rf_prediction.
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 have a specific prediction ID and need its details. It does not explicitly mention alternatives or exclusions, but the 'by ID' scope and sibling names make the intended usage clear without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns related interests, behaviors, and demographics, but does not mention whether the operation is read-only, any error handling, or rate limits. This is adequate but leaves 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 two short sentences with no extraneous information. It front-loads the action and adds one clarifying detail about the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description gives a reasonable overview but does not specify return format or limitations. However, for a single-parameter tool, it covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's phrase 'based on existing targeting criteria' reinforces the targeting_list parameter's purpose but adds no new detail beyond the 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 a specific action ('Get') with a specific resource ('targeting suggestions') and clarifies the basis ('existing targeting criteria'). It mentions the types of suggestions (interests, behaviors, demographics), distinguishing it from general search tools like search_targeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have existing targeting criteria and want related suggestions. It does not explicitly exclude alternatives or mention when not to use, 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.
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 disclosing behavior. It mentions the env var requirement and implicitly indicates a read-only operation ('List'), but it does not describe pagination behavior, default fields, or any other side effects or constraints beyond the env var. Adequate basic disclosure but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, resource, scope, and a critical prerequisite. Every word earns its place, with no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and clear parameter documentation, the description is mostly complete. It covers purpose and a key environmental requirement. However, it does not mention pagination or what fields are returned by default, which would be marginally helpful but not essential given the schema and simple nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters (after, limit, fields) are already well-documented. The description adds no additional parameter-specific semantics beyond the env var requirement, which is not a parameter. Baseline 3 is appropriate given the schema handles the details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description contains a specific verb ('List') and resource ('Facebook Pages') with a clear ownership scope ('owned by the configured business'), distinguishing it from sibling tools like list_businesses or list_business_ad_accounts. It is immediately obvious what this 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for listing Facebook Pages associated with the configured business, which establishes when to use it. It also notes the required META_BUSINESS_ID environment variable, a useful prerequisite. However, it does not explicitly mention when not to use it or name alternative tools for similar operations.
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 transparency burden. It discloses the read-only nature implicitly via 'list' and explicitly mentions pagination behavior. However, it omits details like default limit, ordering, and whether any account-level permissions are required. While this is a low-risk read operation, the description could add a bit more 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?
Two sentences, zero redundancy, front-loaded with the core purpose. It effectively conveys the primary function, filtering capabilities, and pagination without 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 list tool with no output schema, the description covers the essential aspects: scope (ad account), filtering options, and pagination. It omits the default return format or field selection behavior, but given the schema's 'fields' parameter and the simplicity of listing, it is sufficiently complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage of all 6 parameters with descriptions and enums (status, objective). The description only repeats that filtering by status and objective is supported, adding no new semantic meaning. The pagination mention aligns with cursor parameters but doesn't explain them further, so the schema is the primary source of 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 tool lists campaigns in the ad account, which is a specific verb+resource. It distinguishes from siblings like get_campaign (single campaign) and list_ads (different resource) by mentioning the ad account scope and filter/pagination capabilities.
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: use this to list campaigns with optional status/objective filters and paginated results. It does not explicitly mention when to avoid using it or alternatives like get_campaign, but the context is unambiguous for a listing operation.
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 the pagination behavior, which is useful, but it does not explicitly state that the operation is read-only/non-destructive or mention any required permissions. The 'List' verb implies safety, but the description could be more transparent about side effects (or lack thereof) and access 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 two concise sentences, with the primary purpose stated first and the pagination behavior as a brief second sentence. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no output schema, the description covers the essential context: what it lists (reach & frequency predictions for the ad account) and pagination. It does not detail the return shape, but this is less critical since the 'fields' parameter allows selection and the sibling get_rf_prediction likely describes the object structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters (after, limit, fields), so the baseline is 3. The description adds no additional parameter semantics, leaving the schema to carry parameter documentation entirely.
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 ('List') and resource ('reach & frequency predictions for the ad account'), distinguishing it from sibling tools like get_rf_prediction, create_rf_prediction, and delete_rf_prediction. The verb and target are 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?
The description provides clear context: it lists all RF predictions for the ad account and notes pagination. However, it does not explicitly mention when to use this tool instead of get_rf_prediction or other list tools, nor does it mention exclusions or alternatives. This is clear context but lacks 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 of behavioral disclosure. It discloses a critical prerequisite (META_BUSINESS_ID) and implies a read-only operation via the verb 'List.' However, it does not mention pagination behavior, response shape, error conditions, or side effects. For a simple list tool this is acceptable but not richly 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?
A single sentence efficiently conveys both the purpose and a key prerequisite. No filler or repetition. Every element earns its place, making it highly concise and well-structured for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 optional params, no output schema) and full schema coverage, the description is sufficient to understand what the tool does and what is required. It does not explain return values, but 'List' reasonably implies a paginated collection, and the schema already covers parameters. Slightly more detail about pagination behavior could make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all three parameters ('after', 'limit', 'fields') with individual descriptions, achieving 100% schema_description_coverage. The tool description adds no extra parameter-level semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and unambiguous: 'List system users of the configured business' uses a clear verb ('List') and resource ('system users') with a defined scope. It distinguishes itself from sibling tools like list_account_users and list_business_users by explicitly naming 'system users' as the target. The prerequisite META_BUSINESS_ID env var is also stated, adding needed 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 lists system users for the configured business and notes the required environment variable. It does not explicitly compare itself to alternatives or state when not to use it, but the scope is well-defined and the prerequisite is a good usage hint. Missing explicit exclusion or alternative guidance keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Remove' implicitly signals a destructive operation, and the env var requirement provides useful context. However, with no annotations, the description does not disclose permissions, reversibility, or side effects, leaving some 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?
A single sentence conveys the action and the key prerequisite with no redundant words. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description and schema together provide sufficient information to select and invoke the tool correctly. The env var requirement is a valuable contextual addition, though it could mention the source of user_id (e.g., from list_business_users) for extra clarity.
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 parameter user_id is fully described in the schema (100% coverage), and the description does not add meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the specific resource ('a user from the configured business'). It distinguishes this tool from siblings like add_business_user and list_business_users, 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?
It identifies the core use case and notes a critical prerequisite (META_BUSINESS_ID env var). However, it does not explicitly mention alternatives or when-not-to-use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 conveys the core behavior—searches by keyword and returns targeting IDs—but does not disclose details about response format, pagination, error behavior, or how the 'type' filter affects results. This is adequate but leaves gaps expected for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action and resource, and includes a practical note about finding valid IDs. Every sentence earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple search tool, and the description covers its main purpose and use case. It lacks mention of the response structure beyond 'valid targeting IDs,' but since no output schema exists, this is a minor gap. The description is mostly complete given the tool's simplicity and high schema coverage.
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 description coverage is 100%, with each parameter (q, type, limit) having its own description. The tool description adds little beyond the schema, only mentioning 'by keyword' which aligns with q. Since the schema already documents the parameters, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for targeting options (interests, behaviors, demographics, etc.) by keyword' and explicitly notes it is used to 'find valid targeting IDs for ad set targeting specs.' This verb+resource+outcome structure distinguishes it from siblings like search_targeting_map and search_locations which have different output or focus.
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 use case: 'Use this to find valid targeting IDs for ad set targeting specs.' This implies when to use the tool, but it does not explicitly mention alternatives or when not to use it. There is no exclusions guidance, but the context is clear enough for an agent to select it for targeting ID lookup.
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 of behavioral disclosure. It implies a non-destructive mapping operation and lists the detail fields, but does not describe the return format, error behavior, permissions, or any limitations. This is a moderate 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 sentence that front-loads the core action and includes a brief usage note. No words are wasted, and it is appropriately sized for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool and lack of output schema, the description sufficiently explains purpose and use case, and partially describes return content (names, types, paths). It does not specify exact response structure or edge cases, but these are less critical here than for a complex mutation tool.
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 already provides 100% coverage of the single parameter ('JSON array of targeting IDs to look up'). The description does not add additional meaning beyond confirming what the IDs are. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Map targeting IDs to their full details') and clearly states the output (names, types, paths). It distinguishes itself from sibling tools like search_targeting by focusing on ID resolution rather than criteria-based search.
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 'Useful for resolving IDs obtained from other endpoints' provides clear context on when to use the tool. However, it does not explicitly name alternative tools or specify when not to use it, which would strengthen 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 behavioral disclosure. It usefully states that only name and url_tags are modifiable, which is a key behavioral constraint. However, it does not mention permissions, error handling, immutability of other fields in practice, or what happens when attempting to modify unmodifiable fields, leaving some transparency 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 just two sentences and contains no fluff. The first sentence states the purpose, the second adds a critical constraint. Every word earns its place, making it highly efficient and front-loaded.
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 3-parameter tool with no output schema or nested objects, the description adequately covers the core operation and its limitations. It does not explain return values or error semantics, but given the low complexity and existing schema, this is not a significant gap. It fully supports correct tool selection among many siblings.
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 already provides 100% description coverage for all three parameters. The description reinforces that only name and url_tags are updatable, which aligns with the schema but does not add significant new meaning beyond what the schema conveys. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact verb 'Update', the resource 'existing ad creative', and the critical constraint that 'only name and url_tags can be modified'. This clearly distinguishes it from create_creative and update_ad, which target different resources or 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 phrase 'after creation' implies when this tool is appropriate (updating an existing creative) and the restriction 'only name and url_tags' tells the agent what can be changed, preventing misuse. However, it does not explicitly name alternatives like create_creative for initial creation or update_ad for ads, so it lacks an explicit when-not statement.
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 the action (upload), the input types, and the return value (hash). However, it does not mention side effects, permissions, file size/format constraints, or whether the upload is synchronous. Basic behavioral info is present, but important operational details are missing.
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 action, and no redundant information. It efficiently states the purpose and the return value without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 optional params, no output schema, no annotations), the description covers the core purpose, input modes, and output hash. It lacks details on supported formats or limits, but those are not essential for basic selection and invocation. The mention of the hash for ad creatives adds useful context for related use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, each having a clear description in the schema. The description reinforces the url/file_path alternatives and the name default, but adds no new meaning beyond what the schema already provides. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Upload' with a clear resource 'ad image' and distinguishes itself from siblings by stating the two source methods (public URL or local file path). It also specifies the output (image hash for ad creatives), making it unambiguous and distinct from upload_video.
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 when to use it: when you need to upload an image for ad creatives. It does not explicitly name alternatives or exclusions, but the word 'image' differentiates it from video uploads, and the output mention ties to creative creation. No when-not guidance is given, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of indicating the operation type. 'Get details' clearly signals a read-only operation with no side effects. While it does not discuss authentication or rate limits, these are not critical for a simple getter and the read-only nature 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?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and resource, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with only two parameters and no output schema, the description is complete. It covers the essential purpose and scope without needing to elaborate on return values or complex behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (canvas_id and fields) with 100% coverage. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get details') with a clear resource ('specific Instant Experience (Canvas)') and scope ('by ID'). This distinguishes it from sibling tools like list_canvases, create_canvas, and delete_canvas.
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 have a specific canvas ID, but it does not explicitly mention when to use it versus alternatives like list_canvases. The context is clear but lacks explicit exclusions or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavioral trait of being asynchronous and explains the polling workflow via report_run_id. It lacks details on report lifecycle or failure modes, but for a tool whose primary behavior is async creation and polling, this is substantial transparency. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word contributes value. There is no redundancy or vague filler, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking annotations and an output schema, the description completes the core workflow by telling the agent to poll with get_async_report. With 7 optional parameters all documented in the schema, the description provides enough context for basic usage, though it leaves details like report completion timing to the companion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all seven parameters already have descriptions in the input schema. The tool description adds no extra parameter-level meaning beyond naming the resource, and the schema fully documents semantics. Therefore, a baseline score of 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an async insight report for large data queries, using a specific verb and resource. It distinguishes itself from the sibling get_async_report by explaining it returns a report_run_id to poll with that tool, 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?
It provides clear context for when to use this tool ('for large data queries') and directs the agent to the next step using get_async_report. However, it does not explicitly mention when not to use synchronous insight tools or provide alternatives other than the polling tool, so a 4 is appropriate.
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 discloses pagination behavior ('Returns paginated results') and implicitly states read-only nature via 'List', and scopes access. It does not mention rate limits or ordering, but for a simple read operation this is reasonable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the purpose and includes essential behavioral info (pagination). No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema; the description adequately covers what it does and that results are paginated. It does not detail the return object shape or ordering, but these are less critical for a low-complexity list tool that is clearly scoped. It could mention that it returns business objects, but the name implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all three parameters (after, limit, fields) with clear descriptions. The tool description adds only the pagination detail that maps to 'after' and 'limit', but does not add new semantic value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all businesses accessible by the current user'), clearly distinguishing it from sibling tools like get_business (singular), list_business_ad_accounts, and list_business_users. The scope and pagination note make 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 gives clear context—'all businesses accessible by the current user'—which indicates the tool’s scope. However, it does not explicitly state when to prefer this over alternatives like get_business for a single entity, or other list tools, though the context is sufficient for most agents.
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 behavioral burden. It discloses the partial-update behavior ('Only provided fields will be modified'), which is important for a mutation tool. However, it does not mention permissions, validation, or what happens if no fields are supplied, 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 extremely concise: two sentences with no redundant information. It front-loads the purpose and immediately follows with the key behavioral caveat.
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 three optional parameters and no output schema, the description covers the essential purpose and update semantics. The only notable gap is the ambiguous 'configured' account—it does not explain how the account is selected or referenced, but this may be handled at a higher level. Overall, it is sufficiently 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 already provides high coverage (100%) with clear descriptions for each parameter (name, spend_cap, timezone_name), so the baseline is 3. The description enhances understanding by clarifying that all parameters are optional and only those explicitly provided will be updated, adding semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Update the configured ad account settings.' It also adds a key distinguishing detail ('Only provided fields will be modified') that prevents confusion with full-replacement or other update 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 context (for updating ad account settings) but does not explicitly mention alternatives or when not to use it. The word 'configured' hints at a pre-selected account, but there is no guidance on prerequisites or comparison with sibling tools like get_ad_account.
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?
The description discloses a key behavioral trait: 'Only provided fields will be modified', indicating partial-update semantics. Since no annotations are provided, this is essential context. However, it does not mention validation, authorization, or what happens if the schedule_id 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 two short sentences, front-loaded with the primary purpose, and contains no filler. Every word contributes to understanding the tool's function and behavior.
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 relatively simple update operation, the description covers the essential purpose and partial-update behavior. No output schema exists, but that is not a major gap for an update tool. It could mention the response format or error conditions, but the current description is adequate for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already described. The description adds value by clarifying the update behavior for optional fields ('Only provided fields will be modified'), which is not explicitly stated in the schema. This helps the agent understand that omitting fields is intentional.
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 an existing budget schedule') with a specific verb and resource. It distinguishes from sibling tools like create_budget_schedule and delete_budget_schedule by implying modification of an existing entity.
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 'existing' implies this is for modifying schedules that already exist, not for creating new ones. The sibling tool names (create_budget_schedule, delete_budget_schedule) provide context, but the description does not explicitly name alternatives or state 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.

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-patched MCP server](https://glama.ai/mcp/servers/Green-pep/meta-ads-mcp-patched/badges/card.svg)](https://glama.ai/mcp/servers/Green-pep/meta-ads-mcp-patched)

Score Badge

Copy to your README.md:

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

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/Green-pep/meta-ads-mcp-patched'

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