UGC Agent

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

Annotations already cover the safety profile (readOnly, non-destructive, idempotent, openWorld), so the description's job is to add context, and it does: it discloses the transcription fallback logic ('actual video openings when possible, else caption openings') and the caching side effect ('results persist on the leads for 24h'). The persistence note is a state change not implied by readOnlyHint, but it is a benign caching side effect of an analysis tool rather than an outright contradiction of the read-only claim.

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, front-loaded with the core computation, then the usage question, then the persistence caveat. No restatement of the name or title, and every clause carries information an agent would otherwise have to infer.

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 9-parameter, zero-required, no-output-schema tool, the description adequately explains what comes back (ranked per-creator virality plus top videos with captions and hooks) and when to reach for it. It omits prerequisite state (that kept leads must already exist) and any cost/latency warning for the transcription path, small but real gaps for a tool that can transcribe video.

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 already carries its own documentation (defaults, caps, enum meanings, uid/token fallbacks), which sets the baseline at 3. The description adds meaning only at the aggregate level — it explains the virality formula and what 'top videos' contain — without illuminating any individual parameter beyond the schema.

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?

Names a specific chain of operations (fetch posts → compute virality as max views vs followers → rank → return top videos with captions/hooks) on a specific resource set (kept creators). The 'kept creators' scope and the virality metric readily separate it from siblings such as analyze_seed_creators, find_viral_trends, and discover_creators.

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 an explicit usage trigger with a natural-language example ('which of my creators have the most viral videos and what hooks do they use'), which is stronger than implied usage. It stops short of naming alternatives or exclusions — there is no statement like 'use analyze_seed_creators for non-kept creators' — so it lands at clear-context-but-no-exclusions.

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 openWorldHint=true, idempotentHint=true and non-destructive, so the safety profile is covered. The description adds nothing beyond them: it doesn't say that results depend on stored/override preferences, that analyzing is a networked, potentially slow operation, or what the produced 'criteria' look like.

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

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

One front-loaded sentence with no waste, but it is thin enough that it omits the return value and statefulness the tool actually has.

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?

This is a 6-parameter tool with durable conversation state, preference modes and no output schema, yet the description says nothing about what it returns (derived criteria? a list_id?) or how conversation_id affects follow-ups. For this complexity the description is materially incomplete.

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 83%, so the schema already documents uid, bearer_token, conversation_id, preferences_mode and agent_preferences. The description only hints that the input is a set of example creators, adding no detail on handles limits or preference modes; 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 verb (Analyze) and resource (example Instagram creators) plus the intent of the output (derive criteria). It implicitly distinguishes itself from discover_creators by positioning itself as the upstream 'seed' step, but 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?

'before sourcing similar creators' gives a clear sequencing cue that tells the agent this is a pre-sourcing step rather than the sourcing tool itself. No explicit exclusions or named alternatives, which keeps it at a 4 rather than 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?

The description provides essential behavioral context not found in the annotations or schema, specifically detailing the field collection order, the immediate write/scheduled run sequence, and the mandatory timezone canonicalization logic (never pass 'local').

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 description is dense but highly effective. Every sentence contributes critical operational instruction, including constraints on timezone handling and the execution timeline, demonstrating high informational efficiency.

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?

The description is extremely complete regarding the implementation constraints. It handles the interaction pattern (multi-turn), system requirements (IANA conversion), and lifecycle of the object (immediate write/scheduled run) without needing to describe the output schema.

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?

Since schema description coverage is 100%, the baseline is high. The description adds value by dictating the conversational sequence of parameters (e.g., 'criteria or Agent Preferences' comes first, followed by 'lead_count'). It also adds the crucial constraint regarding timezone resolution.

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 tool clearly defines its function: creating a lead automation. Furthermore, the description goes beyond just the outcome by defining the *process* of data collection (collect explicit values one missing field at a time).

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

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

While it doesn't explicitly name sibling tools to contrast against, it provides detailed instructions on the mandatory multi-turn conversational flow required to use this tool. This conversational guidance helps the agent decide when this tool is necessary versus a simple configuration 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?

With annotations already covering safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds real behavioral context the annotations cannot: creation commits immediately with no confirmation step, the first run is scheduled at the returned next_run_at rather than running now, and Region Global is fixed product behavior. It still omits what happens on duplicate/repeat calls (idempotency semantics) and whether the automation is active on creation.

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 sentences, front-loaded with the elicitation order, then the timezone constraint, then the write/schedule consequence. Dense and mostly waste-free, though sentence one is a long comma chain and the trailing "Region Global is fixed product behavior" reads as an appended caveat rather than integrated guidance.

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 14-parameter, zero-required mutation tool with no output schema, the description covers the happy-path elicitation well but leaves gaps: it references "the returned order" and "the returned next_run_at" without explaining what the response contains or how follow-ups should reuse it. It also never explains what the automation actually does once created or how the returned record maps to pause_automation/run_automation_now.

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 only 43%, so the description must compensate, and it does for the critical fields: it establishes ordering, marks weekday/day_of_month as conditional on frequency, requires an exact-format daily_time, mandates a canonical IANA timezone resolved from 'local'/a city (explicitly forbidding the literal 'local'), and frames recipient_email vs. account email as a choice. The auth/session params (uid, bearer_token, conversation_id, preferences_mode, agent_preferences) receive no mention, which the description leaves entirely to the schema.

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 body never states plainly what the tool creates — the closest is "creation writes immediately", which implies a persisted resource but never says this schedules a recurring trend-research report on Instagram/TikTok delivered to a recipient. The concrete values listed (topic, platform, frequency, daily_time, recipient) let an agent infer the artifact's shape, but the purpose comes largely from the name/title, not the description. It also does not distinguish itself from create_lead_automation or update_trend_research_automation.

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 a strong interaction protocol (collect one missing field at a time, in the returned order), which is genuine usage guidance for the create flow. However there is no guidance on when to prefer update_trend_research_automation over creating a new automation, no prerequisites, and no exclusions. Usage is implied by the elicitation sequence rather than stated as when/when-not.

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=true, idempotentHint=true and readOnlyHint=false, so the description earns credit for going further: it discloses that deletion is a *soft* delete (data not hard-removed), that a token gates the call, and that stale tokens are rejected. It stops short of saying whether the soft-delete can be restored or what happens to the automation's run history.

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, zero filler, and the most decision-critical fact (destructive soft-delete) is front-loaded before the preconditions. Every clause carries operational weight.

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 destructive mutation with no output schema, the description covers the safety contract (preview → confirm → token) that an agent most needs. It is slightly incomplete on post-conditions — no statement of what the caller sees on success or what happens to dependent runs — and notably the schema marks zero parameters required despite the description saying the token is required.

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 71%, so the schema carries most parameter meaning, but the description adds real semantics for confirmation_token — that it must be current and that stale values are rejected — which the schema's bare type declaration does not convey. automation_id remains undescribed in both places.

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 the operation type precisely ("Destructive and idempotent soft-delete") and names the sibling tool it pairs with (preview_automation_deletion), which separates it from update_automation and pause_automation. The resource (an automation) is only implied via the tool name rather than stated in the description text, which keeps it just short of a 5.

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

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

Explicit gating: only call after preview_automation_deletion was shown AND the user explicitly confirmed in a new turn. It also names the precondition artifact (current confirmation_token) and the failure mode (stale tokens rejected), leaving nothing about when-to-call 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 destructiveHint=true and idempotentHint=true, but the description adds substantial detail beyond them: it stops a running search, revokes share links, removes results, deletes the transcript, and is irreversible. It also explains the preview/confirmation-token workflow, which is important behavioral context for a destructive operation.

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

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

Three dense sentences with zero waste. The irreversible consequence and confirmation flow are front-loaded before the procedural detail, making the definition easy to scan.

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 destructive mutation with no output schema, the description covers consequences, irreversibility, and the required two-step confirmation. Combined with the fully documented input schema and destructive annotations, an agent has enough information to call it 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 100%, so the schema already documents all five parameters, including the confirmation_token workflow. The description reinforces that workflow but does not add meaning beyond the schema for uid, chat_id, list_id, or bearer_token, so the baseline 3 is appropriate.

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 uses a specific verb and resource, 'Permanently delete one of the user's chats,' and immediately lists the exact side effects. It distinguishes deletion from siblings like get_chat, rename_chat, and reset_conversation by emphasizing permanence and transcript removal.

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 clear procedural guidance for the two-step confirmation flow: first call returns a preview and token, second call happens only after user confirmation. It does not explicitly name alternatives such as get_chat for inspection or preview_automation_deletion, but the usage context is otherwise clear.

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

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

Annotations already declare openWorldHint=true, idempotentHint=false, and destructiveHint=false, but the description adds meaningful behavior by saying candidates are queued for enrichment. It also clarifies that queries are searched independently and are never concatenated or replaced with a fixed taxonomy. It omits details about auth, rate limits, or duplicate handling, but the annotations lower the disclosure 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?

The description is three sentences and front-loads the core action before moving to query usage and similar_to guidance. Every sentence contributes useful information with no 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?

For an 8-parameter open-world tool with no output schema, the description covers the main search-and-queue workflow and the two most important query parameters. However, it does not explain max_results behavior, return structure or list_id handling, or how this differs from sibling discovery/search tools, leaving meaningful gaps.

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 63%, so several parameters are already documented in the schema, including uid, bearer_token, conversation_id, and preferences_mode. The description adds real meaning for queries and similar_to by explaining independent query execution and snowballing, but it does not cover max_results or the preference parameters beyond what the schema provides.

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: search Instagram + TikTok for creator candidates and queue them for enrichment. It is clear what the tool does, but it does not explicitly distinguish itself from nearby siblings such as find_brand_creators or search_ugc_database.

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 clear usage context: pass many varied queries per call because each query is searched independently, and use similar_to to snowball off already-qualified Instagram handles. It does not explicitly state when to choose this tool over alternatives, so it falls short of the highest level.

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, idempotentHint and destructiveHint=false, and the description reinforces this with 'returns text only; nothing is sent'. It adds genuinely new context beyond annotations: the cost ('Free') and the fact that the output is unstructured text with no persisted side effect.

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 clauses, all front-loaded: what it does, what it does not do, and what it costs. No filler, nothing repeated from 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?

The absence of an output schema is offset by 'Returns text only', and side effects are explicitly ruled out, which covers the essentials for a 4-param, 2-required tool. Minor gaps remain: nothing about the tone/format of the drafted reply or whether the draft is retrievable afterwards.

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 50%; the two auth-related params (uid, bearer_token) are documented in the schema, but application_id and decision have no schema descriptions. The description echoes the decision enum values in prose but adds nothing about application_id or the auth fallback semantics, so it does not compensate for the coverage gap. Baseline 3.

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 (draft), a specific resource (a reply for one applicant), and enumerates the three possible decisions. The clause 'nothing is sent and the status does not change' separates it from status-mutating siblings like update_application_status without needing to open 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?

The line 'nothing is sent and the status does not change' makes the use case (preview a reply before committing) and the boundary against update_application_status clear. It stops short of explicitly naming that sibling or stating when not to use it, 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?

The description provides a vital behavioral guardrail that annotations cannot cover: the prohibition against fabricating information ('never invents pay, proof, clients, or results'). This ensures the AI uses the tool responsibly and maintains data integrity.

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 description is highly efficient, using only two sentences. It front-loads the primary function and then uses the second sentence to establish necessary context and strict limitations.

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 text generation tool, the input structure is highly complete. The description successfully sets the scope and limitations of the draft. A score of 4 is given only because it lacks an explicit output schema, which would be helpful for confirming the format of the generated copy.

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?

Since the input schema has 100% coverage, the description does not need to define parameters beyond their existing documentation. It only adds semantic value by implying the overall output style must be 'short' and 'direct'.

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 purpose is extremely clear: to draft short, direct outbound copy specifically for creators. It distinguishes itself from other tools by focusing on drafting/copy generation, rather than sending or analyzing.

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 provides clear sequential instructions: 'Use it after keeping leads to write personalized outreach.' Furthermore, the critical constraint, 'never invents pay, proof, clients, or results,' defines a strict behavioral boundary for when the tool is appropriate to use.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the description adds real behavioral content: voiceover lines are explicitly drafts to be polished, and a hard constraint 'never add claims or results the user didn't provide' guards against fabrication. It also discloses the shape of what gets produced. It doesn't disclose that the call seeds durable conversation state (implied only by schema fields).

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 sentences, zero filler, with the output structure front-loaded and the two most actionable rules (polish voiceover, never invent claims) placed last for emphasis. Every sentence carries distinct 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 15 parameters and no output schema, the description usefully compensates by enumerating the return structure section by section, and it states the non-negotiable constraint. Minor gaps: no mention of the platform/format defaults that shape the script, and no note on the conversation_id/uid continuity that the schema treats as significant.

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 87%, so the schema already carries parameter meaning; description text adds no syntax, defaults, or format guidance beyond the implicit link between output sections and the cta/tone/concept inputs. Baseline 3 applies when the schema does the heavy lifting.

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?

Specific verb ('Draft') plus a precisely enumerated deliverable: hook with timing, body scenes with time ranges, shot directions, voiceover, on-screen text, CTA, caption, hashtags. That distinguishes it clearly from research/analysis siblings, but no sibling is named, so the contrast with ideate_ugc_content (referenced only inside the schema) is left implicit.

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 is implied rather than stated: the agent can infer this is the downstream step after concept generation, and the schema's concept description ('an idea title from ideate_ugc_content') hints at the chain. However, the description itself never says when to use this versus ideating or running the UGC agent, and gives no prerequisites or exclusions.

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 readOnly=false, idempotent=false, openWorld=true and destructive=false, so the bar is lower, and the description still adds real behavior: follower bounds never auto-widen, the effective band is echoed back via applied_follower_bounds and follower_policy, and unqualified creators are dropped rather than returned. It does not disclose whether enrichment consumes credits or how queue state is mutated, which keeps it below 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?

The core action is front-loaded in the first clause, and the three sentences each carry distinct policy (qualification, follower band, agency email toggle). It is appropriately sized for a 14-parameter tool, though the parenthetical condition on email relaxation is dense enough to slow parsing.

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 14-parameter, non-idempotent, open-world tool with no output schema, the description covers qualification and follower policy but omits how the 'queued candidates' mode is populated, what happens to filtered-out creators, and what the response contains beyond the two echoed policy fields. Adequate but with clear gaps for such a complex tool.

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 79% and min_followers/max_followers already document their 100/9999 defaults, so the description mostly restates the schema's follower policy. It does add the important cross-cutting rule that the band applies in every mode without auto-widening, but says nothing about handles, niche, batch_size, conversation_id, or preferences_mode. Baseline 3 for high schema coverage plus one genuine addition.

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 two-stage action: enrich queued candidates or explicit Instagram handles, then keep only qualified on-niche creators with emails. That is a clear verb+resource statement an agent can act on. It stops short of naming which sibling to use instead (discover_creators, find_brand_creators), so differentiation is only implied through the schema's brand-collab note.

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?

Useful conditional rules are present: the email requirement is relaxed by the accept-no-email preference or an explicit 'emails optional' request, and exclude_agency_emails is only for direct/personal email or no-agency requests. However, there is no statement of when to pick this tool over discover_creators or find_brand_creators, nor any prerequisite such as a prior discovery run populating the queue.

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 cover readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely new context: the full column set returned, the whole-CRM default (a size/scope warning), and that the operation is Free, which is cost information no annotation conveys.

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 tight sentences: output shape first, then the three input modes, with the no-argument default front-loaded before the convenience note. No 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?

With nine optional params, no required fields, and no output schema, the description carries the return-value burden and does so via the column list. Minor gap: nothing about size limits or truncation behavior on a whole-CRM export, which matters for a 1000-item maxItems lead_ids tool.

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 67%, and the description compensates by explaining the lead_ids path, delegating filter semantics to list_crm_leads ('the same filters as'), and defining the omit-all default. It does not enumerate individual filters like tag/stage/has_email, but the delegation note keeps it understandable.

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 (Export) and resource (Creator CRM creators) and enumerates the exact CSV columns, so the agent knows both the action and the output shape. It is clearly distinct from list_crm_leads (read/list, not export) and from the generic export_csv sibling, which does not mention CRM creators.

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?

Explicitly gives two selection modes — pass lead_ids, or the same filters as list_crm_leads — and states the default: omit everything to export the whole CRM. It lacks an explicit exclusion versus the sibling export_csv, so the agent still has to infer which export tool to pick.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond them: what the caller receives back (a CSV plus an app_url) and what scope applies when lead_ids is omitted. It says nothing about export size limits or the uid/URL mismatch constraint documented in the schema.

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

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

Two sentences, no filler, and the output shape is front-loaded ahead of the default-scope rule. Nothing here repeats the title verbatim or wastes tokens.

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 six optional parameters, 83% schema coverage, no output schema and no nested objects, the description is close to sufficient: it covers what is returned and the default filter scope. The remaining gap is sibling disambiguation against export_crm_csv, which the description never addresses.

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 83%, so the baseline is 3. The description goes beyond the schema for the one undocumented parameter, lead_ids, explaining that omitting it exports the entire kept-lead set for the conversation. It adds no meaning for conversation_id, preferences_mode, or agent_preferences, which is acceptable because those are already documented.

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+resource ('Return a CSV of kept leads') and even states the return shape (CSV plus app_url for table review/export). It does not, however, distinguish itself from the sibling 'export_crm_csv', which an agent must otherwise infer from the name alone.

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?

'Omit lead_ids to export all kept leads in the MCP conversation' is a useful default-scope rule, and 'table review/export' hints at the use case. But there is no explicit when-to-use/when-not guidance and no routing between this tool and export_crm_csv, list_leads, or export of CRM records.

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?

With annotations already covering safety (readOnly=false, idempotent=false, openWorld=true), the description still adds substantial context: it discloses the data sources, that authors are queued as candidates 'with proof', that brand-owned accounts are excluded, and that posts older than 18 months are discarded. This explains the surprising side effect of queuing candidates, which the annotations alone would not.

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?

Four sentences with the differentiator front-loaded ('Content-first search...'), followed by mechanism, exclusions, and the pipeline requirement. No filler; each sentence carries distinct 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?

For a 7-parameter tool with no output schema, it explains the mechanism, the exclusion rules, and the required hand-off to enrich_and_score. It leaves paging/result caps and the effect of preferences_mode to the schema, which is reasonable given 86% coverage.

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 86%, so the schema already documents uid, bearer_token, conversation_id, preferences_mode, and agent_preferences. The description only reinforces the `brands` parameter via 'passing the same brand names in `brands`' and does not add meaning for max_results or the preferences plumbing. 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 verb and resource with a sharp qualifier: creators who ALREADY made content for specific brands, and lists the three search surfaces (Instagram posts tagging the brand, brand hashtags, TikTok keyword videos). This cleanly separates it from discover_creators, search_ugc_database, and track_creators.

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 an explicit mandatory follow-up ('ALWAYS follow with enrich_and_score passing the same brand names in `brands`') and the schema reinforces researching brands with research_company first. It lacks an explicit when-not clause or a direct contrast with sibling search tools, so not a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open world), so the bar is lower. The description still adds real value by disclosing partial-failure behavior — 'Evidence remains available when generation is partial or fails' — and by characterizing the sources (TikTok/Instagram posts plus grounded web). It omits rate limits, latency, and auth expectations that the schema only hints at via bearer_token.

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 sentences, front-loaded with the verb and output shape, then sequencing, then the resilience note. Dense but each sentence carries distinct information. The trailing resilience sentence is the least essential, keeping it just under top marks.

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 9-parameter research tool with no output schema, the description does the important work: it describes the return shape (1-5 trends with proof links, observations, usage guidance) and the failure semantics. With all parameters schema-documented, the remaining gap is minor — nothing on latency or how conversation_id follow-ups behave beyond the schema field.

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 is already documented in structured form and the baseline is 3. The description adds no syntax or format guidance beyond what the schema states; the '1-5 validated trends' phrasing also risks being read as the limit parameter, which actually governs collected posts (default 12).

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 and resource ('Collect ... posts and grounded web sources', 'return 1-5 validated trends') and names the concrete artifacts returned: proof links, observations, safe usages. It also distinguishes itself from the nearest sibling by naming ideate_ugc_content, so an agent can route without opening schemas.

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

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

Gives an explicit ordering rule: 'Use before ideate_ugc_content for trend-aware ideas.' That is a clear when-to-use signal tied to a named sibling. It stops short of stating when NOT to use it or pointing to adjacent alternatives (e.g. analyze_seed_creators, research_company) for already-known topics.

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 readOnly/idempotent/non-destructive, so the safety burden is lifted; the description adds genuinely new context — the figures are 'as the web app sees it' and team members share the owner's pool, which affects how an agent should interpret the numbers. It does not cover staleness or failure behaviour for unauthenticated calls, keeping it below 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?

The payload-bearing content comes first, followed by a short usage directive, which is the right ordering. The trailing one-word fragment 'Free.' is ambiguous and slightly undercuts an otherwise tight three-part structure.

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 two-parameter read tool with no output schema, the description does the work of describing the return payload field-by-field and adds the pool-sharing rule an agent needs to interpret it. What it lacks is authentication expectations and whether results vary by plan tier in ways that change tool selection.

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 both uid and bearer_token are documented in-schema including the local-fallback caveat. The description adds no parameter-level guidance (e.g. when a caller should supply uid versus relying on the URL), 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?

Names a specific resource (the account's plan and usage) and enumerates its contents — lead pool used/remaining, API quota, automation and tracking limits, UGC Brands access. That enumeration separates it cleanly from neighbours like get_preferences or get_tracking_dashboard, which are settings- and data-dashboards respectively.

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 two concrete triggers: 'before large searches or unlocks' and 'when the user asks about limits', which implicitly routes budget checks ahead of unlock_ugc_database_creators and search-type tools. It stops short of naming a sibling or stating when not to call it, so it is clear context without explicit alternatives.

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, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description's enumeration of returned content is modest added value, but it says nothing about auth requirements despite the schema hinting at non-trivial auth (URL uid matching, local fallback, bearer tokens).

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 zero filler; the payload contents are listed in the most scannable position possible. Nothing could be removed without losing 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 no output schema, the description's field list is the only spec of what comes back, which is genuinely useful for a five-parameter context-fetch tool. But it stops at names, giving no sense of return structure, size, or when the call is expected in an agent's lifecycle, leaving a gap for a bootstrap-style tool.

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?

All five parameters carry 100% schema description coverage, including the preferences_mode enum and the interaction between agent_preferences and preferences_mode. The description adds nothing beyond the schema, so the baseline of 3 applies.

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

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

The verb 'Return' plus a concrete enumeration of the payload (auth mode, plan, usage, preferences, service config, operating instructions) makes the tool's output scope unambiguous. However, it never distinguishes itself from siblings like get_preferences or get_account, which overlap conceptually with the 'preferences' and account/plan content named here.

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 call this tool, no prerequisites, and no named alternative. Notably, get_preferences is a direct sibling that also surfaces preferences, yet the description gives no rule for choosing between them, leaving the agent to infer.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the meaningful qualifier 'owned' (authorization scoping) and the polling-implies-repeatability behavior, but says nothing about what an in-progress or failed run returns or whether the call blocks.

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 verb and resource lead and the payload enumeration trails. It could be trimmed slightly, but every clause conveys a real capability.

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 no output schema and seven parameters (zero required), the description should have closed the gap on run identification and polling cadence, and it does not. It does at least scope the result set to owned runs and name the result categories, which is the minimum an agent needs to decide to call 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 coverage is 71%, but the two undocumented parameters are run_id and automation_id — precisely the identifiers needed to fetch a single run — and the description gives no hint how to identify the run or whether either is required (required list is empty). The remaining params (uid, bearer_token, conversation_id, preferences_mode, agent_preferences) are documented in the schema, so the description adds nothing.

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 (poll) and resource (one owned automation run) and enumerates what the caller learns: status, progress, errors, delivery state, trend results. That separates it from list_automation_runs, but it never distinguishes itself from the sibling get_run_status, leaving a real ambiguity unresolved.

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?

The word 'poll' implies repeated use after kicking off a run, which is useful implied guidance, but there is no explicit statement of when to use this versus get_run_status or list_automation_runs, and no note about when a run is finished. Usage must be inferred.

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 cover read-only, idempotent and non-destructive, so the description's added value is the ordering guarantee ('oldest message first'), the content inventory, and the cost note ('Free'), which is genuinely useful for deciding whether to fetch. Pagination behavior is left to the schema rather than described, keeping it from 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?

What it returns is front-loaded, followed by the use case, the identification options, and a one-word cost note. Every sentence carries distinct information and there is no 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?

For a read-only single-resource fetch with no output schema, the description covers what is returned, in what order, how to identify the target, and the cost. Nothing an agent needs in order to call it correctly is 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 the baseline would be 3; the description earns an extra point by explaining the two key identifiers semantically — chat_id comes from list_chats, list_id from run_ugc_agent — which clarifies that they are alternative ways to target the same chat. It says nothing about limit/cursor, which the schema already handles.

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 ('Read one of the user's chats') and enumerates exactly what comes back: requests, agent answers, step summaries, run progress and the result table id. It is clearly distinguishable from siblings like list_chats (enumeration) and delete_chat/rename_chat (mutation).

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 a concrete use case ('recall what was asked and found earlier') and tells the agent how to obtain the two identifiers, pointing at list_chats and run_ugc_agent. It does not state an explicit when-not-to-use or name an alternative retrieval tool, 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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the cost is free, the payload shape is enumerated, and list_id alters scope rather than adding a filter dimension. It does not address auth, though the schema does.

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 payload contents are front-loaded in the opening clause, with the list_id scoping and cost note trailing. The enumerated metric list is dense but every item is a real return field; the one-word 'Free.' sentence is terse and useful 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?

For a read-only, zero-required-parameter summary tool with no output schema, the description effectively doubles as the return-contract by listing every reported aggregate. The only missing piece is a hint that this is the natural entry point before drilling into individual leads or lists.

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 uid, list_id and bearer_token are all documented and the baseline of 3 applies. The description restates the list_id scoping behavior already in the schema and says nothing about uid or bearer_token, so it adds no meaning beyond the structured fields.

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 and deliverable: a CRM pipeline summary plus the user's custom lists, enumerating exactly what aggregates come back (creators per stage, in-conversation counts, committed deal value, tasks due, list id/name/size). The aggregate-count framing makes it obviously distinct from list_crm_leads and manage_crm_list without having to name them.

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?

Only guidance offered is the conditional 'Pass list_id to scope the pipeline to one list' and the note that it is free. There is no explicit statement of when to reach for this overview versus list_crm_leads or manage_crm_list, so the when-to-use is implied rather than stated.

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

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

Annotations already cover readOnly, idempotent, non-destructive, closed-world, so the safety profile is handled. The description adds non-annotation value: the cost signal ('Free'), the conceptual shape of the response (preferences plus excluded-creator count), and the opt-in behavior of include_excluded_emails. It omits any mention of pagination behavior despite limit/cursor existing, which is the main remaining gap.

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?

Four tight sentences, front-loaded with what is returned, then the parameter hint, then the usage trigger, then the cost note; every sentence carries information. Parentheticals are dense but not padded.

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?

No output schema exists, so the description must convey return content — and it does, naming the preference fields and exclusion count. With 5 params including limit/cursor, the absence of any pagination note is the one substantive omission; otherwise complete for a simple read tool with full annotation coverage.

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 80%, with include_excluded_emails being the one undocumented parameter — and the description explicitly explains what it does (lists excluded emails, i.e., creators already worked with). That is exactly the compensation needed. It adds no extra detail for uid/limit/cursor, but the schema already documents those.

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?

Specific verb 'Read' plus a precisely scoped resource: the user's saved Agent Preferences, with the two key contents enumerated (default creator criteria, whether email-less creators are accepted) and the exclusion count. This is clearly distinguishable from update_preferences and from the search/discovery siblings it influences.

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 an explicit triggering condition: 'Check this when results look unexpectedly narrow,' which links this read to debugging search outcomes. It also implicitly separates the read path from update_preferences, but it doesn't state exclusions (e.g., don't call this to change settings, or that it isn't needed before every search).

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 establish that this is a safe read-only, idempotent, non-destructive operation. Beyond that, the description explains the polling behavior, what is returned while running (found_so_far and target), what is returned on terminal states (creators, stop reason, short explanation), and that the call is cheap, which is valuable because no output schema exists.

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 description is front-loaded with the core purpose, followed by timing, return behavior, and polling guidance. Despite being a single dense paragraph, every sentence contributes operational information and there is no 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?

With no output schema, the description appropriately explains the return behavior for both running and terminal states. It also covers polling cadence and when to stop, while the fully documented schema handles the remaining parameter details, so the definition is complete for correct invocation.

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 the schema already documents all six parameters, including uid, list_id, bearer_token, conversation_id, preferences_mode, and agent_preferences. The description adds only limited parameter meaning by reinforcing the list_id relationship to run_ugc_agent, which merits the baseline score rather than a higher one.

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: it polls a search started by run_ugc_agent. It clearly distinguishes this tool from run_ugc_agent, which starts the search, and from stop_run, which stops it, so an agent can identify the tool without opening the 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?

The description gives explicit timing and conditions: call about 30 seconds after run_ugc_agent or a previous get_run_status returned 'running' or 'queued', and reuse the same list_id. It also specifies polling every 30 seconds until the status is terminal, leaving little to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the safety burden is light. The description adds meaningful beyond-annotation context: it is free on every plan and that viewing tops up stale data in the background, a non-obvious side effect. It does not describe pagination behavior despite a cursor parameter, which keeps it at a 4.

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?

Purpose is front-loaded with the view name, and the sentence is dense but information-rich with no filler. The long run-on enumeration of view contents would scan better as structured bullets, which is the only reason it is not a 5.

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 12-parameter tool with no output schema, the description does the important work of describing what each view returns, effectively standing in for the missing output schema, and it notes plan availability and background refresh. It omits pagination semantics and authentication guidance (uid vs bearer_token vs API key), preventing a 5.

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 high (83%), so the baseline is 3, but the description adds real value for the undocumented `view` parameter by explaining what each enum value produces, and it clarifies `mode`/`metric` are overview-only and `collection_id` targets a single collection. Minor gaps remain around uid, bearer_token, and account_ids interactions.

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 resource (the Creator Tracking dashboard) and enumerates what each of its four views (summary, overview, payouts, collections) returns, so an agent knows exactly what it is fetching. It does not explicitly distinguish itself from siblings such as list_tracked_accounts or refresh_tracking, keeping it below a 5.

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?

By listing what each view contains, the description implicitly guides the agent to pick the right view, which is genuine usage guidance for the main selector. However, it never states when to use this dashboard versus sibling tools like list_tracked_videos or refresh_tracking, and offers no exclusions or prerequisites.

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 readOnly/idempotent/non-destructive, so safety is covered. The description adds genuine context: tier gating, default 30-day window, and provenance discipline ('cite those when quoting a rate' / sources with quote and check date). However, it doesn't cover pagination behavior or error/permission failure modes, so it sits at a solid but not rich 3.

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?

Front-loaded with the core resource statement, then organized by view mode. Dense but each clause carries information (pay model details, tier gates, defaults). The long run-on sentences for pay/overview slightly hurt scannability.

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 11 params, no output schema, and annotations covering safety, the description does the heavy lifting of explaining what each view returns and the tier prerequisites. Remaining gap: it doesn't detail the pagination/cursor contract even though a cursor param exists, but schema covers it adequately.

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 91%, so baseline is 3. The description goes beyond by explaining the view enum semantics (which are undocumented in the schema), window options and defaults ('window 7d/30d/90d/365d/all, or from/to dates; default last 30 days'), and the range block behavior — meaningful additions to the structured fields.

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 (one brand's UGC program) and verb (retrieval), then enumerates three distinct view modes with their contents. An agent can tell exactly what it gets and how it differs from list_ugc_brands or list_ugc_brand_creators.

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?

Per-view guidance is explicit: overview for how the program runs and pay, videos for sorted video data, playbook 'to brief creators on a proven program.' Tier availability (Free/Pro/Premium) is also stated. It lacks explicit when-not-to-use or naming of sibling alternatives, so not a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds the materially useful 'Free' cost signal versus paid unlocking. It also discloses that returns include the user's unlock access and remaining leads, which is behavioral context not present in any annotation. It does not state whether the facet counts respect the uid/view parameters or how heavy the aggregation is.

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 purpose is front-loaded in the first clause, which is good, but the middle is a single sprawling 20-item enumeration that reads as a dump rather than a structured summary. The closing sentences ('Use it to...' and 'Free.') are efficient; the facet list could be trimmed substantially without losing selection value.

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 30 parameters, no required params, and no output schema, the description bears real weight for explaining what comes back, and it does list the returned dimensions including access state and remaining leads. That is enough for an agent to decide when to call it, though it omits whether the response is nested per facet and how the uid/view parameters interact with the counts.

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 73%, so the schema carries most of the burden and baseline is 3. The description's facet enumeration loosely mirrors the parameter list and confirms that values like proven/for_hire/has_rates and rate fields exist as filter dimensions, but it adds no syntax, ranges, or semantics beyond what the schema already documents. Several parameters (uid, bearer_token, added_within_days, max_followers) get no mention at all.

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+resource: it shows what the UGC Database holds for a set of filters, and it enumerates exactly what is counted (niche, country, tier, platform, rates, access). It also distinguishes itself from the search and unlock siblings by framing itself as the pre-flight step ('size an audience before searching or unlocking'). An agent can tell this apart from search_ugc_database and unlock_ugc_database_creators without opening 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?

Explicit when-to-use: 'to pick valid filter values and to size an audience before searching or unlocking.' The alternatives are referenced by function rather than by tool name, so the agent must map 'searching' to search_ugc_database itself. 'Free' adds a strong contrast to the costly unlock path.

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 readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real behavior: the output is deliberately unfinished scaffolding that must be rewritten, and it depends on upstream trend data. No contradiction with annotations. Auth/uid and durable-state behavior are left to the schema.

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

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

Three dense sentences with no filler: purpose first, then the scaffolding warning, then the trend_context pointer. Each sentence changes how an agent would call or present the tool.

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 13 optional parameters and no output schema, the description compensates by describing the exact shape of each returned idea and the state of the output (scaffolding, not final). Nothing an agent needs in order to call and correctly present results is 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 92%, so the baseline is 3; the description adds genuine meaning by explaining how brand/product/audience/pain_points are combined and by specifying that trend_context is the summary object returned by find_viral_trends, which the schema only hints at. The remaining 13 parameters (uid, bearer_token, preferences_mode, conversation_id) are covered by the schema, not the prose.

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 and resource ('Generate structured UGC video ideas') and explains the mechanism: crossing a named library of short-form formats with brand/product/audience/pain points. It also enumerates the output's anatomy (hook, 3-beat outline, why it works, CTA), which separates it from downstream siblings like draft_ugc_script that produce finished copy.

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 two concrete usage rules: pass trend_context from find_viral_trends for trend-aware ideas, and rewrite the scaffolding before presenting. That names an upstream sibling and its condition. It stops short of an explicit when-not-to-use or a named handoff to draft_ugc_script for the rewriting step.

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?

Adds substantial behavior beyond annotations: re-import performs an upsert rather than duplicating, preserves existing status, and enforces a 1,000-row cap. 'Free' also communicates the cost profile, which is not captured anywhere in structured fields. The upsert-and-preserve semantics is exactly the kind of write behavior an agent cannot infer from idempotentHint alone.

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, front-loaded with the core action and format, then the dedupe behavior, then the optional scoring. Nothing is redundant with the title or schema.

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 write tool with no output schema, the description covers input sources, limits, dedupe semantics, and cost, which is most of what an agent needs. It does not say what a successful import returns (counts of created vs. updated, row-level errors), a modest gap for a bulk mutation.

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 the baseline is 3, but the description adds real meaning on top: the 1,000-row limit is a constraint on the required `csv` parameter not present in the schema, and 'Pass criteria to pre-score them' explains the effect of `criteria` rather than just its shape. `source` and the auth parameters are left entirely to the schema.

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 and resource ('Import creator applications') plus the accepted input formats (CSV or plain-text export). It is clearly distinguishable from siblings like list_applications, review_applications, and update_application_status, so an agent can route correctly.

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 clear operating context — bulk import from form exports, up to 1,000 rows, with optional criteria pre-scoring. It does not explicitly say when to prefer this over per-applicant alternatives, but the bulk-vs-single distinction is strongly implied by 'up to 1,000 rows' and the export-source framing.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: result ordering ('best fit first'), the fields surfaced, and cost ('Free'). It does not discuss paging behavior despite a cursor parameter.

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 sentences, front-loaded with the core capability and sorting rule, then the single-record mode, then the usage cue. The field enumeration is long but each item conveys what will be returned, so little is wasted.

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 no output schema, the description usefully enumerates returned fields and the two result shapes (list vs single application). The main gap is pagination guidance for a tool that exposes limit and cursor; otherwise an agent has what it needs to call 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 67%, with limit, cursor and uid documented in the schema. The description compensates for the undocumented application_id by explaining it switches to a single-application view that additionally includes account and video analysis. It says nothing about the status enum filter or interaction between filters.

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+resource ('list the user's imported UGC creator applications') and enumerates the fields returned (status, fit score, recommendation, handles, answers, review notes) plus the sort order. It implicitly separates this read from mutation siblings like review_applications and update_application_status, though it never names them.

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?

'Use before reviewing or drafting responses' gives a clear ordering cue relative to draft_application_response and review_applications, and 'Pass application_id for one application' explains the single-record mode. There is no explicit when-not-to-use statement, keeping it 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 readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the default (20) and cap (100) on results, which is genuinely useful behavior. However, it does not disclose ordering of runs, and since the schema exposes no offset/cursor parameter, an agent cannot tell that results beyond 100 are unreachable without changing filters.

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, front-loaded with what is returned and scoped to whom, with the limit behavior appended. No filler or restatement 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?

With 7 optional parameters, 71% schema coverage and no output schema, the description is thin: it never explains run ordering, whether omitting automation_id lists runs across automations, or how preferences_mode changes the result set. Adequate to call the tool, but leaves real ambiguity about what comes back.

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 71%, above the point where the schema does most of the work, so a 3 is the baseline. The description only adds the default value for limit; the more consequential parameters (conversation_id, preferences_mode, agent_preferences) are untouched, and the phrase "for an owned ... automation" implies automation_id is required when no parameter is actually required.

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 ("List") and resource ("normalized run history") scoped to "an owned lead-sourcing or trend-research automation." This distinguishes it from get_automation_run (single run) and list_automations by implication, though it never names those siblings 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?

The second sentence is pagination mechanics, not usage guidance. Nothing says when to use this vs. get_automation_run for a single run, or vs. list_automations when the automation id is unknown, and there is no mention of what happens when automation_id is omitted.

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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description earns credit for adding non-obvious behavior: unsupported legacy records are filtered out, so an agent should not treat the result as a complete inventory. It stops short of describing pagination or ordering.

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 with zero filler: scope and returned fields first, then the exclusion caveat, then the usage rule. Everything is front-loaded and each clause carries distinct 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 no output schema, the description usefully signals the return payload (lifecycle state and recent status) and the coverage caveat (legacy records excluded). The five optional auth/preferences parameters remain entirely on the schema, but nothing critical to calling it correctly is 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 description coverage is 100% and all five parameters (uid, bearer_token, conversation_id, preferences_mode, agent_preferences) are documented in the schema itself. The description adds no parameter guidance at all, so the baseline 3 applies — the schema does all the work here.

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?

Names a specific verb (List) and a precisely scoped resource (the authenticated user's lead-sourcing and trend-research automations), plus what each record carries (lifecycle state, recent status). This clearly separates it from sibling tools like list_automation_runs, get_automation_run and the create/update/delete automation tools.

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?

Explicitly frames the call as a prerequisite: 'use this before editing or deleting an automation,' which gives an agent a concrete decision rule. It does not, however, contrast itself with list_automation_runs, the closest alternative an agent might pick by mistake.

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 readOnly/idempotent/non-destructive/closed-world, so the description only needs to add operational context — and it does: sort order, the two fields returned, and the pagination convention ('Pass next_cursor back as cursor for the next page'). It omits what happens when the cursor is exhausted or page is empty, which is a minor gap.

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 sentences, each doing distinct work: what is returned, why to call it, how to paginate. No filler and the crucial scope/ordering detail is front-loaded.

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 zero-required-param read-only list tool with fully described schema and explicit annotations, the description covers the only things left open: return fields, ordering, and pagination. Nothing an agent needs in order to call it correctly is 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?

With 100% schema coverage the baseline is 3, but the description adds genuine meaning by explaining the output-to-input round trip between next_cursor and cursor. limit and uid are left to the schema, which already documents both adequately.

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 and resource ('List the user's chats') plus scope ('as they appear in the app.ugcagent.app sidebar'), ordering ('newest first') and returned fields ('id and title'). This separates it cleanly from get_chat and the many other list_* siblings.

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?

Explicitly routes the agent downstream: 'Use it to find the chat_id to pass to rename_chat.' It does not name the alternative for reading message content (get_chat) or state exclusions, so it falls short of a full when/when-not pair.

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, idempotentHint=true and destructiveHint=false, so safety is covered structurally; the description adds genuinely new signal with the cost note "Free, no leads used" and clarifies that lead_id overrides other filters. It does not discuss pagination semantics beyond the cursor parameter, which keeps it from 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?

Three sentences plus a short contrast clause, front-loaded with what the tool returns, then the single-record path, then the sibling distinction. No sentence is 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?

With no output schema, the description compensates by enumerating the record fields returned, and annotations cover the safety profile for a 13-parameter read tool. Minor gaps remain around pagination behavior and how multiple filters intersect, but nothing blocks correct invocation.

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 69%, so the schema documents most parameters (tag, cursor, search, lead_id, list_id, limit) themselves. The description reinforces only lead_id and search semantics and adds nothing about sort, stage, platform, or how filters combine — the baseline for partial coverage.

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 and resource ("List creators saved in the user's Creator CRM") and enumerates the contents returned (pipeline stage, deal terms, tags, notes, tasks, activity). It explicitly separates itself from list_leads, a sibling an agent would otherwise confuse it with.

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 concrete routing rules: pass lead_id for a single full record, use search to find a creator by name or handle before updating, and do not confuse it with list_leads which reads a single search's result table. The when-to-use-for-what pattern is explicit rather than implied.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds only that full rows are returned and the scope is the current conversation, without explaining 'kept,' limit behavior, fallback auth, or how durable state works.

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 description is a single front-loaded sentence with no filler. It is concise and easy to scan, though its brevity contributes to the ambiguity noted elsewhere.

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 tool with six optional parameters, durable conversation state, and multiple sibling list tools, the description is too sparse. It leaves key concepts such as 'kept' leads and the relationship to list_crm_leads unexplained, though the schema covers most parameters and no output schema exists.

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 83%, so the parameter documentation largely carries the burden; the description adds no parameter-level meaning. A baseline 3 is appropriate because the schema itself explains uid, bearer_token, conversation_id, preferences_mode, and agent_preferences.

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 verb ('Return') and resource ('full kept lead rows'), but 'kept' is undefined and the scope 'this MCP conversation' is vague. It does not distinguish this tool from sibling list_crm_leads or clarify what kind of leads are returned.

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 guidance on when to use this tool instead of list_crm_leads, list_applications, or other lead-related siblings. The only contextual clue is 'this MCP conversation,' which does not tell an agent when this tool is the right choice.

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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds that campaigns come from an external connected account (Instantly/Smartlead) and are 'Free', plus the accepts_leads filter nuance. It does not describe pagination behavior or result shape, but the schema's limit/cursor largely cover that.

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, front-loaded with the core action and scope. No filler; each sentence adds a distinct piece of information, though it is sparse rather than rich.

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 read-only list tool with well-documented parameters (83%) and no output schema, the description covers purpose, source accounts, and the key filtering nuance. It is sufficient to call correctly, though it omits any note on what fields campaigns return.

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 83%, so the schema already documents provider, limit, cursor, search, uid, and bearer_token. The description only reinforces provider (Instantly/Smartlead) and the accepts_leads concept; with high schema coverage, baseline 3 is appropriate.

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 'List' and resource 'campaigns' scoped to the user's connected Instantly or Smartlead account, so the agent knows exactly what is being returned. It does not explicitly name the sibling (list_outreach_integrations, send_leads_to_campaign) it complements or differs from, so sibling differentiation is only implied.

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?

The 'accepts_leads=true can receive leads' line gives useful context that this list is consulted before sending leads, implying a workflow with send_leads_to_campaign. However, there is no explicit when-to-use/when-not guidance or named alternative, leaving selection 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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new context beyond them: the integration must be set up by the user in the app (not via this tool) and the call is 'Free' (no credit consumption), both of which affect agent planning.

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 compact sentences with no filler; the return content is front-loaded and the constraint follows. The opening 'Whether the user has...' is a sentence fragment, which makes the first read slightly awkward, but nothing is wasted.

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?

There is no output schema, so the description takes on the job of explaining the return payload — connection status, last campaign, auto-send flag — and it does so. Authentication is handled by the schema and safety traits by annotations, leaving no critical gap for a zero-required-param read tool.

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 both parameters (uid, bearer_token) are documented as optional in the schema itself. The description adds no parameter-level information, so the baseline 3 applies — the schema carries all the weight here.

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 the resource (Outreach integrations: Instantly/Smartlead) and enumerates exactly what is reported: connection status, last-used campaign, and the auto-send setting. The verb is only implied by the title ('List'), so it is not a textbook verb+resource statement, and no sibling such as list_outreach_campaigns is called out, but the reported content is specific enough to distinguish it.

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 explicitly states a when-not case: connecting a tool happens in the UGC Agent app under Integrations and 'cannot be done here', which prevents the agent from attempting a write through this tool. It doesn't contrast itself against list_outreach_campaigns or update_auto_send, which would be needed for 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 establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavior beyond annotations: what metrics are included, what the single-account view returns, that new accounts show pending until first scrape, and that the tool is free.

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 description is reasonably concise and front-loads the returned metrics before covering the single-account variant and pending-status note. It is dense but not wasteful; a small amount of structural separation could make it easier to scan.

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 read-only tool with no output schema, the description gives a useful summary of returned metrics and the richer single-account page contents. It is not fully complete on filtering combinations or pagination behavior, but those are partly covered by the schema and are less critical for correct invocation.

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 77%, so the schema already documents most parameters. The description elaborates on account_id mode and date-range scope, but does not add meaning for the other filters such as q, sort, platform, account_ids, cursor, or collection_id beyond what the schema already provides.

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 clearly identifies the resource (tracked creators) and the metrics returned for a date range, plus the single-account page mode. It does not explicitly distinguish this tool from overlapping siblings such as get_account or get_tracking_dashboard, so it stops short of a 5.

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

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

It implies usage through 'Pass account_id for one creator's page' and notes pending status for new accounts. However, it gives no explicit guidance on when to use this tool instead of siblings like get_account or list_tracked_videos, nor any exclusions.

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 readOnly/idempotent/non-destructive, so the bar is lower; the description still adds value by disclosing the returned metric set (important since there is no output schema) and the cost signal 'Free.' It does not mention pagination limits or cursor behavior, which are left entirely to the schema.

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

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

Roughly four telegraphic sentences with the payload description front-loaded and the two calling patterns and pricing note following in a logical order. Dense rather than padded, though it reads as a field dump in places.

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 16 optional parameters and no output schema, the description carries the return-value burden well by naming every metric column. It omits guidance on combining cursors with the many filters and on the default sort, which is the main remaining gap for correctly paginating a list this wide.

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 69%, so baseline is 3. The description reinforces the account_id+video_id pairing and the outlier_multiple sort key, but those are already documented in the schema, and key filters like uploaded_in_range, collection_id, platform and timezone get no extra meaning added in prose.

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?

Opens with a specific verb+resource ('Videos from tracked creators') and enumerates the exact metrics returned (views, views gained, outlier multiple, 24h/7d/14d/30d growth, engagement), which cleanly separates it from list_tracked_accounts and search_ugc_database. It stops short of naming a sibling tool outright, so it is clear but not maximally differentiated.

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 two concrete usage patterns: sort by outlier_multiple to surface viral videos, and pass account_id + video_id to get the single-video daily snapshot history. It never states when NOT to use it, nor points to the sibling to use for untracked/unenriched video discovery.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real behavioral context the annotations can't convey: 'possible' accounts are returned but excluded from KPIs, and the account_id mode returns a much richer per-account payload (all videos plus attribution reasons). The trailing 'Needs Premium or higher. Free.' is a confusing, apparently contradictory gate statement.

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 opening sentence is a dense fragment without a verb, and the final 'Needs Premium or higher. Free.' is a dangling, self-contradicting two-word tail that costs clarity rather than adding it. The middle content (KPI exclusion, account_id mode) is well placed, but the closing fragment should be resolved or removed.

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 10 parameters, no output schema, and no annotation detail on result shape, the description does explain the two result modes and the confidence/KPI caveat, which is the core an agent needs. It omits sort/order behavior and the pagination workflow (cursor + stable filters), which matter for a list tool at this parameter count.

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 60%, with limit, cursor, dedicated, uid and account_id documented in-schema. The description adds semantics for account_id (single-account mode) and for the confidence tiers, but says nothing about the undocumented sort enum or the platforms filter. Baseline 3 is right for a schema that carries most of the weight.

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 resource (creator accounts attributed to a brand's UGC program) plus the payload each carries (confidence tier, signals, 30-day output). It implicitly distinguishes this from UGC discovery/search by framing the result as already-attributed accounts, but it never names a sibling tool such as find_brand_creators or search_ugc_database, so the differentiation is inferential.

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 concrete usage context: use the list mode for a roster, and 'Pass account_id for one account with every video we hold and why it was attributed' describes a distinct second mode. It also states a plan gate (Premium or higher). It does not, however, say when to prefer this over find_brand_creators or discover_creators, so there are no explicit exclusions.

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?

The annotations already cover read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond annotations by noting the database is curated and free on any plan, which clarifies scope and access. It does not describe pagination or rate-limit behavior, 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?

The description is front-loaded with the core purpose, then gives usage guidance, then access/pricing context. It is compact and every sentence adds useful information without 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?

For an 11-parameter list tool with no output schema, the description explains what is returned at a useful level: program facts, 30-day KPIs, and all-time views. It also covers usage and alternatives, though it leaves pagination and filter behavior to the schema and annotations.

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 73%, and the schema already documents most filters and enums. The description mentions markets and all-time views in the return data, but does not add input-filter semantics for query, sort, sizes, platforms, categories, pay_rate, cursor, or pagination. Its parameter-level value is therefore adequate but not compensating for the remaining coverage gap.

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 action and resource: browse the curated UGC Brands database. It clarifies the domain (brands that run UGC creator programs) and the returned facts (program.pay, hashtags, markets, KPIs, all-time views). It also distinguishes this tool from research_company for brands not listed.

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 explicitly says when to use it: when the user asks how a known brand runs its UGC program or wants programs to copy. It also names research_company as the alternative for brands not in the curated database, giving a clear when-not condition.

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 flag destructiveHint=true and idempotentHint=true, so the description's real contribution is the blast-radius clarification that delete removes only the list while creators remain in the CRM, plus the two-step preview/confirm flow and the cost note ('Free'). It stops short of describing what create/rename do on duplicate names or what the response contains, but given the annotation coverage this is solid added context.

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, front-loaded with the operation set and immediately followed by disambiguation and prerequisites. Slightly run-on with parentheticals, but no sentence is 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?

For a 6-parameter mutation tool with no output schema, the description covers what an agent most needs beyond the schema: the danger model of delete, the confirmation protocol, sibling routing, and cost. Nothing essential to correct invocation is 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 description coverage is 83%, so the enum on `action` and the requiredness of `name`/`list_id` are already documented. The description reinforces the confirmation_token handshake but adds no new meaning about the `uid`/`bearer_token` auth alternatives or name length limits — baseline 3 is appropriate 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?

States a specific verb set (create, rename, delete) against a precisely scoped resource (the user's custom Creator CRM sidebar lists) and explicitly distinguishes it from search result lists, which is the most likely point of confusion.

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?

Names the companion call for inspecting existing lists (get_crm_overview) and the one for populating them (update_crm_lead list_ids), and states the precondition that delete requires the preview + confirmation_token step. An agent knows both when to call this and which route to take for adjacent needs.

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=true and idempotentHint=false, and the description reinforces the destructive path with 'Only delete when the user asks'. It adds genuinely non-schema behavior: the cost is free, the tool returns the updated creator, and log_touch has a state transition ('the first touch moves a sourced creator to contacted') that an agent could not infer otherwise. Auth details are left to the schema's uid/bearer_token descriptions.

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?

Front-loaded with the resource and scope, and every clause carries information — the action-to-parameter mapping, the date semantics, the side effect, and the deletion guard. It is a single dense run-on paragraph, which costs a little readability, but there is no filler to cut.

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 an 8-action, 12-parameter destructive dispatcher, the description covers scope, per-action parameters, return value, cost, and the key state transition. It leaves authentication and idempotency-retry behavior to the schema's own parameter descriptions, which is reasonable given they are documented there.

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?

With 67% schema coverage across 12 parameters, the description does real work by mapping each parameter group to its action (body/note_id for notes, title/due_at for tasks, task_id for complete/reopen/delete, channel/text for log_touch). It also adds format semantics the schema lacks: due_at accepts YYYY-MM-DD or ISO, and a bare date resolves to 09:00 UTC.

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 the resource precisely (one CRM creator's record) and enumerates the eight action values it accepts, so an agent knows exactly what operations are available. It does not, however, contrast itself with near-siblings like update_crm_lead or remove_crm_lead, so the boundary is only implicit in the action list.

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 guidance is limited to 'Only delete when the user asks' and the cost signal 'Free'. That gives a real when-not rule for the destructive path, but there is no routing guidance for choosing this tool over update_crm_lead, save_creator_to_crm, or list_crm_leads when a user asks to 'update a lead'.

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=true and idempotentHint=true; the description adds non-obvious behavior beyond them – that delete leaves creators tracked but collection-less, that delete requires a two-turn preview/confirm flow, and that update is a sparse patch. It also discloses the tool is 'Free', which is cost context annotations cannot carry. Missing: who can call it and what a create returns.

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?

Front-loads the action set, then layers domain semantics, then per-action details – a sensible ordering. It is dense and semicolon-chained, so a couple of clauses (the 'Free' aside) read as tacked on rather than integrated, but no sentence is 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?

For a 12-parameter, no-output-schema mutation tool, the description covers the high-risk parts: destructive delete flow, sparse update, and the matching semantics that determine what the collection actually measures. Gaps are minor – no mention of the auth/uid fallback or what the confirmation preview contains (schema covers the token mechanics).

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?

With only 50% schema description coverage, the description usefully compensates: it explains the operational meaning of match_terms (caption must contain a term), the starts_at..ends_at window as the counting scope, and that target_cpm/budget/posts_per_week drive payout and posting-target views rather than being mere fields. Primary keys (collection_id, name) are left entirely to the schema's own descriptions.

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?

Opens with a specific verb set and resource ('Create, update or delete a Creator Tracking collection'), then defines the domain concept (a campaign, posts matched by caption term within a date window). This distinguishes it well from list/get siblings, but it never names an alternative such as track_creators or untrack_creator, so an agent must infer the boundary itself.

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 per-action guidance: 'update changes any field you pass' establishes partial-update semantics, and delete is explicitly gated behind 'the preview + confirmation_token step'. No sibling tool is named as an alternative, so cross-tool routing is left implicit.

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?

The description adds concrete behavioral details beyond annotations: future scheduling stops, nextRunAt becomes null, and active runs/pending deliveries are unaffected. It also reiterates idempotency (already in annotations). It does not mention permissions or rate limits, but for a simple pause operation, this is quite transparent.

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 concise sentences, front-loaded with the core action and key behavioral effects. No filler or redundancy; every sentence 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?

For a mutation tool with no output schema and annotations covering safety, the description is nearly complete: it explains what the tool does, what happens to scheduling, and what is not affected. It could mention authentication needs or edge cases, but overall it provides sufficient context for an agent to invoke it correctly.

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

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

Schema description coverage is high (83%), so the schema already documents most parameters. The description does not add any parameter-specific meaning, and the one parameter lacking a schema description (automation_id) is not clarified in the description. Baseline 3 is appropriate given the high coverage.

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 (Pause) and resource (automation), and clarifies that active runs and pending deliveries are not canceled, which distinguishes it from delete_automation. However, it does not explicitly name sibling tools like resume_automation or delete_automation, so the differentiation is implicit rather than explicit.

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

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

The description implies when to use this tool (when you want to stop future scheduling but keep active runs) but does not explicitly state when to use it versus alternatives such as delete_automation or resume_automation. No exclusions or explicit comparisons are given.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered; the description adds the genuinely useful part – this produces a summary plus a confirmation token that must be relayed and awaited. It stops short of stating token lifetime, whether the preview expires, or what happens if the token is reused.

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, both load-bearing: the first establishes the read-only nature, the second gives the required agent workflow. The key constraint is front-loaded and there is no 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?

With six optional parameters, 83% schema coverage, and no output schema, the description usefully reveals that the return carries an automation summary and a confirmation token – information an agent would otherwise lack. It does not say which automation is selected when automation_id is omitted, a minor 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 description coverage is 83%, so the schema already documents uid, bearer_token, conversation_id, preferences_mode and agent_preferences; only automation_id is bare. The description adds no parameter meaning of its own, which is acceptable at this coverage level but earns no premium.

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?

"Read-only deletion preview" states a specific verb (preview) and resource (automation deletion), and it explicitly names the sibling it precedes, delete_automation, so an agent can separate the two without opening 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 workflow condition: show the summary and confirmation token to the user, then wait for a new confirmation turn before calling delete_automation. That is both the when (before a destructive call) and the ordering constraint, leaving nothing 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?

Goes well beyond the annotations by disclosing the 10-minute freshness window for both modes, that the no-account_id path is queued with numbers updating over the next minutes (async), and that the call is free. These are exactly the behavioral facts an agent needs and none are derivable from the readOnlyHint/idempotentHint flags.

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, front-loaded with the action, then the with/without branching, then the cost note. No filler 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?

With no output schema, the description covers timing, cost, and sync/async semantics well enough to call the tool correctly, but it never hints at what 'fresh numbers' contains or what the queued response returns, leaving the agent to infer the result shape.

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 75% (uid, bearer_token, idempotency_key documented; account_id bare), and the description fills the key gap by explaining that account_id switches the tool into single-creator synchronous refresh. It adds no guidance on uid, bearer_token, or idempotency_key, but those are already covered in the schema.

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 and resource ('Re-scrape tracked creators' latest videos') and immediately splits the two operating modes. An agent can distinguish this from track_creators, untrack_creator, and update_tracked_account 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?

Explicitly states when to pass account_id (refresh one creator now, synchronous fresh numbers) versus omitting it (queue all stale creators, asynchronous update). It does not name a read-only sibling such as get_tracking_dashboard or list_tracked_videos as the alternative when the agent only wants to view data, so it falls short of full when/when-not/alternatives coverage.

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 flag destructiveHint and idempotentHint, but the description adds what the annotations cannot: exactly what else is destroyed (notes, tasks, deal terms), that the operation is two-phase with a preview and confirmation_token, and that removed creators stay excluded from future searches. The token flow in particular is behavior an agent cannot infer from 'destructive'.

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 tight sentences: what it does, how the two-step confirmation works, and the lasting consequence. The destructive warning and the confirmation protocol are front-loaded where an agent will see them before acting.

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 destructive mutation with no output schema, the description covers the cascade, the confirmation protocol, and the post-removal search behavior. It does not say what the preview call returns or what auth/permissions are required, which the uid and bearer_token parameters hint at but never explain.

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 75% and the schema already describes confirmation_token, but the description reinforces the sequencing rule beyond the schema ('call again with the token only after the user confirms in a later turn'), which matters because it forces a turn boundary. lead_id, the one required parameter, has no description in either place, leaving a small gap.

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 and resource ('Permanently remove a creator from the user's Creator CRM') and immediately scopes the blast radius with 'including its notes, tasks and deal terms'. That cascade detail is what separates it from siblings like remove_leads or untrack_creator, so an agent can discriminate without opening the 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 clear operational context: it is destructive, needs a preview + user confirmation in a later turn, and removal is persistent ('not delivered again by searches'). It never names the alternative siblings (remove_leads, untrack_creator, update_crm_lead), so there is no explicit when-not guidance, which keeps it below a 5.

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