chatgpt-ads-manager-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly scoped to specific resources and actions (campaign vs ad group vs ad, pause vs activate vs archive). The main boundary blur is between get_audience_operation and poll_audience_operation, which both serve the same polling purpose, and create_campaign_hierarchy partially duplicates the create_campaign/create_ad_group/create_ad sequence.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern using snake_case throughout, e.g., list_campaigns, get_campaign, create_campaign, update_campaign, pause_campaign, archive_campaign. Even longer names like create_ad_account_spend_limit_window remain predictable.
Tool Count1/5
89 tools is an extreme count, far exceeding the 50+ threshold for a cohesive tool set. While the domain is broad, several helpers like poll_audience_operation and create_campaign_hierarchy inflate the surface without adding distinct capabilities.
Completeness3/5
Core ad account, campaign, ad group, ad, audience, and lead form lifecycles are well covered. However, some subdomains are incomplete: conversion pixels/event settings have no update or delete, business agents cannot be archived/deleted, and lead-sync subscriptions lack update support.
Average 3.7/5 across 89 of 89 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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 carries the full burden of behavioral disclosure. It only states that an update occurs and does not explain whether the update is partial or full, what fields can be modified, whether status changes have side effects, or what response to expect. This is minimal transparency 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, focused sentence with no wasted words. It is front-loaded and easy to parse, though its brevity contributes to the lack of semantic depth in other dimensions.
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?
For a tool with 9 parameters, nested objects, an enum, no output schema, and no annotations, this description is far too incomplete. It does not explain which fields may be updated, how status interacts with dedicated status tools, or what configuration objects like bidding_config and landing_page_configuration contain, leaving agents without enough context to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, with 8 of 9 parameters undocumented. The description adds no meaning for name, status, description, product_set, ad_account_id, context_hints, bidding_config, or landing_page_configuration. The only hint, 'by ID,' merely reinforces the required ad_group_id field already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as updating an ad group, identified by ID. It distinguishes the tool from list/get/create operations but does not differentiate it from sibling tools like pause_ad_group, activate_ad_group, or archive_ad_group, which are also ad group modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use update_ad_group versus pause_ad_group, activate_ad_group, archive_ad_group, or even update_campaign. An agent is left to infer the appropriate context from the tool name and parameter schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that archiving is 'terminal', which suggests irreversibility, but it does not explain what happens to associated ads, whether the action can be undone, or what side effects may occur.
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 extremely short and contains no filler, but it is under-specified rather than efficiently complete. Every word earns its place, yet the brevity sacrifices important behavioral and usage information.
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 mutating, terminal operation with no annotations and no output schema, the description provides only minimal context. An agent still lacks information about consequences, required authorization, and how this differs from pausing or deactivating an ad group.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: ad_group_id is described as 'Ad group ID' but ad_account_id has no description. The tool description does not compensate for the undocumented parameter or clarify whether ad_account_id is optional or how it relates to the archive operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (archive) and the resource (ad group), and the parenthetical '(terminal)' hints at the irreversible nature. It does not explicitly differentiate from sibling tools like pause_ad_group or activate_ad_group, so it loses a point for lack of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to archive an ad group versus using pause_ad_group, activate_ad_group, or other lifecycle tools. The word 'terminal' implies finality but does not explain use cases, prerequisites, 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 of behavioral disclosure. It reveals only that archiving produces a 'terminal' state and does not state whether the operation is reversible, whether the ad must be in a particular state first, or what side effects occur on the parent campaign. The '(terminal)' hint is a start but leaves most behavioral questions unanswered.
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 one short, front-loaded sentence with no filler. However, it borders on under-specification — the unexplained '(terminal)' parenthetical could be replaced with a plain behavioral disclosure that would serve agents better without adding noticeable bulk.
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 state-changing mutation with no annotations and no output schema, yet its entire description is six words. An agent cannot determine reversibility, prerequisites, return behavior, or how the operation differs from pause_ad — the description is incomplete for safe 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 only 50%: ad_id's schema description is the tautological 'Ad ID.', and ad_account_id has no description at all. The tool description mentions neither parameter, so nothing clarifies what ad_account_id is for or whether it affects invocation.
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 ('Archive') with a clear resource ('an ad'), which distinguishes the action from sibling lifecycle tools like pause_ad, activate_ad, and update_ad. The parenthetical '(terminal)' hints at an end-state operation but is ambiguous — an agent must infer whether it means irreversibility, a lifecycle stage, or both.
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 archive versus using lifecycle siblings such as pause_ad, activate_ad, or archive_campaign. An agent choosing among pause/activate/archive receives no selection criteria, 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?
There are no annotations, so the description must carry the full transparency burden. It merely says 'List', implying a read-only operation, but it does not disclose whether archived lead forms are included, pagination behavior, ordering, or how missing/invalid ad_account_id is handled.
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 redundant words. It is appropriately concise for what it states, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is simple and there is no output schema, so the description should fill gaps about return values, pagination, and optional/required behavior of ad_account_id. It does none of that, leaving an agent with insufficient information to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'for the ad account' which adds little beyond the parameter name 'ad_account_id'. It does not explain the parameter format, whether it is optional, or which account is used if omitted.
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 has a specific verb ('List') and a clear resource ('Lead Forms') plus the ad-account scope, making the operation identifiable. It doesn't explicitly differentiate from sibling tools like get_lead_form or list_lead_sync_subscriptions, but the resource name is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_lead_form, create_lead_form, or list_lead_sync_subscriptions. The intended use is only implied by the word 'List' and the resource 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 the full burden of behavioral disclosure. It only says 'activate' and 'paused' without explaining prerequisites, consequences, reversibility, idempotency, or failure behavior. The state qualifier is mildly informative but far from sufficient.
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. The word 'paused' earns its place by clarifying the target state. It is concise, though it sacrifices behavioral and contextual 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 is a mutating tool with no annotations and no output schema. The one-line description does not explain preconditions such as whether the ad group must exist and be paused, what happens after activation, or whether ad_account_id is needed. An agent is not given enough context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%; ad_account_id has no schema description and the tool description does not mention it. The description adds no meaning to the parameters beyond what the schema already provides, so it fails to compensate for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Activate a paused ad group.' This clearly identifies the operation and narrows the target state to paused ad groups, though it does not explicitly call out sibling tools such as activate_campaign or pause_ad_group.
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 qualifier 'paused' implies this tool should be used when an ad group is currently paused, but there is no explicit when-to-use guidance, no mention of alternatives, and no statement about when this tool should not be used.
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 'list' and restates the required parameter, but discloses nothing about pagination, result format, read-only behavior, or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with no wasted words. However, the second sentence mostly restates the schema requirement rather than adding new decision-relevant 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 one-parameter list tool, this is minimally viable for invocation. But with no annotations and no output schema, it lacks useful context such as pagination behavior, return shape, or when to prefer this over get_lead_sync_subscription.
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 schema already fully documents ad_account_id. The description adds little beyond repeating that it is a required query param, which is the baseline behavior for high 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 action ('List'), the resource ('lead-sync subscriptions'), and the scope ('for an ad account'). It is distinguishable from the get/create/delete lead-sync siblings by context, though it does not explicitly differentiate itself from get_lead_sync_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given versus alternatives like get_lead_sync_subscription, create_lead_sync_subscription, or delete_lead_sync_subscription. The 'Requires ad_account_id query param' note is a parameter constraint, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It mentions that the ad should be active, but does not disclose side effects such as stopping delivery, changing status, idempotency, or whether pausing is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. It could be slightly expanded with usage guidance without becoming bloated, but as written it is clear and efficiently structured.
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 mutating tool with no annotations and no output schema, the description is too thin. It omits lifecycle context, alternate actions, account scoping, and expected outcome, leaving an agent with insufficient information to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: ad_id is minimally described, while ad_account_id has no description at all. The tool description adds no parameter-level meaning, so an agent cannot determine the role, optionality, or constraints of ad_account_id from the definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('pause') and resource ('ad'), and the qualifier 'active' clarifies the intended target state. This clearly distinguishes it from sibling tools like pause_ad_account, pause_campaign, or archive_ad.
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 activate_ad, archive_ad, pause_campaign, or pause_ad_account. It states what the tool does, but not when it should be chosen over related lifecycle 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 must carry the behavioral burden, but it only states the action. It does not disclose side effects, reversibility, permission requirements, idempotency, or what happens to related entities such as ads.
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, economical sentence with no filler. It is concise, though this conciseness comes at the cost of missing useful contextual details scored elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, and the description provides only a minimal purpose statement. It does not explain prerequisites, the role of ad_account_id, effect on the ad group's ads, or what response to expect, so an agent has too little context to invoke it confidently.
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?
Only 50% of parameters have schema descriptions, and the one description ('Ad group ID.') is largely tautological. The description adds no meaning for either parameter and completely ignores ad_account_id, leaving its purpose and optionality unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Pause') and resource ('active ad group'), which precisely identifies the operation and differentiates it from sibling tools like pause_ad_account, pause_campaign, and pause_ad.
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 such as archiving, deactivating, or pausing at a different hierarchy level. The word 'active' hints at a precondition, but no explicit when-to-use or when-not-to-use direction is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It conveys that this is a read-only list operation, but it does not disclose pagination behavior, ordering/defaults, scoping semantics, or what the returned settings represent beyond the name. This leaves meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with the primary purpose stated in the first sentence. The second sentence adds usable downstream context, though it is a bit cryptic; overall it avoids waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, 0% schema coverage, no annotations, and no output schema, the description is not complete enough. It provides the core purpose and a use case, but leaves pagination parameters, return shape, and potential filtering semantics unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the five undocumented parameters. It only echoes the 'ad account' concept and vaguely refers to output IDs, but says nothing about `after`, `before`, `limit`, or `order`. No added semantic meaning beyond the bare schema property names is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('conversion event settings'), and the scope ('for the ad account'). This is specific enough to distinguish it from siblings like 'list_conversion_events' and 'create_conversion_event_setting'.
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 gives a practical downstream context: the returned IDs should be used with 'campaign conversion_event_setting_ids' and 'conversions bidding'. However, it does not explicitly explain when to choose this tool over sibling tools such as 'list_conversion_events', so the when-to-use 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?
No annotations are provided, so the description carries the full burden. It implies a read-only operation (listing) but does not explicitly state that it has no side effects, nor does it disclose pagination, ordering, rate limits, or response size. The vague 'etc.' adds little. For a listing tool, this lack of behavioral detail leaves significant uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently conveys the core action and resource. The inclusion of 'etc.' is somewhat vague and could be seen as unnecessary, but overall it is concise and well-structured. Minor deduction for the ambiguous trailing phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description provides a basic overview but is incomplete. It mentions the fields returned (id, name, status) but omits pagination, default behavior, whether ad_account_id is mandatory, and any other response details. Given the lack of output schema and minimal parameter info, more explanation is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (ad_account_id) with no description, and schema description coverage is 0%. The description mentions 'the ad account' but does not explain the parameter's purpose, format, or whether it is required (context shows required=0). The description adds minimal value beyond the schema's property name, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('Business Agents') scoped to the ad account. It mentions key fields (id, name, status) and naturally distinguishes from singular operations like get_business_agent or mutation tools like publish_business_agent. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of when to list all agents versus retrieving a single one via get_business_agent, nor any context about prerequisites or typical usage scenarios. The description fails to differentiate from sibling tools, leaving the agent to infer 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?
No annotations are provided, so the description must carry the behavioral transparency burden. The only behavioral hint is that results include feed_id values for downstream tools. It does not disclose pagination behavior, ordering defaults, response shape, ad account requirements, authentication expectations, or any side effects. This is a minimal disclosure for a tool with six pagination and filtering parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences, no filler, and the second sentence adds a valuable routing hint for using feed_id downstream. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no output schema or annotations, the description is too incomplete. It fails to explain pagination semantics, parameter meanings, default values, return format, or any constraints. The single downstream hint about feed_id is useful, but overall the agent has insufficient context to use the tool well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the six parameters. It only mentions 'ad account' and 'feed_id' conceptually, which loosely maps to ad_account_id and the output, but after, limit, order, before, and include are entirely unexplained. With 0% schema coverage, this is a serious gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'List product feeds for the ad account.' It also signals the tool's role as a discovery step by saying 'Use feed_id with query/patch/sftp tools,' which helps distinguish it from other product-feed-related tools like list_product_feed_uploads. It could be slightly stronger by explicitly naming sibling distinctions, but the purpose is clear.
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 actionable context: after listing, the returned feed_id should be used with query/patch/sftp tools. This implies when this tool is the right entry point for feed management. However, it does not explicitly state when not to use it or compare it with list_product_feed_uploads or other list 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, and it reveals nothing beyond the basic operation. It does not mention pagination cursors, limits, sorting, filtering, segmentation behavior, or the fact that time_ranges is required for conversion insights. The agent gets no safety or behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the core scoping statement front-loaded and zero filler. The chaining instruction is efficient and earns its place. The terseness is borderline under-specification rather than deliberate density, but structurally this is clean and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters, no output schema, and no annotations, the description is far too thin. An agent gets no sense of which metrics are returned, how pagination works, what behavioral caveats apply, or how this differs from the other three insights tools. The burden shifts entirely to the parameter schema, which is insufficient for confident selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 79%, so the schema documents most parameters. The description adds real value for the one required parameter by specifying that ad_group_id should come from list_ad_groups, which is more meaningful than the schema's generic 'Ad group ID.' This provenance hint compensates for the few undocumented parameters and helps the agent assemble a correct call.
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 verb 'Get' plus resource 'ad group insights' states the operation precisely, and the ad-group scope differentiates it from sibling tools like get_campaign_insights, get_ad_insights, and get_ad_account_insights. The chaining hint reinforces the target resource. It is clear and specific, though it does not name sibling alternatives explicitly as the strongest definitions do.
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 'Chain from list_ad_groups -> ad_group_id' line gives a concrete prerequisite and data source for the required parameter, providing implied usage guidance. However, it does not state when to choose this over the sibling insights tools, nor does it mention any exclusions or conditions, leaving the choice largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose two meaningful behaviors: it creates a new draft revision and uses expected_draft_revision_id for conflict detection. However, it does not explain what happens on a conflict, whether changes are reversible, or other side effects of saving the revision.
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, no fluff, and the main purpose is front-loaded. The second sentence adds a genuine prerequisite that is not obvious from the schema alone. 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?
The tool is a non-trivial mutation with seven parameters, no output schema, and no annotations, and the description only covers one parameter and the core action. It lacks context about what the call returns, how conflicts are surfaced, or the workflow relationship with get_lead_form and publish_lead_form. This is not enough for an agent to call it with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, so the description was expected to compensate for the seven parameters. It adds semantics only for expected_draft_revision_id ('conflict detection'), while important parameters like fields, privacy_policy_url, ad_account_id, name, and description receive no explanatory help in the tool description.
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 action ('Save a new draft revision') and the resource ('Lead Form'), which is distinct from related siblings like create_lead_form, publish_lead_form, or archive_lead_form. However, it does not explicitly name or contrast alternative siblings, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement for expected_draft_revision_id gives some context for using the tool correctly, but the description does not state when to prefer this over create_lead_form or get_lead_form, nor any exclusions. Usage is implied from 'draft revision' but not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states the activation and resumption of ingestion, but does not mention preconditions, idempotency, side effects on already-active feeds, or whether credentials or specific permissions are required. Minimal behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word adds meaning, and the key action and outcome are immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an undocumented optional parameter, the description is too sparse. It does not clarify the prerequisite relationship with create_product_feed_sftp_access, whether ad_account_id must be supplied in some contexts, or what happens if the SFTP access is already active.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: feed_id is documented as 'Product feed ID', but ad_account_id has no description. The tool description does not mention either parameter or clarify when ad_account_id is needed, so it fails to compensate for the undocumented 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 a specific verb ('Activate') with a clear resource ('SFTP access for a product feed') and adds the behavioral outcome '(resume ingestion)'. This clearly distinguishes it from sibling tools like pause_product_feed_sftp_access and get_product_feed_sftp_access.
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 '(resume ingestion)' implies this is used after pausing, providing some contextual guidance. However, there is no explicit statement of when to use this versus create_product_feed_sftp_access or pause_product_feed_sftp_access, nor any mention of prerequisites like the existence of SFTP access created beforehand.
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 usefully reveals the asynchronous creation pattern (returns an upload id for polling), but does not disclose side effects, whether processing begins immediately, failure modes, or permission requirements. It adds one meaningful behavioral trait while leaving several 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?
Two sentences, roughly 23 words, with the verb and resource front-loaded. Sentence one states the purpose; sentence two discloses the return value and the follow-up polling workflow. Every word earns its place with no filler 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 3-parameter tool with no annotations and no output schema, the description covers the return value but omits prerequisites and parameter selection logic. The schema lists all parameters as optional, yet a real call requires at least some of them; the description does not clarify which combinations are valid or that file_id likely references a file uploaded via a sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% with ad_account_id completely undocumented, and the description adds no parameter-level meaning whatsoever. It does not explain how file_id, upload_type, and ad_account_id relate to each other, nor which combinations are valid. Given the partial coverage gap, the description should compensate for the undocumented parameter but fails to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Create an Ads partner-data upload') and clarifies the partner-integration context. The polling reference to get_partner_data_upload anchors the tool in a recognizable workflow, though it does not explicitly differentiate it from adjacent upload operations like upload_image or upload_audience_file.
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 context is implied through the parenthetical '(for partner integrations)' and the follow-up workflow hint 'Returns upload id for polling via get_partner_data_upload'. However, there is no explicit guidance on when to choose this tool over alternatives, no when-not-to-use conditions, and no mention of the likely prerequisite that a file must first be uploaded via a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure, and 'Get' does communicate a read-only operation. However, it does not mention response shape, archived/deleted ad group behavior, or any 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 one short, front-loaded sentence with no filler. Every word contributes to the core meaning.
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 3-parameter tool with no output schema, the description is thin. It omits any context around the include array and ad_account_id, and does not state when an agent should prefer this over listing ad groups or fetching related insights.
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 only 33%, and the description adds no meaning beyond what the schema already states for ad_group_id. The include and ad_account_id parameters remain entirely unexplained, so agents cannot confidently determine how to populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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'), a specific resource ('ad group'), and a precise scope ('single ... by ID'). This clearly distinguishes it from siblings like list_ad_groups and get_ad without requiring the agent to inspect schemas.
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, or whether ad_account_id is needed for scoping. The agent must infer usage solely from the tool name and ID-based phrasing.
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 transparency. It only says 'Get' (implying a read operation) but does not disclose any potential side effects, default behaviors, return format, pagination handling, or error conditions. Given the tool's complexity (14 parameters, no output schema), the description is severely lacking in behavioral disclosure. It adds almost no value beyond stating the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two short sentences with no filler. The main purpose is front-loaded, clearly stating the tool's function immediately. Every word contributes to understanding what the tool does. There is no redundant or irrelevant information, making it an exemplar of 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?
Despite having 14 parameters and no output schema, the description provides minimal context. It does not explain what fields are returned by default, how to use filters, segments, time_ranges, or how pagination works. The description is far from complete for an API of this complexity. Agents would need to rely heavily on the schema and external documentation, and the description does not bridge any gaps. Given the absence of output schema and annotations, the description is insufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description makes no mention of any parameters, so it adds no semantic value to the input schema. Schema description coverage is 79%, which is moderate but not high enough to give baseline 3. Several parameters (e.g., includes, override_segment_group_order) lack descriptions in the schema, and the tool description does not compensate by explaining them. The description fails to help users understand parameter relationships or usage context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get ad insights for a single ad. Check creative-level performance.' It uses a specific verb (Get) and resource (ad insights), and explicitly scopes to a single ad with a focus on creative-level performance. This distinguishes it from sibling insight tools like get_ad_account_insights or get_campaign_insights, which target different levels. No ambiguity remains about 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'single ad' and 'creative-level performance,' which suggests it is for ad-level insights. However, it does not explicitly state when to use this tool versus alternatives like get_campaign_insights or get_ad_group_insights. No explicit 'when not to use' or references to sibling tools are provided. The usage guidance is implicit rather than explicit, making it adequate but not strong.
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 present, the description carries the full burden of behavioral disclosure. It adds some value by specifying 'recent' and 'ingestion history,' implying a time-scoped, historical read operation. But it does not describe pagination semantics, default ordering, ad account scoping, or response shape, which are important behavioral details for a listing 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 wording, and the primary action is stated immediately. It is concise, though the shortness contributes to missing parameter and behavioral details.
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 4 undocumented optional parameters, no output schema, and no annotations, this description is insufficient for an agent to invoke the tool confidently. It communicates the high-level purpose but leaves crucial invocation details such as pagination parameters, account scoping, and return format unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any of the four parameters (`after`, `limit`, `before`, `ad_account_id`). The word 'recent' weakly implies time-based filtering relevant to `before`/`after`, but no parameter-level meaning is provided.
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 names the resource ('product feed uploads') and adds useful context ('ingestion history'), making its purpose immediately understandable. It stops short of a 5 because it does not explicitly differentiate this tool from the closely related sibling `list_product_feeds`, though the focus on uploads/history makes the distinction recoverable.
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 to debug catalog fetch issues' gives a concrete, actionable use case, which is clear contextual guidance for an agent. However, it does not mention when not to use this tool or name any alternatives, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It reveals the action and one post-condition, but does not mention irreversibility, side effects, permission requirements, or what happens to an already-published form.
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 with the primary action front-loaded. Every word contributes meaning and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description needs to explain enough for a correct call. It omits what ad_account_id is for and does not state expected behavior on success or failure, leaving meaningful gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes lead_form_id only as 'Lead form ID.' and leaves ad_account_id completely undescribed. The description does not compensate for this gap or clarify the role of either parameter, especially ad_account_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action 'publish' and the resource 'Lead Form draft,' and clarifies the intended consequence: the form can then be attached to a Business Agent. This separates it from sibling tools like create_lead_form, update_lead_form, and publish_business_agent.
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: publish a draft lead form before attaching it to a Business Agent. However, it does not explicitly state when not to use this tool, what prerequisites exist, or how it compares to update_lead_form or create_test_lead_submission.
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 important partial-update behavior: 'Only provided fields are updated.' However, it does not mention permissions, validation side effects, reversibility, or what happens when ad_account_id is changed, which leaves meaningful gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The core action is front-loaded, and the second sentence adds a critical semantic detail about partial updates. It is appropriately concise for a simple update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, a nested creative object, no output schema, and no annotations, yet the description only covers the basic update action and partial-update behavior. It omits parameter semantics, usage guidance against status-specific siblings, and any behavioral context for a mutation operation. The description is too sparse to fully prepare an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, with ad_id being the only documented parameter. The description adds no semantic detail beyond 'by ID' and 'only provided fields,' so it does not compensate for the heavily undocumented schema. Parameters like creative, description, status, and ad_account_id have almost no explanatory 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 states a specific verb ('Update'), a specific resource ('an ad'), and the addressing mechanism ('by ID'). The phrase 'Only provided fields are updated' clarifies that this is a partial update, which clearly distinguishes it from create_ad and from status-specific tools like activate_ad, pause_ad, and archive_ad.
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 about when to use this tool versus sibling alternatives. In particular, the tool can update the status field, but the description does not explain how this should be chosen over activate_ad, pause_ad, or archive_ad for status changes. The context is implied by the resource type but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates a read operation via 'Get', which implies non-destructive behavior, but it does not describe response characteristics, error conditions, or how the optional ad_account_id affects the lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core operation and resource scope.
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, the description is minimally adequate, but it omits the role of ad_account_id and any expected output or error behavior. Given no output schema and no annotations, the definition leaves some operational context to be inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with subscription_id documented as 'leadsync_...', but ad_account_id has no description. The tool description adds no meaning beyond referencing 'by ID', so it does not compensate for the undocumented 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 states a specific verb ('Get') and resource ('lead-sync subscription') with a clear scope ('by ID'). It is immediately distinguishable from the sibling tools list_lead_sync_subscriptions, create_lead_sync_subscription, and delete_lead_sync_subscription, all of which imply 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 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 list_lead_sync_subscriptions for enumeration or create_lead_sync_subscription for new subscriptions. The 'by ID' phrasing implies targeted retrieval, but no explicit context or exclusions are given.
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 disclosure burden. It discloses pagination and the memberships_revision return field, and 'List' implies a read-only operation. However, it doesn't disclose account scoping (whether ad_account_id is required), authentication needs, or pagination mechanics.
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?
Four short sentenses with no wasted words; the core purpose is front-loaded and each sentence adds distinct information (filters, return field, pagination). Slightly choppy phrasing around 'policy_revision for eligibility' keeps it from top marks.
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 list tool with no annotations and no output schema, the description covers core behaviors but leaves ambiguity about account scoping, pagination cursor semantics, and matched_count_granularity. An agent can call it correctly for basic cases but may need to probe for edge details.
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 only 33% (3 of 9 parameters documented), so the description must compensate. It adds meaning for intended_use, ids (mapping to custom_audience_ids), and policy_revision ('for eligibility'), but leaves ad_account_id, the pagination cursors (before/after/limit/order), and matched_count_granularity without explanatory value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List custom audiences') and names the filter dimensions (intended_use, ids, policy_revision). It does not explicitly contrast with siblings such as get_custom_audience, but its list/scoping purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool — to list/filter audiences and to obtain membership_revision for later mutations — but provides no explicit exclusions or alternative routing (e.g., 'use get_custom_audience for a single audience'). Guidance is present but left to 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 of behavioral disclosure. It states the primary effect ('stop ingestion') but does not mention whether the action is reversible, what permissions are required, whether existing active sessions or credentials are affected, or what the result/response looks like. For a mutating operation 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, front-loads the action and resource, and contains no filler. It is concise without sacrificing the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is minimally adequate, but it omits guidance about the optional ad_account_id and does not mention related next steps such as using activate_product_feed_sftp_access to resume. There is no request/response context, which leaves the tool not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: feed_id is described in the schema, but ad_account_id has no schema description, and the tool description adds no parameter information at all. The description does not compensate for the undocumented ad_account_id parameter, so an agent is left without meaning for 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 uses a specific verb and resource: 'Pause SFTP access for a product feed', with the clarifying parenthetical '(stop ingestion)' making the exact effect clear. This distinguishes it from sibling tools like activate_product_feed_sftp_access, get_product_feed_sftp_access, and other pause_* tools for 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 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 halt SFTP ingestion for a product feed, but it does not explicitly state when not to use it or mention alternatives (e.g., activating to resume, or get to check current state). No exclusions or differentiating conditions are given, leaving usage largely to 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?
No annotations are present, so the description carries the full burden of disclosing behavioral traits. It does not mention whether archiving is reversible, what status changes occur, any permission requirements, or what happens if the condition is violated. The 'not attached' constraint is useful but does not cover the behavioral consequences of the mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that wastes no words. It conveys the key action, resource, and a necessary precondition without 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?
For a mutation tool with no annotations and no output schema, the description is too thin. It omits the role of ad_account_id, the effects of archiving, and any prerequisites beyond the published Business Agent condition. An agent would likely need to infer or discover additional context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%; lead_form_id has a minimal description ('Lead form ID.') while ad_account_id has no description. The tool description does not explain the purpose of either parameter or how they relate to the archiving operation, leaving ad_account_id entirely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Archive') and resource ('Lead Form'), with a precise condition ('not attached to a published Business Agent') that distinguishes it from related lead form operations like publish_lead_form, update_lead_form, and list_lead_forms. The scope is immediately clear.
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 applicability condition: only archive lead forms not attached to a published Business Agent. This implicitly tells the agent when the tool is appropriate, though it 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses useful traits beyond the schema: the return contract (campaign_id) and idempotency behavior for retry safety. For a mutating, potentially billing-impacting tool, it does not disclose prerequisites, side effects, or reversal options, but the two disclosed behaviors are genuinely informative and not derivable from structured fields.
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?
Three short sentences, front-loaded with the primary action, then the return-value chain, then idempotency. Some mild redundancy: 'Returns campaign_id for chaining to create_ad_group' and 'Common next: create_ad_group with campaign_id' convey the same idea twice. Otherwise no waste.
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 17-parameter tool with nested targeting objects and no output schema, the description is sparse but compensates through a rich 94%-coverage schema. It supplies the critical orchestration knowledge (what to do with the returned id, retry-safety) that the schema cannot. Not exhaustive about conditional constraints like mode vs product_feed_id/business_agent_id, but the schema carries those.
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 94%, so the schema already documents nearly every parameter; baseline is 3. The description adds marginal value by explaining the idempotency key's purpose (avoid duplicates on retry), which reinforces rather than repeats the schema text. No critical parameter meaning is left unexplained.
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?
States a specific verb+resource ('Create a campaign') that is unambiguous among siblings like update_campaign, activate_campaign, pause_campaign, and archive_campaign. Adds a workflow hint ('Returns campaign_id for chaining to create_ad_group') that anchors its role. Does not explicitly delimit against create_campaign_hierarchy, but the singular 'a campaign' plus the create_ad_group chain makes the core purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context ('Common next: create_ad_group with campaign_id') that situates this as the entry point of a creation pipeline. However, it never states when to choose this over create_campaign_hierarchy, update_campaign, or the activate/pause tools, and gives no exclusion conditions. The guidance is suggestive rather than directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It usefully discloses the returned api_key, the single-display nature, and the secure-storage requirement. It does not mention permissions, revocability, or consequences of creating multiple keys, which leaves some gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry purpose, usage context, return value, and a security warning with no filler. The most important information is front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core invocation context is present: what is created, for whom, why, and what to do with the result. Gaps remain around the ad_account_id parameter semantics and the precise relationship to the sibling create_api_key, but the description is adequate for a low-complexity creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the name parameter, but ad_account_id has no schema description. The description says 'for the ad account' without explicitly mapping that to ad_account_id or explaining whether it is optional/defaulted. With only 50% schema coverage, the description should compensate more heavily and does not.
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 operation as creating a Conversions API key for an ad account, and adds the distinguishing purpose of sending server-side events via bzr.openai.com outside this MCP. It does not explicitly contrast itself with the sibling create_api_key, but the 'Conversions API key' scope provides reasonable differentiation.
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: use this tool when you need a Conversions API key for server-side events outside the MCP. It does not state when not to use it or explicitly name the create_api_key alternative, but the external-sending context is sufficient for basic routing.
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 key behavioral effect of deletion—stopping webhook delivery—which is useful. But with no annotations, it omits other important behavioral details such as irreversibility, permission requirements, or side effects on other resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys action and consequence without any unnecessary words. It is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with no annotations and no output schema, the description is minimal. It does not explain how to obtain subscription_id, the role of ad_account_id, or any caveats around deletion, leaving the agent to infer important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents subscription_id but leaves ad_account_id without any description. The tool description adds no meaning for either parameter, so the agent gets no help understanding ad_account_id's purpose or whether it is needed for the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 specific resource 'lead-sync subscription', and clearly states the intended outcome ('to stop webhook delivery'). This strongly distinguishes it from sibling tools like create/list/get_lead_sync_subscription.
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 'to stop webhook delivery' implies the tool should be used when webhook delivery needs to be terminated. However, it does not explicitly address alternatives or provide conditions for when to choose this tool over related subscription 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?
No annotations are provided, so the description bears the full behavioral disclosure burden. It does add two genuinely useful traits: attribution for the current local day is preliminary, and results are paginated via limit/after/before. It does not mention return format, default granularity when unspecified, or rate limits, but for a read-style reporting tool the disclosed caveats are meaningful and non-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?
Four short sentences, purpose front-loaded first, and each sentence earns its place: purpose, data-quality caveat, breakdown pattern, pagination. There is no redundancy, filler, or repetition of schema 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 13-parameter tool with no output schema and no annotations, the description is reasonably thorough—it covers purpose, a data-quality caveat, breakdown usage, and pagination. It leaves gaps around response shape, default behavior when no time_ranges/time_granularity are supplied, and prerequisites, which matter more because there is no output schema to fill those in.
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 77%, so the schema already documents most parameters well. The description adds modest value beyond the schema by explaining how parameters combine ('Use time_ranges + fields + segments for breakdowns') and by associating pagination cursors with the limit/after/before fields, but it does not fully compensate for the ~23% of parameters lacking schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get ad account insights') plus an aggregation behavior ('by time granularity'), which is clear and unambiguous. It implicitly separates itself from sibling insights tools (get_campaign_insights, get_ad_group_insights, get_ad_insights) via the resource scope, but it never names or contrasts them, so differentiation is implicit rather than 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 offers parameter-composition guidance ('Use time_ranges + fields + segments for breakdowns') and flags pagination, which implies when the tool's features are useful. However, it provides no explicit guidance on when to choose this tool over the sibling insights tools (campaign/ad group/ad/conversion level) or any exclusions, leaving tool-selection context to be inferred.
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. It communicates the read-only nature through 'Get' and adds the revision-selection behavior, but it does not mention permissions, default revision behavior, response shape, 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?
Two short sentences with no filler. The core action and the optional revision variant are front-loaded and 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?
For a simple GET-style tool the description is mostly adequate, but it omits ad_account_id context and does not explain what the response contains or whether the latest revision is returned when rev_id is absent. Without annotations or an output schema, these gaps reduce 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 67%: lead_form_id and rev_id are documented in the schema, and the description reinforces the ID and revision semantics. However, ad_account_id remains undocumented in both schema and description, so the agent gets no help understanding its purpose.
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 single-resource fetch ('Get a Lead Form by ID') with an optional revision. It distinguishes itself from list_lead_forms through ID-scoping, though it does not explicitly name that sibling.
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 this tool when you have a lead_form_id rather than wanting to list lead forms. There is no explicit guidance about when to use list_lead_forms or whether ad_account_id is required for certain contexts.
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 relies on the word 'preview' to imply a non-destructive, pre-publish operation. It does not explicitly disclose that nothing is published, whether the agent is actually invoked, or what side effects might occur.
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 the core purpose front-loaded. There is no filler or redundant elaboration.
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 definition is minimally viable for a simple preview tool, but with no annotations and no output schema it could usefully clarify that the operation does not publish changes and what the returned response looks like. Optional parameter context is left to 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?
The input schema already documents business_agent_id, message, and conversation_id, covering 75% of parameters. The description's 'Provide a test message' largely repeats the schema's message description and adds no new meaning for ad_account_id or parameter relationships.
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 ('Preview a response') on a specific resource ('Business Agent') and ties it to QA before publishing. It is distinct from publish_business_agent by implication, though it does not explicitly name a sibling.
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 'Useful for QA before publishing' gives a clear situational context for when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools such as publish_business_agent.
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 safety/disclosure burden. It does disclose the core behavior — a mutation that transitions a draft to a live state — and adds a prerequisite-style cue about previewing. However, it omits whether publishing is reversible, what side effects a live agent has, and what a successful publish returns, leaving meaningful gaps for a state-changing 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?
Two short sentences with no filler; the primary action is front-loaded first and the second sentence earns its place by adding workflow guidance. This is appropriately sized for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool (2 params, no output schema, no nested objects) the purpose is adequately stated. But as a mutating tool with no annotations and no output schema, it would be improved by noting the return/confirmation behavior and whether a preview is a hard prerequisite, so completeness is only borderline adequate.
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 only 50% and the description contributes zero parameter meaning. business_agent_id is documented in the schema, but ad_account_id has no schema description and the description does not clarify its purpose or whether it is needed for publishing, so the gap the description should have compensated for remains open.
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?
States a specific verb+resource: publish a Business Agent draft to make it live, and clearly marks the state transition from draft to live. This differentiates it implicitly from create/update/list business-agent siblings, though it never names an alternative or exclusion explicitly, so it does not earn the top score.
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 draft-to-live framing gives clear context for when to call this tool — after a draft exists and the user wants it public. The instruction to 'Ensure preview looks good first' is concrete pre-publish guidance that implicitly points to preview_business_agent, but no alternatives or when-not-to-use conditions are stated explicitly.
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 state the main consequence—archived audiences cannot be used for targeting—but it does not disclose reversibility, impact on existing campaigns or ads that reference the audience, or what happens to the audience data itself. This is meaningful but incomplete.
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 with no filler; the action is front-loaded and the consequence in the second sentence earns its place. The structure is compact and immediately 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 two-parameter archive action, the description covers the core purpose and effect, which is largely adequate. However, without annotations or an output schema, it leaves gaps around reversibility, return value or operation status, and the optional ad_account_id parameter, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level meaning; it only refers to 'a custom audience' generally. The schema describes custom_audience_id, but ad_account_id has no description, and with schema description coverage at 50% the tool description needed to compensate for the undocumented ad_account_id but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb ('Archive'), a specific resource ('custom audience'), and a concrete consequence ('Archived audiences cannot be used for targeting'). This clearly differentiates it from sibling audience tools like list_custom_audiences, merge_custom_audiences, and add_audience_members, as well as archive variants on other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The consequence 'Archived audiences cannot be used for targeting' implies the tool is for making an audience unavailable for targeting, but there is no explicit guidance on when to choose this over alternatives such as remove_audience_members or whether archiving is reversible. Usage context is therefore implied rather than explicitly instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals a meaningful postcondition — archived feeds cannot be used for new campaigns — but does not disclose whether archiving is reversible, how existing campaigns are affected, or what response is returned. Some transparency, but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The first states the action, and the second adds the key consequence; both sentences earn their 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 two-parameter mutation with no output schema, the core information is present, but the description leaves gaps around reversibility, the role of ad_account_id, and the effect on existing campaigns. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%. feed_id has a minimal schema description, and ad_account_id has none. The tool description does not address ad_account_id at all, so the description fails to compensate for the undocumented optional 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 opens with a specific verb and resource — 'Archive a product feed' — and immediately differentiates this tool from sibling archive_* tools by naming the product-feed resource. The added consequence, 'Archived feeds cannot be used for new campaigns,' clarifies the intended effect.
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 a product feed should no longer be available for new campaigns, but it never states when not to use it or points to an alternative. There is no explicit exclusion or comparison with related feed or archive tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full transparency burden. It only says the tool creates a feed and that SFTP setup happens afterward; it does not disclose whether the feed is activated immediately, whether there are side effects on existing feeds, permission requirements, or what the response indicates about success.
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 with no wasted words. The main action is front-loaded, followed by the key SFTP caveat and a useful pointer to a sibling tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and all parameters optional, the description leaves important gaps: how the caller knows the feed was created, how hosted vs SFTP feeds map to the url parameter, and how the ad account is identified. It does give one useful verification pointer via list_product_feeds, but overall 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 coverage is 67%, with url and name already minimally described. The description adds merchant-catalog context and SFTP sequencing, which helps, but it does not clarify ad_account_id, the only parameter lacking a schema description, nor the fact that no parameters are formally required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 the exact verb and resource: 'Create a product feed for the ad account (merchant catalog)'. It also disambiguates follow-up work for SFTP catalogs and points to list_product_feeds, so the tool's role is clear even among many feed-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical guidance: 'For SFTP-fetched catalogs, configure SFTP after' and 'Use list_product_feeds to see existing'. This conveys sequencing and a verification/alternative action, though it does not explicitly state when this tool should not be used versus related feed management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'Get' clearly indicates a read operation with no side effects, but the description does not explicitly state that it is read-only, nor does it disclose error behavior (e.g., what happens if the ID is not found) or any permissions required. It adds minimal behavioral context beyond the literal 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?
A single sentence with zero filler, front-loaded with the core action and resource. Every word contributes meaning, and the description is appropriately sized for such a simple retrieval 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 by ID' operation, the description covers the core intent, and there is no output schema to require return-value documentation. However, with no annotations and half the parameters undocumented, the agent lacks information about required permissions, error cases, or the purpose of ad_account_id. The description is adequate but leaves noticeable gaps for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with business_agent_id described as 'Business agent ID.' (essentially redundant with the parameter name) and ad_account_id left completely undocumented. The tool description merely says 'by ID' without clarifying which parameter is which or how they relate. It adds no meaning beyond the input schema and does not compensate for the missing ad_account_id documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a Business Agent by ID' uses a specific verb (Get), a clear resource (Business Agent), and the identifying condition (by ID). This clearly distinguishes it from sibling tools like list_business_agents, create_business_agent, or update_business_agent, which serve different purposes.
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 tool name and description: use this when you have a specific business_agent_id and need a single agent. However, it does not explicitly state when to use this instead of list_business_agents or other alternatives, nor does it mention any preconditions or exclusions. Only implied usage, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It communicates that this is a mutation, but does not explain permissions, whether patches merge or replace existing values, partial failure behavior, or what the API returns. The 'delta' phrasing adds some context but not enough for a state-changing 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 sentences with no filler. The action and key differentiator appear first, and the second sentence clarifies the required payload shape. Every phrase 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?
Without annotations or an output schema, the description should address prerequisites, patch semantics, and how to verify results. It only provides the basic invocation shape and leaves important operational questions open for a mutation tool with nested data and an optional account parameter.
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 feed_id, products, price, and availability at 67%, and the description usefully adds that item identifiers are expected. However, ad_account_id remains entirely undocumented in both the schema and description, and item_id itself lacks schema-level meaning. This adds some value but does not fully compensate for the coverage gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Update product availability and prices for a feed.' It also distinguishes itself from full SFTP re-upload with 'delta without full SFTP re-upload,' which clarifies the intended scope beyond 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 clearly frames when to use this tool: for incremental/delta updates rather than a full feed re-upload. It does not name sibling alternatives or state exclusions, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It repeats the inclusive/exclusive semantics already present in the schema, but gives no additional behavioral context: no side effects, no conflict behavior with existing windows, no response or error semantics, and no permissions or rate-limit guidance.
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 with zero filler. The core action, boundary semantics, and purpose are all front-loaded. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The parameters are fully documented in the schema and the purpose is clear, so basic invocation is feasible. However, with no output schema and no annotations, the description omits what happens on success, whether the window can conflict with existing ones, and account-scope implications. It is adequate but not complete for a state-changing 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 baseline is 3. The description's mention of inclusive/exclusive boundaries adds no information beyond the schema's own parameter descriptions. It provides no extra context for ad_account_id or spend_limit_micros.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Create a spend limit window,' and adds precise semantics with 'inclusive start and exclusive end.' The word 'Create' clearly differentiates it from sibling tools like update_ad_account_spend_limit_window and delete_ad_account_spend_limit_window.
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 gives a clear context for use: 'Use to cap spend over a date range.' It does not explicitly mention alternatives or when not to use the tool, but the intended use case is stated plainly and is not buried or vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that the tool creates an ad group and returns an ID for chaining, but it does not mention side effects, idempotency behavior, permissions, errors, or response structure beyond the ID. This is partially transparent but not fully.
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 with no filler. The action, return value, chaining behavior, and prerequisites are front-loaded and easy to parse. 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?
This is a complex tool with 10 parameters, nested objects, and no output schema or annotations. The description mentions only a couple of required parameters and the return value, leaving required name, optional configuration semantics, and nested bidding/product-set behavior unexplained. The agent is not equipped to use the tool safely or correctly in many real cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, so the description needs to compensate for undocumented parameters. It names campaign_id and bidding_config but omits name, which is also required by the schema. It adds no semantics for optional parameters like product_set, idempotency_key, or landing_page_configuration, and could mislead an agent into thinking only two fields are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 an ad group'), the resource ('for a campaign'), and the key output ('Returns ad_group_id for chaining to create_ad'). This distinguishes it from sibling tools like create_campaign and create_ad without requiring schema inspection.
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: create an ad group under a campaign, then chain to create_ad. It also names the key prerequisites, campaign_id and bidding_config. It doesn't explicitly say when not to use it or point to alternatives like update_ad_group, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation is a delete but does not mention irreversibility, side effects on the ad account, permission requirements, or behavior if the window has already ended. This is a meaningful gap for a destructive 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 with no filler. Every word adds value, and the key scoping detail ('active or scheduled', 'before it ends') is included without unnecessary elaboration.
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 delete operation, the description plus 100% schema coverage is arguably sufficient to invoke the tool. However, the lack of behavioral transparency around irreversibility and side effects, combined with no output schema and no annotations, leaves the definition only minimally complete rather than fully contextual.
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 window_id and ad_account_id are already documented in the schema. The description does not add parameter-level meaning beyond what the schema provides, which meets the baseline but does not exceed 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 uses a specific verb ('Delete') and a specific resource ('spend limit window'), and clarifies the applicable lifecycle state ('active or scheduled'). This clearly distinguishes it from sibling tools like create_ad_account_spend_limit_window, update_ad_account_spend_limit_window, and get_ad_account_spend_limit_windows.
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: the tool applies to active or scheduled spend limit windows and must be used before the window ends. It implies the tool is not for completed windows, though it does not explicitly name alternatives or conditions for when update would be more appropriate than delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully discloses the state machine (processing → succeeded/failed) and advises polling with backoff. However, it does not describe the return payload shape, error conditions, or behavior for expired/missing operation IDs, leaving notable gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with every sentence contributing useful information: what it retrieves, how to poll, what states to expect, and how to obtain the key input. There is no filler 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 description covers the core workflow well, but important context is missing: there is no output schema to clarify the return format, no discussion of failure handling beyond a 'failed' state, and no clarification of how this tool relates to the sibling 'poll_audience_operation'. These gaps make it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, with operation_id and custom_audience_id already described in the schema. The description adds little beyond the schema for these parameters; 'Save operation_id from mutation response' essentially restates the schema's operation_id description. The optional ad_account_id remains undocumented in both schema and description.
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 as retrieving the lifecycle state of a custom audience mutation, naming the relevant mutation types (add/remove/replace/merge). However, it does not differentiate this tool from the sibling 'poll_audience_operation', which appears to serve a very similar role, so it falls short of fully distinguishing from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance: use it after an audience mutation, save the operation_id from the mutation response, and poll with backoff until a terminal state is reached. It does not explicitly state when not to use this tool or mention the alternative 'poll_audience_operation', but the usage context is otherwise clear.
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 behavioral burden. It discloses that the tool is scoped to one campaign and that campaign_id should come from list_campaigns, but it does not describe the return shape, read-only nature explicitly, rate limits, authentication requirements, or any pagination/data-freshness behavior. The name implies a read operation, but the description itself adds little 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?
Two compact sentences with no filler. The core scope statement is front-loaded, and both sentences earn their place by explaining what the tool does and how to invoke it correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, no annotations), the description is adequate but thin. It provides the essential chaining workflow and scope, but it leaves important contextual details—such as expected output format, required parameters for conversion insights beyond what the schema notes, and operational caveats—to be inferred or looked up elsewhere.
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 79%, so the schema already documents most parameters. The description adds value for campaign_id by instructing the agent to chain it from list_campaigns, and the 'Same params as ad account insights' hint may transfer known semantics. However, it does not add per-parameter detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Get campaign insights') and immediately clarifies the scope: 'scoped to one campaign.' This distinguishes it from account-, ad-group-, and ad-level insight tools, and the reference to 'Same params as ad account insights' reinforces its identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit chaining guidance ('Chain from list_campaigns -> campaign_id') and contrasts with ad account insights, which implies when the account-level variant is appropriate. It could be stronger by naming the alternative tool directly and stating exclusions for ad-group/ad-level insights, but the usage 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?
No annotations are provided, so the description carries the full burden. It correctly implies a read-only list operation and hints at the return shape by mentioning ad_group_id, but does not disclose pagination behavior, default account context, or response format beyond IDs. This is a moderate gap for a list 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?
Two concise sentences with the primary action and key optional filter front-loaded, plus downstream usage guidance. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, and no output schema, the description is too sparse. It omits how pagination works, whether ad_account_id is ever required, what the default limit is, and the nature of the returned objects. An agent might correctly call the tool without knowing the full behavior or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with four params undocumented (after, limit, order, before). The description only mentions campaign_id, which is already described in the schema, and does not add meaning for pagination, ordering, or includes. It fails to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'ad groups for the ad account', and an optional filter by campaign_id. It also explains how to use the output (ad_group_id) for downstream actions, distinguishing it from list_campaigns, list_ads, and get_ad_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: this is for listing ad groups and filtering by campaign_id, with a note on using the returned IDs for creating ads or fetching insights. It does not explicitly name alternatives or exclusion criteria, but the context is sufficient for typical selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It conveys that this is a read-only listing operation scoped to the ad account and that results can be narrowed by campaign_id or ad_group_id. However, it does not disclose pagination semantics (after/before/limit), ordering behavior, or output structure, despite these being 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?
Two sentences with no filler; the core function and filtering behavior are front-loaded. The second sentence adds a valuable routing note that helps prevent misuse of list_ads for single-ad retrieval.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should provide more operational context, but it omits pagination, ordering, include behavior, and the role of ad_account_id. The nine-parameter schema and large sibling-tool set suggest richer guidance is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only campaign_id and ad_group_id receive semantic clarity via 'optionally filtered,' while the other seven parameters—name, after, limit, order, before, include, and ad_account_id—are left unexplained. With schema description coverage at only 22%, the description should compensate but covers only two of nine parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a precise verb–resource pair ('List ads') and scopes it to 'the ad account.' It also names the two optional filter fields and points to get_ad / insights / preview for ad_id, which clearly distinguishes this list operation from single-ad sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'Use ad_id for get_ad / insights / preview' gives an explicit routing rule for when an ad_id is already known. It implies list_ads is for enumeration and filtering, but it does not explicitly name alternatives like list_campaigns or list_ad_groups, nor does it state when not to use the 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. It discloses pagination ('Paginated') and filterability ('Filter by name if needed'), and its 'List' verb implies a read-only operation. However, it does not mention default ordering/limits, cursor usage, the include option, ad_account_id fallback behavior, or the return structure beyond campaign_id, so behavioral coverage is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four short sentences, each earning its place: the core purpose, pagination, downstream usage of the returned ID, and the optional name filter. It is front-loaded with the main action and contains no filler or redundant 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?
No output schema or annotations exist, so the description should provide more context. It explains pagination and downstream use of campaign_id, but it does not explain how to paginate (cursor usage, default limit/order), the include option, or the ad_account_id environment variable fallback. For a tool with 7 optional parameters, this 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?
Schema description coverage is 100%, so the baseline is 3. The description adds only 'Filter by name if needed', which lightly reinforces the name parameter but does not add syntax, format, or behavior details beyond what the input schema already documents. This is acceptable given the high 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 states 'List campaigns for the ad account', which is a specific verb and resource, making the tool's purpose immediately clear. It distinguishes campaigns from other list tools by naming the resource, but it does not explicitly contrast itself with siblings such as list_ad_groups or get_campaign, so it falls just short of full differentiation.
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: this is the tool to list campaigns and obtain campaign_ids for downstream tools like get_campaign, update_campaign, create_ad_group, and insights tools. It implies when to use it (when you need campaign IDs or a list) but does not explicitly state when not to use it or name alternative tools, leaving a minor gap.
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 behavioral disclosure burden. It adds useful context beyond the tool name by stating the serving prerequisites, but it does not disclose side effects, reversibility, permission requirements, or behavior when prerequisites are not met.
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 with the action and resource front-loaded, followed by a meaningful prerequisite. There is no filler 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 description is adequate for a simple state-change tool, naming the target and a key serving condition. However, it omits parameter context especially for ad_account_id, likely API error states, and return behavior, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents ad_id with 'Ad ID' but leaves ad_account_id undocumented, and the description does not mention either parameter. With 50% schema coverage and no compensatory description detail, the agent receives limited guidance on the second parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Activate') and resource ('a paused ad'), clearly distinguishing this tool from siblings like activate_campaign and activate_ad_group. The prerequisite sentence adds further clarity about the target and conditions.
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 conveys clear usage context: activate an ad that is paused, and only when the campaign and ad group are already active and review approved. However, it does not explicitly name alternatives or state when not to use the tool, leaving exclusions mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that the result is a draft and that publishing is a separate later step, and it summarizes required field constraints. However, it does not disclose auth/permission needs, reversibility, or what the response 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?
Two tight sentences with the core verb, resource, validation constraints, and next-step workflow all present. No filler or repetition of every schema property.
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 plus rich schema covers required inputs and the draft/publish workflow. The lack of an output schema and annotations is partially mitigated by the clear draft-state note, though a hint at the returned object would 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?
Schema coverage is 80%, so the schema already explains most parameters. The description condenses the required name/fields rules accurately but adds no meaning beyond the schema; optional parameters such as ad_account_id and privacy_policy_url are left entirely to 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 states a specific action ('Create a draft Lead Form') and target resource, and adds 'Publish after creation' to mark lifecycle stage. This clearly separates it from sibling tools like publish_lead_form, update_lead_form, and list_lead_forms.
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?
'Publish after creation' implies a workflow and distinguishes this creation step from later publishing, but it does not explicitly name the alternative tool or state when this tool should be used instead of update/publish. Usage context is 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?
No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful information about review_status and typical approval timing, and the verb 'Get' implies a read operation. However, it does not disclose error behavior, response structure, or how include/ad_account_id affect the call.
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 with no redundant wording. The primary action is front-loaded, and the review_status guidance is a compact, high-value addition. 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 a simple single-resource getter, so the description covers the core invocation need. However, with no output schema and no annotations, the lack of return structure detail and undocumented optional parameters leaves some ambiguity for an agent deciding how to use include and ad_account_id.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with include and ad_account_id left undocumented. The description confirms the ad_id parameter's role but does not clarify the meaning or effect of the optional parameters. Since coverage is low, the description was expected to compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 precise verb-resource pairing: 'Get a single ad by ID.' This clearly differentiates it from list_ads and sibling getters like get_ad_group or get_campaign. The additional note about review_status confirms the tool is for retrieving one ad and monitoring its approval state.
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 use context: retrieve an ad and check review_status to monitor approval, which typically takes minutes. It implicitly tells an agent when this tool is useful after creating or updating an ad, though it does not explicitly mention alternatives or exclusions such as using list_ads when multiple ads 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 behavioral disclosure burden. It reveals the HTTP method, the required invocation parameters, and the totals-vs-daily output distinction, which is helpful. It does not explicitly state that this is a read-only operation or describe response/error behavior, but the 'Get' verb and 'attributed conversion totals' wording make the non-mutating intent reasonably clear.
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 tight: three sentences with no filler, and the result type is front-loaded before endpoint and parameter details. It earns its length, though the endpoint line and some parameter guidance partially duplicate 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?
Given 8 parameters, no annotations, and no output schema, the description provides enough to invoke the tool correctly: required fields, segmentation options, and grouping semantics. It does not mention entity_ids, ad_account_id, or include_zero_rows, but those are adequately documented in the schema, so the overall context is sufficient.
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 high at 88%, so the baseline is 3, and the description adds value beyond the schema. It connects aggregation_level and time_ranges as the required pair, spells out breakdown options as device/country, and clarifies that group_by_entity splits results by campaign/ad_group/ad, which is more concrete than the schema's 'entity_id' phrasing.
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 operation: 'Get attributed conversion totals or daily values' and names the resource endpoint, POST /conversions/insights. It is specific enough to identify the tool's purpose, but it does not explicitly distinguish itself from sibling insights tools like get_campaign_insights or get_ad_insights beyond the conversion-focused wording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage context: it names the required parameters (aggregation_level + time_ranges), explains when to use breakdown for segmentation, and clarifies what group_by_entity does. However, it does not explicitly state when this tool should be chosen over the other insights siblings, so it stops short of full exclusionary 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. It adds useful context that the response exposes processing state and membership_revision and positions the call as a precondition for mutations, but it does not state read-only/no-side-effect behavior, required permissions, or output/error 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 short sentences, with the core action front-loaded and the warning in the second. No filler or repeated schema 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?
As a simple read-by-ID tool, the description provides the essential required parameter and a valuable precondition hint. However, with no output schema and no annotations, it omits return value details and leaves the two optional parameters unexplained, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% and the description only paraphrases custom_audience_id via 'by ID'. ad_account_id and matched_count_granularity receive no explanation, so the low schema coverage is not compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), target resource ('custom audience'), and lookup method ('by ID'), which clearly separates it from list_custom_audiences and mutation siblings. The additional mutation-check guidance reinforces its role as a read tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence tells the agent to use this tool to check processing state and membership_revision before mutations, giving a clear use context. It does not explicitly name alternatives or exclusion cases, but the context is enough for distinguishing from sibling list/create tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. The 'poll' hint usefully implies idempotent reads that return status information, but the description discloses no response format, status values, or rate/quota notes. It adds a bit of context beyond the tool name but stops short of actionable detail.
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, with zero filler. The ID example and the polling guidance each earn their place; nothing extraneous is present.
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 this is largely sufficient, but since there is no output schema, the description needs to define what the poll response looks like — including terminal status states — to tell an agent when to stop polling. It also never addresses ad_account_id, leaving a potential correctness gap in ambiguous multi-account environments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: upload_id is already fully documented in the schema with a pattern and description, and the tool description merely mirrors that ('by ID, e.g., pdu_...'). The optional ad_account_id has no schema description and the description adds nothing about its role, such as whether it scopes the query or is needed in multi-account contexts, so the agent receives no help for half the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Get), a specific resource (Ads partner-data upload), and an identifier format (pdu_...). This clearly distinguishes it from its creation sibling create_partner_data_upload and from other get_* tools in the list, so an agent can select it correctly without opening schemas.
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 'Poll to check processing status' provides clear context: this is the status-checking companion to create_partner_data_upload, meant for repeated calls after upload creation. It does not explicitly name alternatives or exclusion criteria, but the polling guidance is sufficient to route an agent to the right 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 available, the description carries the full burden of behavioral disclosure. 'Get' signals a read operation and the listed fields hint at the response contents, but the description does not mention prerequisites such as requiring an existing/active SFTP setup, or any caveats about credential handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, each carrying independent value: one states exactly what is retrieved, the other states when to use it. The action is front-loaded and there is 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 description is minimally adequate for a straightforward read operation: it names the output fields and the use case. However, the missing explanation of the optional ad_account_id parameter and the lack of any behavioral or prerequisite details leave it incomplete for an agent that has no other guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds little parameter-level meaning beyond the schema: 'product feed' merely restates feed_id's description. It does not explain ad_account_id at all, and with only 50% schema description coverage, the description needed to compensate for that gap but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 a specific resource ('SFTP access details for a product feed'), and lists what is returned (host, username, path). This clearly differentiates it from sibling tools like create_product_feed_sftp_access or pause_product_feed_sftp_access, which perform different actions on the same 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 phrase 'Use to configure catalog uploads' provides a clear, practical usage context. It does not explicitly name alternative tools or state when not to use it, but the intended scenario is specific enough for an agent to select this tool appropriately.
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 scope ('for the ad account') and the key output ('connected pixel IDs', 'pid'), but does not mention pagination, ordering behavior, rate limits, or other response details. The read-only nature is implied by the name 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The purpose is front-loaded and the pointer to the downstream tool is direct and economical.
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 list tool, covering its purpose and downstream usage. However, without annotations, an output schema, or parameter explanations, it is incomplete for agents needing to paginate or understand ordering/cursor behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only implicitly explains ad_account_id via 'for the ad account'. The pagination parameters after, before, limit, and order receive no explanation, leaving the agent to guess at cursor semantics and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('conversion pixels and connected pixel IDs') for the ad account. It also distinguishes itself from the sibling list_conversion_events by directing the agent to use its pid output there.
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 'Use pid from here with list_conversion_events' gives explicit downstream usage guidance and establishes this tool as a prerequisite for another sibling. It does not explicitly state when not to use alternatives, but the relationship 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?
No annotations are provided, so the description carries the full behavioral burden. It does disclose that the operation is reversible and acts on active campaigns, which is meaningful. However, it does not state what pausing does to delivery, whether it affects child ad groups/ads, 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 sentences with no filler. The primary action is front-loaded and the reversibility note adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool, the description conveys the core action, the state requirement, and reversibility. The absence of an output schema is acceptable given the low complexity, though explicit comparison to archive_campaign would 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?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no new parameter-level meaning, 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 a specific verb ('Pause'), a specific resource ('campaign'), and the required precondition ('active'). It naturally distinguishes itself from sibling tools like pause_ad, pause_ad_group, and pause_ad_account by naming the campaign resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when pausing an active campaign. It also mentions the reversal path ('Reversible via activate_campaign'), which is useful. However, it does not explicitly compare to alternatives such as archive_campaign or explain when pausing is preferred over archiving.
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 conveys that this is a read-only listing operation filtered by ad group product filters, which is core behavioral information. However, it does not mention pagination behavior, return shape, authentication needs, or how the filters interact with feed products beyond 'matching.'
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 wasted words. The primary action is front-loaded, and the usage guideline is placed immediately after. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a basic agent to understand the tool's purpose and when to use it, especially given the self-explanatory after and limit parameters. However, with no annotations, no output schema, and several undocumented parameters, the description leaves out important details about pagination behavior and the role of ad_account_id, making it incomplete for fully autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description adds little parameter-level detail. It references 'ad group product filters,' which gives context to the filters parameter, but it does not explain after, limit, or ad_account_id. The description fails to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a target resource ('products in a feed'), and a clear scoping criterion ('matching ad group product filters'). This clearly differentiates it from sibling tools like list_product_feeds or patch_product_feed_products, since it is about querying products rather than managing feeds.
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 second sentence gives an explicit use case: 'Use to validate targeting before creating ad_group with product_set.' This clearly tells the agent when to invoke this tool. It does not mention alternatives or exclusions, but the stated use case is direct and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does add a meaningful behavioral constraint ('All ancestors must be active for ads to serve'), but it does not explain what happens if the campaign is already active, whether partial activation is possible, or what the response looks like. It is adequate but has clear 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?
Two short sentences deliver the core action and the most important precondition with no filler. The purpose is front-loaded and every sentence 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 activation tool, the description covers the essential state and the prerequisite for success. However, with no output schema and no annotations, it omits expectations around return values, error cases, and permissions, making it minimally complete rather than fully contextual.
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 parameter-level meaning beyond what the schema provides, so it stays at 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 a specific verb ('Activate') and clear resource ('a paused campaign'), making the tool's purpose immediately obvious. It is also distinct from siblings like pause_campaign or activate_ad_group, as the resource and state are explicitly named.
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 states that this tool is for activating a paused campaign, which gives the agent a direct cue for when to use it. It also adds a useful precondition—ancestors must be active—though it does not explicitly enumerate alternatives 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?
With no annotations, the description carries the full disclosure burden. It conveys the mutating nature ('Create'), the linkage mechanism, and prerequisites ('Requires name + event_type + source_ids'), but it doesn't disclose the response or return value, behavior on duplicate settings, validation of source_ids against existing pixels, or default attribution-window 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?
Three sentences, each earning its place: purpose, usage context, and prerequisites. The core action is front-loaded, and there is no filler or repetition of schema 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 create operation with no output schema, the description should hint at what is returned (presumably an ID destined for campaign conversion_event_setting_ids) and clarify ad_account_id, neither of which appears. The tool also sits in a chained workflow (create_conversion_pixel → this → create_campaign), so the missing return-value information is a real gap, though invocation-level details are otherwise solid.
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 83%, so the schema already documents most parameters, placing this at baseline 3. The description reinforces the three required parameters and frames event_type + source_ids as the core linkage, but it adds little per-parameter meaning beyond the schema; ad_account_id remains undocumented in both description and 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 states a specific verb and resource ('Create a conversion event setting') and clarifies the mechanism ('linking an event type to source pixel(s)'). The usage context ('Used for conversions bidding...') differentiates it from adjacent siblings such as create_conversion_pixel, create_conversion_api_key, and list_conversion_event_settings.
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 this is needed: conversions bidding (bidding_type=conversions) and conversion_event_setting_ids on campaigns, and it states the required inputs. However, it doesn't explicitly name alternatives or exclusion conditions (e.g., when to use create_conversion_pixel instead), so it stops short of the highest bar.
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 that the delivery is synthetic, signed, queued, and intended for testing. However, it does not explain what happens after queueing, whether the delivery is observable, what errors may occur, or whether it requires an existing lead sync subscription.
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 action and target, the second conveys the requirement and use case. There is no filler or redundant elaboration.
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 purpose, the test nature, and the idempotency requirement, but because there is no output schema and no annotations, the agent is left unsure about the response format, queuing semantics, and any preconditions beyond the required parameters. This is adequate but not fully complete for a tool without structured safety/output metadata.
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 75%, so the schema already documents most parameters. The description only restates that Idempotency-Key is required, which is already in the schema. It adds no meaningful semantic detail about field_values or ad_account_id beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Queue') with a specific resource ('synthetic signed lead-sync webhook test delivery') and target ('Lead Form'). It clearly distinguishes this from actual lead sync subscription tools like create_lead_sync_subscription by emphasizing it is synthetic and a test.
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 states when this is useful: 'validate webhook handling before going live.' It also notes the required Idempotency-Key, signaling correct invocation. It does not explicitly name alternatives or exclusion criteria, but the 'test delivery' framing implies it is not for production webhook traffic.
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 burden. It discloses the primary effect (stop all serving) and reversibility via activate_ad_account, which is helpful. However, it omits other behavioral traits such as whether it's idempotent, any required permissions, impact on active campaigns or spend, and what the tool returns. 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?
Two sentences, zero waste. The core purpose is front-loaded and the reversibility note is placed efficiently. Everything 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 (one optional param, no output schema), and the description covers the core action and reversal. However, because annotations are entirely absent, the description does not fully compensate: it doesn't state what happens to live campaigns, whether pausing is synchronous, or what response to expect. These gaps matter for an agent deciding whether and how to call it.
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 single parameter ad_account_id has its own description ('Optional ad account ID override'). The tool description adds no further semantic detail beyond the schema, so 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 action ('Pause the ad account') and its effect ('stop all serving'), distinguishing it from sibling pause tools for campaigns, ad groups, and ads by explicitly naming the resource. The reversal route via activate_ad_account adds clarity about its place in the lifecycle.
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 intent is obvious: use when you want to halt all ad serving for the account, not just individual entities. It does not explicitly list alternatives or exclusions, but the resource-specific wording and reversibility hint guide selection. Lacks an explicit 'use instead of pause_campaign when...' statement, so a strong 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?
No annotations are provided, so the description carries the burden. It discloses important behavioral requirements: idempotency, expected revision, and asynchronous polling. It does not cover irreversibility, authentication requirements, failure modes, 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 compact sentences with no filler. The core operation, required parameters, and follow-up polling instruction are all front-loaded and 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?
For a mutating, asynchronous operation with no output schema or annotations, the description covers the essential call pattern but leaves gaps: the relationship between file_id and identifiers, ad_account_id context, operation result format, and error handling are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by explaining the 'file or inline' distinction, hinting at file_id vs identifiers, and calling out required idempotency_key and expected_revision. However, schema coverage is only 38%, and key parameters like ad_account_id, identifier_type, and identifier_resolution remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') with a clear resource ('custom audience') and notes the two modes ('file or inline'). This clearly distinguishes the tool from sibling operations like add_audience_members and replace_audience_members.
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 states when to use the tool (removing identifiers from a custom audience) and gives required usage context: Idempotency-Key, expected_revision, and polling via get_audience_operation. However, it does not explicitly mention when not to use it or name 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 carries the behavioral transparency burden. It adds useful provenance (window_id must come from get/create) and boundary semantics, but it does not disclose whether omitted optional parameters leave existing values unchanged or reset them, nor any other side effects. This is a serviceable but partial 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?
The description is two brief sentences with no filler. The core action and semantic detail are front-loaded, and the second sentence supplies the one essential usage clue needed to call the tool correctly.
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?
Together with the fully described schema, the definition is usable: it names the operation, the required ID source, and the time-window boundaries. However, for an update tool with no annotations and no output schema, it does not state partial-update behavior or what the caller should expect in return, leaving moderate contextual 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 the schema fully documents each parameter's meaning, types, an constraints. The description itself only reinforces the inclusive/exclusive start/end semantics and points to window_id provenance, adding no significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Edit') and resource ('spend limit window') and clarifies the critical boundary semantics (inclusive start, exclusive end). It is easily distinguishable from the sibling create/get/delete spend-limit-window tools because the operation is clearly an edit.
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 operating context by instructing the agent to 'Provide window_id from get/create', which explains how to obtain the required identifier. It does not explicitly state when not to use this tool or name alternatives, but the create/get/delete sibling tools make the selection fairly obvious.
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 must carry the behavioral burden. It does disclose important non-obvious behavior: omitted optional fields reset to defaults except where noted, and sending null clears description/start_time/end_time. This is meaningful beyond the schema, though it stops short of covering side effects, permissions, or response 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 compact and front-loaded. The core action is in the first sentence, and each subsequent sentence adds distinct, valuable behavioral information without repetition 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?
For a tool with 14 parameters, nested objects, no output schema, and no annotations, the description is too thin. It omits details about what the nested objects accept, what the response contains, and how status interactions with pause/archive/activate siblings should be handled. The behavioral notes are valuable, but they don't make the tool adequately comprehensible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, so the description needs to compensate. It adds semantics for null-clearing on description/start_time/end_time and the general reset-on-omit rule, but it leaves the meaning of budget, targeting, landing_page_configuration, conversion_event_setting_ids, and several other parameters unexplained. The schema's enums and field names help, but the description itself only marginally compensates for the low 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 opens with a specific verb and resource: 'Update a campaign by ID.' This distinguishes it clearly from create_campaign and from sibling update tools for other resources (update_ad_group, update_ad), and from status-specific tools like pause_campaign, archive_campaign, and activate_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for how to use the tool: it updates an existing campaign and only affects provided fields, with omitted fields resetting to defaults. It doesn't explicitly contrast itself with pause_campaign/archive_campaign/activate_campaign or state when not to use it, but the partial-update framing makes the intended usage reasonably 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 full behavioral burden. It discloses the effect ('resume serving') and a key dependency (parent objects must be active), which is meaningful context. However, it does not mention idempotency when already active, error conditions, scope/auth requirements, or how success is reported.
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 with zero waste. The action is front-loaded in the first sentence, and the second sentence delivers the critical prerequisite. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one optional parameter, the description covers the essential context: what the tool does and the key precondition for it to have effect. Minor gaps remain regarding response shape and behavior on already-active accounts, but nothing an agent needs for correct invocation is missing.
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% since the only parameter, ad_account_id, is already documented as 'Optional ad account ID override' in the schema. The description adds no parameter-level 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 states a specific verb and resource: 'Activate the ad account (resume serving)'. This clearly differentiates it from sibling tools at other hierarchy levels like activate_campaign, activate_ad_group, and activate_ad, as well as its inverse pause_ad_account.
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 condition 'All parent campaigns/ad groups/ads must also be active to serve' gives clear context for when this tool is effective, implicitly signaling that the agent may need to activate lower-level objects via sibling tools first. It does not explicitly name alternatives or state exclusions, but the prerequisite guidance is actionable.
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 behavioral disclosure burden. It does well by stating the auth prerequisite, the fact that the key is returned, and especially that it will not be shown again — an important security-sensitive behavior. It does not mention other behaviors like idempotency or side effects beyond creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The action and scope are front-loaded, followed by the auth requirement and the one-time-secret warning — each sentence carries meaningful, non-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 two-parameter creation tool with no output schema, the description covers the essential operational context: what it creates, the auth condition, and the return behavior/security caveat. Only a brief note on alternatives or usage boundaries is missing, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both name and ad_account_id are already documented in the schema. The description adds no new parameter-level detail beyond reinforcing that the key is scoped to the ad account, matching the schema's ad_account_id semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create an API key scoped to the selected ad account.' This clearly distinguishes the tool from similar siblings like create_conversion_api_key by emphasizing the API key type and ad-account scoping.
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 gives useful context about when this tool applies: creating an ad-account-scoped API key, and it names the required authorization. However, it does not explicitly say when to prefer this tool over alternatives such as create_conversion_api_key, leaving the choice somewhat to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the return-value consequences (pid used for event attribution and listing sampled events) and implies a persistent side effect via 'create.' But it omits auth requirements, duplicate-name behavior, and whether the pixel is immediately active/listable — meaningful gaps for a write operation with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and roughly 35 words, with the core create action front-loaded in the first sentence and return semantics plus workflow sequencing compactly delivered in the second. Every clause earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, the return-value disclosure (pid and its uses) is necessary and provided, and the chaining hint covers the immediate next actions an agent needs. Remaining gaps—auth prerequisites and idempotency/duplicate behavior—are minor for a simple 3-parameter, 1-required-field create tool, so the definition is near-complete for its 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 67%: name and client_type have descriptions ('Pixel name 3–1000 chars', 'Client type (currently only web)'), while ad_account_id has none. The description partially compensates by anchoring the operation 'for the ad account,' but it does not clarify ad_account_id's expected format or add meaning beyond the schema for the other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Create a conversion pixel (client data source) for the ad account'), names the concrete return artifact (pid), and explains its purpose (event attribution, listing sampled events). It also orients the operation within the conversion-pixel workflow by naming the two sibling chain steps, distinguishing it from create_conversion_api_key and create_conversion_event_setting.
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 'Chain to create_conversion_api_key and create_conversion_event_setting' instruction gives explicit sequencing, signaling that this tool is the first step of a setup workflow. However, it offers no when-not-to-use conditions or alternatives (e.g., checking list_conversion_pixels for an existing pixel before creating a duplicate), so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does state the mutation ('create or replace') and the return value, which is more transparent than a bare 'Create'. However, it does not disclose consequences of replacement, such as whether existing credentials are invalidated, 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.
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 redundancy. 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 three-parameter tool with one required field, the description provides the operation, scope ('product feed'), and output behavior ('returns credentials'). Since there is no output schema, mentioning the return value is important and is included; the only real gap is the undocumented optional ad_account_id.
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 67%, and the schema already documents feed_id and password. The description adds no parameter-level detail and does not clarify the undocumented ad_account_id, but the strong schema descriptions cover most of the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb-resource pair — 'Create or replace SFTP access credentials for a product feed' — and clearly distinguishes it from siblings like get_product_feed_sftp_access, activate_product_feed_sftp_access, and pause_product_feed_sftp_access. Even without the title, the resource and action are 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 context is clear: use when SFTP credentials for a product feed need to be created or replaced, and the returned credentials are meant for SFTP client configuration. It does not explicitly list exclusions or compare with get/activate/pause siblings, 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, the description carries the behavioral disclosure burden. It usefully discloses that the account is tied to the API key and that no chaining is needed, but it does not explicitly state read-only behavior, error conditions, or return format. This is adequate but not rich for a tool with no annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action is front-loaded, followed by concrete use cases and a clear sequencing instruction. Every sentence earns its place.
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 one-parameter, read-style metadata call, the description covers purpose, use cases, and call ordering. It names the relevant fields an agent can expect (timezone, currency, review status). The lack of an output schema makes exact return envelope and error details slightly under-specified, but this is acceptable for a simple health-check-like 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 already documents the optional ad_account_id parameter and the environment variable fallback. The tool description adds no parameter-level detail beyond that, 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 states a specific verb and resource: 'Get metadata for the ad account associated with the API key.' It also differentiates the tool from siblings like list_ad_accounts and get_oauth_me by making clear this is about the single account tied to the current key, not enumeration or broader identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: 'Use to verify auth, check timezone/currency/review status.' It also gives strong sequencing guidance with 'call first to confirm key works.' It does not mention specific alternatives to avoid, but the intended 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 full responsibility for behavioral disclosure. It conveys that this is a read/retrieval operation and that include=[serving_issues] influences the response. However, it omits any details about response shape beyond the ID, error conditions, permissions, or side effects (even if 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?
Three short sentences, no filler. The main purpose is front-loaded, followed by the key optional behavior and a workflow hint. Each sentence contributes information an agent needs.
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-resource GET with a required ID and two optional parameters, the description captures the essence: what it fetches, how to request delivery-problem details, and how to use the result. The absence of an output schema makes the brief mention of 'Returned id' useful, though more detail about other returned fields would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all three parameters, providing the baseline. The description adds valuable semantic meaning to the include parameter by explaining its purpose ('audit delivery problems'), which is not present in the schema's bare 'Optional includes.' For campaign_id and ad_account_id, the schema already describes their purpose adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb plus resource: 'Get a single campaign by ID.' This distinguishes it from siblings like list_campaigns (plural) and create/update/activate campaign tools without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives functional context—using the include parameter for auditing delivery problems and using the returned ID for ad group creation—but it never explicitly contrasts this tool with list_campaigns or states when not to use it. The 'single campaign by ID' phrasing implies the appropriate 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.
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. It communicates that the operation is a read-only listing and that results depend on the authenticated token's access. However, it does not mention pagination, response shape details, or any limits, which would add useful behavioral context for a no-output-schema 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 short sentences with no filler. The purpose is front-loaded, and the second sentence adds the key downstream use of the returned ids. Every word contributes to agent decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter, the description covers purpose, authentication scope, and the primary use of the return value. Because there is no output schema, a bit more detail about the response format or pagination would improve completeness, but nothing critical is missing 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?
The input schema provides 100% coverage for the single optional parameter, including a clear explanation that it is a header override rarely needed. The description adds no parameter-specific semantics, but since the schema already documents it fully, 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 ('List') and resource ('ad accounts'), and adds meaningful scope: accounts accessible to the authenticated key/OAuth token. It also states the returned ids are meant for use as ad_account_id in other tools, which clearly distinguishes this listing tool from account-specific tools like get_ad_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for discovering which ad accounts the current credentials can access and for obtaining ids to pass to other tools. It does not explicitly name alternatives or say when not to use it, but the use case is specific enough for an agent to select it appropriately.
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, and it does disclose important traits: events are 'sampled,' results are capped at 50 per call, and a pid is required. It does not discuss pagination beyond the cap, ordering, or authentication, but for a read-style list tool these are fairly minor omissions.
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, front-loaded sentences with no filler. The core action and scope appear first, followed by the limit and use case, making it easy for an agent to scan and act on.
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 basic list call since it covers the resource, required pid, and limit. However, there is no output schema, and the description does not clarify the meaning of ad_account_id, pagination behavior beyond 50, or what fields the sampled events contain, leaving the context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds little meaning beyond the schema: 'requires pid' and 'Up to 50' merely restate the required pid and max limit already present in the input schema. The ad_account_id parameter has no schema description and no explanation in the description, leaving a real semantic gap unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'List recent sampled conversion events for a pixel,' immediately scoping to conversion events rather than pixels. It also states the key prerequisite ('requires pid') and gives a distinct use case ('verify ingestion'), which separates it from sibling tools like list_conversion_pixels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear intended context: 'Use to verify ingestion from bzr.openai.com.' It does not explicitly mention when not to use it or name an alternative tool, so it falls short of a perfect 5, but the stated use case is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the behavioral burden. It conveys a read-only search operation and explains what the output is for (targeting IDs), which is useful. However, it does not disclose output shape/format, whether ad_acccount_id is required, or any rate/limit behavior beyond the schema's limit param.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero fluff: purpose first, then downstream usage, then a concrete chain example. Every sentence carries distinct information and the most important scoping detail (what the tool returns and how to use it) is 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-param lookup tool with no output schema and no annotations, the description covers the core workflow end-to-end. The main gaps are the exact response structure and the role of ad_account_id, but the chain example partially bridges the former; nothing critical is missing for a competent 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 covers q and limit (67%), and the description reinforces q's semantics with a concrete example ('California') and shows how results map to targeting.locations.include. However, ad_account_id has no description in either schema or description, and the description does not clarify when it is needed, so the gap is not fully compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search DMA and standard region codes') plus its purpose ('advertiser geo targeting'). No sibling tool performs geo lookup, so it is immediately distinguishable from campaign, audience, and ad management tools. The scope and deliverable ('location IDs') are both explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit workflow: search first, then feed returned IDs into campaign targeting.locations.include, with a concrete chain example (search_geo_lookup {q:'California'} -> create_campaign). It doesn't state when-not-to-use or name alternatives, but none exist among siblings, so the positive guidance 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 provided, the description carries the full burden. It discloses the key failure mode (403 if programmatic brand updates are not enabled) and implies a mutating operation. However, it does not explain whether updates are partial or full replacements, what the response contains, or what permissions beyond the account-level flag 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?
Three short sentences, front-loaded with the primary action, followed by the critical prerequisite and a practical sequencing hint. There is no filler or redundant restating of schema 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?
For a low-complexity update tool with no required parameters and no output schema, the description covers the main operational concerns: what is updated, the likely failure mode, and how to inspect current values. It would be slightly stronger if it noted partial-update behavior or the response type, but these are not critical gaps 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?
Schema coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds no parameter-specific semantics beyond saying 'name, url, etc.', and the suggestion to chain after get_ad_account provides indirect context for current values. This matches the baseline 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 states a specific verb and resource: 'Update ad account brand metadata (name, url, etc.)'. This clearly distinguishes it from sibling update tools like update_ad_account_negative_keywords, since the target is brand metadata specifically.
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 concrete usage context: it requires the account to be enabled for programmatic brand updates, otherwise a 403 will result. It also recommends chaining after get_ad_account to inspect current values. It does not explicitly name alternatives or exclusion cases, but there is no obvious sibling alternative for this operation.
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 disclosure burden. It does a solid job by revealing that the tool creates a temporary preview, targets an existing ad, and returns a preview URL/html without activating the ad. It does not discuss permissions, expiry, or side effects, but the core non-mutating behavior is clearly communicated.
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. It front-loads the action and resource, and covers both the purpose and the return value 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 2-parameter tool with no output schema, the description explains what the call returns and when it should be used. It is missing detail on the optional ad_account_id and on the lifespan of the 'temporary' preview, but the core call path is clear enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with ad_account_id completely undocumented in both the schema and the description. The description adds no parameter-level detail beyond 'existing ad,' leaving the optional account parameter unexplained and requiring an agent to infer its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'create a temporary iframe preview for an existing ad.' It clearly distinguishes the tool from siblings like create_ad, activate_ad, and preview_business_agent by specifying both 'temporary' and 'existing ad.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for QA before activating' provides clear usage context, telling the agent this is a staging/validation step rather than a final action. It does not explicitly name alternative tools or exclusions, but the context is sufficient for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It does more than say 'create': it states that leads will be POSTed and signed with Standard Webhooks HMAC, and it requires an idempotency key—core operational behavior an agent needs. It stops short of describing duplicate-key semantics or the response, but these are secondary for selecting and invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by prerequisites and delivery behavior. Every sentence earns its place; there is no filler, and the most important information appears first.
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 gives enough to start a call: required key and URL, plus the post-creation delivery behavior. However, it does not explain how to supply the ad account when both ad_account_id and ad_account_ids are optional, nor what the tool returns. Without an output schema or annotations, these gaps make the definition 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?
Three of four parameters have schema descriptions, so the baseline is 3. The description adds no per-parameter meaning beyond the schema and leaves the undocumented ad_account_id ambiguous relative to ad_account_ids. Restating the required Idempotency-Key and destination URL duplicates the schema rather than adding 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 action ('Provision') paired with a clear resource ('lead delivery to a managed webhook endpoint for an ad account'). This makes the creation intent unmistakable and distinguishes it from the sibling list/get/delete subscription tools and from lead-form tools. There is no ambiguity about what resource is acted on.
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 clearly states the use case—delivering leads to a webhook endpoint—and gives actionable prerequisites: an Idempotency-Key and a destination URL. It does not explicitly name alternatives or when-not-to-use conditions, but the context is strong enough for an agent to decide when this tool 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?
With no annotations, the description carries the burden and discloses key behavioral traits: destructive full replacement, use of current revision (concurrency check), idempotency requirement, and an asynchronous flow requiring polling. It does not cover failure modes or response format, but the critical behaviors are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main action is front-loaded, and every clause adds distinct information: the operation, the mechanism, the idempotency requirement, and the follow-up polling step.
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 10-parameter asynchronous mutation with no output schema, the description covers the core workflow but omits the purpose of several optional parameters and what a successful poll should return. It is minimally viable but not fully self-contained.
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 only 40%, so the description must compensate. It clarifies file_id and expected_revision via 'uploaded file and current revision' and idempotency_key via 'Requires Idempotency-Key.' However, it does not explain filename, mimetype, identifier_type, ad_account_id, or other optional fields, leaving a significant parameter gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact operation: 'Replace all members of a custom audience using an uploaded file and current revision.' This is a specific verb+resource that clearly differentiates it from add/remove and other audience operations in the sibling list.
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 strong usage context: full replacement requires an Idempotency-Key and expected_rvision, and directs the agent to poll via get_audience_operation. It does not explicitly name alternatives like add_audience_members or remove_audience_members, but the 'replace all' wording makes the intended scenario unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full behavioral burden. It substantively discloses that the operation is terminal and cannot be undone via activate, which is the critical behavioral trait for this mutation tool. It does not detail side effects on ads or authorization, but the irreversibility warning is strong 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 a parenthetical that packs essential information. There is zero filler and every word adds value.
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 tool with no output schema, the description plus schema covers the essential call correctly. It lacks explicit guidance on when to supply the ad_account_id override and what response to expect, but the terminal qualifier supplies the most important 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%: both campaign_id and ad_account_id already have descriptions in the schema. The tool description adds no extra parameter-level meaning, so the schema carries the weight and a 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 states a specific verb and resource ('Archive a campaign') and immediately adds a distinguishing qualifier ('terminal — cannot be reactivated via activate'). This makes it unmistakable what the tool does and separates it from pause_campaign and activate_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The terminal qualifier gives clear context for when to use this tool: choose it when you want an irreversible archive rather than a pause, and do not expect to bring the campaign back with activate. It does not explicitly name an alternative like pause_campaign, so it stops just short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the most important behavior: processing is async and the caller must poll until the audience is published. It also states the return value (custom_audience_id). It doesn't mention failure modes or authorization requirements, but the async caveat is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core purpose, input mode, async behavior, polling instruction, and return value are all front-loaded. Every sentence earns its place.
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 9-parameter mutation tool with no annotations and no output schema, it covers the essential operational facts: how the audience is sourced, that processing is async, what to poll, and what is returned. The phrase 'if enabled' is somewhat ambiguous and ad_account_id is not explained, but an agent has enough to invoke the tool and monitor the 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 description coverage is 78%, and the schema already documents file_id, name, filename, file_size, identifier_type, and identifier_resolution. The description reinforces the file_id-vs-empty choice but adds little beyond what the schema property descriptions already say. ad_account_id remains undocumented in both the description and schema, so some parameter semantics are still thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Create') and resource ('custom audience'), and specifies the two source modes: an uploaded file via file_id or an empty/small audience if enabled. This clearly distinguishes it from sibling list/get/archive/merge/audience-member tools without requiring schema inspection.
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?
Explicitly tells the agent to poll get_custom_audience until published, which establishes the correct follow-up workflow. It also indicates when file_id should be provided versus the empty-audience path. It doesn't explicitly rule out alternatives like merge_custom_audiences or add_audience_members, but the core create-and-poll guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of safety and behavior info; the word 'View' conveys read-only, and the interval/ordering semantics tell the agent exactly how the result set is bounded. It doesn't cover pagination or what happens when none exist, but for a simple read tool the disclosed semantics are above par.
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, no fluff: the first packages the core behavior and two precise semantic constraints, the second gives the practical use case. Information is front-loaded and every word carries weight.
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 one-optional-param read-only tool, the description is nearly complete: it says what the tool returns conceptually, how the windows are ordered, and when to use it. The only notable gap is the lack of any description of the returned window fields, but with no output schema and a self-explanatory resource name this is a minor omission.
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 parameter ad_account_id has a description ('Optional ad account ID override')—so by the rubric baseline is 3. The tool description adds no extra param meaning, so it doesn't rise above 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 a specific verb-resource pairing ('View spend limit windows') and adds distinguishing details (inclusive/exclusive bounds, ascending order) that set it apart from the create/update/delete siblings on the same resource. The name alone could be ambiguous, but the description pins down the exact read operation.
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 states the intended use cases—'audit or plan budget caps'—which gives an agent a clear trigger for choosing this tool. It does not name alternatives or exclusions, so it lacks full when-not guidance; still, 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, the description carries the behavioral disclosure burden. It reveals the OAuth-only requirement, the stable opaque nature of the ID, and the intended verification use. However, it does not describe output structure, authorization failure behavior, or any other side effects, leaving some behavior unspecified.
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 with no filler. The core behavior is front-loaded and the usage hint earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only identity check, the description covers the essential call semantics: return the authenticated user's opaque ID under OAuth. It lacks an exact response shape, but the stated return value is specific enough 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. The baseline of 4 applies because parameter semantics are trivially satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the exact verb and resource: returns the authenticated user's stable opaque ID. The 'OAuth only' qualifier and 'verify token identity' use case make the tool's purpose unmistakable and distinct from any sibling.
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?
Gives clear context for when to use: OAuth partner flows that need to verify token identity. It does not name explicit alternatives or exclusions, but no sibling tool serves a similar purpose, so 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 provided, the description carries the full behavioral transparency burden. It adds useful context: the list is scoped to 'the authenticated API project' and filtered to 'eligible' tools, which implies not every installed tool may appear. However, it does not disclose response format, pagination, or what 'eligible' means, leaving some behavioral ambiguity for a no-output-schema 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 with no filler. The core action and resource are front-loaded, and the usage hint is appended as a separate helpful clause.
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 zero-parameter list tool, the description covers the essential context: what is listed, for whom, and why it might be used. The lack of output schema and annotations makes the vague term 'eligible' a minor gap, but overall the tool is simple enough that the provided context is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameter meaning. Baseline 4 is appropriate because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 the specific verb 'List' and a precise resource: 'eligible Business Agent tools installed for the authenticated API project.' It clearly distinguishes this discovery tool from sibling tools like list_business_agents, which list agents rather than tools/connectors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to discover connectors/tools available for business agent creation,' providing clear context for when to call the tool. It does not name an alternative or state when not to use it, but the purpose is specific enough that an agent can identify the right scenario.
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 behavioral burden. It discloses that source audiences are not modified ('Independent copy'), that an Idempotency-Key is required, and that the merge is performed across a bounded set of sources. It does not mention asynchronous behavior or return values, but the key non-destructive and idempotency traits are clearly 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?
Three short, information-dense sentences with no filler. The core action, scope, independence guarantee, and critical idempotency requirement are all front-loaded and every clause earns its place.
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 creation-style tool, the description provides the essential selection and invocation facts: what it creates, from how many sources, that the copy is independent, and the required idempotency key. It does not specify the return shape or whether the operation is asynchronous, which could matter for follow-up polling via get_audience_operation, but the core contract is well covered.
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 60%; custom_audience_ids, idempotency_key, and name already carry schema descriptions. The tool description mostly restates those constraints ('2-64 source audiences', 'Requires Idempotency-Key') rather than adding new meaning. The optional ad_account_id and description parameters remain unexplained in both the schema and the description, so coverage is not fully compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a specific resource ('a new audience'), and the exact scope (all matched members from 2-64 source audiences). It also adds 'Independent copy,' which differentiates this from in-place audience mutation tools like add/remove/replace_audience_members.
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 the tool's context clear: use it when you need a new audience built by merging 2-64 existing audiences as an independent copy. It does not explicitly name alternative tools or state when not to use it, but the 'new audience' and 'Independent copy' phrasing provides enough directional guidance against in-place modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses that the tool makes exactly one call to get_audience_operation, does not loop internally, and exposes terminal states. This meaningfully helps an agent avoid hammering the API. It doesn't describe the return payload shape or error behavior, but the core non-obvious behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each carrying distinct information: what it does, how to call it, and what it deliberately avoids. No filler or repetition, and the most important behavioral constraint (no internal loop) is prominently included.
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 polling helper, the description covers purpose, retry pattern, terminal states, and rate-limit rationale. The main gap is that it doesn't specify the structure of the returned 'current state' or explain how this differs from calling get_audience_operation directly. This is a minor omission given the tool's simplicity and the lack of 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 input schema already describes operation_id and custom_audience_id, covering 67% of parameters. The description adds no new parameter-level meaning, and it does not help clarify the undocumented ad_account_id. Since the coverage is not high enough to fully rely on the schema, the gap around ad_account_id remains, but this is acceptable for a simple helper.
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 as a helper to poll a custom audience mutation, stating it calls get_audience_operation once and returns the current state. This is a specific verb+resource pairing that distinguishes it from nearby mutation tools. However, the phrase 'poll ... until terminal' is slightly at odds with the explicit note that it does not loop internally, so the precise scope of a single call is a bit muddled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage direction: call repeatedly with backoff and expect processing to transition to succeeded/failed. It also explicitly says the agent controls retry timing to respect rate limits, which tells the agent when and how to invoke the tool. This is actionable and complete.
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, and it handles the key destructive aspect: this is a full replace, not an append, so callers must provide the entire desired list. It also explains the domain purpose (blocking unwanted contexts for ad eligibility). It could add impact details such as irreversibility or immediate propagation, but the core mutation behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, with the critical replace-not-append warning front-loaded and no filler. Every sentence adds decision-relevant 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 two-parameter mutation with a well-described schema and no output schema, the description gives enough for an agent to use it correctly: what it operates on, the replace semantics, and when to use it. It could mention side effects explicitly, but nothing essential is missing 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?
The input schema already describes both parameters well: ad_account_id is an override and negative_keywords is the full list to set, with empty array clearing. The description mostly restates the 'full desired list' constraint, adding no new param-level detail, 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 ('Replace'), names the exact resource ('account-level negative keywords'), and ties it to ad eligibility. It also explicitly distinguishes the behavior from appending ('this is a replace, not append'), which differentiates it from sibling update/add tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage context ('Use to block unwanted contexts') and the replacement semantics an agent must understand before calling. It does not name alternative tools or state when not to use it, but the sibling list contains no similar negative-keyword tool, so the guidance 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 carries the full burden. It usefully discloses that the created agent is a draft and that publication is a separate action, but it does not mention permissions, idempotency, failure behavior, or what the call 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?
Two sentences, no filler: required fields, optional attachments, and the follow-up publish step are all in the first sentence, with the routing to the sibling in the second.
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 10-parameter creation tool with no output schema and no annotations, the description covers the core lifecycle but does not mention return behavior or several optional fields (tools, description, conversation_starters, ad_account_id, privacy_policy_url). It is adequate for invocation but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 90%, so the schema already documents most parameters. The description adds value by highlighting the two required parameters (name, instructions) and grouping the three common attachable resources (product feeds, connectors, lead form), making parameter selection quicker. It omits some optional params like conversation_starters, but the schema covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 opens with 'Create a draft Business Agent,' giving a specific action and resource, and the word 'draft' immediately separates it from publish_business_agent and update_business_agent. The close 'Publish separately via publish_business_agent' reinforces the distinct lifecycle stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the intended workflow: create the draft here, then publish through publish_business_agent. This directly orients the agent to the correct sibling for the next step and implies this tool is not for publishing.
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 behavioral burden. It discloses file type/size limits, the requirement to provide file_base64, the fixed purpose, and the file_id return format, which gives the agent meaningful behavioral expectations beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences with no filler. The core purpose and result are front-loaded, and the file-format and size constraints are stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return value and how to use it in downstream operations. It covers input format, size, purpose, and next steps, making it complete enough for a 4-parameter upload tool 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 coverage is 75%, so the schema already documents three parameters clearly. The description adds some semantic context around file_base64 and the file's purpose, but it does not elaborate on ad_account_id, which lacks a schema description, leaving that parameter under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Upload a file'), a clear resource ('custom audience creation'), and concrete constraints (CSV/TXT, up to 500MB). It also names the return value and downstream tools, making it distinct from siblings like upload_image and create_custom_audience.
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 frames this as a preparatory step for create_custom_audience or add_audience_members, which gives the agent a solid when-to-use context. It does not explicitly exclude alternatives such as upload_image or create_partner_data_upload, so it falls short of full usage-guideline coverage.
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 behavioral burden. It discloses that this is an asynchronous operation requiring polling, that an idempotency key is required for safe retries, that expected_revision is needed for concurrency control, and that inline size is capped around 10k. It does not mention duplicate handling, response shape, or whether the operation is reversible, but the disclosed behaviors are highly relevant.
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 dense sentences with no filler. It front-loads the core action, then critical requirements, then sizing guidance. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and no output schema, the description covers the most important operational facts: prerequisites, async polling, and inline size limits. It does not explain return values or the undefined optional parameters, but the combination of schema and description is largely sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining the file-or-inline choice and the ~10k inline threshold. However, schema coverage is only 63%, and parameters such as ad_account_id, identifier_type, and identifier_resolution are not clarified by the description. The description helps but does not fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add identifiers to an existing custom audience.' It also distinguishes file-based from inline-based additions, and the sibling list includes remove/replace/merge operations, so the tool's role is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the file approach vs inline identifiers ('Supports up to ~10k inline identifiers; use file for larger'), calls out required prerequisites (Idempotency-Key and expected_revision), and instructs the agent to poll get_audience_operation. This is strong routing and execution guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behavior: creation requires a creative object, returns ad_id, and has mutually exclusive file_id/token requirements based on creative type. It does not cover auth, idempotency, or failure modes, but the most decision-relevant behavioral details are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by only the essential type-specific instructions and the return value. Every sentence adds operational value with 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 tool with 7 parameters and a nested creative object, the description covers the two creative type branches, the upload_image prerequisite, and the ad_id return value. It does not explain status or idempotency behavior, but the schema provides field constraints and the core calling requirements are sufficiently specified.
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 only 43%, so the description adds meaningful value by specifying how to construct the creative object and when to provide or omit file_id. This compensates for the schema's gaps on the most complex parameter, even though some self-explanatory parameters like ad_account_id and status are not described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Create an ad for an ad group,' which clearly distinguishes it from sibling tools like create_ad_group and create_ad_preview. The wording leaves no ambiguity about what is being created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear conditional guidance: chat_card requires file_id from upload_image, while product_ad_template requires {{product.*}} tokens and must omit file_id. It does not explicitly route away from alternatives like update_ad or create_ad_preview, but the in-tool branches are clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and handles it well. It reveals critical behavior: omitted optional fields reset to defaults, lead_form is preserved when omitted but can be unlinked with null, and the result is only a draft.
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 concise sentences with no filler. The core operation is front-loaded, and each subsequent sentence adds a distinct, important behavioral or usage detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 11-parameter mutation without annotations or output schema, the description covers the essential behavioral and usage nuances well. Minor gaps remain around return values, permissions, and explicit relationship to publish_business_agent, but the description is sufficiently complete for a competent agent to call it 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?
Schema description coverage is only 27%, so the description must compensate. It adds valuable global semantics for omitted optional fields and specifically explains lead_form behavior, but it does not document the other eight undocumented parameters beyond their property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Replace'), names the resource ('Business Agent'), and scopes the action to 'name and config'. The phrase 'save as draft' clearly differentiates this from publish_business_agent, and 'Replace' distinguishes it from create_business_agent.
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 usage context: the operation replaces an existing agent's configuration and saves as a draft, and 'Requires full desired state' warns that callers must supply the complete intended configuration. It does not explicitly name sibling alternatives or state when not to use it, but the context is strong enough.
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 behavioral burden. It discloses the SSRF guard on image_url, the https-only/no-private-host restriction, and the fact that the call returns a file_id for downstream use. It does not mention permissions, persistence, or size limits, but the most critical behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the action, the critical either/or rule, the security constraint, the return value, and the workflow note in three sentences. Every sentence earns its place.
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?
There is no output schema and no required parameters in the schema, so the description must compensate. It explains the return value, downstream usage, and the chat_card sequencing. It could mention image format or size constraints or clarify behavior if both image_url and image_base64 are provided, but the core calling information is present.
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 semantics beyond the schema: the either/or constraint between image_url and image_base64, the SSRF/private-host behavior, and the relationship to create_ad's file_id. These details help the agent invoke the tool correctly despite the schema not marking either parameter as required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 distinct resource ('creative image for ads') and clarifies that it feeds into create_ad through a returned file_id. This makes it easy to distinguish from sibling tools like upload_audience_file or 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 clearly explains that the agent should provide either image_url or image_base64 and includes the important chat_card workflow: upload first, then create_ad. It does not explicitly list alternatives or say when not to use the tool, but the context is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and meets it: it reveals the non-atomic partial-failure behavior ('If any step fails, earlier objects remain'), the return shape (all three IDs), and that cleanup requires separate update/archive calls. This is precisely the kind of operational surprise an agent needs to know before invoking.
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?
Five short sentences, each carrying distinct information: purpose, use case, return value, failure semantics, and alternative routing. There is no filler, no restatement of schema fields, and the most decision-relevant facts are 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 mutating composite tool with no output schema and no annotations, the description covers the critical operational facts: single-call creation, three returned IDs, and partial-failure cleanup. The minor gap is that it does not clarify the role or necessity of ad_account_id, which the schema also leaves undocumented.
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 80%, with the schema already documenting the campaign/ad_group/ad payloads and the idempotency_key suffixing behavior, so the baseline applies. The description adds no parameter-level detail and does not compensate for the one undocumented parameter (ad_account_id).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'create a full campaign -> ad group -> ad chain in one call.' It clearly identifies this as a composite workflow, which distinguishes it from the atomic create_campaign, create_ad_group, and create_ad siblings without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it ('Useful for quick end-to-end creation') and when not to, naming the alternatives ('Prefer atomic tools (create_campaign, create_ad_group, create_ad) for fine-grained control'). It also routes post-failure cleanup to update/archive tools, leaving little to inference.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/niyogi/chatgpt-ads-manager-mcp'

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