ZuckerBot

Server Quality Checklist

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

Latest release: v0.4.4
Disambiguation3/5
With 60 tools, there is some overlap (e.g., multiple campaign creation tools like create_campaign, create_full_campaign, create_campaign_from_spec) that could confuse an agent despite detailed descriptions. However, most tools have distinct purposes and the descriptions help clarify boundaries.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern prefixed with 'zuckerbot_' (e.g., zuckerbot_delete_audience, zuckerbot_get_performance). Underscores are used throughout, and no mixing of conventions like camelCase.
Tool Count2/5
60 tools is excessive for a single server; it significantly exceeds the typical well-scoped range (3-15). While the domain of Meta advertising is broad, the tool count feels overwhelming and could be trimmed without losing functionality.
Completeness4/5
The tool set covers a wide range of Meta advertising workflows: campaign creation (multiple methods), audience management, creative analysis, CAPI, performance monitoring, research, and portfolio management. There are minor gaps (e.g., direct ad editing), but the surface is largely complete for the stated purpose.
Average 4.1/5 across 60 of 60 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed—no side effects, permissions, or return behaviors are mentioned. The description does not compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but serves as a status notice rather than a tool description. It front-loads the unavailability message but is not informative about the tool itself.
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 an unavailable tool, the description omits what the tool normally does, its return value, and how it relates to sibling tools beyond the alternative. Incomplete for understanding the tool's intended function.
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 no parameter-level information, but the input schema has 100% description coverage, 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.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only declares it is temporarily unavailable and provides an alternative. The core function of 'activate_campaign' is never explained, leaving the purpose unclear.
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 tells the agent not to use this tool due to unavailability and directs to use zuckerbot_launch_campaign instead, providing clear when-not-to-use and an alternative.
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 provided, so description must cover behavioral traits. It only states the tool is unavailable and must not create Meta objects, but does not explain what it does when operational, required permissions, side effects, or return values. Minimal transparency.
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?
Three sentences, front-loaded with key status information. However, the core purpose is missing, making it under-specified. Conciseness is good but at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and the description lacks essential details about the tool's function and behavior. For a likely complex launch tool, the description is incomplete and does not provide enough context for an agent to understand its utility.
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?
Input schema covers 100% of parameters with descriptions. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate as schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool is temporarily unavailable and directs to use an alternative, but does not clearly state what the tool itself does. The verb 'launch' is implied but not defined; the purpose is vague and overshadowed by the unavailability notice.
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 says when not to use (during Dealify launch hardening) and provides an alternative tool (zuckerbot_launch_campaign). Also mentions creating a legacy-mode draft, giving clear context for usage despite the temporary unavailability.
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 fully disclose behavior. It partially covers permissions and error returns but omits key details: side effects, idempotency, return value on success, or asynchronous behavior. This leaves agents uncertain about the tool's full impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no redundant words, and the most critical information (purpose, prerequisites, error handling, parameter list) is front-loaded. Highly concise and well-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?
The tool has 5 parameters with nested objects and no output schema. The description does not explain what the tool returns (e.g., conversion ID, status), nor does it clarify if the operation is synchronous. For a creation tool, this leaves significant gaps in the agent's understanding of the outcome.
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 parameters. The description adds an example for the rule parameter but largely restates schema information. Baseline score of 3 is appropriate as the description provides minimal additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a custom conversion on the connected ad account', using a specific verb and resource. It clearly distinguishes from sibling tools like list_custom_conversions and other creation 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 mentions prerequisite permissions and an error case (insufficient_permission). It lists required and optional parameters, providing some usage context. However, it does not explicitly state when to use this tool over alternatives, though the context of custom conversion creation 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 full burden. It indicates the tool creates a portfolio, implying mutation, and notes that portfolio launch is temporarily disabled. However, it does not disclose side effects, permissions needed, or other behavioral traits such as whether the portfolio is immediately stored or requires further action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence captures the core action and variants, while the second adds key behavioral context (budget splitting and temporary disablement). It front-loads the primary purpose and avoids unnecessary verbiage.
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 7 parameters, no output schema, and no annotations, the description explains the portfolio concept and parameters but omits return value and preconditions like whether a business context must be set. It is somewhat complete for creating a portfolio but lacks details that would help an agent fully anticipate the tool's behavior and integration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about budget splitting across tiers and use of templates, which maps to parameters like template_id, tiers, and total_daily_budget_cents. However, it does not provide detailed explanations for each parameter beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating a planning and monitoring-only multi-tier audience portfolio for a business. It distinguishes this from sibling portfolio tools like launch, update, or get by specifying that it creates a new portfolio from a template or custom tier array.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly tell when to use it vs. alternative portfolio tools (e.g., update_portfolio, rebalance_portfolio). It mentions the use of templates and custom tiers, providing some context, but no when-not-to-use guidance or prerequisites.
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 full behavioral disclosure. It fails to state that this is a read-only operation, mention any authentication or rate limits, or note whether data is cached or real-time. The verb 'Get' implies non-destructive intent, but this is insufficient given the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences split logically: first lists outputs, second gives usage context, third adds secondary use case. No filler or repetition, making it quick 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?
Given no output schema, the description partially covers output by listing market size, audience estimates, and benchmarks. However, it lacks details on format, time period, or constraints (e.g., does it return percentages or raw numbers?). For a simple tool, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with clear descriptions (e.g., industry: 'Industry/business category (e.g., fitness, dental)', location: 'City/region (e.g., United States)'). The description merely mentions 'industry and location' without adding any new semantic detail, so it adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'market size, addressable audience estimates, and Meta ad benchmarks (CPL, CTR, CPM)' for a given industry and location. This specific verb ('Get') and resource enumeration distinguishes it from sibling research tools like 'zuckerbot_research_reviews' and 'zuckerbot_research_competitors'.
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 advises using this tool 'before creating a campaign' to set budget expectations and understand audience size, and notes it is 'also useful for proposals and client presentations'. This provides clear context, though it lacks explicit alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the tool 'locks in the plan' but does not explain whether the action is reversible, what permissions are needed, or what the response looks like. This is minimal for a potentially critical mutation 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 just two sentences with no redundant words. The first sentence states the action and optional parameters, the second provides workflow context. 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 description lacks return value information (no output schema) and does not cover prerequisites or side effects beyond the sequential dependency. For a mutation tool, this is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds value by explaining that tier_names and angle_names are 'optional subsets' for narrowing approval, clarifying their purpose in context. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool approves an AI-generated intelligence strategy for a campaign, with optional narrowing to specific tiers and angles. It distinguishes from siblings by naming two subsequent tools that depend on this approval, making its role unique.
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 the tool ('before creative production starts') and provides a required sequence ('Required before calling zuckerbot_request_creative or zuckerbot_upload_creative'). However, it does not mention when not to use it or alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It does not mention that the tool is read-only, non-destructive, or that it does not modify state. Also missing details like pagination, sorting, or error behaviors. The agent must infer the read-only nature from the 'list' verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first defines the action and return, the second provides usage contexts. No extraneous information; every word contributes. Highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and return value (files with summaries), and provides practical usage examples. For a simple list tool with one optional parameter and no output schema, it is mostly complete. Minor gaps: no mention of error states or maximum results, but these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'business_id' parameter already described as 'Optional business ID override'. The tool description adds no additional semantics beyond the schema. 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?
Clearly states the verb 'List', the resource 'uploaded business-context files', and the scope 'for a business'. The description also includes the extracted summaries, providing a complete picture. This differentiates it from sibling tools like zuckerbot_upload_business_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states two specific use cases: confirming planning documents before creating a campaign and checking if a previous upload was processed successfully. This gives clear guidance on when to use the tool, though no explicit alternatives or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description partially carries the behavioral disclosure burden. It explains that budget and tier changes take effect on the next autonomous evaluation cycle, which is useful. But it lacks information on permissions required, idempotency, or any side effects like blocking concurrent operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action. It is efficient and avoids redundancy. However, it could be slightly more structured by grouping effects (e.g., listing the delayed effect separately).
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 there is no output schema, the description does not mention what the tool returns (e.g., success status or updated portfolio object). For an update tool, this is a gap. However, it sufficiently covers input and purpose. The complexity is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra context (e.g., 'Changes to budget and tiers take effect on the next autonomous evaluation cycle') but does not enrich individual parameter meanings significantly. 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 'Update the name, total daily budget, active status, or tier configuration of an existing audience portfolio.' The verb 'update' and resource 'audience portfolio' are specific. It distinguishes from siblings like create_portfolio (create new) and rebalance_portfolio (rebalance budget allocation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to adjust a portfolio without relaunching all tiers,' giving a clear use case. It also mentions when changes take effect (next evaluation cycle). However, it does not explicitly state when NOT to use or list alternatives like rebalance_portfolio for budget reallocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It fully discloses the return structure: average metrics per group, trend direction, insight object with recommendations, and optional top/bottom ads. This gives a clear behavioral understanding without hiding side effects (it is read-only). It could mention required permissions or data dependencies, but it is still transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. The first sentence states the purpose and grouping options, the second lists outputs, and the third gives usage guidance. Every sentence earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains return values (groups, trends, insights, recommendations). It also mentions optional outputs (include_ads, summary_mode) and grouping attributes. It could clarify defaults (e.g., metric defaults to cpl) but overall provides sufficient context for a tool with 9 parameters.
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 meaning by explaining that group_by uses creative attributes, include_ads returns top 5/bottom 5, and summary_mode returns a condensed narrative. This enhances understanding beyond the schema's parameter descriptions, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyse creative performance patterns by grouping ads by hook type, visual style, etc.' It specifies the verb ('Analyse') and resource ('creative performance patterns'), listing seven grouping attributes. However, it does not explicitly distinguish from sibling tools like zuckerbot_creative_cross_analysis, so it loses a point for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use this before generating new briefs to inform the creative strategy.' This implies when to use it, but it does not mention when not to use it or suggest alternatives among siblings. Thus, it meets the minimum for clear context but lacks 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?
Without annotations, the description carries full burden. It discloses the crawling and extraction behavior and the force_refresh option, but lacks details on potential failures, side effects (e.g., data modification), or output format. Adequate 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 sentences effectively convey core purpose and usage guidance with no redundant words, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and usage but lacks details on return value structure, error handling, or prerequisites (e.g., needing a stored business). Given no output schema, the description should provide more context for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema descriptions already explain parameters well. The description adds context for force_refresh usage but doesn't significantly extend beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('crawl and extract') and the resource ('business website') with detailed output examples (company description, services, etc.), clearly distinguishing it from sibling tools like research_reviews or research_competitors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool ('before creating a campaign when the business has not been enriched') and when to use force_refresh, but does not explicitly mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it manually sends an event and authenticates via API key or header. However, it does not mention side effects, idempotency, error handling, or permissions. The behavior is partially transparent but lacks detail on what happens after sending.
Agents need to know what a tool does to the world before 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 concise sentences with no wasted words. It front-loads the purpose, then adds use cases and authentication info. Each 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 tool with 14 parameters and no output schema or annotations, the description is adequate but not complete. It explains purpose and when to use but lacks details on return values, error scenarios, or rate limits. Some behavioral gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters (e.g., fbc, fbp, source_stage). The description itself does not add extra parameter semantics beyond the schema. Baseline of 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a Conversions API event manually for a business contact/lead. It provides specific use cases (debugging, testing mappings, custom integrations) and distinguishes from webhook-based sending. The verb 'send' and resource 'event' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool: debugging CAPI pipelines, testing stage mappings, sending events for custom integrations not covered by webhook. It also explains authentication methods. However, it does not explicitly state when not to use it, though the use cases imply boundaries.
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 mechanism (Claude vision analysis, storage) and data flow (feeds creative_analysis pipeline). With no annotations provided, the description carries full burden. It does not mention permissions, rate limits, or side effects, but the mutation nature is implied by 'tag'. Adequate but not comprehensive.
Agents need to know what a tool does to the world before 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 very concise: three sentences that cover purpose, method, downstream use, and timing. Every sentence adds value with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not mention return values or output behavior. It explains the stored tags and pipeline but not what the function returns to the caller. Considering the complexity (nested objects in input), the description leaves a gap in expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context about using Claude vision with asset URLs, but this is already implied by schema parameter descriptions. No additional meaning 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 clearly states the action ('Tag Meta ads'), the resource, and specific attributes (hook type, visual style, etc.). It also mentions the use of Claude vision and differentiates from sibling tools like 'zuckerbot_creative_analysis' by noting that this tagging feeds that pipeline.
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 timing advice ('Run this after launching new ads'), which helps the agent decide when to invoke. However, it does not mention when not to use the tool or suggest alternative tools, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key traits: read-only, available on all tiers, and report saving behavior under certain conditions. However, with no annotations, it could provide more detail on dependencies or edge cases, but covers the essentials for a safe, read-only 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 three concise sentences, front-loaded with the core purpose and outputs. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description provides a solid overview of purpose, outputs, and side effects. It lacks detail on error handling or data source freshness, but adequately covers the tool's role and 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 coverage is 100% with both parameters described. The description adds no new information beyond the schema's parameter descriptions, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool performs a full audit of a Meta ad account, detailing specific outputs like wasted spend detection, creative fatigue, opportunity score (0-100), and action items. It distinguishes itself from sibling tools by being a comprehensive first-call analysis.
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 recommends using this tool as the first call for new accounts or when users ask 'how are my ads doing?', providing clear usage context. However, it does not explicitly mention when not to use it, 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, the description must convey behavior. It states the tool returns a performance matrix, best/worst combinations, and an insight string, implying a read-only analysis. However, it does not disclose authorization needs, data scope, or potential side effects, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences and an example. It front-loads the core purpose and quickly lists return values without unnecessary detail. Every element 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?
Given the lack of an output schema, the description provides sufficient context by specifying the return components. It covers what the tool produces but could be enhanced by noting that the analysis is read-only and clarifying data source or time range handling.
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 all 7 parameters with 100% coverage, including enums for metric, group_by, and cross_by. The description adds no additional parameter-level information beyond the example, so it meets the baseline but adds no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: cross-referencing two creative dimensions to find winning combinations. It provides a concrete example (hook_type vs visual_style) and distinguishes itself from the sibling 'zuckerbot_creative_analysis' by focusing on cross-analysis rather than single-dimension analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use: when you need to explore interactions between two creative dimensions. However, it does not explicitly exclude situations where single-dimension analysis would be more appropriate, nor does it mention 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 full burden of disclosure. It states the tool returns a 'pattern-match score' and accepts raw specs, implying a read-only operation with no side effects. However, it does not explicitly confirm safety (e.g., no data modification) or address permissions, latency, or error scenarios. The description is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences clearly state purpose, input/output, and usage advice. No redundant or extraneous words, and critical information is front-loaded. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects, no output schema), the description covers purpose, inputs, output (pattern-match score), and usage timing. It is mostly complete for an agent to decide when and how to invoke it. Minor gaps include lack of detail on scoring methodology or data prerequisites, but these are not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters already well-documented. The description adds context by listing examples like 'copy, headline, CTA, asset URLs, frame URLs', but this largely echoes the schema. For a high-coverage schema, the baseline is 3, and the description does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Score proposed creative variants against the business's historical top-performing patterns', providing a specific verb (score) and resource (creative variants). It distinguishes from sibling tools like zuckerbot_suggest_angles (which suggests new angles) and zuckerbot_creative_analysis (which likely analyzes existing creatives).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Use this before producing expensive creative assets to pre-validate concepts against what has historically worked', giving clear usage context and benefit. However, it does not explicitly mention when not to use it or provide alternative tools, which would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly implies a read-only operation by saying 'fetch', but does not explicitly confirm non-destructiveness, mention rate limits, or describe behavior on missing IDs. The listed return fields help but leave behavioral aspects partially uncovered.
Agents need to know what a tool does to the world before 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 first packs the core functionality with specific details, the second gives usage guidance. Every sentence adds value; the description is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, no-output-schema tool, the description is fairly complete. It lists the kinds of details returned, asserts lifecycle-stage flexibility, and differentiates from siblings. It lacks error-handling info, but the simplicity mitigates that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds that the ID is used 'by ID' and lists the return fields, but does not provide additional meaning or format beyond what the schema already states ('ZuckerBot campaign 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 uses a specific verb ('fetch') and resource ('full details of a ZuckerBot campaign by ID'), lists concrete components (intelligence workflow state, approved strategy, etc.), and clearly distinguishes it from sibling tools like get_campaign_insights or get_performance which serve narrower purposes.
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 to use this tool 'to inspect a campaign at any stage of the lifecycle', providing clear positive guidance. However, it does not explicitly mention when not to use it or point to alternatives, missing an opportunity for full differentiation among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies a read-only operation by stating 'Fetch' and listing return data. It does not explicitly state non-destructive nature but is sufficient for a read 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: first defines purpose and return data, second provides usage guidance. Front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return fields (tiers, budgets, CPA targets, performance) and usage scenario. Lacks specification on portfolio status constraints but is adequate for a simple read tool with no 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 single parameter 'portfolio_id' is fully described in the schema (100% coverage). The description adds 'by ID' and usage context but no additional semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches configuration and performance data for a portfolio by ID. It identifies the resource (audience portfolio) and action (fetch), but does not explicitly differentiate from sibling portfolio tools like update_portfolio or rebalance_portfolio.
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: use for planning, monitoring, or rebalancing an already-active portfolio. However, it does not mention when not to use it or list alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. While 'list' implies a read operation, the description does not explicitly state it is non-destructive or read-only. A clear statement of safety would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first states what the tool does, and the second provides usage context. No fluff 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?
Given the tool has only one optional parameter and no output schema, the description adequately covers what the tool returns (audiences, sizes, etc.) and when to use it. It would benefit from mentioning pagination or error conditions, but completeness is high for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single optional parameter (business_id). The description does not add additional context about the parameter beyond what the schema already provides, so baseline score 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 explicitly states the tool lists 'all stored Meta audiences' and enumerates specific types (seed, lookalike, sizes, delivery statuses, CAPI source details). It uses a clear verb+resource structure and distinguishes from siblings like deletion or creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides two clear use cases: before launching a campaign and for finding IDs for refresh/delete operations. It does not explicitly state when not to use or mention alternatives, but 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?
No annotations provided, so description carries full burden. Discloses that tool lists conversions and outputs specific fields. However, lacks details on potential side effects, rate limits, or authentication requirements beyond the implied read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loads purpose and adds a practical usage hint. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers what it lists and why. No output schema exists, but description mentions returned fields. Could be improved by noting if it returns all conversions or has pagination, but overall fairly 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 covers the single optional parameter with a description. The tool description adds no extra parameter information beyond what's in the schema. Baseline of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists custom conversions with specific fields (id, name, rule, source event, pixel). It distinguishes from siblings like 'zuckerbot_create_custom_conversion' by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'find the custom conversion id a campaign spec's optimisation_event should reference.' Does not mention when not to use or alternatives, but provides a clear primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It mentions that calling with select_id changes the selected page for future launches, implying a side effect. But it doesn't disclose potential issues like overwriting without confirmation or authorization 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 clear sentences that front-load the core purpose and optional behavior. Every word is useful and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers both usage cases and the persistence of selection. It could hint at output format but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (select_id), and the description essentially repeats the schema explanation. It adds no new meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Facebook Pages and shows current selection, with optional selection by ID. This distinguishes it from sibling tools, which are mostly about campaign management, audience, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the selected page is used for future launches, indicating this is a setup tool. However, it doesn't explicitly state when not to use it or mention prerequisites like having a connected Meta account, which is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. The description implies a read operation ('Fetch live...') but does not explicitly confirm it is non-destructive or mention any side effects. It also lacks details on authorization, rate limits, or data freshness. The mention of 'live' indicates real-time data, but overall transparency is adequate 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?
The description is two sentences: the first states the action and return contents, the second provides usage guidance. It is front-loaded with the key purpose and contains no unnecessary words. Every sentence 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?
Given the simple input (one required string) and no output schema, the description provides a good overview of return values (enriched tier rows, daily metrics, etc.). However, it does not address error conditions (e.g., portfolio not found, not launched) or prerequisites. This is a minor gap considering the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter: portfolio_id). The description does not add meaning beyond the schema's 'Audience portfolio ID' – it does not explain format, validation, or how to obtain it. With high coverage, the baseline is 3, and there is no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Fetch' and the resource 'Meta performance and downstream CAPI attribution for a launched audience portfolio.' It enumerates specific return items (enriched tier rows, ad breakdowns, daily metrics, CPA comparisons, autonomous evaluation outputs). This effectively distinguishes it from sibling tools like get_portfolio (which likely fetches basic portfolio data) and rebalance_portfolio (which executes rebalancing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use this to monitor a running portfolio and decide whether to rebalance.' This guides the agent to invoke it for monitoring and decision-making before rebalancing. It does not provide exclusions or alternatives, but the context is clear enough given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behavioral traits: uses Claude for data-driven recs, defaults for cold start, returns comparable_historical_cpl with source and disclaimer, never CPL projection, and lead destination defaults. It also mentions the recommendation should be presented for approval. However, it does not explicitly state read-only nature or potential side effects (though it's a recommendation, so likely safe). Overall, good transparency for a non-destructive 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 about four sentences, efficient and front-loaded with the main purpose. It includes essential details without fluff. A minor improvement could be more compact phrasing, but overall it's well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, nested objects, no output schema), the description explains the main behavior and output elements (comparable_historical_cpl, disclaimer) but lacks detail on the full output structure of the recommendation. It mentions components like 'audience tiers, budget allocation, creative mix' but does not specify how these are returned (e.g., separate fields or nested object). This leaves some gap for an AI agent to understand the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for lead_destination (reiterating schema) and explains overall behavior but does not add significant new meaning to individual parameters beyond what the schema provides. The description's main value is in tool-level context, not parameter-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate a campaign structure recommendation' and specifies components (audience tiers, budget allocation, creative mix). It distinguishes between accounts with history and new accounts, and uses specific verbs like 'generates' and 'returns'. The purpose is unambiguous and differentiates from sibling tools like zuckerbot_create_campaign which actually creates campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use: generating recommendations before proceeding to creation. It explains behavior for accounts with history vs cold start, and gives guidance on lead_destination for lead campaigns. However, it does not explicitly mention when NOT to use this tool or name alternative tools (e.g., use zuckerbot_create_campaign instead for direct creation). The guidance is good but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It describes what the tool does (searches Google/Yelp, returns structured data), but lacks details on limits, authentication requirements, or response format. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with clear front-loading: purpose, output detail, and usage recommendation. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although no output schema exists, the description adequately outlines what the tool returns (star rating, review count, sentiment themes, quotes). Given the tool's simplicity (3 parameters, simple search) and the presence of sibling tools, it provides sufficient context for an AI agent to decide when and how to use 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?
The input schema covers 100% of parameters with descriptions. The tool description does not add additional semantic value beyond the schema's existing documentation for 'business_name', 'location', and 'platform'. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches review intelligence for a business by name, specifying sources (Google, Yelp) and outputs (star rating, review count, sentiment themes, quotes). This distinguishes it from sibling research tools like zuckerbot_research_competitors or zuckerbot_research_market.
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 advises using it 'before creating a campaign' to identify proof points and objection-handling angles. While it doesn't explicitly exclude alternatives, the use case is clearly contextualized, and no competing tool performs the same function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it teaches Meta's algorithm to improve lead quality. Does not detail authentication needs or side effects, but schema covers required token.
Agents need to know what a tool does to the world before 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, then usage and benefit. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides context on trigger (lead status change) and effect (algorithm improvement). No output schema, but tool likely returns basic status. Adequate for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds no extra meaning beyond schema; does not explain parameter purpose further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 it sends conversion quality feedback to Meta via CAPI for ZuckerBot-sourced leads, with specific conversion types. Distinguishes from sibling 'zuckerbot_send_capi_event' by focusing on lead quality feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly specifies when to call: when a lead status changes (converted or bounced). Provides context from CRM. Does not explicitly mention alternatives or exclusions, but context 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?
Describes the core behavior of expanding a seed into a lookalike with typical percentages. No annotations provided, so description carries full burden; however, it omits details like idempotency, error handling, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. First sentence states purpose, second adds key details. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not mention return value (e.g., new audience ID). For a creation tool, this is a notable gap. Otherwise covers purpose and typical use adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all four parameters with descriptions. Description adds usage context (typical percentages 1, 3, 5) and clarifies that seed_audience_id references a stored row, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'create' and resource 'lookalike audience' from a seed. Distinguishes from sibling tools like create_seed_audience and delete_audience by specifying it expands a seed into a prospecting 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?
Provides context that it's for prospecting tier of an intelligence campaign. Implicitly differentiates from deletion or listing tools but lacks explicit when-not-to-use or prerequisites like seed must exist.
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 provided, so description carries full burden. Discloses use of hashed CAPI data and filtering, but omits details on permissions, idempotency, or what happens if audience already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states action and resource, second gives 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description should mention return value (e.g., audience ID) and prerequisites like CAPI setup. Misses these, but covers core functionality well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters. Description adds value by explaining source_stage with examples and linking audience building to hashed CAPI data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds a Meta custom audience from hashed CAPI data filtered by CRM stage. Distinguishes from sibling audience tools like create_lookalike_audience and list_audiences by specifying the data source and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use as first step for retargeting/reactivation from first-party CRM data. Does not exclude alternatives, but context and sibling tools provide implicit 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 full burden. It details the output structure for legacy vs Intelligence campaigns but does not explicitly state that the operation is read-only or safe. It implies non-destructive behavior by describing metrics retrieval, but lacks explicit safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and immediately followed by concrete detail on output differentiation. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no output schema, the description fully covers the expected behavior: it explains what metrics are returned for both legacy and Intelligence campaigns, including AI recommendations. The use case is explicitly stated, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is campaign_id, which the schema already describes as 'ZuckerBot campaign ID.' The description does not add extra meaning or format details beyond what the schema provides. With 100% schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches real-time performance metrics for a ZuckerBot campaign, distinguishing between legacy and Intelligence campaigns with specific metrics listed. It also provides a use case ('monitor an active campaign or diagnose underperformance'). This differentiates it from siblings like zuckerbot_get_campaign or zuckerbot_get_campaign_insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to monitor an active campaign or to diagnose underperformance,' giving clear guidance on when to use it. It doesn't directly state when not to use it or mention alternatives, but the context is sufficient for appropriate 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the key behavioral trait that selecting a pixel sets it for all future conversion tracking and CAPI attribution, indicating a persistent side effect. It does not mention destructive actions or permissions, but the mutation is clearly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and efficiently covers both listing and optional selection with its consequences. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not detail the output format when listing or after selection (e.g., list structure, confirmation message). It also omits potential error conditions (e.g., invalid pixel ID). For a low-complexity tool, it provides adequate but not complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, and the description essentially restates the parameter's purpose from the schema ('If provided, selects this Meta Pixel ID for conversion tracking. If omitted, lists all available pixels.'). It adds no new semantic details 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 verb 'List' and the resource 'Meta Pixels', specifying the context 'on the currently selected ad account'. It also distinguishes itself from sibling tools by focusing on pixel listing and selection, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to list available pixels or optionally select one. However, it does not explicitly mention when not to use it or suggest alternative tools for pixel management.
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?
Discloses key behavioral traits: 'queues the Meta upload and ad-creation jobs asynchronously, then polls until they complete or the polling window expires.' This goes beyond the bare minimum. Since annotations are absent, the description carries the full burden, and it adequately covers the asynchronous nature and polling mechanism.
Agents need to know what a tool does to the world before 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 that front-load the purpose and follow with behavioral detail. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity (5 parameters, async behavior), the description lacks an explanation of the return value or output format. There is no output schema, so the description should clarify what the agent receives after polling completes (e.g., success confirmation, creative IDs). This gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all 5 parameters already described in the input schema. The tool description adds no additional meaning or context for the parameters beyond what the schema provides. 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?
Clearly states the verb 'Upload' and resource 'finished creative assets (images or videos)' to a specific target 'approved intelligence campaign'. Distinguishes from sibling tools like zuckerbot_get_creative_status (status check) and zuckerbot_tag_creative (tagging), as no sibling handles uploading creatives.
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 says 'Use this when you have your own creative assets ready.' This provides clear context for when to invoke the tool. However, it does not mention when not to use it or suggest alternative tools (e.g., if assets are not ready), which would elevate the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation that returns statistics, with no mention of destructive actions. It could explicitly state it is read-only, but the behavior is well implied.
Agents need to know what a tool does to the world before 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 waste. The first sentence lists the data returned, and the second states the purpose. Every sentence is necessary and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values: total events, events by type, match quality breakdown, attribution counts. It lacks format details but is sufficient for a status tool. Minor gap: no mention of possible errors or limits.
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?
There is only one optional parameter (business_id), and its schema description is already clear. The description adds no extra meaning beyond 'for the business,' which is implicit. With 100% schema coverage, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves CAPI delivery statistics for 7-day and 30-day periods, listing specific data like total events, event types, match quality, and attribution. It is distinct from sibling tools, none of which seem to provide similar statistics.
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 this to confirm CAPI is functioning and that events are being matched by Meta,' providing a clear use case. It does not mention alternatives or when not to use, but the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses key behavioral traits: 'Logs as a test event (does not affect real attribution)' and implies the event is sent to Meta Graph API but as a synthetic test. This adequately conveys non-destructive behavior, though more detail on side effects or permissions could strengthen transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence clearly states the action and purpose; the second adds a critical behavioral disclaimer and usage suggestion. No wasted words, front-loaded with the core idea.
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 all 8 parameters are optional, schema coverage is 100%, and no output schema exists, the description is fairly complete. It covers purpose, usage timing, a key behavioral trait, and the testing nature. It does not mention expected output or error scenarios, but is adequate for a straightforward test 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?
With 100% schema description coverage, the baseline is 3. The description adds high-level context (e.g., 'verify raw passthrough') but does not significantly enhance parameter meaning beyond the schema's existing descriptions of each property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send a synthetic CAPI test event' and explicitly distinguishes from real event sending (e.g., zuckerbot_send_capi_event) by noting 'does not affect real attribution' and 'Logs as a test event'. This provides a specific verb+resource and distinguishes 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 advises 'Use after setting up or updating CAPI config to confirm events are flowing', giving clear context for when to apply the tool. It does not explicitly exclude other uses, but the guidance is sufficient for a testing tool among related CAPI siblings.
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 full burden. It discloses the permanent, irreversible nature and that deletion affects both Meta and local registry. It does not cover error cases or prerequisites, but is still informative.
Agents need to know what a tool does to the world before 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 zero waste. The first states action and scope, the second gives usage context. Every part is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple delete function with one parameter and no output schema, the description covers the core purpose, permanence, and use cases. It lacks mention of response or potential errors, but for a straightforward delete it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add further meaning beyond the schema's 'Stored audience row ID'. No additional parameter details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it permanently deletes an audience from both Meta and local registry. It uses a specific verb and resource, distinguishing it from list, create, or refresh 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?
It explicitly mentions when to use: stale audience, creation error, or freeing up slots. While it does not explicitly state when not to use, the listed use cases are sufficient and imply alternatives (e.g., refresh).
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?
Discloses it's 'the money endpoint' that creates real ads and immediately starts spending. Explains auto-resolution of credentials and behavior of launch_all_variants. With no annotations, it carries full burden; missing details on idempotency or effects of re-launching, but the critical financial impact is clearly highlighted.
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?
Concise at 6 sentences, front-loaded with purpose and money warning. No unnecessary details. Well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, key parameter explanations, and warning. Lacks return value description (e.g., status or campaign ID), error conditions, and handling of non-draft campaigns. With no output schema or annotations, more context would be helpful for a high-stakes tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters described). Description adds value by noting auto-resolution for meta_page_id, meta_access_token, and meta_ad_account_id, and explaining launch_all_variants behavior. Provides guidance beyond schema for key optional 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?
Clearly states verb 'Launch' and resource 'draft campaign on Meta (Facebook/Instagram)'. Emphasizes it creates real ads and spends budget, distinguishing it from other campaign tools like zuckerbot_create_campaign (draft creation) and zuckerbot_activate_campaign (activation).
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 instructs to check budget availability and Meta connection via zuckerbot_meta_status before calling. Mentions use of launch_all_variants for A/B testing. Does not explicitly list when not to use (e.g., if campaign already live), but context implies it's for drafts.
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 fully compensates by explaining listing behavior, selection, and persistence for future launches. It does not mention error handling or limitations, but overall provides adequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover all necessary information: listing, selection, and usage context. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter and no output schema, the description is sufficient for an agent to understand when and how to use the tool. It explains the business reason for selection (reuse CRM form) and the two modes of operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and defines select_id clearly. The description reinforces that omitting it lists forms and providing it selects one, but adds no new detail beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists Meta lead forms, shows which is currently selected, and optionally selects one by providing select_id. This distinguishes it from sibling tools that deal with other aspects of Meta advertising (e.g., audience creation, campaign insights).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use before launching a leads-objective campaign to reuse a CRM-connected form, avoiding unnecessary new form creation. While it doesn't list alternatives, the context makes the recommendation 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?
Describes return values (connection status, ad accounts, connect URL) but does not disclose side effects or confirm it's read-only. With no annotations, should be more explicit about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences: one for purpose, one for usage guideline. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers return values and pre-launch context. Could mention error behavior or rate limits, but sufficient for a simple status check.
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?
No parameters exist (schema coverage 100%), so description doesn't need to add param info. Baseline 4 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?
Description uses specific verb 'Check' and clearly identifies the resource: connection status of Facebook/Meta account. Distinguishes from siblings by focusing on a prerequisite check.
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 states when to use ('Always call this before attempting to launch a campaign'), providing clear context. Does not explicitly mention alternatives but the instruction 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?
Description discloses key behaviors: scrapes the site, writes AI-generated copy, and generates ad images. It also states no Meta account or live budget is needed. However, it does not mention potential limitations like rate limiting or data retention. With no annotations to rely on, this is decent 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 efficiently convey purpose, method, and usage. Every sentence adds value, and the key action 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?
Given 2 parameters and no output schema, the description covers the tool's input and high-level output (headlines, body, images). It lacks specifics on return format but is adequate for an agent to infer expected results.
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% (both url and ad_count have descriptions). Description adds context about zero-cost generation but does not elaborate on parameter details beyond what schema provides. 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?
Description clearly states it generates a zero-cost campaign preview from any business URL, including scraping AI headlines and ad images. This distinguishes it from siblings like zuckerbot_create_campaign or zuckerbot_create_full_campaign, which require live budgets and accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this as the first step to show a user what their ads could look like before committing to a full campaign.' Provides clear when-to-use context. Does not explicitly mention when not to use or alternatives, but the intent 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 carries full burden. It discloses that dry_run=false updates Meta ad set budgets and local records in one operation, indicating a destructive write. However, it does not detail permissions, reversibility, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main action and modes. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the dry-run and execute paths, and mentions the effect on Meta budgets and local records. No output schema exists, but the description implies recommendations are returned for dry-run. It lacks detail on error conditions or exact output format, but is adequate for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining the dry_run parameter's default and overall behavior beyond the schema, but does not significantly enhance parameter understanding 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 performs a budget rebalance across portfolio tiers based on CPA performance. It distinguishes between dry-run and execution modes, and differentiates from sibling tools like zuckerbot_get_portfolio or zuckerbot_update_portfolio by focusing on rebalancing.
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 explains when to use dry_run=true (review) vs dry_run=false (commit), and mentions it's useful for review before committing. It provides clear context, though it doesn't explicitly list when not to use it or alternatives.
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 discloses key behavioral traits: for seed audiences it re-hashes latest CAPI events, for lookalikes it syncs size and delivery status. It does not mention permissions or error handling, but the core behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey core function, subtype behaviors, and usage guidance. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and lack of output schema, the description covers the essential aspects: behavior for both audience types and when to use. It omits return value details but is otherwise 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 100% with one parameter (audience_id) described as 'Stored audience row ID.' The description adds no additional semantic beyond what the schema provides, so baseline score 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 it rebuilds a stored audience from fresh data, with specific behaviors for seed and lookalike audiences. It distinguishes from sibling tools like create_seed_audience, delete_audience, and get_audience_status.
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 advises 'Use this when CAPI has received new events since the audience was last built,' providing a clear condition for use. It does not explicitly state when not to use it but implies that creation of new audiences is handled by other 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?
No annotations provided, so description carries full burden. It discloses external data scraping (Meta Ad Library, web search) and return types. Could mention potential rate limits or data freshness, but overall transparent for a research 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: first explains action and outputs, second gives usage context. No redundant words, front-loaded with key information. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are documented in schema; description adds usage context and return types (positioning, hooks, gaps). Lacking explicit output format or example, but sufficient for a research tool with no 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?
Schema coverage is 100% with descriptions for all three parameters. Description adds minimal extra meaning—reiterates industry, location, and optional country refinement. Baseline score of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool scrapes Meta Ad Library and web to analyze competitor ads, returns positioning, hooks, and gaps. It distinguishes itself from siblings like zuckerbot_research_market (broader) and zuckerbot_suggest_angles (different output).
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 says 'Use before creating a campaign to benchmark...' providing clear context. Does not explicitly state when not to use, but the sibling list offers alternatives. Slight deduction for missing exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behaviors. It states changes take effect immediately for new CAPI events, which is a key behavioral trait. However, it doesn't mention side effects (e.g., overwriting existing config), authorization needs, or other implications of the rotate_webhook_secret parameter. More detail on what gets destroyed or updated would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the main purpose, then lists capabilities, and ends with behavior and verification suggestion. Every sentence earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, many siblings), the description covers the main purpose, configurable items, immediate effect, and testing recommendation. It lacks details on error scenarios, authentication requirements, and full behavioral specification, but overall it is fairly complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by providing normalization details for event_mapping keys (lower-cased, non-alphanumerics stripped) and an example mapping ('lead' → Meta Lead event). It also advises preferring a dedicated tool for rotation. This extra context justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates the Conversions API configuration, specifying the verb 'Update' and the resource 'Conversions API configuration'. It lists specific configurable items (stage-to-event mappings, enable/disable, CRM source, currency, etc.), and distinguishes from siblings like get_capi_config (read) and capi_test (test) by mentioning the test tool for verification.
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 advises using zuckerbot_capi_test to verify the updated config, providing a clear post-update action. While it doesn't explicitly state when not to use this tool, it implies it's for modifications and hints at alternatives like zuckerbot_rotate_webhook_secret for dedicated rotation. It lacks prerequisites or context like needing an existing configuration, but 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?
No annotations are provided, so the description carries the full burden. It discloses that raw text is accepted and that insights will be extracted, but omits important behavioral details such as whether the uploaded data overwrites previous entries, what the success response looks like, any size limits, or authentication requirements. As a result, an agent might not fully understand the tool's side effects or constraints.
Agents need to know what a tool does to the world before 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 consists of two tightly packed sentences with no wasted words. The first sentence clearly states the action and purpose, and the second adds a usage instruction. Every phrase earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain what the tool returns or how the system reacts. It only implies future insight extraction ('so ZuckerBot can extract...') but doesn't state the immediate outcome (e.g., whether a confirmation message or ID is returned). It also lacks details on limitations (e.g., max content size) that would be needed for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 4 parameters with descriptions, so baseline is 3. The description adds value by clarifying that content is 'raw text content — not binary files,' which is more specific than the schema's 'File content as text.' It also provides context for the 'context_type' enum by listing example types, helping the agent choose appropriate values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('upload a text document'), the resource ('business context'), and the purpose ('so ZuckerBot can extract structured planning insights'). It enumerates specific document types (ad performance, brand guidelines, etc.), making it unambiguous. Among many sibling tools, this one is uniquely about uploading text for insight extraction, differentiating it effectively.
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 tool: 'Use this when the business has existing performance data or brand docs that should inform campaign strategy.' It also clarifies what not to do: 'Accepts raw text content — not binary files,' which implicitly guides against using it for non-text files. While it doesn't name alternatives, the context of siblings like 'zuckerbot_upload_creative' provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a behavioral side effect: 'this clears the stored page selection so you can pick a matching page.' This goes beyond simple listing and provides important context. It does not mention authentication or rate limits, but for a read-like operation, this is adequate.
Agents need to know what a tool does to the world before 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 sentences that front-load the main purpose and then add a clarifying detail about the selection side effect. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema, no nested objects), the description covers the purpose, usage context, parameter behavior, and an important side effect. It is complete for an agent to correctly invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter select_id, and the parameter description in the schema is identical to the tool description's mention. Thus, the tool description adds no new semantic value beyond the schema. Baseline is 3, and no extra credit is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool lists Meta ad accounts and shows the currently selected one, with an option to select a new account via select_id. It is specific about the verb (list/select) and resource (ad accounts), and distinguishes itself from sibling tools by its unique function of listing and selecting ad accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this during setup or when switching between multiple ad accounts,' providing clear context for when to use the tool. It does not explicitly state when not to use or mention alternatives, but the guidance is sufficient for an agent.
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?
Discloses the side effect: 'Updates the local audience registry row'. Without annotations, the description carries the full burden, and this is a key behavioral trait. It also implies it's a read operation with a minor write, which 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 sentences, no fluff, front-loaded with purpose and usage. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the action (fetch with side effect), the specific data fetched (delivery status, size, readiness), and the use case (pre-launch check). It is complete for an agent's needs.
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 already covers 'Stored audience row ID' for the single parameter. The description adds no new meaning beyond what the schema provides, 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 it fetches Meta delivery status, size, and readiness for a stored audience, with a specific verb and resource. It distinguishes from sibling tools like 'delete_audience' and 'refresh_audience' by focusing on checking status for campaign readiness.
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 says to use this tool to 'check if an audience is large enough to use in a campaign before launch'. While it doesn't mention alternatives or when not to use, this provides clear context for 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?
Despite no annotations, the description discloses key behaviors: immediate stop of delivery and spend, object retained in Meta, response reports prior status, and temporary disablement of resume. This covers the essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-loaded with core operation, then effects, then use case and limitation. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description covers how to use (parameters, levels), what happens (immediate stop, object kept, response includes prior status), and a current limitation (resume disabled). Sufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the relationship between entity_level and IDs ('set entity_level and pass the matching id') but largely mirrors schema descriptions. No additional parameter meaning beyond what 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 clearly states the verb 'pause' and the resource (campaign/ad set/ad) with scope options. It distinguishes from sibling tools like activate_campaign or delete_audience by focusing on pausing delivery.
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 explicit guidance on when to use adset/ad level to stop underperformers without harming winners. Also mentions that resume is disabled during a specific period. No explicit mention of when to avoid the tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behaviors: dry_run produces a preview without side effects, live mode creates PAUSED Meta objects, auto-activation is disabled, and generated videos link for rejection tracking. With no annotations provided, the description carries the full burden and largely meets it, though it omits details on idempotency or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences with clear structure: purpose, important default, dry_run flow, live mode behavior. Front-loaded with key action. No wasted words; every sentence 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?
Given the complexity (6 params, no output schema), the description covers the main workflow and side effects. It mentions return structure for dry_run (campaign structure) but does not describe the return format for live mode or error handling. Sibling tools context is clear, placing this as a middle step in architect workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by explaining the dry_run/activate parameter workflow and the approval process, which is not evident from schema alone. This context helps the agent understand parameter interactions and usage order.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a complete PAUSED Meta campaign from an approved Campaign Architect session, using a specific verb ('Build') and resource. It distinguishes from siblings like zuckerbot_create_campaign or zuckerbot_launch_campaign by emphasizing the session-based, approval-driven workflow.
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 states the dry_run default, the safe preview, and the need for customer approval before setting dry_run=false. It also mentions that live mode creates PAUSED objects and auto-activation is disabled. Implicitly positions the tool after an approved architect session, but does not explicitly exclude alternatives like zuckerbot_activate_campaign.
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 fully discloses key behaviors: auto-pagination, truncation with a truncated flag, and the effect on data coverage. It also warns that zero-delivery days are legitimately absent and advises comparing the covered range with the requested range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the core purpose first, followed by details and caveats. It is slightly lengthy but every sentence adds value (e.g., truncated behavior, zero-delivery days). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description lists return metrics, response fields (row_count, covered, truncated), and handles edge cases (truncation, missing zero-delivery days). This is comprehensive for a read-only data fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description confirms the date range and time_increment usage but adds no new semantics beyond what the schema already provides. It mentions auto-pagination but does not add parameter-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action (fetch historical Meta ad account performance), the resource (connected business over a date range), and the specific metrics returned (spend, clicks, impressions, CTR, CPM, CPC, frequency). It clearly distinguishes from sibling tools like zuckerbot_get_campaign_insights by focusing on account-level performance.
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 states the tool is 'useful for top-level budget reporting and month-over-month trend analysis without opening Ads Manager.' While it doesn't explicitly say when not to use or name alternatives, the context implies it's for aggregate account data vs. campaign-specific 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, the description carries full burden. It discloses that rows are tagged with is_zuckerbot for benchmarking, explains status_scope and status_synced_at, notes that spend-by-date is authoritative for delivery, and mentions cache bypass via refresh. It does not explicitly state it is read-only, but the query nature is clear. Minor omission of explicit non-destructive statement prevents a 5.
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 lengthy but well-structured, front-loading the core purpose and then layering details. Every sentence provides useful guidance (metric preferences, status handling, benchmarking). It could be slightly more concise by grouping related details, but the density is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description covers the main aspects: purpose, filtering, sorting, metrics reliability, status interpretation, and cache behavior. It does not mention error scenarios or rate limits, but for a read-only query tool this is acceptable. The thorough metric guidance and benchmarking feature make it quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 11 parameters. The description adds significant value beyond schema by explaining preferred sort values (meta_result, conversion_leads), clarifying deprecated metrics (leads/cpl), detailing status filter behavior (simple vs legacy), and describing refresh, time_increment, and status semantics. This goes well beyond baseline schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries campaign, ad set, or ad-level performance for any campaign in the connected Meta ad account. It specifies the resource (campaign/adset/ad-level performance) and action (query), and distinguishes from sibling tools by noting it includes campaigns not created by ZuckerBot and provides benchmarking via is_zuckerbot tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (for performance queries) and includes detailed guidance on metric selection (prefer meta_result over deprecated leads) and reliability conditions (campaign-level, non-time-incremented). However, it does not explicitly contrast with sibling tools like zuckerbot_get_account_insights or zuckerbot_get_campaign, which would strengthen when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the read-only validation behavior and its position in the workflow. It does not disclose auth requirements or side effects, but for a validation tool this is sufficient and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action and followed by usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description explains the purpose and when to call. It could optionally describe the output format, but it's not critical for an agent to use it 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 input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info, which is acceptable since none exist. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resolves and validates Meta launch credentials (access token, ad account, page, pixel) and reports readiness for autonomous launch. It differentiates from sibling tools like zuckerbot_launch_campaign by specifying it should be called after setup before launching.
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 says to call after completing the setup sequence and before launching a campaign. Provides clear context but does not mention when not to use or list alternatives, though sibling tools like zuckerbot_create_campaign provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns status, recommendations, pricing, and setup guide, implying it is a read-only, non-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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 3-4 sentences and covers all essential information. It is somewhat detailed but not excessively verbose, and it front-loads the key functions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description thoroughly explains the return values (status, steps, pricing, setup guide). It is complete for its purpose.
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?
No parameters, so baseline 4. Description adds value by detailing what the tool returns, compensating for the lack of 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 explicitly states it shows authentication mode, billing tiers, setup instructions, and recommended tool flow. It clearly differentiates as the first call for orientation.
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 says 'Call this first in any new session to orient the agent.' Provides clear context for usage, though lacks explicit when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the code format, valid purchase sources, stacking behavior, and that redemption immediately upgrades all API keys, providing good behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet informative, covering all necessary details without extraneous text. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description fully explains the tool's behavior including code formats, stacking, and upgrade effects, making it contextually 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?
Only one parameter 'code' with 100% schema coverage. The description adds value by specifying the format and examples beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool redeems a ZuckerBot lifetime license code with a specific format, which is a unique action among many sibling tools. It clearly distinguishes its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (to redeem a license code) and explains how codes stack and upgrade accounts, but does not explicitly mention when not to use it or alternative 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 carries full burden. It clearly states what the tool returns (creative angles and audience tiers) and what it omits (stored creatives, tier execution details), implying a read-only subset operation. However, it does not mention side effects, auth needs, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and result, followed by the contrasting sibling tool. Every word is necessary; no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description adequately covers purpose, usage alternative, and output scope. It could mention that the campaign_id must exist, but otherwise is sufficiently 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 100% with campaign_id described simply as 'Campaign ID'. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns 'creative angles and audience tiers' for a campaign draft, and explicitly differentiates itself from sibling tool zuckerbot_get_campaign by calling itself a 'lightweight alternative' that omits stored creatives and tier execution details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises use when needing 'just the strategy summary without the full campaign payload', and names the alternative tool zuckerbot_get_campaign that provides the full payload, along with what that includes.
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?
Discloses that it reads billing information but does not explicitly state it's read-only. Acceptable for a simple lookup tool with no 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, front-loaded sentences with no redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description sufficiently covers what the tool returns (tier, usage, quota, overage). No 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?
No parameters exist, and schema coverage is 100%. Description adds no param info because none needed. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Check' and specific resource 'billing status' with explicit outputs: tier, usage, quota, overage. No sibling tool covers billing, so it's distinct.
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 'Use this when a user asks about their plan or usage limits.' Provides clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it only creates a draft, does not spend money or interact with Meta, and intelligence mode cannot be activated. This is transparent and prevents misuse.
Agents need to know what a tool does to the world before 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 that are front-loaded with the primary purpose, then clarify constraints and next steps. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 13 parameters and nested objects, the description omits the return value or output format. Since there is no output schema, the description should at least indicate what the tool returns (e.g., a draft ID). This gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter has a description. The tool description adds minimal extra detail beyond the schema (e.g., default mode is legacy). It does not elaborate on parameter usage, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a campaign draft for a business, specifies it defaults to legacy mode, and distinguishes from launch tools by noting it does not spend money or create anything on Meta. It contrasts with sibling tools like zuckerbot_launch_campaign, providing clear purpose.
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 instructs when to use (create a draft) and when not (does not launch, does not spend money), and directs the agent to zuckerbot_launch_campaign for activation. It also explains mode constraints, making usage guidance 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 provided, the description covers key behaviors: campaigns are always created paused, dry_run behavior, validation error format, and special requirements (e.g., EXISTING_AD needs credentials even for dry_run). It could mention implications of resending with changes, but overall is quite comprehensive.
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 lengthy but well-structured: first sentence on purpose, then paused behavior, recommended flow, validation, and a detailed breakdown of the spec shape. It uses clear formatting with brackets and parentheses. Minor redundancy (e.g., 'always' emphasized twice), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, multiple ad types, conditional fields, no output schema), the description is exceptionally thorough. It covers error handling, dry run, special cases, and references a sibling tool for conversions. The agent can confidently construct and call this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds extensive detail about the nested spec object, including all fields, enums, conditional requirements (e.g., WEBSITE vs INSTANT_FORM), and asset types. This far exceeds what the minimal schema provides, giving the agent full 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?
The description starts with 'Build a complete Meta campaign VERBATIM from a declarative JSON spec', clearly stating the tool's purpose. It explicitly says it does not generate strategy or copy, distinguishing it from siblings like zuckerbot_create_full_campaign and zuckerbot_generate_campaign_brief.
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 recommended flow: use dry_run first, review payloads, then re-send without dry_run. It also mentions using zuckerbot_list_custom_conversions for finding conversion IDs. However, it does not explicitly state when not to use this tool versus alternatives, though the spec-driven nature implies it is for users with a complete spec.
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 full burden. It reveals that briefs are 'weighted toward the top-performing creative attributes,' which is a key behavioral trait. It does not mention destructive actions, auth needs, or rate limits, but as a generation tool it is likely non-destructive.
Agents need to know what a tool does to the world before 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: first defines the tool's purpose and output components, second provides usage guidance. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and the generative nature, the description is complete. It explains what the generated briefs contain (hook type, etc.) and the weighting logic. It also references the prerequisite tool for proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 7 parameters have descriptions). The description adds value by explaining how parameters like 'bias' and 'metric' influence the weighting toward top performers, beyond the schema's basic 'Optional generation bias' etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Generate creative production briefs based on the business's tagged ad-performance patterns' and specifies the components of each brief (hook type, visual style, etc.). It distinguishes itself from sibling tools like zuckerbot_generate_campaign_brief by focusing on creative production and requiring prior analysis.
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 after running zuckerbot_creative_analysis to know which patterns to bias toward,' providing a clear precondition. It does not mention when not to use or alternatives explicitly, but the context is sufficient.
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 fully assumes responsibility. It discloses safety (non-destructive, read-only), notes automatic data pulls (brand context, historical patterns), and explains cold-start behavior. Transparent about internal workings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, safety, and workflow. Every sentence adds distinct value: purpose, safety, input sourcing, output details, next steps. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a generation tool with no output schema: describes return format (per-slot directions, static/video details) and includes workflow context (present to customer, call ad generation tools). No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions, but the tool description adds value by explaining parameter relationships (session_id vs approved_structure, auto-resolution of business_id) and intent of additional_creative_direction, going beyond raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates a detailed creative brief from an approved campaign structure, specifies inputs and outputs (per-slot creative directions), and distinguishes from sibling tools by naming subsequent steps (zuckerbot_generate_static_ad / zuckerbot_generate_video_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?
Explicitly declares safety ('SAFE — pure function, no Meta API calls'), clarifies when to use (after campaign structure approval), and provides workflow guidance ('present to customer, then call...'). Lacks explicit 'when not to use' but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It discloses a critical constraint: the webhook secret is write-only, with reads only returning set and last4 fields. However, it could mention any required permissions or authentication context, but given the tool is read-only, the transparency is good but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences front-loaded with purpose, followed by usage guidance, then a behavioral note. Every sentence adds value and there is no fluff. It is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple read with one optional parameter and no output schema, the description lists all returned fields (CAPI delivery, CRM source, currency, mappings, action source, webhook URL) and covers the important behavioral constraint on the secret. It is complete for an AI agent to understand what it does and what to expect.
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 single optional parameter 'business_id' is fully described in the input schema with a clear description. The description adds no additional meaning beyond the schema, and schema coverage is 100%, 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 it fetches the Conversions API configuration for a business and lists specific fields: CAPI delivery, CRM source, currency, stage-to-event mappings, action source, and webhook URL. It distinguishes from sibling tools like set_capi_config and rotate_webhook_secret by emphasizing its read-only nature and the write-only secret behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use: 'Use this before configuring CAPI to see what is already set, or to audit the current event mapping.' Also specifies when not to rely on it for the full webhook secret and points to the sibling tool zuckerbot_rotate_webhook_secret as the alternative.
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 full burden. It discloses the poll returns all_complete=true when jobs finish and notes intelligence activation is temporarily disabled. However, it doesn't mention rate limits or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with purpose, then usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with 1 param and no output schema, the description covers purpose, usage, return value, and a state note. It feels complete given the 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 coverage is 100% with campaign_id described as 'Intelligence campaign ID'. The description adds no extra meaning beyond this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the async upload queue for a campaign to see if Meta ad-creation jobs are complete. It uses specific verb 'check' and resource 'queue', and distinguishes itself from siblings like zuckerbot_upload_creative and zuckerbot_get_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to poll this after zuckerbot_upload_creative when creative_status='uploading', providing clear when-to-use context and an alternative (the upload tool).
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?
Without annotations, the description fully discloses critical behavior: the new secret is returned exactly once in this response, and every other read shows only metadata. The old secret stops authenticating immediately. This goes beyond basic purpose to explain side effects and one-time nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences front-loaded with the action. Every sentence adds essential information: purpose, one-time return behavior, and immediate invalidation. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (new secret in response, only once) and the condition (old secret stops working). For a single-parameter tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the sole parameter (`business_id`), and the tool description does not add any additional meaning to what the schema already provides. 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 the specific verb 'Rotate' and resource 'Conversions API webhook secret for a business', clearly identifying the tool's function. It is distinct from sibling tools which cover other operations like deleting audiences, getting insights, or syncing conversions, making it easy for the agent to select correctly.
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 the immediate effect (old secret stops authenticating) and the necessary follow-up action (update the system that signs inbound webhooks). It implies the tool should be used when ready to update, but does not explicitly list when not to use it or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: for accounts with history, it returns aggregated metrics, top creatives, and CPL ranges; for new accounts, it returns is_cold_start=true and industry benchmarks. This transparently sets expectations about the two distinct outcomes based on account history.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences: one explaining the tool's function for both account types, and one providing usage guidance. Every sentence is valuable and there is no redundancy, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers return values (aggregated metrics, top creatives, CPL ranges for history; is_cold_start and benchmarks for new accounts). It also explains the cold start scenario. However, it could be slightly more detailed on the exact format of aggregated metrics, but overall it is sufficiently complete for its role as a first-step analysis 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 baseline is 3. The description does not add significant new meaning beyond the schema; it reiterates parameter purposes (e.g., business_id auto-resolves, lookback_days range, target_audience optional check). No additional semantics are provided, so score remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes historical ad performance for a business, distinguishes between accounts with history (returns aggregated metrics, top creatives, CPL ranges) and new accounts (cold start flag with industry benchmarks), and positions it as the first step in campaign planning. This is specific and differentiates from sibling tools like zuckerbot_get_account_insights.
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 instructs 'Use this as the FIRST step in campaign planning — feed the result into zuckerbot_recommend_campaign_structure.' This provides clear context and a sequential workflow, effectively guiding the agent on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![zuckerbot MCP server](https://glama.ai/mcp/servers/DatalisHQ/zuckerbot/badges/card.svg)](https://glama.ai/mcp/servers/DatalisHQ/zuckerbot)

Score Badge

Copy to your README.md:

[![zuckerbot MCP server](https://glama.ai/mcp/servers/DatalisHQ/zuckerbot/badges/score.svg)](https://glama.ai/mcp/servers/DatalisHQ/zuckerbot)

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/DatalisHQ/zuckerbot'

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