HypeFox

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

Annotations already establish idempotency and non-destructiveness, but the description adds important behavior: HypeFox makes each video about 30 hours before its slot, and approval may depend on real facts being added first. It does not discuss auth, failure handling, or return behavior, but it is well above the annotation baseline.

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 definition is front-loaded with the manual-mode scope and the batch approval action, then adds the timing behavior and alternatives. All sentences are relevant, though the in-app analogy is slightly expendable and the final Automatic-mode sentence is terse.

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 single-parameter action tool with annotations covering safety and idempotency, the description covers the main operational context: mode, timing side effect, prerequisites, and alternatives. It lacks response or failure details, but no output schema exists and the core invocation context is present.

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

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

There is only one parameter, plan_id, and schema coverage is 0%. The description usefully says where to find it ('the plan_id is in get_calendar'), but it does not describe its format or any validation constraints, so it only partially compensates for the schema 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 gives a specific verb and resource: approve every upcoming idea of a weekly plan at once. It also clearly distinguishes the batch action from approve_slot (one by one) and notes the manual-mode condition, so an agent can identify the operation 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?

It explicitly scopes use to Manual mode, names the alternative approve_slot for individual approvals, points to update_slot when real facts are needed first, and notes that Automatic mode approves ideas on its own. This is clear when-to-use and when-not-to-use guidance.

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

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

Adds genuinely non-obvious behavior beyond the annotations: HypeFox renders the video roughly 30 hours ahead and consumes one of the user's videos at that point. That is the kind of resource-side-effect disclosure an agent cannot get from readOnlyHint/destructiveHint/idempotentHint. It still does not say what state the slot moves to after approval or what happens if the user has no videos left.

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, purpose front-loaded, followed by the timing/side-effect and the conditional trigger. The parenthetical is slightly awkward but carries real information, so 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?

For a one-parameter mutation with no output schema, the description covers purpose, trigger, prerequisite, and the main side effect (video consumption). The remaining gap is outcome — what the slot looks like after approval and failure modes when no video is available.

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?

The schema has 0% description coverage and the description never mentions slot_id or where to obtain one. The parameter is a single self-describing identifier, so the cost is low, but no added meaning is supplied beyond the field name.

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 concrete verb and resource ('Approves an idea in the calendar'), so an agent knows this commits a slot's idea rather than a plan or a finished video. It stops short of explicitly contrasting with the adjacent siblings approve_plan, approve_video, or skip_slot, so the boundary is inferable rather than stated.

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 a real usage rule: 'In Automatic only slots that asked for real facts need it, after update_slot' — a condition plus a sequencing prerequisite. It does not cover the manual mode case or name what to do instead when the condition fails (skip_slot, change_slot_idea), so it is clear context without full 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 flag openWorldHint=true and destructiveHint=false, but the description adds genuinely non-structured information: approval is not an immediate post, it defers to the slot's time and networks, and public posting additionally requires explicit in-chat user consent after viewing. It omits reversibility (cancel_publication exists) and idempotency behavior.

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 no filler, but the phrasing is tangled: 'a ready video of the calendar that waits for it (Manual)' requires re-reading, and the colon-plus-parenthetical structure buries the key consequence. The outcome (it posts) should lead rather than trail the mode labels.

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 one-parameter, openWorld mutation with no output schema, the description covers the action's consequence and the consent gate, which is the critical piece. It leaves gaps the agent would care about: what happens on failure, whether approval is revocable, and which slot_id to supply.

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

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

There is one required parameter, slot_id, with 0% schema description coverage, and the description never mentions it or explains how to obtain a slot id. 'The calendar that waits for it' and 'its slot's time' only obliquely imply the slot concept, so the agent gets almost no semantic help beyond the schema's bare string type.

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 (approve / 'gives the OK') on a specific resource (a ready video in the calendar) and names the resulting effect: posting at its slot's time on the slot's networks. It does not differentiate itself from close siblings like approve_slot, approve_plan, or publish_video, so an agent must infer the boundary 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?

It splits usage into two named modes (Manual vs Public) and states the precondition for Public: the user must have watched the video and said yes in this chat. That is real conditional guidance, but it never says when to reach for this instead of publish_video or approve_slot, and it doesn't say whether Manual videos can also be approved here.

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 non-read-only, non-destructive, idempotent semantics, so the description isn't carrying the safety burden alone. It still adds real context beyond them: cancel is a publication-level operation and does not remove content already live on the network, which no annotation expresses.

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 the action and its granularity, then a clarifying caveat. Every clause adds information an agent needs to call this correctly.

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 one-parameter, non-destructive, idempotent tool with no output schema, the definition covers scope, ID sourcing, and the live-post caveat. It does not say what happens when the target post is already canceled or already live (error vs. no-op), which is the last remaining gap.

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

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

Schema coverage is 0%, so the description must compensate for the single undocumented parameter, and it does: it explains what publication_id identifies (one network of one video) and which endpoints surface it. It omits the ID format or an example, so it is not fully self-sufficient.

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 ('Cancels one scheduled post') and pins the unit of granularity to 'one network of one video', which an agent could not infer from the name alone. It stops short of distinguishing itself from near-siblings like retry_publication or move_publication.

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?

Tells the agent where to obtain the required identifier ('publication_id is in get_video or get_calendar'), which is concrete routing guidance. It also excludes a case ('posts already live are not deleted'), but never names the alternative tool to use for live posts or for rescheduling.

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 only flag destructive/non-idempotent/non-open-world; the description adds the crucial detail that it consumes one video credit (Paper Collage 2), that the old video is moved to the reserve, that the slot's scheduled posts are withdrawn, and that the slot keeps its time. That is exactly the context an agent needs before an irreversible action.

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 action and example, then behavior, then the sales toggle, then guardrails. It is dense but nearly every clause carries non-obvious information; the run-on construction makes it slightly harder to scan than it could be.

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 cover effects, side effects, and preconditions — which it largely does (credit use, reserve, withdrawn posts, confirmation requirement). What the call returns is not described, leaving a small gap for a destructive, non-idempotent operation.

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 already 86%, and the description still adds meaning: it explains the sales:true/false toggle's effect on slot kind and the DM keyword requirement for sales slots. Only slot_id and why are left 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 (change a slot's idea) plus the immediate consequence (remakes its video now), with a concrete example (a sales video at 16:05). It is clearly distinguishable from siblings like update_slot, move_slot, or make_video, which don't swap the idea and regenerate in one step.

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

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

Gives explicit exclusions: not for slots going out within the hour, already published, or mid-render. Also dictates the interaction protocol (show the user what changes, including the 70-20-10 mix, and act only on explicit yes). No sibling tool is named as an alternative, which keeps it from a 5.

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

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

Beyond the annotations (which only declare it as a non-readonly, non-destructive, non-idempotent, closed-world write), the description discloses the 20-characters-per-project quota and the side effect that use_in_videos makes this character apply to the next videos. It does not say what is returned on success, which matters somewhat given there is no output 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 dense sentences, front-loaded with the verb and resource, then the two input modes, then limits and the use_in_videos side effect. The telegraphic phrasing ('character_fields (get_catalog)') is efficient rather than wasteful, though it reads a bit compressed.

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 5-parameter mutation with a nested object and no output schema, the description covers input modes and quotas but leaves gaps: no return value, no indication of whether project is required or defaulted, and no note on name constraints beyond the schema's maxLength.

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 40%; the nested look subobject is thoroughly enumerated but name, project, and use_in_videos carry no schema descriptions. The description compensates partly by pointing at get_catalog for character_fields/character_presets and explaining that look fields override a preset, and it explains use_in_videos, but 'name' and 'project' semantics remain unstated.

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 — creating an AI character for the project's videos — and scopes it to a 'look' being either a full field set or a preset. The 'from a look' framing implicitly separates it from create_character_from_photo, but no sibling is named 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?

Gives clear usage context: two input paths (full look via character_fields from get_catalog, or a preset name with overrides), a hard cap of 20 per project, and the effect of use_in_videos. It stops short of explicit exclusions such as when to prefer create_character_from_photo or update_character instead.

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 only declare the non-read-only, non-idempotent, non-destructive profile; the description adds genuinely new operational facts: plan gating (paid), a rate limit (10/day), a size/format ceiling, and a privacy guarantee ('The photo is only looked at, not stored'). It also names the follow-on tool for modifying the result, which shapes 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?

Front-loaded with the core transformation, then constraints and privacy, with no repeated text from the title. One dense block rather than separated structure, but every sentence 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?

There is no output schema, and the description never says what a successful call returns (presumably a character, but the identifier needed for the follow-up update_character call is unstated). Prerequisites, limits, and the photo_url vs photo_base64 exclusivity are otherwise well covered for a mutation 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 0% across 5 parameters, so the description must carry the load. It explains photo_base64/photo_url well (formats, 3 MB cap, https link, implicit either/or choice) but says nothing about name (1-40 chars), project, or use_in_videos, leaving three parameters undocumented 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 a specific verb and resource ('Turns a photo of a person ... into a cartoon character') plus the derived attributes (skin, hair, beard, clothes). It also contrasts with a sibling by noting the result 'can be changed with update_character', and the from-photo scope is unambiguous against create_character.

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 preconditions: paid plans only, 10 photos/day cap, accepted input as base64 (JPEG/PNG/WebP, up to 3 MB) or an https link, and 'a selfie works best'. It also states the consent boundary ('only use photos of the user, or of people who agreed'). It never explicitly says when to pick this over the plain create_character sibling.

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 safety (readOnly=false, destructive=false, idempotent=false, openWorld=false), and the description adds real value beyond them: it pulls from saved setup answers with optional overrides, may also create a character, and triggers automatic navigation afterward. It stops short of saying a duplicate call creates a second project or what the response contains, which matters given idempotentHint=false.

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, front-loaded with the core action and source data, then conditional usage, then post-conditions. The closing "Then help them make the first video" is slightly extraneous to tool selection but is short and arguably useful onboarding 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 16-parameter, nested-object creation tool with no output schema, the description says nothing about the return value (project id? character id?), error behavior, or how saved answers interact with passed parameters when both exist. Annotations cover safety, but the operational picture is only partially complete.

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 16 parameters and only 63% schema description coverage, the description contributes almost nothing per-parameter beyond the phrase "plus any answers you pass here." The nested `sells`, `character`, and style/voice/people relationships are documented only in the schema, so the description neither compensates for the coverage gap nor adds meaning on top of it.

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 (creates) and resource (the project) and adds the source of truth: the saved setup answers plus any answers passed here, and the character if present. That distinguishes it from update_project and create_character reasonably well, 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?

"Use it for the first project and for more projects when the plan allows them" gives clear selection context and even surfaces the plan-limit constraint. It also describes what happens after creation (app advances to the chosen plan or into the app), but it does not state prerequisites such as setup answers needing to be saved first or what to do instead if a project already exists.

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

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

Annotations declare readOnly=false, destructive=false, openWorld=true and non-idempotent, but say nothing about side-effect visibility. The description supplies exactly that missing context: sending is public and immediate, requires an explicit in-chat confirmation, and is length-constrained (1–1,000 chars, 150 for TikTok public replies). That is material behavioral disclosure beyond the structured fields.

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

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

Three tight sentences, front-loaded with the action taxonomy then the safety gate then the limits. Nothing is redundant, though the TikTok 150-character note is slightly compressed and could read as a general limit at first pass.

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 public, open-world mutation with no output schema, the description covers the essentials: what each action does, the confirmation requirement, and character limits. It stops short of describing batch behavior (max 50 decisions, partial failures) or the return value, but those are secondary 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?

Top-level schema coverage is 0%: neither 'project' nor 'decisions' is documented in the schema. The description does explain the three action meanings and the text length bounds, which matches the nested schema descriptions, but it never mentions the 'project' parameter or clarifies where reply_id values come from.

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 ('applies the user's decisions on drafted replies') and enumerates the three concrete actions available: send as drafted, send with a new text, save without sending, skip. An agent can immediately tell this is the execution step for drafts, distinct from listing 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?

Gives explicit per-action semantics plus a hard precondition: show the exact final text and act only on the user's explicit yes in this chat. It does not, however, route the agent relative to siblings like list_pending_replies (where reply_ids come from) or publish_video/approve_video, so the boundary between this and other approval tools 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known; the description adds genuine domain context beyond that — existing videos retain the character, and future videos fall back to a faceless random narrator until another character is chosen. It does not state whether deletion is reversible or requires permissions, which keeps it out of 5 territory.

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 and immediately followed by consequences and the confirmation requirement; nothing is padding. The parenthetical about Cartoon Storytime is slightly noisy but conveys the fallback behavior concretely.

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 single-parameter destructive tool with annotations covering the safety profile and no output schema, the definition covers the consequences of deletion and the user-confirmation requirement. The only real gap is the identifier format for character_id.

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

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

There is a single required parameter with 0% schema description coverage, so the description must compensate. The phrase 'if it was the one used in the videos' implies it identifies a specific existing character, but it never clarifies whether character_id is an ID, slug, or name — the schema leaves that open.

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

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

The description opens with a specific verb and resource ('Deletes a character'), which maps unambiguously to the tool name and clearly separates it from update_character, create_character, and delete_videos. It does not explicitly name a sibling as an alternative, but the operation is unambiguous.

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?

'Confirm with the user first' gives a concrete precondition before invoking, and the downstream effects tell the agent when caution matters. It stops short of naming alternatives (e.g. update_character if the goal is only to modify), so it falls just below full when/when-not guidance.

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

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

Annotations declare destructive=true, but the description adds the important context: the action is irreversible, associated files are removed, in-progress videos cannot be deleted, and the remake path returns a new_video_id. That is genuine side-effect and outcome disclosure beyond the annotations.

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 and the irreversibility warning, which is the right priority. The nested parenthetical about remake timing is dense and slightly convoluted, but every clause carries operational meaning.

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 two-parameter tool with no output schema, the description covers preconditions, irreversibility, confirmation, and the one return value it exposes. It stops short of stating batch semantics (partial failures, behavior when some ids are ineligible), which matters at maxItems 50.

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?

The description fully explains the `planned` enum semantics (remake vs leave_empty, when each applies, and the one-hour threshold), which the schema only labels superficially. It does not however clarify `video_ids` beyond the name (source of ids, max of 50, mixed valid/invalid handling), leaving part of the 50% coverage gap unaddressed.

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 ("Deletes ready or failed videos ... and their files"), and immediately narrows scope by excluding videos still being made. An agent can distinguish this from retry_video, cancel_publication, or delete_character 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?

Explicitly names the precondition (only ready or failed videos), the confirmation step ("confirm with the user first"), and the branching rule for scheduled videos via the `planned` enum. It also spells out the alternative behaviors and the timing condition (>1 hour away), 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 this is a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds useful context about the payload contents and even a token-cost comparison to get_started, which is behavior beyond the annotations. It doesn't discuss auth or rate limits, but those are minor for a no-param read.

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 and returned fields are front-loaded in the first sentence, with the sibling comparison second. The enumeration of fields is dense but each item maps to a real part of the payload; it is appropriately sized for a tool with no schema to explain the return shape.

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 must convey what comes back, and it does so by enumerating plan status, video counts, renewal dates, quotas, voice, subscription, and locked features. That is substantially complete for a read-only account snapshot, though it doesn't describe the response structure or formatting.

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?

The tool takes zero parameters, so the baseline is 4 per the rubric. The description adds no parameter meaning because none exists, and nothing is missing.

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 states the resource: the user's current plan, remaining videos, renewal/trial dates, project quotas, voice, subscription, and locked features with unlock paths. It distinguishes itself from get_started but does not clarify how it differs from the sibling get_plans. An agent can tell what it returns, though one sibling comparison is left ambiguous.

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

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

It explicitly names an alternative ('Cheaper than get_started when you only need the plan'), giving a clear selection condition. It doesn't mention when to prefer get_plans or get_started instead, so the routing guidance is one-sided rather than complete.

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 genuinely non-obvious behavior: a minimum 3-hour spacing constraint against other posts, scores in the 0-1 range, and the best time being flagged. It doesn't say what happens when no history or audience data exists, which would round this out.

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 dense sentences that front-load the returned value and then the caveat about video_id. Nothing is wasted, though the parenthetical about data sourcing slightly interrupts the flow of the first sentence.

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 does the right thing by describing the return shape (times with 0-1 scores, best one marked). The remaining gap is parameter definition — notably project and the days window — which an agent 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 0%, so the description carries the burden. It explains video_id's purpose well and implies days via 'the next days,' but never defines the days window (1-31), the default when omitted, or what 'project' identifies. Partial compensation only.

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 (suggested posting times for the project's audience) and adds the derivation logic (audience habits, or the account's own numbers when history exists). It doesn't name a sibling to distinguish from (e.g., get_calendar or get_plans could be confused with scheduling data), but the verb+resource is unmistakable.

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 only conditional guidance is 'Pass video_id when moving a video, so its own time doesn't block' — useful but narrow, covering one parameter rather than when to call this tool at all. There's no statement of when to prefer this over get_calendar or the slot-creation tools, so usage is implied rather than spelled out.

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 non-open-world, so the safety profile is covered. The description does add real behavioral context beyond that: results are merged from two sources (plan slots plus the user's own scheduled videos), rendered in the audience's time zone, and the per-slot allowed actions depend on the current mode. It stops short of covering limits, ordering or what 'warnings' and 'status' mean.

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 sentence then unrolls a long parenthetical field dump (idea, angle, format, role, hook, ending, keyword...) that is expensive to scan. A short structured list or a trimmed enumeration would carry the same information more cheaply.

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 correctly takes on the burden of describing the return payload and does so thoroughly, including side data (weekly plan explanation, per-slot permissions). The remaining gaps — the meaning of status/warnings and the behavior of the unscoped project parameter — are minor rather than blocking.

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 only reinforces the 'from'/'to' semantics via the default period. The 'project' parameter — the one undocumented in the schema — is only obliquely implied by "The project's calendar"; it never says whether omitting it defaults to the current project or spans all projects.

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 (the project's calendar for a period) and enumerates exactly what it returns: weekly plan slots, the user's scheduled videos, the current weekly plan and per-slot permissions. It is distinguishable from get_plans and list_videos by the calendar/period framing, although it never explicitly contrasts itself with those 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?

There is no statement of when to use this tool versus get_plans, get_best_times or list_videos, nor any prerequisite or exclusion. The only guidance is the implicit default window ('today and the next 7 days'), which is helpful but does not route the agent between 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 openWorldHint=false, so the safety profile is covered. The description adds the catalog's content scope and its role as an ID source, but it does not add operational behavior such as return shape, pagination, caching, or failure modes. With annotations carrying the safety disclosure, a 3 is appropriate.

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

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

The description is a single dense sentence that front-loads the key idea ('Every value you can use') and then enumerates distinct catalog sections. It is somewhat long, but nearly every clause names a concrete category of returned data, so the length is mostly earned.

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 no input parameters, the description must carry the burden of explaining what comes back. It does so by listing the catalog's major sections and some field details, such as styles with id/name/appearance/cost and countries with ISO codes. It stops short of describing the exact response structure, but it is complete enough for an agent to know what this lookup provides.

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?

The tool has zero parameters, so there are no parameter semantics for the description to explain. The baseline for a 0-parameter tool is 4, and nothing in the description is needed to compensate for schema gaps.

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 states that this is a catalog of every usable value and enumerates the exact categories it covers: styles, voices, niches, channels, countries, languages, character fields, phases, and mode differences. It also tells the agent how the result is used: 'Use these ids in the other tools.' This makes its purpose and scope distinguishable from action-oriented 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?

The line 'Use these ids in the other tools' gives clear usage context: call this to resolve reference IDs before invoking tools that need them. It does not explicitly state when not to use it or name alternatives, but the intended role is unambiguous for a reference/catalog tool.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful context beyond that: the link expires after 10 minutes, the file is MP4 with a readable filename, and free-trial videos carry a HypeFox watermark. It stops short of saying what happens when the video is not yet ready.

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

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

Two short sentences with no waste, and the most decision-relevant facts (format and expiry) are 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 simple read-only tool with no output schema, the description adequately conveys what comes back and how long it's valid. It is missing the readiness prerequisite for the video and any error behavior, which are the main things an agent could get wrong here.

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

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

Schema description coverage is 0% and the single video_id parameter is undocumented in both schema and description. The description never explains what video_id refers to, where it comes from, or what form it takes, so it fails to compensate for the 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 clearly identifies the resource (an MP4 download link for a video file) and its format, which distinguishes it from siblings like get_video or preview_video_edit. However, it is phrased as a noun phrase describing the return value rather than stating the action, and it doesn't explicitly name the sibling it differs from.

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 use this tool versus alternatives such as get_video, preview_video_edit, or list_videos. The prerequisite that the video must be approved/ready appears only in the title, not the description, so an agent gets no explicit guidance on preconditions or call ordering.

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 guide's topical scope but does not describe the return format, size, or whether the content is static; for a read-only documentation tool this is acceptable but not especially rich.

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 that starts with the core purpose and then lists covered topics. It is efficient, though the trailing get_started note is slightly ambiguous and could be clearer.

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?

Given the absence of parameters, rich annotations, and no output schema, the description is largely complete: the agent knows this returns the full HypeFox guide and what topics it covers. The remaining gap is that the relationship to get_started is only hinted at, not clarified.

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?

The tool has zero parameters, so the baseline is 4 under the rubric. The description appropriately does not waste space discussing arguments and instead focuses on what content the guide covers.

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 as 'The full guide to HypeFox' and enumerates its coverage areas such as projects, styles, voices, videos, calendar, posting, and plans. It is specific enough for an agent to know this returns comprehensive product documentation, though the mention of get_started including it blurs the sibling distinction rather than sharpening 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?

The description hints at an alternative by noting 'get_started includes it too', which implies the agent may not need get_guide if it already calls get_started. However, it never explicitly states when to prefer get_guide over get_started or vice versa, leaving the choice largely 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 establish this as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond annotations: the plan links lead to an app page where the user completes payment, and the agent itself cannot perform payment or plan changes.

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 two front-loaded sentences, each carrying useful information: first what the plans contain, then how the upgrade link works and the agent's limitation. There is no filler or repetition of structured fields.

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 parameters, no output schema, and annotations already covering safety characteristics, the description supplies the missing return-value context: plan prices, allowances, inclusions, extra-video pricing, and links. It is complete enough for an agent to know what to expect and how to direct the user.

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?

The tool has zero parameters, so there is no parameter semantics to document in the description. The baseline for a parameterless tool is 4, and nothing in the description misrepresents the input shape.

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 states the resource is HypeFox plans and enumerates the concrete contents: monthly and yearly prices, video/project allowances, plan inclusions, extra-video pricing, and per-plan app links. It distinguishes this informational lookup from plan-changing actions by explicitly noting that the agent cannot pay or change the plan 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?

It gives clear context for use: retrieve plan details and provide the user with the in-app link where payment happens. It also explicitly excludes payment or plan changes by the agent. It stops short of naming a specific sibling tool for plan approval, but the boundary is clear from the description.

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 structurally. The description still earns credit for adding two things annotations cannot express: an expected latency of ~10 minutes, and an explicit prompt-injection warning that 'What people asked' quotes UNTRUSTED public comments. It is held to 3 rather than higher because the latency note is buried in a parenthetical with no advice on long-running behavior.

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?

It is a single dense sentence that front-loads the report contents, with the security warning placed last as a self-contained clause. Nothing is redundant, though the trailing '(10 minutes)' is ambiguous — it reads as either generation latency or report-reading time — which slightly undercuts an otherwise tight 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?

With no output schema, the description carries the full burden of explaining return contents, and it does that well by enumerating the sections plus the PDF download link. What is missing is the input side: how to obtain report_id and whether the call is slow enough to need waiting/retry strategy. For a simple single-parameter read tool this is adequate but visibly 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?

There is one parameter, report_id, and schema description coverage is 0% — the schema supplies no type-level meaning beyond 'string'. The description never mentions the parameter at all, so it fails to compensate for the coverage gap, leaving the agent with no clue whether report_id is a slug, an integer, or must be fetched via list_reports.

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 enumerates exactly what a Monday report contains (per-network numbers, best/worst videos, audience questions, weekly plan learnings, next-week plan, PDF link), which is genuinely informative about the resource. However it is phrased as a noun phrase rather than a verb+resource statement, and it never distinguishes itself from the sibling list_reports, which an agent would also need to find report_id.

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 versus list_reports, and no guidance on where report_id comes from — which is the single prerequisite for invoking the tool. The only usage-adjacent signal is the parenthetical '(10 minutes)', which implies a slow call but doesn't say what to do about it.

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 the tool as read-only, idempotent, non-destructive, and closed-world. Beyond that, the description adds that it returns status and lines and that wait_seconds (up to 25) will wait for the script to be ready, which clarifies blocking behavior not captured by annotations.

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 two short sentences and front-loads the core return information and waiting behavior. Every phrase contributes directly to understanding 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 annotations covering safety and no output schema, the description sufficiently explains the main return content (status and lines) and the wait_seconds behavior. The main remaining gap is the lack of explicit definition for script_id, though the preview_script connection provides a usable clue.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains wait_seconds as a readiness wait capped at 25, but it does not explicitly define script_id beyond the contextual phrase 'from preview_script,' leaving the identifier parameter only indirectly 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 clearly identifies the resource as a script from preview_script and states that it returns status and lines. It distinguishes itself from the sibling preview_script by being the follow-up retrieval tool, though it does not explicitly use a verb like 'retrieve' or 'get'.

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 phrase 'from preview_script' implies this tool is used after preview_script to check results, and wait_seconds is described as waiting for readiness. However, there is no explicit guidance on when to poll, when to use wait_seconds versus calling again later, or when not to use this tool.

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

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 that: it is a session-bootstrap aggregate call and it discloses the shape of its payload, including that locked features come back with the unlocking plan and link.

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 imperative instruction is front-loaded in the first four words, then a single semicolon-delimited list covers the payload. It is dense and slightly long, but every clause maps to a distinct return area, so nothing 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?

There is no output schema, so the description carries full responsibility for explaining return values, and it does so item by item. Combined with annotations covering the safety profile and a zero-parameter schema, an agent has everything needed to call it correctly and interpret the result.

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

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

There are zero parameters, so no parameter semantics are needed; baseline 4 applies. The description correctly avoids inventing arguments and instead spends its space on the return contract.

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 enumerates concretely what the tool returns (user identity and language, plan and limits, projects with pending items, setup state, app links, usage guide), which is far more specific than the name 'get_started'. It implicitly overlaps with siblings like get_account, get_plans, list_projects and get_guide but never names them as alternatives, so the differentiation is left to inference.

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

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

'Call this first in every session' gives an unambiguous trigger for invocation, which is stronger guidance than most bootstrap tools provide. It stops short of exclusions — it doesn't say whether the account/plan/guide siblings become redundant after this call, or whether to re-call mid-session after state changes.

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 one piece of context annotations cannot convey — the paid-plan/connected-account prerequisite — but says nothing about response shape, rate limits, or what happens when no accounts are connected.

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?

It is a single run-on sentence with a long parenthetical metric list, so it is dense but not front-loaded — the key fact (project-level rollup across connected accounts) sits before the enumeration while the plan requirement is buried at the end. Nothing is actively wasteful, but the flat structure makes scanning harder than it needs to be.

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 must carry the return-value burden, and the metric enumeration does help an agent anticipate what comes back. However, it gives no sense of nesting/structure, units, empty-state behavior, or how the 'best and worst posts' are ranked, which leaves real gaps for a complex aggregate 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 50%: 'days' only says 'Default 28' (with min 1 / max 40 enforced in schema) and 'project' has no description at all. The description's phrase 'for the last days' vaguely gestures at the window but adds no default value, unit semantics, or explanation of what 'project' accepts (name vs. id), so it does not compensate for the 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 names a specific resource — aggregated stats for the project's connected accounts — and enumerates the concrete metrics returned (views, likes, comments, shares, saves, followers, best/worst posts, watch time). It never states a verb and does not distinguish itself from siblings like get_video_stats or get_report, so an agent must infer the aggregation level from the metric list 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?

Usage is only implied: 'the last days' hints at the days parameter, and 'Paid plans with connected accounts' states a prerequisite. There is no explicit when-to-use, no when-not-to-use, and no routing to alternatives such as get_video_stats for per-video data or get_best_times for timing questions.

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 non-destructive behavior, so the safety profile is covered. The description adds valuable behavior beyond annotations: the status/phase model, a 6-hour validity window for links, and wait_seconds polling semantics, though it does not describe failure behavior beyond the 'failed' status.

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 and front-loaded with the video status concept, then enumerates ready-state fields and polling behavior. It is somewhat long and list-heavy, but every clause adds relevant 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 must explain return content, and it does so thoroughly: statuses, links, cover expiry, titles, captions, hashtags, script lines, duration, and posting/scheduling state. It also covers the key polling parameter, making it complete enough for an agent to call the tool 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 0%, so the description must carry parameter meaning. It explains wait_seconds well (waits while the video is being made, up to 25 seconds), but does not explicitly define video_id beyond the tool name and schema, leaving one of two parameters without added semantic context.

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 provides a specific resource (a video) and a concrete purpose: retrieving its status, production phase, links, captions, metadata, and posting state. It clearly distinguishes itself from siblings like list_videos (singular video lookup) and get_download_link (explicitly named as the alternative for downloads).

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 clearly explains when to use the tool for status and ready-state details, including the wait_seconds polling behavior, and explicitly redirects download-link use to get_download_link. It does not explicitly contrast with list_videos or get_script, but the usage context is clear enough for correct selection.

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 the description goes beyond them with real operational context: values keep growing for days, YouTube data arrives 2-3 days late, and a paid plan with connected accounts is required. What it doesn't cover is the failure/latency path (e.g. what comes back for a video that isn't posted yet or an account without a connected network), so it falls just short of complete.

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?

It is front-loaded with the resource and then the returned metric set, followed by the freshness caveat and the sibling routing sentence — no filler. The long metric enumeration is dense but each item carries information an agent may need to decide relevance, though the run-on paragraph form is slightly heavy.

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 takes on the burden of describing return values and does so by listing the metrics plus the fact that measurement timestamps are included, along with plan and freshness constraints. It is nearly complete; only the zero-data / not-yet-posted case is unaddressed.

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

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

Schema description coverage is 0% for the single video_id parameter, so the description has to compensate. It implies the video must be 'posted' and refers to a single video, which narrows the expected identifier, but it never states the identifier format (internal ID vs. platform video ID) or whether unpublished videos are accepted.

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+resource (the per-network metrics of one posted video) and enumerates exactly which numbers come back, so an agent knows what it gets without opening anything else. It also explicitly separates itself from the sibling get_stats, which returns account totals, so the two stats tools are distinguishable at a glance.

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 names the alternative ('For the totals of the account use get_stats') and the condition that selects it, plus the prerequisite 'Paid plans with connected accounts.' That is explicit guidance on both when to use this tool and when to use the other one instead.

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, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the returned fields but does not disclose any additional behavioral traits such as ordering, pagination, permissions, or empty-result behavior.

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 efficient sentence that front-loads the resource and includes the key return fields. There is no redundant or wasted text.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description supplies enough context by naming the resource and returned fields. Minor gaps such as ordering or pagination are reasonable omissions at this complexity level.

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

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

Schema description coverage is 100%, and the schema already explains that 'project' accepts an id or name and is optional if the user has one project. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource as a project's cartoon characters and lists the fields returned: id, name, look, and video usage. It distinguishes itself from sibling mutation tools like create_character, update_character, and delete_character by implying a read/list operation, though it does not explicitly use a verb such as '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?

The parenthetical 'for Doodle Comedy and Cartoon Storytime' gives useful applicability context, and the schema notes the project parameter is optional when the user has one project. However, the description does not explicitly say when to use this tool versus alternatives like list_projects or create_character, leaving usage largely implied by the name.

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/closed-world, so the safety profile is covered. The description adds real value beyond them: newest-first ordering, the breadth of notification categories, and an explicit prompt-injection warning that some texts quote public comments as UNTRUSTED content. It does not disclose truncation or pagination behavior when limit is hit.

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 dense but purposeful sentences: the resource and its contents up front, the ordering, then the untrusted-text caveat. No filler, though the category list is long enough to slightly blunt the front-loading.

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 does describe the subject matter of returned items (which is its job), and the annotations cover safety. But for a list tool with a capped `limit` and an `unread_only` filter, the absence of any parameter or result-size behavior leaves the definition adequate rather than complete.

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?

Two parameters exist with 0% schema description coverage, and the description mentions neither `limit` nor `unread_only`. The agent gets no stated meaning for the cap (maximum 50) or for filtering to unread items, so it must guess from bare property names — a real gap the description was positioned to fill.

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 (the user's HypeFox notifications) and enumerates the concrete event types it surfaces (videos ready/failed, posts live/failed, pending approvals, Monday report, billing news). An agent can distinguish it from action tools like approve_video or retry_video, though it never names mark_notifications_read as the contrasting sibling.

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 'bell in the app' framing implies the read-the-inbox use case, but there is no explicit when-to-use or when-not-to-use guidance and no routing to alternatives such as list_pending_replies (which covers the OK-waiting items) or mark_notifications_read. The agent must infer the boundary itself.

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

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

Annotations already cover the safe read-only, idempotent, closed-world profile, and the description adds meaningful context beyond that: the mode-dependent result set, the fact that the returned comment/message text is UNTRUSTED public input that must never be executed as instructions, and the existence of a send deadline per item. It stops short of saying how many items come back or whether results are paginated.

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 core definition, then enumerates the returned fields and the workflow. Dense but each clause carries information (mode semantics, untrusted-text warning, deadline, plan restriction); only the parenthetical examples in the mode breakdown feel slightly 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?

With no output schema, the description does the work of describing per-item return fields (original text, draft, reason for waiting, network, post, send deadline) and closes the loop by pointing to decide_replies for applying decisions. Plan restriction and prompt-injection risk are both disclosed.

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?

The schema has one optional 'project' parameter with 0% description coverage, and the description never mentions it — no indication of whether it narrows results to one project, what format it takes, or what omitting it does. With near-zero schema coverage the description needed to compensate and simply doesn't.

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 (drafted replies awaiting approval) and immediately scopes it by mode: Automatic shows only the unsent/uncertain ones, Manual shows all. An agent can distinguish this from decide_replies, which is named here as the follow-up action.

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

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

Gives explicit workflow guidance — review each item with the user, classify as send/change/skip, then 'apply their decisions with decide_replies' — and names the prerequisite 'Paid plans only'. The alternative tool is named along with the condition that triggers it.

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 (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false) already carry the safety/boundedness profile, so the description's main added value is disclosing that it returns the full settings payload rather than a summary. It does not mention pagination, ordering, or what happens when the user has no projects, which are the remaining behavioral unknowns for a list tool.

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, though the long comma-separated field enumeration reads as a data dump rather than prioritized information. It is dense but every item does correspond to returned data, so nothing is truly 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?

For a zero-parameter read-only tool with no output schema and no sibling ambiguity, the description covers the essential question (what comes back). The field list compensates nicely for the absent output schema; only return ordering/empty-state details are missing, which is minor.

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?

The tool takes zero parameters, so the baseline is 4; nothing in the schema needs explaining and the description correctly describes a parameterless, unfiltered listing.

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 clearly that this returns every project along with its full settings, and it enumerates those settings (name, mode, channels, posting cadence, etc.). The resource is unambiguous against the sibling list_* tools (list_characters, list_videos, list_reports). It doesn't explicitly flag itself as the 'list all, no filtering' variant or contrast with get_account/update_project, but the resource distinction is clear from the text 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?

There is no guidance on when to call this versus alternatives such as get_account or update_project, and no mention of prerequisites (e.g., that the user must have an account/projects). Usage is only inferable from the tool name and the field list.

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 readOnly, idempotent, non-destructive, and closed-world behavior. The description adds useful non-annotation context: reports are generated weekly on Mondays, require a paid plan, are ordered newest first, and expose a concise set of fields. It does not discuss pagination, empty-result behavior, or access errors, so it falls short of fully rich behavioral disclosure.

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

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

The description is compact and front-loaded: it states what the reports are, notes ordering and fields, and ends with the relevant alternative in one additional sentence. There is no wasted text.

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

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

For a simple list tool with annotations covering safety and no output schema, the description is mostly complete: it names the returned fields and ordering and explains that get_report is for reading one report. The remaining gap is the unexplained project parameter, which is material because the schema does not describe 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?

There is one parameter, project, with 0% schema description coverage, and the description does not explain what the parameter means, whether it is optional, or what form it should take. The title hints that reports belong to a project, but this is not developed enough to compensate for the schema 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 specifies the resource (weekly reports), cadence (every Monday), scope (paid plans), ordering (newest first), and returned fields (week, one-line summary, status). It also distinguishes the list operation from the detail operation by directing the agent to get_report for a single report.

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 clearly indicates the context in which reports exist (weekly reports on paid plans) and explicitly routes single-report reads to get_report. It does not spell out when-not to use the tool or how optional project scoping affects the call, but the listing-versus-detail distinction is 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real context beyond that: at most one account per network and a reconnection flag, plus the important constraint that this resource cannot be mutated through tools.

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: the resource is front-loaded, and the operational constraint follows. Nothing is 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 does right by sketching the return shape (per-network accounts plus reconnect status). The only gap is the vague 'give the user the link' – it is unclear where that link comes from and whether the tool returns 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 0% for the single 'project' parameter, and required count is 0, so the description carries the burden. It mentions that accounts belong to a project but never says whether the parameter is a name or ID, or what happens when it is omitted (all projects? default project?).

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 (connected Instagram/TikTok/YouTube accounts) and what it reports (connection + reconnection status). It is clear what the tool returns, though it does not explicitly contrast with the nearby get_account sibling.

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 usage rule: connecting or disconnecting must happen in the app, so the agent should hand the user a link rather than attempt the action. It stops short of saying when to prefer this over get_account or list_projects.

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 establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavior beyond that: newest-first ordering, a 60-item cap, and the fields returned.

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 compact and front-loaded: resource, ordering, cap, returned fields, then the sibling alternative. Every clause carries useful 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 read-only list tool with no output schema, the description does a good job by naming returned fields and ordering. The remaining gap is that status filtering is not described, which matters because one of the three parameters is an enum filter.

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 only 33%, so the description needs to compensate more. It maps loosely to project and limit via "project's videos" and "up to 60," but it does not explain the status filter enum, the default limit, or that project is optional when the user has one project.

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 and scope: the project's videos, newest first, capped at 60, with enumerated returned fields. It also distinguishes the tool from get_video, so an agent can identify its role 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?

It gives explicit routing guidance: use get_video for links and captions. That clearly defines the boundary with the most relevant sibling, though it does not cover when to avoid this tool or how to choose between this and broader listing tools.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false), and the description adds real context beyond them: the approximate timing (~30 hours before, or immediately if the slot is sooner) and the automatic fallback at film_by. It stops short of saying whether generation consumes credits, is reversible, or requires an approved plan/slot.

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 the eligibility precondition before the effect and the timing detail. The first sentence is a long run-on with nested parentheses that takes a re-read, but every clause (style match, timing, fallback) 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?

For a one-parameter, non-destructive tool with annotations and no output schema, the description covers eligibility, effect, timing, and the no-call default. Remaining gaps are minor: error behavior for ineligible slots and whether the change can be undone.

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?

The single slot_id parameter has 0% schema description coverage, but the description compensates by tying it to a slot that appears as to_film in get_calendar, which tells the agent what kind of slot ID is valid. It never literally states that slot_id is that identifier or what happens with an invalid/non-to_film slot.

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 action (HypeFox generates the video with AI in the project's style) on a specific resource (a slot that was marked to_film in get_calendar). The to_film precondition cleanly separates it from make_video, make_video_from_audio, and approve_video without needing to open those 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?

"Use it when the user says they won't film it" gives an explicit trigger, and "Without it, HypeFox does the same on its own at film_by" states the default behavior and the consequence of not calling it. Both when-to-use and the alternative path are spelled out.

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 only say it is a non-idempotent, non-destructive write; the description adds substantial behavior the annotations cannot: the call consumes one of the user's videos (two for Paper Collage), generation is asynchronous and takes 1-3 minutes before get_video returns links, at most 2 videos run concurrently, and free-trial output carries a watermark. These are exactly the operational constraints an agent needs before invoking.

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

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

Dense but nearly every clause carries information; the critical constraint (video consumption / say so first) is front-loaded. It is a single run-on paragraph, however, and the mode-selection rules would scan better as separated sentences or bullets.

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

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

For a 10-parameter, no-output-schema generation tool, the description covers the full arc: inputs, prerequisites, latency, where results are retrieved (get_video supplies links, title, captions, hashtags), concurrency limits, and licensing/watermark effects. An agent can execute and follow up correctly without further reading.

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 coverage over 10 parameters, the description carries real weight: it explains the idea/script_id+lines pairing, clarifies that facts are strictly limiting ("the video only uses the facts it is given"), ties script_id to the edit case where style/voice/character are inherited, and notes character eligibility by style. It leaves 'voice', 'project' and 'keyword' (beyond 'sales video with keyword') unexplained, so it does not fully compensate for the coverage gap.

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

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

States a specific verb and resource ("Makes a video") and immediately enumerates the two input modes: from an idea (HypeFox writes the script) or from a script/edit produced by preview_script or preview_video_edit. It also names the downstream tool (get_video) and the prerequisite tools, so an agent can place this tool precisely in the workflow.

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

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

Gives explicit routing rules: use idea when starting fresh, use script_id + lines with a preview_script result, and "To change a video that's already made always go through preview_video_edit, never an idea." It also states a consent obligation ("It uses 1 of the user's videos ... say so before calling"), which is a when-to-use condition rather than mere description.

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 (non-readOnly, non-destructive, closed-world, non-idempotent), so the description's added value is the credit cost ('Uses 1 video, on every plan') and the hard input limits, which are exactly the facts an agent needs before spending a credit. It does not say what is returned on success/failure or what happens to the source audio.

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 definition and the input contract come first, and each later sentence carries actionable detail. The ffmpeg command and the 'New video → Use your audio' UI hint are on the verbose side but still earn their place as fallback paths.

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 5-param, zero-required, no-output-schema generation tool, the description covers input format, size, duration, credit cost, and a manual alternative — enough to call it correctly. The gaps are the ambiguous style/Paper Collage relationship and any statement about the returned artifact.

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 80% schema coverage the baseline is 3, but the description adds real constraints for audio_url and audio_base64 (WAV/PCM, mono preferred, duration window, size cap) and clarifies that exactly one of the two should be supplied, which the schema does not express since nothing is required. It leaves the style enum and the project parameter unexplained, and 'Uses 1 video (Paper Collage 2)' sits uneasily beside a five-value style enum, leaving the agent unsure whether style is actually selectable.

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 plus the key differentiator from the sibling make_video: the user's own recording is the voice and no synthetic voice is generated. The 'no synthetic voice' phrasing lets an agent route between this and make_video 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?

Gives concrete acceptance conditions (WAV PCM 16-bit, mono preferred, 3s–1:30, ≤20 MB) and an escape hatch with an exact ffmpeg command for other formats, plus a pointer to in-app recording. It never explicitly says 'use this instead of make_video when the user already has audio', so the alternative-routing is only 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=false, idempotentHint=true and destructiveHint=false, so safety is largely covered. The description adds genuinely new context by disclosing that omitting ids mutates every notification in bulk, which is the main risk an agent needs to know.

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 short sentence, front-loaded with the action and ending on the default-scope caveat. Nothing redundant and 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 one-parameter idempotent mutation with annotations covering safety and no output schema, the description supplies the essential scope semantics. Minor gaps remain around whether unread-count/return data exists and whether ids come from list_notifications, but nothing blocking.

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

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

Schema description coverage is 0% and the sole parameter is optional, so the description carries the burden of explaining what happens when it is absent ('all of them without ids'). It does that clearly; only the id format (string ids from list_notifications) is left implicit.

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 ('Marks ... as read') and resource ('notifications'), and adds the scope distinction that no ids means all notifications. It is clearly distinct from the read-only sibling list_notifications, though it never names that sibling explicitly.

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

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

Usage is implied by the operation itself and the 'or all of them without ids' clause signals the bulk case, but there is no explicit when-to-use/when-not guidance or reference to alternatives such as list_notifications for discovering ids first.

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 the safety profile (not read-only, non-destructive, idempotent), so the bar is lower; the description still adds real context by disclosing that the move applies across all networks and that the target must be at least 15 minutes out. It doesn't say what state changes (e.g., whether approval is reset) or what errors the minimum-lead-time rule produces, 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?

One compact sentence that front-loads the action and the format constraint, with zero filler. The parenthetical 'all its networks' slightly interrupts the flow but carries genuinely useful scope information, so the tradeoff is acceptable.

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 mutation with no output schema and annotations that cover reversibility and idempotency, the description supplies the format rule, the lead-time constraint, and the target population. Remaining gaps — failure modes and whether the move resets approval state — are modest but real.

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

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

Schema description coverage is 0%, so the description must carry the load. It compensates well for 'when' (ISO 8601, at least 15 minutes from now) but leaves 'video_id' implicit — the agent must infer it refers to the ID of a scheduled video, not any video.

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 ('Moves a video the user scheduled') plus a scope qualifier ('all its networks') and a target ('another time'). The clause 'Not for videos already posted' separates it from publish_video and the post-publication tools without the agent needing to open a 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 an explicit exclusion ('Not for videos already posted') and an eligibility constraint ('at least 15 minutes from now'), which is clear when-to-use context. It stops short of naming alternatives such as move_slot or update_slot, so the agent must infer which scheduling tool applies to slots vs. videos.

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 idempotent, non-destructive, closed-world; the description adds genuinely new behavioral rules: the new time must be at least 15 minutes out and within a year, and the operation is only valid pre-post in manual mode. It stops short of saying what happens on violation (error vs. clamp) or what the response contains.

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 the core action and constraints, then the disambiguation. No filler or repetition of structured fields.

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

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

For a simple two-parameter mutation with rich annotations and no output schema, the description covers scope, time-window constraints, mode gating, and the sibling alternative. Nothing an agent needs in order to decide to call it 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 only 50% (slot_id is undocumented), so the description must compensate; the "at least 15 minutes from now, within a year" window is real semantics for the `when` parameter beyond the schema's bare ISO 8601 note. The slot_id parameter still gets no explanation of how to obtain it.

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 ("Moves a slot of the calendar") plus the exact target dimension (day and time). It explicitly distinguishes itself from the sibling move_publication, so an agent can route between them 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?

Gives explicit preconditions ("Manual mode only, before it's posted") and names the alternative tool plus the condition that selects it ("For videos the user scheduled themselves use move_publication"). This is the when/when-not/alternative pattern done fully.

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 past the annotations: discloses the ~15s typical latency and the 25s wait ceiling, the daily quota (5 free / 15 paid), the one-script-at-a-time limit, and the prerequisite that the user has at least one video left. Annotations only flag it as a non-idempotent, non-destructive write; the quota-consumption behavior an agent must respect comes entirely from the text.

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 value proposition ("about 15 seconds without making it: free"), then workflow, then constraints, then the async fallback. Sentences are dense but each carries a distinct decision-relevant fact; nothing is boilerplate. Minor cost: some fragments ("free, it doesn't use any videos") read as crammed rather than clean.

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 params at 100% schema coverage and no output schema, the description supplies what structured fields cannot: latency, quota, the one-script-at-a-time limit, the prerequisite of remaining videos, and the handoff to make_video/get_script. The only soft spot is that the successful return shape (script id + lines) is implied through the make_video handoff rather than stated.

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 descriptions of idea, facts, style, voice, keyword and sales already carry their own meaning; the tool description mostly restates defaults and prerequisites rather than adding syntax or format guidance. The mention of "script_id + lines" pertains to the downstream make_video call, not to this tool's inputs. Baseline 3 for a well-documented 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 ("writes the script of a video") plus the key differentiator — it does not produce the video itself, and it is free because no video is consumed. That contrast makes it immediately separable from make_video and preview_video_edit.

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 workflow: generate, show the lines to the user, let them revise, then call make_video with script_id + lines. It also names the fallback path ("if it isn't ready yet, call get_script") and the eligibility condition, so both the happy path and the alternative are covered.

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

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false) and the description adds valuable specifics annotations cannot: it is free, takes ~15 seconds, uses no videos now, and leaves the original video intact. However, idempotentHint=false is not addressed (does repeating the same request create another preview script?), and the 'doesn't use any videos' claim is only partly reconciled with the later 'it uses 1 video' statement for the follow-up call.

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?

Long and dense but front-loaded with the selection rule ('Use this whenever...') and organized as scope → behavior → return value → follow-up. The quoted user phrasings earn their place as routing cues; the aside about Paper Collage 2 and video accounting is slightly muddled but still informative.

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 fully compensates by describing the return payload (new lines with changes marked, other changes, script_id), the latency budget (~15s, up to 25s wait) and the fallback (call get_script). An agent has everything needed to call it, interpret the response and chain 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 both parameters are already documented, and the description largely restates them ('ready videos made with HypeFox's voices' constrains video_id; 'in the user's own words' restates request). The eligibility and formatting constraints add some meaning, but not enough to go far beyond the schema baseline.

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 modifies a video the user already has, starting from that video and changing only what the request touches. It explicitly contrasts with making a new video from an idea, which separates it from make_video, make_video_from_audio and preview_script.

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 triggering user phrasings, gives an explicit prohibition ('never make a new video from an idea for that'), states eligibility limits (only ready videos made with HypeFox's voices, not user audio/footage), and prescribes the follow-up flow (show result, then make_video with the returned script_id).

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?

Beyond annotations, it discloses important behavior: auto mode may replace a planned video and keep it in reserve, get_video reports placement after about 10 seconds, a paid plan and connected accounts are required, and public publishing requires explicit user approval in chat.

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 action and then details scheduling modes and constraints. It is dense and somewhat parenthetical, but most sentences carry useful information for a complex scheduling 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?

Given the absence of an output schema, the description covers the key behavior an agent needs: scheduling modes, public confirmation, prerequisites, auto-mode side effects, and where to check automatic placement afterward. No critical context 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?

The description adds substantial meaning to the when parameter and explains that networks may be limited to only some connected accounts. video_id is not described, but its meaning is self-evident and schema coverage is reasonably high at 67%.

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: posting a ready video to the project's connected accounts. It clearly distinguishes scheduling modes and separates the action from sibling tools like approve_video and get_video.

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 explains when to use each scheduling mode, including now, best, ISO 8601 within 60 days, and auto. It also states prerequisites, the public confirmation requirement, and that weekly-plan videos post automatically unless in Manual mode via approve_video.

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 this as a non-read-only, non-idempotent, open-world operation; the description adds that some failures are not retryable by the tool at all and need in-app account reconnection. That is genuine behavioral context beyond the annotations. It stops short of warning about duplicate attempts or what happens to the publication after a retry is queued.

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 a useful parenthetical caveat; nothing is wasted. Slightly awkward phrasing but appropriately sized for a one-parameter mutation.

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 single-parameter mutation with no output schema, the description covers the failure context and the precondition check well, but leaves the parameter unidentified and does not say what a successful retry produces (new attempt, rescheduled post, immediate republish). Adequate but with clear 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 0% and the single parameter publication_id is never explained — where to obtain it, whether it is the same ID surfaced by get_video, or what format it takes. The parenthetical points at get_video for error text but says nothing about the ID itself, so the description does not compensate for the undocumented parameter.

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

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

The description states a specific verb ('tries again') and resource ('a post that failed'), narrowing the action to network-failed publications. It does not explicitly distinguish retry_publication from the sibling retry_video, but 'post' vs. video contextually separates them. Clear enough for an agent to select 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 gives real gating guidance: read the error first via get_video, and do not retry when the error requires the user to reconnect the account in the app. That is a when-to-use and when-not-to-use rule. It lacks an explicit cross-reference to retry_video or cancel_publication as 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 non-read-only, non-destructive, non-idempotent behavior, so the description's added value is the state prerequisite (only failed videos) and the reason for the audio restriction (HypeFox deletes the audio on completion or failure). It does not say whether a retry replaces the failed video or creates a new one, nor whether credits are consumed, which are the remaining behavioral gaps for a regeneration tool.

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: the action and preserved context come first, then the exception and its alternative. No filler, and the most important routing constraint is front-loaded enough to be actionable.

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 one-parameter, no-output-schema tool with annotations covering the safety profile, the description supplies what is needed to call it correctly: the failure precondition and the audio exclusion with an alternative. Only the retry's effect on the original video and any cost implication are left unstated.

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

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

The single parameter has 0% schema description coverage, but its identity is obvious from the tool's framing. The description does add implicit meaning — the video_id must reference a failed video and must not be audio-based — though it never names the parameter or states that constraint in terms of it.

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 ('Makes a failed video again') plus the scope of what is preserved (idea, facts, style, voice). It is clearly distinguishable from make_video (new video) and make_video_from_audio (audio-sourced case), which the description explicitly names.

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 the positive condition (the video failed and 'didn't count') and the negative condition with the exact alternative: audio-based videos cannot be retried, use make_video_from_audio instead. Both when-to-use and when-not-to-use are explicit.

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 idempotent=true, destructive=false and closed-world, so the safety profile is covered. The description adds genuine behavior beyond that: incremental persistence across calls, the response telling you what's still missing plus the next question, and the live UI mirroring in the HypeFox app. It doesn't say what happens when a previously saved answer is omitted or overwritten, but that gap is modest given idempotentHint.

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 short sentences, each doing distinct work: what it does, how to call it, what the return means, and the first-project special case. The core action is front-loaded in the first clause with no preamble.

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 16-parameter, nested-schema, no-output-schema tool, the description supplies the missing piece the schema can't: the interactive loop (save incrementally, get the next question, stop on complete). The one notable hole is the automatic/manual mode distinction, which silently changes which other fields matter and is left entirely to the 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?

Schema coverage is 63% and the schema itself already carries the conditional logic ("Automatic only", "Business accounts only", "When people is character"). The description adds meaning only for heard_about ("For a first project HypeFox also asks how they heard about it"), and says nothing about the top-level mode switch or how partial payloads interact with required-looking nested objects like character.

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 ("Saves the user's answers to the setup questions") plus the non-obvious scope ("a few at a time") and what it returns ("what's still missing with the next question to ask"). It also routes to the follow-on sibling create_project, so an agent can place it in the setup flow without opening update_project or create_project.

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

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

Gives explicit operating instructions — "Send only what the user told you", "ask one question at a time" — and names the handoff condition ("When it says complete, call create_project"). It stops short of stating what this tool should NOT be used for (e.g. re-editing a finished project, which is update_project's job).

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 non-readonly, non-destructive, idempotent, and closed-world, so the safety profile is covered. The description adds behavior the annotations do not: the change is scoped to this user and also affects outbound emails, not just the app UI. That's meaningful side-effect disclosure for an agent reasoning about consequences.

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 compact sentence with the core scope stated first and the disambiguation trailing, so it's front-loaded correctly. The leading colon construction is 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?

With one enum-constrained parameter, full schema coverage, and annotations covering idempotency and safety, the description only needs to fix scope and side effects, which it does. A note on whether the user must be re-authenticated or what confirmation returns would close the remaining gap, but that's minor.

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

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

Schema coverage is 100% and the enum already documents en = English, it = Italian. The description repeats the 'en' or 'it' values without adding format, default, or fallback semantics. Baseline 3 is appropriate when the schema carries the parameter burden.

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 the specific resource and effect: it changes the app and email language for this user, with the allowed values en/it. It clearly separates this from video_language, so an agent won't conflate it with update_project. It stops short of using an explicit verb such as 'set', but the intent is unambiguous.

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 real exclusion ('not the language of the videos') and points to the correct alternative for that need (update_project's video_language). What's missing is positive guidance on when to reach for this tool, e.g. after the user asks to change UI/email language, but the routing signal is strong.

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

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

Annotations declare non-destructive, idempotent, closed-world, but the description adds real side-effect detail beyond them: Manual skips upcoming slots without a video and holds already-made videos for approval. This is substantive behavioral context not covered by the structured fields.

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

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

Dense and information-rich; nearly every sentence carries scheduling or side-effect detail. It could be better front-loaded by stating the switch action before the mode definitions, but there is little waste.

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 mode-switch tool with no output schema, it covers both mode outcomes, prerequisites, scheduling edge cases, side effects on slots/videos, and points to get_catalog for the change explanation. Nothing essential 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 50% schema coverage, the description compensates by clarifying that style and videos_per_week are passed 'if they change' and explaining the mode enum semantics. It doesn't address the optional 'project' parameter, leaving one gap, but overall adds conditional meaning 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?

The title plus description make it clear this switches a project between Automatic and Manual modes, with both modes concretely defined. No sibling tool performs this action, so distinguishing is unnecessary, but the description defines outcomes rather than leading with an explicit verb+resource statement.

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

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

It states Automatic's prerequisites (paid plan, scheduling window logic) and what happens on switching to Manual, plus instructs to explain changes via get_catalog modes.what_changes first. Clear context, though it doesn't explicitly frame when a user should prefer one mode over the other.

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

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

Annotations already declare idempotent=true, destructiveHint=false and readOnlyHint=false, so safety is partly covered; the description adds real value with the manual-mode and pre-video timing constraint. It does not say whether a skip is reversible (e.g. via update_slot or approve_slot), what error occurs if called in auto mode, or what a successful response looks 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?

Two tight sentences with the effect first and the precondition second; no filler, no repetition of the title or annotations.

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 and only one parameter, so the description does not need to explain return values, but for a state-mutating tool it should say what happens when the precondition is violated and whether the skip can be undone. As written an agent can invoke it, but only confidently if it already knows the surrounding workflow.

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

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

Schema description coverage is 0% and the description says nothing about slot_id — no format, no hint that it comes from get_calendar. The name is suggestive, but the description does not compensate for the documentation gap even though slot_id is the only required input.

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 (skips) and resource (a slot) plus the concrete effect: nothing is made or posted for it. This separates it from mutation siblings like update_slot or move_slot, though it never names an alternative such as cancel_publication or delete_videos.

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?

"Manual mode only, before its video is made" gives an explicit precondition and an implicit exclusion, which is genuinely useful routing information. It stops short of naming the sibling to use in auto mode or once a video already exists, so the agent must infer the fallback.

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 the safety profile (readOnly=false, idempotent=true, destructive=false, openWorld=false). The description adds two facts the annotations cannot convey: omitted fields are left untouched, and existing videos retain the old look, so the change is not retroactive. That non-retroactivity is exactly the kind of side-effect disclosure that matters for a mutation tool.

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

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

Two short sentences, the mutation scope is front-loaded, and the caveat about existing videos follows immediately. No filler or repeated title text.

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, it covers partial-update semantics and one downstream consequence, which is more than most. Still missing: what happens if character_id is invalid, whether changing a look affects videos already scheduled or in progress, and whether name collisions are rejected.

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?

Top-level schema coverage is effectively 0% for character_id, name, and look, so the description has to compensate. It clarifies that both name and look are optional and partially applied, which is helpful for a nested object, but it says nothing about character_id (must reference an existing character) or the name length bounds. The nested enum descriptions in the schema carry the bulk of the field-level meaning.

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 (changes) and resource (a character) and names the two mutable field groups, name and look. It is reasonably distinguishable from create_character or delete_character, though it never explicitly contrasts with a sibling.

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 parenthetical 'only the fields you send' establishes partial-update semantics, which is real usage guidance and tells the agent not to resend the whole look object. However, there is no explicit when-to-use, no pointer to list_characters for obtaining character_id, and no stated alternative for identity changes.

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 mutability and safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so this is complementary context: the partial-update contract, the consequence of changing style in Automatic when weekly-plan videos already exist, and an explicit keep/remake/remove choice with a note to ask the user first. That is substantive disclosure about a mutation beyond what the structured fields give. The gap is the lack of any statement about the response or partial-failure behavior.

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 front-loading is good: the verb and the field inventory lead, and the conditional rules follow. Every clause earns its place, including the note that the icon is app-only. It falls short of a five because a few phrasings are compressed into ambiguity, such as 'the style stays among those that work with them'.

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 17-parameter nested mutation with no output schema, the definition supplies the constraints that determine correct invocation: partial update, the already_made decision, the style compatibility rule, and pointers to set_mode and get_catalog. It is close to sufficient. Missing are permission or auth requirements and how to obtain valid voice and character ids.

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 65%, and the schema itself carries the nested sells object, videos_you_film, fixed_times, and the voice/video_language dependency. The description adds field grouping and restates a few cross-field constraints, which helps orientation, but leaves name, niche, account_type, channels, style, and voice without added meaning and doesn't say what happens when fields are omitted. Baseline three is right for a definition that improves navigability without closing the 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 uses a specific verb for a specific resource ('Changes a project's settings') and then inventories the concrete fields grouped into Project, Posting, and Videos. That, plus the reference to Settings in the app, lets an agent separate this tool from create_project, update_character, and set_mode without opening any schema.

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

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

It gives explicit operating rules: 'Send only what changes' establishes partial-update use, 'To switch Automatic/Manual use set_mode' names the alternative and the condition that selects it, 'get_catalog' points to the sibling for compatible styles, and 'The project icon is changed in the app' rules out an operation this tool cannot do. The agent has both the route to use this tool and the routes away from it.

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 non-readonly, idempotent, non-destructive. The description adds real context beyond that: edits are gated by project mode, only slots without a video are editable, and facts must come from the user rather than being invented. That last constraint is an important behavioral rule no annotation encodes. Missing is what happens to an existing approval or script after an edit.

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 action, then the two mode branches, then the follow-up call. The parenthetical '(the warning says so)' is a small indulgence but ties the rule to something the agent will observe.

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 four-parameter mutation tool with no output schema, the description covers the important ambiguity: which slots are editable per mode and what facts are acceptable. No return-value explanation is needed since there is no output schema. It leaves open the post-edit state (whether approval is cleared).

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 only 25% (only 'facts' is documented in the schema), so the description must compensate. It does name idea, angle and facts as the editable fields and reinforces the facts semantics ('add the facts the user gives you, never invented ones'). But it adds nothing about slot_id or the meaning of angle vs idea beyond their names, so compensation is partial.

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 target with the editable fields enumerated: 'Changes a slot's idea, angle and facts before its video is made.' An agent immediately knows the mutation. It does not, however, distinguish itself from the sibling change_slot_idea, which appears to touch the same 'idea' field, so sibling differentiation is missing.

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

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

Gives explicit mode-dependent conditions: in Automatic only slots needing real facts are editable, in Manual any idea or approved slot without a video. It also routes to the next step ('then approve_slot'), which is genuinely useful chaining guidance. It stops short of naming change_slot_idea as the alternative for pure idea edits.

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