toffu

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds meaningful context about the breadth of returned diagnostics (EMQ match-key coverage, freshness, per-group A/B results), which is genuinely useful beyond the annotations. It does not disclose latency, data freshness windows, or rate-limit behavior for external Meta calls, so a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence that front-loads the domain and then enumerates outputs. It is efficient and has no filler, though the parenthetical stacking is slightly hard to parse on first read compared to a short lead plus bullets.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't detail return shapes, and it correctly avoids that. It gives enough topical surface for an agent to know what diagnostics come back. It stops short of telling the agent when this tool is the right call versus its siblings, which is the main remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already documents the `sections` enum and the `account_id` override with defaults. The description mentions the same section categories (opportunity, pixels, catalogs, ab_tests) but adds no syntax, default behavior, or dependency detail beyond what the schema states. Baseline 3 applies when the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific domain (Meta ad account health) and enumerates the concrete outputs: opportunity score with ranked recommendations, pixel EMQ diagnostics, catalog diagnostics, and A/B test results. This is a clear read-oriented verb+resource. It does not, however, distinguish itself from the lookalike diagnostics in query_campaign_performance or creative_report, leaving the sibling boundary slightly ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to reach for this tool versus query_campaign_performance, creative_report, or get_account_context, and no exclusions. For an agent choosing among nine siblings, the description provides no routing signal beyond the topic itself.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds real context: server-side budget hard-limits apply, per-operation results are returned, and undo availability is signalled, which is what makes destructiveHint=false credible. It does not state auth/permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with zero filler, and the core action and its source are front-loaded before the caveats. Every sentence carries distinct information (source, constraint, return behavior).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be detailed, and the description still notes per-operation results and undo availability. Budget hard-limits are disclosed, which matters for a non-idempotent mutation. Failure modes (e.g. what happens on a stale or unapproved proposal_id) are left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter (proposal_id) with 0% schema description coverage, so the description must compensate. It does explain the provenance and required state of the value ('a confirmed proposal from propose_change'), which is the key semantic an agent needs. It does not describe the ID format or where to obtain it if the proposal was created elsewhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Execute) and a specific resource (a confirmed proposal from propose_change), and the phrasing 'confirmed proposal' distinguishes it from the sibling propose_change that creates the proposal. An agent can immediately tell this is the commit step, not the drafting step.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is clear: this is the execution step following propose_change and prior confirmation, with undo_change available as the inverse. It does not explicitly say when NOT to use it (e.g. unapproved proposals) or spell out the approval prerequisite, so it stops short of the full when/when-not treatment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavior (rows sorted by spend, default limit of 50 by spend) but says nothing about pagination, rate limits, or freshness of the data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that names the resource and scope before listing contents. The long metric parenthetical is dense but each item is informative rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and required dates plus defaults are handled by the schema. For a read-only reporting tool this is largely complete, with only pagination or data-freshness notes missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all five parameters are already documented in the schema, including the date format, account override, and conversion_events default. The description's metric enumeration adds framing but no new parameter-level semantics, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (Meta Ads creative-level performance) and enumerates exactly what each row contains: creative fields plus a full metric list, sorted by spend. This clearly delineates it from the campaign-level sibling, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not guidance is given. The only routing hint is the passing remark that conversion_events behaves the same as in query_campaign_performance, which implies a relationship but never states the condition for choosing one report over the other.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond them: the precedence rule ("These rules override your defaults") and the exact content categories returned. It does not discuss result size, pagination, or failure modes, but the presence of an output schema lowers the burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences with the imperative call-to-action front-loaded, followed by payload contents and the precedence caveat. No filler, no restatement of the title, and every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value structure need not be explained, and the description still summarizes the payload categories. For a zero-required-parameter read-only context tool, an agent has everything it needs to decide to call it first and how to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single optional 'skills' parameter is fully documented in the schema, so the baseline is 3. The description mentions skills as part of the returned payload but adds no syntax, naming, or selection semantics beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific retrieval action and enumerates its payload precisely: owner's standing rules (conversion events, data sources, targets, currency, scope), knowledge-base sheets/docs, skills, and connected ad accounts. This is clearly distinguishable from the sibling action tools (apply_change, propose_change, undo_change), which mutate rather than fetch context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Call FIRST before analyzing or changing this company" gives an explicit ordering rule and a clear trigger condition, which is strong guidance for a context-priming tool. It stops short of stating exclusions or an alternative fetch path, but for this tool none is apparent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real behavioral context by disclosing that this is a polling operation with an expected interval and a terminating status. It does not say what happens on non-'done' terminal states or how long to keep polling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the purpose and then the operational instruction. No filler, no repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple polling tool whose return values are covered by an output schema, the description covers purpose, trigger, cadence, and terminal state. The remaining gap is handling of error or non-'done' outcomes, and the session_id source is only implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter (session_id) with 0% schema description coverage, so the description must compensate. It implicitly conveys that session_id comes from the send_message call, but never names or describes the parameter itself, leaving the value's origin to inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('collect the answer') and ties it to the sibling tool send_message, so an agent can distinguish it from send_message, propose_change, or query_campaign_performance without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives the precise triggering condition (a send_message call that returned status='working') and the polling cadence (~30s) plus the terminal condition ('done'). It lacks any explicit when-not-to-use guidance or mention of failure/timeout statuses, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=false and openWorldHint=true, so the safety profile is partly covered, but readOnlyHint=false leaves ambiguity about whether this mutates state. The description resolves that by clarifying it only stages for review and 'Does NOT create anything', which is genuinely additive. It still omits permissions, idempotency behavior, and what staging produces (covered by the output schema), so it is not 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the primary action front-loaded and the key non-behavioral fact ('Does NOT create anything') immediately after. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a 100% covered schema and an output schema present, the description needn't explain parameters or return values, and it correctly clarifies the non-creation semantics. However, for a propose-stage tool the critical missing context is the follow-up path (what applies the staged test, whether approval is needed), which the agent cannot derive from the structured fields alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter already carries rich inline documentation (date constraints, cell structure, percent defaults, account override). The description adds nothing about parameters, so the baseline of 3 for a fully documented schema applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Stage a Meta A/B test (split test)') and adds the scope qualifier 'for review', so an agent understands this is a proposal operation. It stops short of naming the sibling that would execute the test (apply_change), so differentiation is implied rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no when-not guidance, and no named alternative such as apply_change or propose_change. 'Stage for review' hints at a propose-then-apply workflow, but the agent must infer which sibling commits the staged test.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds substantively beyond them: no execution occurs, a proposal_id plus current→new diff is returned, proposals expire in 1h, and the human-confirmation gate before apply. This is rich behavioral context the annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The non-execution and workflow constraints are front-loaded, and every line adds needed information given the 0% schema coverage. It is dense, but the density is warranted rather than redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description still surfaces the return contract (proposal_id + diff preview) and the lifecycle (1h expiry), and covers all operation field semantics. An agent has everything needed to build a valid proposal and route to apply_change correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% with a single loosely-typed 'operations' array, so the description carries the full burden and does so: it defines platform values, level values with the ad_set→Google-ad-group mapping and campaign default, object_id meaning, account_id purpose, and per-platform constraints (daily_budget only for Meta campaign/ad set or Google campaign; ads take status only), plus the MAJOR-unit currency caveat.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (stage/propose) and resource (campaign changes) and immediately bounds the scope with 'Does NOT execute anything', which cleanly separates it from the apply_change sibling. An agent can distinguish propose from apply without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit workflow routing: 'Show the preview to the user; call apply_change(proposal_id) only after they confirm.' This names the alternative tool and the exact condition that selects it, plus the 1h expiry constraint. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine context by stating results are merged and normalized across platforms, but it says nothing about coverage gaps (e.g. breakdown/level restrictions to Meta, LinkedIn's whole-range behavior) or latency/cost of querying all platforms at once.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; the platform list and the merged-table outcome are stated compactly without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. Still, for an 8-parameter cross-platform query tool with subtle platform-specific behavior (Meta-only breakdowns/levels, LinkedIn ignoring time_increment), the description omits any operational caveats an agent would need to call it well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (level, platforms, breakdowns, time_increment, conversion_events, account_ids) is already documented in the schema. The description adds the 'omit all connected' framing for the platform scope but no new syntax or format detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The sentence names a specific resource (campaign performance) and an explicit scope (all connected platforms, merged into one normalized table), which is far more informative than a restated title. It does not, however, differentiate itself from siblings like account_health or creative_report, so an agent gets no explicit routing signal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use, when-not-to-use, or alternative-tool guidance anywhere in the description. The agent must infer from the name alone that this is the cross-platform performance reporting tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the safety envelope is already partly covered. The description adds genuinely useful context beyond that: mutations require approval, the agent acts on the company's connected accounts, and long tasks emit progress before a final answer. It stops short of stating what persists or how approval is granted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and the sibling-distinguishing rule are front-loaded, and the capability list is packed but relevant to scoping. It runs slightly long and the capability enumeration is dense, but every clause carries selection-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and the description still covers capabilities, approval, and progress behavior. The only gap is the unsignposted relationship to get_task_result for async completion, which is a minor completeness miss rather than a blocker.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both message and session_id are already fully documented in the schema, including the 'omit on first message' semantics. The description adds nothing about parameter format or usage, so the baseline 3 for a well-covered schema applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a precise verb and resource: delegate a marketing task or question to the Toffu agent, and enumerates the concrete action classes it covers (analytics, diagnosis, campaign/adset/audience edits, content, reports). It explicitly distinguishes itself from the sibling query_campaign_performance by scoping itself to 'anything beyond raw campaign metrics.' An agent can pick this tool without reading either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit routing rule ('Use for anything beyond raw campaign metrics') and notes that write actions happen 'with approval.' It does not, however, address the get_task_result sibling or explain how the 'progress' emission relates to polling for long-running tasks, leaving a real ambiguity in the when-to-use story.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds genuinely new behavioral context: the 24-hour expiry and the guarded refusal that prevents clobbering a concurrent change. It does not explicitly address idempotency or what the caller observes on refusal/expiry, so it is not fully comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste, with the core action front-loaded and the constraints following in priority order. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the mutation semantics plus preconditions are well covered. What remains thin is the post-refusal caller experience (error vs. status) and any permission requirements, but the essentials for correct invocation are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the meaning of proposal_id. Saying the tool reverts "an applied proposal" ties the ID to the output of apply_change and implies a non-arbitrary identifier, which is meaningful, though it does not spell out the expected ID format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb+resource ("Revert an applied proposal") and further qualifies it as restoring "the values read just before it was applied." This clearly separates it from the sibling apply_change/propose_change without needing to open any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the eligibility window ("Available for 24h after apply") and the refusal condition (objects no longer hold what the apply wrote), which effectively defines when to use and when not to. It stops short of naming alternatives for the post-24h or stale-state cases, so it is strong but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.