Tutorializer Video Tutorials

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=false. The description adds value beyond them by noting that 'Each call creates another project' (duplicate accumulation) and by enumerating the returned fields, though it does not explain the surprising destructiveHint=true for a create operation or any auth/permission requirements.

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

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

Three short sentences, front-loaded with the trigger condition, then the return values, then the exclusion. The return-value enumeration is slightly redundant given an output schema exists, but nothing is padded or 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 a rich annotation set, 100% schema coverage, and an output schema, the description need not explain return values or safety. It supplies the trigger, the exclusion, and the duplicate-creation behavior, leaving only minor gaps like the reason for the destructive flag and any permission requirements.

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

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

Schema description coverage is 100%, so all three parameters (name, domain, defaultLocale) are already documented in the schema with lengths and examples. The description adds no parameter-level detail such as format rules or how domain/defaultLocale defaults are applied, so the baseline 3 applies.

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

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

States a specific verb and resource ('start a new Tutorializer project for a product or app') and explicitly carves out the update case ('Not for changing an existing project'). It differentiates from update_project but does not distinguish itself from the other create_* siblings (create_tutorial, create_video), which the agent must infer from the resource noun.

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 clear trigger ('when someone wants to start a new Tutorializer project') and an explicit exclusion ('Not for changing an existing project'), which routes the agent to update_project. It stops short of naming that alternative or stating prerequisites such as required fields, so it is strong context without full when/when-not coverage.

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

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

Annotations already declare destructive=true, non-idempotent, non-readonly, but the description adds a genuinely non-obvious trait beyond them: synthesis spends the organization's credits when no url is given, whereas url records existing audio without synthesizing. It does not, however, address reversibility or cleanup of created segments.

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

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

Four tight sentences, front-loaded with purpose then the url branch then the exclusion. The return-value sentence ('id, language, voice and audio URL') is largely redundant given an output schema exists, a minor 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?

With an output schema present, return values need not be detailed, and the description covers the material decisions an agent faces (whether to pass url, credit cost, when not to use it). Complete for a 6-param creation tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: the url/no-url branch maps to synthesis-vs-record and to credit expenditure, which is more than the schema's field-level text conveys. It is still silent on the optional translatedText/voice interplay.

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 ('new narration or voiceover in a project') that distinguishes it from siblings like create_video/create_tutorial. The exclusion 'Not for fixing an existing line' further pins it apart from update_speech. 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?

Gives an explicit trigger ('when someone wants new narration or voiceover') and an explicit anti-trigger ('Not for fixing an existing line'), the latter routing the agent away toward an update-style sibling. Nothing about selection is left to inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=true; the description reinforces non-idempotency ('Each call creates another tutorial') and adds genuinely new scope context by clarifying that no video is recorded or rendered. It does not explain the destructiveHint=true flag, which is a notable gap for a create operation.

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

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

Three short, front-loaded sentences with no filler; the trigger condition and scope boundary come first. The return-value sentence is somewhat redundant given an output schema exists, which costs it the top mark.

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?

Covers purpose, scope limitation, and repeat-call behavior, and an output schema handles return values. The one unexplained item is why a create tool carries destructiveHint=true, which an agent might reasonably want clarified before invoking.

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% — all three parameters (name, projectId, defaultVoice) are documented with types, lengths and meaning in the schema itself. The description's mention of 'id, name, project and default voice' is about return values, not parameter behavior, so it adds essentially nothing beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('add a new tutorial to a project') and immediately delimits the scope against a sibling: 'it records the tutorial without recording or rendering a video. Not for adding a rendered video.' An agent can distinguish this from create_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 a clear triggering condition ('Use this when someone wants to add a new tutorial to a project') and an explicit exclusion ('Not for adding a rendered video'), which routes the agent away from create_video. It stops short of naming that alternative tool directly, so the routing requires one small inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false. The description usefully corroborates and explains the non-idempotency ('each call adds another record'), which is real added context. It omits auth/permission requirements and says nothing about what the destructive hint implies (e.g., whether re-listing the same URL duplicates or conflicts), leaving one gap.

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

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

Four tight sentences with the when-to-use condition front-loaded and the exclusion last, which is good structure. The return-value sentence ('Returns the new video record with its language, device, dimensions and URLs') is somewhat redundant given an output schema exists, so it is not perfectly waste-free.

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 13-parameter mutation tool with full schema coverage and a declared output schema, the definition covers purpose, prerequisite, cardinality behavior and sibling boundaries adequately. Missing only permission/auth details and what happens on duplicate or invalid URLs.

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% across all 13 parameters, so the schema already carries the field meanings and the baseline is 3. The description's URL framing ('public https URL' of a pre-hosted file) largely restates the schema's own url description rather than adding new syntax or constraints.

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 first sentence states a specific verb and resource ('wants it listed under a tutorial') and names the precondition (an already-uploaded file). The negative clause 'Not for recording, rendering or uploading a video' separates it from sibling create_* tools that an agent might confuse it with.

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

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

Explicit when-to-use plus prerequisite workflow: 'Host the file first and pass its public https URL.' It also states an exclusion boundary (not recording/rendering/uploading), so the agent knows when to pick a different path.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description adds substantive context beyond them: the audio and timing files are erased, restoring requires re-synthesis that spends credits, and repeated deletion is a no-op. This is exactly the kind of consequence disclosure an agent needs before calling a destructive tool.

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

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

Every sentence earns its place: trigger, return value, irreversibility/cost, idempotency, and exclusion are each stated once with no filler. The trigger is front-loaded so the agent can decide quickly.

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 an output schema, the description covers everything needed: what is destroyed, the cost of reversal, idempotent behavior, and the sibling it must not be confused with. Nothing material 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 a single parameter at 100% schema description coverage, the schema already fully documents speechId. The description adds no format, syntax, or lookup guidance beyond what the schema provides, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ('one voiceover line permanently deleted with its audio') and explicitly distinguishes the tool from its sibling update_speech by stating 'Not for changing its words.' An agent can identify the exact operation and its scope 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 states a clear trigger condition ('when someone wants one voiceover line permanently deleted') and an explicit exclusion ('Not for changing its words'), which routes the agent toward update_speech. However, it does not name the alternative tool directly, leaving a small inference step.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real behavioral context beyond them: the call returns the deleted tutorial id, child videos and voiceover lines survive and require their own deletes, and re-deleting is a no-op. This discloses cascade behavior and return content that the annotations alone do not.

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

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

Three tight sentences, front-loaded with the use condition, followed by return/cascade behavior and the scope exclusion. Every sentence carries distinct information.

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

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

Covers purpose, permanence, cascade consequences, idempotency, and scope exclusions; an output schema exists so return values need not be elaborated further. Nothing an agent needs to invoke this correctly is missing.

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

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

Only one parameter and schema coverage is 100%, so the schema fully documents tutorialId. The description adds nothing about the identifier format or constraints, so the baseline 3 applies.

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

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

States a specific verb (permanently delete) and resource (tutorial), and explicitly carves out scope boundaries against siblings: not for removing one language or device version, and children like videos/voiceover lines need their own delete. An agent can distinguish this from delete_video/delete_speech without opening schemas.

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

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

Explicit when-to-use ('someone wants a tutorial permanently deleted') plus when-not ('Not for removing one language or device version'), and it routes the agent to separate delete operations for the tutorial's videos and voiceover lines. Nothing is left to inference.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description goes further: it names exactly what is erased (the record and the video file in Tutorializer storage) and states the recovery cost (re-upload or re-render). That consequence detail is precisely what an agent needs before committing a destructive 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?

Three short sentences, front-loaded with the trigger, then the return value and consequences, then the scope exclusion. No filler and nothing buried.

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

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

An output schema exists, and the description still supplies the non-schema-critical facts: irreversibility, the storage-level effect, and the boundary against delete_tutorial. For a one-parameter destructive tool, nothing an agent needs is missing.

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

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

Schema description coverage is 100% for the single videoId parameter, so the schema already carries the meaning. The description adds no format, constraint, or ID-source detail beyond the schema, so the baseline 3 applies.

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

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

Specific verb (delete) plus a precisely scoped resource: 'one rendered tutorial video'. It explicitly distinguishes itself from the sibling that deletes a whole tutorial, so an agent can route correctly 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 an explicit trigger ('Use this when someone wants one rendered tutorial video permanently deleted') and an explicit exclusion ('Not for deleting the whole tutorial'). The alternative is described rather than named (delete_tutorial), so it falls just short of the fully explicit 5.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral detail beyond that: a hard cap of 'up to 50 pronunciation rules' in the result and lookup via either project id or vanity id, which prepares the caller for truncation.

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 with the usage trigger front-loaded, then the return payload, then the exclusion. Efficient overall, though the trailing exclusion sentence is vague enough that it spends words without fully earning 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?

With an output schema present, return values need not be spelled out, yet the description usefully previews the payload and the 50-rule cap. Nothing an agent needs to invoke it correctly is missing; only the unclear exclusion clause keeps it from being fully self-explanatory.

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 single parameter already documents 'Project id or its stable public vanity id'. The description repeats that same fact ('looked up by project id or vanity id') without adding format, constraint, or edge-case guidance, so this is the baseline 3 case.

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+resource ('get' a single 'project's settings') and enumerates the returned content (name, domain, locales, voice settings, pronunciation rules), so an agent knows exactly what it produces. It does not explicitly distinguish itself from list_projects or show_project_overview by name, leaving the sibling boundary 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?

It states when to reach for it ('when someone asks about one project's languages, default voice, narration speed or pronunciation rules') and includes an exclusion clause ('Not for finding languages or devices that lack videos'). The exclusion is cryptic and references no actual sibling tool, so the when-not guidance is weaker than it looks.

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 read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds real value beyond that by disclosing the data scope: counts are computed 'from the latest 100 of each,' which tells the agent results may be truncated for large projects. No permission or error behavior is mentioned, but that gap is minor here.

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 with no filler, and the trigger condition is front-loaded before the return shape and the exclusion. Marginally verbose in the first sentence, but every clause carries information.

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

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

For a read-only aggregate over a single required project id, the agent knows what question this answers, what it returns, the truncation caveat, and what it is not for. With an output schema present, no further return-value documentation is needed, and nothing required to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so both projectId and expectedDevices (including its default of computer/tablet/smartphone and the 1-10 name constraint) are already fully documented in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 is correct.

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 (project localization summary) and enumerates exactly what it covers: video and voiceover counts per language, video counts per device, plus missing entries. It explicitly distinguishes itself from the per-tutorial siblings with 'Not for one tutorial's videos,' so an agent can separate it from get_tutorial/get_video without opening 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?

Opens with a concrete triggering condition ('Use this when someone asks which languages or devices a project still lacks...') and adds a when-not ('Not for one tutorial's videos'). It stops short of naming the alternative tool to call instead, which is the only thing keeping this 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description reinforces read-only with "Not for changing the words" but adds no behavioral caveats beyond that (no auth, rate-limit, or side-effect notes), and the enumerated return fields overlap the existing 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?

Three short sentences, front-loaded with the trigger condition and ending with a crisp exclusion. The enumeration of returned fields is slightly redundant against the output schema but remains compact and readable.

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 single-parameter read tool with an output schema, the description covers purpose, trigger, and exclusion adequately and need not explain return values. It is complete enough to invoke correctly, though a pointer to update_speech for edits would tighten it.

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

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

Schema description coverage is 100% with a single well-documented speechId parameter, so the baseline is 3. The description adds no format or constraint detail about the id beyond what the schema already provides.

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

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

"Read a voiceover line" plus the description's concrete scope (full wording, translation, or audio link of ONE line) states a specific verb and resource. It clearly distinguishes this from get_project/get_video/get_tutorial siblings by naming the exact entity it returns.

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 this when someone needs the full wording or translation of one voiceover line, or its audio link" gives a clear triggering condition, and "Not for changing the words" provides an explicit exclusion that steers the agent away from update_speech. It stops short of naming the alternative tool directly, so a 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the hard cap of 8 videos, that they are the 'most recently edited', and the rendered field set. It does not mention pagination or ordering semantics beyond recency, but the truncation disclosure is the important one.

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, usage trigger front-loaded, then return contents, then the exclusion. It is efficient and front-loaded with only minor redundancy between the title and the opening clause.

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

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

An output schema exists, so return values need not be fully spelled out, and the description still summarizes the payload and the 8-video cap. Combined with full annotation coverage and a single well-documented parameter, an agent has what it needs; only the lack of a named alternative tool for the 'every video in a project' case keeps it from a 5.

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

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

Only one parameter exists and schema description coverage is 100%, so the schema already documents tutorialId (albeit thinly as 'Tutorial id'). The description says 'one tutorial' but adds no format, source, or lookup guidance for the ID. Baseline 3 applies since 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?

States a specific verb and resource ('Get a tutorial and its videos') and adds scope: the tutorial's name, project, default voice, plus up to 8 of its most recently edited videos. It explicitly carves itself away from list_videos via 'Not for every video in a project', so an agent can distinguish it from siblings without opening schemas.

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

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

'Use this when someone asks about one tutorial and the videos rendered from it' gives a clear triggering context, and 'Not for every video in a project' provides an explicit exclusion. It never names the alternative tool (e.g., list_videos) that the exclusion implicitly routes to, which keeps it just short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description's 'Not for changing those details' restates read-only behavior, and the return-value list duplicates the output schema, adding little behavioral context 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?

Two sentences; the use case and returned fields are front-loaded, followed by the exclusion. No filler or restated title.

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

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

For a read-only single-entity fetch with full annotations and an output schema, the description supplies purpose, trigger, scope and the negative boundary. Nothing an agent needs to call it correctly is missing.

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

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

With one parameter at 100% schema description coverage, the schema already documents videoId. The description says nothing about the id's format, provenance, or what happens with an unknown id, so the baseline 3 applies.

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

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

States a specific verb+resource ('get' a 'video') and enumerates exactly what is retrievable (link, subtitles, chapters, thumbnail), which cleanly separates it from get_tutorial, get_speech and get_project among the 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?

Gives an explicit trigger ('when someone asks about one tutorial video') plus example asks, and adds an exclusion ('Not for changing those details') that routes writes to update_video. It never names an alternative tool explicitly, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs added context. It delivers: sorting by name, default page size of 25, and the exact fields returned. It does not mention auth requirements or cursor expiry, which keeps it short of a 5.

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

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

Two tight sentences: the triggering condition first, then the return shape and the boundary. No filler and nothing that repeats the title verbatim.

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

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

An output schema exists, so return values needn't be spelled out, yet the description still previews the fields and the ordering. Combined with annotations and a fully documented 2-param schema, an agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so limit and cursor are fully documented in the schema. The description restates the 25-per-page default but adds no paging semantics beyond it, so the baseline 3 is appropriate.

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

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

States a specific verb (list) and resource (Tutorializer projects), plus when it's needed (to obtain a project id). The closing sentence explicitly separates it from sibling territory ('languages or voice settings'), so an agent can route between list_projects, get_project, and show_project_overview without opening schemas.

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

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

Names the triggering user intent ('which projects they have') and a concrete secondary use (fetching a project id), and adds an explicit exclusion ('Not for a project's languages or voice settings'). When-to-use and when-not are both present.

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 behavioral context beyond that: the returned fields, sort order ('most recently edited first'), and a default page size of 25, which materially affects how results are consumed.

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 first front-loads the when-to-use condition, the second packs return shape, ordering, pagination and the exclusion. Every clause carries information with no padding.

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

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

An output schema exists so return values need not be fully explained, yet the description still summarizes the key fields and pagination behavior. Combined with full parameter coverage and annotations, an agent has everything needed to call this 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 100%, so all four parameters (limit, cursor, language, projectId) are already documented in the schema. The description echoes the pagination default and the optional language filter but adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb (list) and resource (voiceover/narration lines) and immediately constrains scope to a project. It also distinguishes itself from the get-a-single-line sibling with 'Not for the full text of one line,' so an agent can separate it from get_speech 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?

'Use this when someone asks which voiceover or narration lines a project has, optionally in one language' gives a clear triggering context, and the closing exclusion routes the agent away from full-text retrieval. It stops short of naming the alternative tool (get_speech) explicitly, so it is strong but not fully prescriptive.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond that: sort order (most recently edited first) and default page size (25 per page), which an agent cannot get from 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?

Three tight sentences: trigger first, return shape second, exclusion last. Every sentence earns its place with no redundancy.

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

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

With an output schema present and annotations covering safety, the description supplies the remaining essentials — ordering, pagination default, project scoping, and the neighboring-video exclusion. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so limit, cursor, and projectId are already fully documented including the default of 25 and the nextCursor semantics. The description only restates the page size, adding no syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a specific verb+resource ('which tutorials a project has') and enumerates the returned fields (id, name, project, default voice and times). It also explicitly distinguishes itself from list_videos with 'Not for the rendered videos of each language or device.'

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 triggers ('when someone asks which tutorials a project has, or when another tool needs a tutorial id') and an explicit exclusion routing to the sibling video listing. Nothing is left to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description's job is to add the rest: it supplies sort order ('most recently edited first') and default page size (25), which annotations cannot convey. It stops short of noting auth or rate-limit 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?

Three tight sentences: trigger first, then return shape, then the exclusion. No filler, and the most decision-relevant information is front-loaded.

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

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

Filters, pagination, sort order and returned fields are all covered, and an output schema exists so return values need not be explained in depth. Only minor gaps (cursor round-tripping is left to the schema) keep it from a 5.

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

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

Schema coverage is 100% and each of the six parameters is documented in the schema, so the baseline is 3. The description restates the filter dimensions but adds no format, default, or interaction detail beyond what the schema already says.

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

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

States a specific verb and resource ('list tutorial videos') plus the filterable scope (project, tutorial, language, device), which cleanly separates it from the singular get_video sibling and the other list_* 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 an explicit trigger ('when someone asks which tutorial videos exist') and one exclusion ('Not for checking missing languages'). The exclusion doesn't name the alternative tool (e.g. get_project_localization_summary), so the routing is clear but not fully closed.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds real value beyond them: it clarifies that a missing rule changes nothing (reinforcing idempotency), that existing audio is preserved, and what the response reports. It does not spell out auth requirements, though the operation's blast radius is well characterized.

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, each earning its place: purpose, effect/return behavior, and the exclusion. Purpose is front-loaded with no filler.

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

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

Covers purpose, effect, idempotency behavior, and an explicit exclusion, which is complete for a simple two-parameter mutation. Mentioning the return value is somewhat redundant given an output schema exists, but it is harmless rather than misleading.

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%, with both projectId and word fully documented, so the schema carries the parameter burden. The description adds no syntax or format detail beyond what the schema provides, making the baseline 3 appropriate.

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

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

States a specific verb+resource ('drop a pronunciation rule') and the resulting effect ('word is spoken the default way again'), which cleanly distinguishes it from the sibling set_pronunciation_rule. 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?

Gives clear when-to-use context ('when someone wants to drop a pronunciation rule') and an explicit exclusion ('Not for changing a rule's phonemes'). It stops short of naming set_pronunciation_rule as the alternative, leaving the agent to infer the sibling route.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description corroborates by stating it adds or replaces a rule. It adds real behavioral context beyond the schema: the 500-rule cap and the fact that the pronunciation dictionary is synced for later synthesis. It does not spell out what happens to the prior rule on replacement or any auth requirements.

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

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

Three tight sentences, front-loaded with the when-to-use trigger, then effect, then exclusion. No filler and every clause carries information.

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

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

For a moderately complex mutation covered by annotations and an output schema (so return formatting needn't be explained), the description supplies the trigger, the effect, the rule cap and the dictionary-sync behavior. Only the replacement semantics and any permission requirements are left implicit.

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

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

With 100% schema description coverage, the schema already documents all four parameters, so the baseline is 3. The description references the IPA/CMU alphabets and the 500-rule cap, but the 500 is a system limit rather than a per-parameter detail, so the added parameter value is marginal.

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 (add or replace a pronunciation rule) and resource (a word/name/brand in a project's voiceovers), making the effect unambiguous. It does not explicitly name the sibling remove_pronunciation_rule, so an agent infers the boundary rather than being told 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?

'Use this when narration mispronounces a word' gives a clear triggering condition, and 'Not for re-voicing lines that already have audio' is an explicit exclusion. It stops short of naming the alternative tool an agent should reach for instead of re-voicing.

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, destructiveHint=false, closed world), and the description adds real behavioral detail beyond that: counts are capped at 100 each and only the 8 most recently edited tutorials are returned. Those truncation limits are the kind of nuance an agent needs and are not implied 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?

Three tight sentences, front-loaded with the usage trigger, then the return shape, then the exclusion. Every clause carries information; no filler or restatement of the tool name.

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

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

With an output schema present, return values need not be re-explained, and the description still surfaces the count caps and the 8-item tutorial limit. Minor gap: it does not indicate where to go for the full tutorial list or full counts (e.g. list_tutorials) once those truncations apply.

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

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

Schema description coverage is 100% and the single parameter ('Project id or its stable public vanity id') is fully documented in the schema. The description adds no syntax, format, or lookup guidance beyond 'one Tutorializer project', so baseline 3 applies.

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

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

States a specific verb and resource ('quick visual overview of one Tutorializer project') and then enumerates exactly what the overview contains (name, domain, logo, counts, 8 most recently edited tutorials). The closing exclusion ('Not for missing languages or devices') implicitly separates it from get_project_localization_summary, so an agent can route without opening other schemas.

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

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

Gives a clear trigger ('Use this when someone wants a quick visual overview of one project') plus an explicit exclusion for languages/devices. It does not name a sibling alternative (e.g. get_project for full detail or list_tutorials for the complete tutorial list), so the when-not guidance is partial 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?

With destructiveHint and idempotentHint already present, the description adds important update semantics: omitted fields keep their values, while a new locales list replaces the entire set. This clarifies exactly which kind of destructive behavior to expect and complements the annotations rather than repeating them.

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

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

The description is three tightly written sentences: use case first, update semantics second, exclusion last. Every sentence carries operational information, with no filler or repetition.

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

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

For a project update tool with a full input schema, an output schema, and rich annotations, the description supplies the missing behavioral context about partial updates and locale replacement. Together with the structured metadata, it is complete enough for correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds useful semantics by stating that fields left out keep their values and that locales replaces the whole list. Those details give the agent behavior-level understanding beyond the parameter descriptions themselves.

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

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

The description states a specific action ('rename a project or change its domain, languages, default voice or narration speed') against a named resource, making the tool's scope clear. It also explicitly separates itself from pronunciation fixes, so an agent can distinguish it from set_pronunciation_rule 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 a clear when-to-use condition and a when-not-to-use exclusion ('Not for pronunciation fixes'). It stops short of naming the alternative tool for pronunciation work, so it is clear but not fully explicit about routing 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 flag destructiveHint=true and idempotentHint=true, but the description adds the substantive context: a real change re-synthesizes audio via the project's voice provider, spends synthesis credits, and replaces the old audio, while identical values are a no-op. Credit cost and the audio-replacement consequence are exactly the traits an agent needs and cannot get from the hints alone.

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

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

Four tight sentences, front-loaded with the trigger condition, then the return value, then the cost/destructive consequence, then the exclusion. No filler and nothing important buried.

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 full schema coverage and an output schema, the description covers the remaining risks: credit spend, audio replacement, no-op behavior on identical input, and scope exclusions. An agent has everything needed to decide and 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 description coverage is 100%, and each parameter already carries its own description with constraints (lengths, language code example). The description's field list (words/translation/language/voice) merely restates what the schema documents, adding no syntax, defaults, or interaction rules beyond the 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 (change) and resource (one voiceover line) plus the exact editable facets: words, translation, language, voice. It also draws an explicit boundary against project-wide pronunciation work, so an agent can separate it from set_pronunciation_rule and create_speech without reading 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 this when someone wants to change the words, translation, language or voice of one voiceover line" gives an explicit trigger condition, and "Not for project-wide pronunciation fixes" gives an exclusion. It falls short of naming the alternative tool (set_pronunciation_rule) outright, so routing still requires a small 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 idempotentHint=true and destructiveHint=true; the description usefully reinforces idempotency ('repeating the same values changes nothing') and discloses partial-update semantics ('fields left out keep their values'), plus the return shape. However, given destructiveHint=true it never explains what is destructive about the change (e.g. effect on existing synthesized narration), leaving the safety-relevant behavior unstated.

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 trigger condition, then update semantics, then the exclusion. Every sentence carries distinct information with no filler or repetition of the title.

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

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

With an output schema present, there is no need to enumerate return fields, and the description covers trigger, partial-update behavior, and exclusions adequately for a simple 3-parameter mutation. The remaining gap is the unexplained destructive behavior flagged by annotations.

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

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

Schema description coverage is 100% and all three parameters (tutorialId, name, defaultVoice) are documented with constraints in the schema itself. The description only alludes to name and voice at a high level, adding no syntax, format, or constraint detail beyond the structured fields, so baseline 3 applies.

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

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

States a specific verb and resource (rename a tutorial / change its default narration voice) and scopes the tool against adjacent operations with 'Not for editing narration text.' An agent can distinguish it from update_video, update_speech, and update_project 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?

'Use this when someone wants to rename a tutorial or change the default voice' gives a clear triggering condition, and the closing exclusion tells the agent when not to use it. It stops short of naming the correct alternative for narration-text edits, so it is not fully explicit routing.

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 idempotentHint=true, destructiveHint=true and readOnlyHint=false. The description adds concrete semantics beyond them: omitted fields retain their values, identical values are no-ops, and the updated record is returned. It omits any note that overwriting an existing value is irreversible, which is the one gap given destructiveHint=true.

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 trigger, then the update semantics, then the exclusion. No filler and every sentence carries distinct information.

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

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

With an output schema present, the description need not explain return values, and annotations cover the safety profile. Combined with 100% schema coverage, the definition is nearly sufficient; only the video-vs-tutorial sibling boundary and overwrite irreversibility are 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 coverage is 100%, so the schema fully documents all 12 fields with types, ranges and formats. The description's field list (language, device, dimensions, links, subtitles, chapters, thumbnail) roughly mirrors the schema and adds no syntax beyond it; format, duration and fileSize are not even mentioned. Baseline 3 is appropriate.

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

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

The description names a specific verb ('correct'/'fix') and resource (a tutorial video) and enumerates the editable facets: language, device, dimensions, file link, subtitles, chapters, thumbnail. That is far more specific than a restatement of the title. It does not, however, explicitly distinguish itself from the sibling update_tutorial, leaving mild ambiguity about the video-vs-tutorial boundary.

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

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

It gives an explicit trigger ('Use this when someone wants to correct...') and an explicit exclusion ('Not for re-rendering the video itself'). It stops short of naming a sibling alternative to redirect to, so the routing guidance is clear but not complete.

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