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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: 'No cost, no allowance used' (quota behavior) and the code-point vs UTF-16 measurement nuance, which is non-obvious behavior for emoji-containing 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?

Two tight sentences with the core measurement claim front-loaded; each clause carries information. Slightly dense with three numeric examples, but 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 the return-value burden — and it does, describing both the limit outputs and the dual code-point/UTF-16 measurement. Nothing an agent needs to call 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?

Schema coverage is 100%, so the baseline is 3, but the description adds concrete semantics for the 'field' enum by giving actual limit values (title 100/search ~60, description 5000/~120 visible), which enriches the choice beyond the bare enum labels.

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+resource: counts text against YouTube's limits, and names the exact metrics reported (hard cap, softer cutoff, code points vs UTF-16 units). Clearly distinguishes from siblings like runsheet_style_text or runsheet_preserve_line_breaks, which transform rather than measure text.

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

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

The description implies when you'd use it (to check whether text fits YouTube's display limits), but never states prerequisites, when-not-to-use, or how it relates to alternatives such as style_text. Usage context is inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the 'Read only' line is largely redundant. However, the description adds genuinely useful behavioral context beyond the annotations: the data is a snapshot 'as Runsheet last recorded it' with a 'when it was last synced' field, telling the agent results may be stale rather than live.

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 that are front-loaded with the core purpose and the returned fields. The trailing 'Read only' is a minor redundancy against the readOnlyHint annotation, but nothing is wasted overall.

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

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

With no output schema, the description usefully enumerates the returned fields and flags the cached nature of the data, which is what an agent needs for a zero-parameter read. The only gap is the lack of routing guidance relative to sibling getters, which is minor for such a simple 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No parameter meaning is needed or 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 names a specific resource (the connected YouTube channel) and enumerates the exact fields returned (title, handle, subscriber count, total views, video count, last sync), so the purpose is unambiguous. It does not explicitly differentiate itself from siblings like runsheet_get_schedule or runsheet_get_library, but the 'channel' resource is distinct enough that an agent can separate it from the other getters.

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: it's a read of the channel's recorded state, but there is no statement of when to call it versus the sibling getters or of any prerequisites. The phrase 'as Runsheet last recorded it' hints at cached/local data as opposed to a live API call, which is mildly useful, but no explicit when/when-not guidance is given.

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

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

Goes well beyond the annotations: a 50-item cap, snapshot cadence (twice a day), the fact that counts are not live from YouTube, that history begins at channel connection and is bounded by the plan's window. These constraints materially affect how an agent should interpret the numbers, and nothing contradicts the readOnly/openWorld hints.

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 what is listed and in what order, then the per-line contents, then the caveats. It runs several clauses long, but each clause carries a distinct fact (order, fields, snapshot provenance, history limits) rather than 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?

With no output schema, the description carries the return-format burden and does so: it explains each line contains views, seven-day gain (with the short-history caveat), and the video_id. Combined with the snapshot/history provenance notes, an agent has everything needed to call 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?

Schema coverage is 100% – both 'kind' and 'limit' are fully documented with their defaults and the enum. The description only restates the 50-item maximum already present in the limit field, adding no new filtering or formatting semantics, so the baseline 3 applies.

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

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

The description identifies the resource precisely ('Published videos, most recent first'), which separates it from siblings like runsheet_get_watchlist and runsheet_get_schedule. The verb is implicit (the title's 'Get'), but the scope and ordering are concrete enough for an agent to know what 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?

Usage is only implied: it notes the output includes 'the video_id that the write tools take' and that it is read only, which hints at a read-then-write workflow. There is no explicit when-to-use statement and no sibling named as an alternative, so the agent must infer 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description's 'Read only' repeats that rather than adding to it. What it does add beyond structured fields is a hard result cap ('Returns at most 50'), which is real behavioral information an agent needs for pagination reasoning, though it omits what happens when the cap 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?

Three short sentences, front-loaded with what the list contains before moving to the consumer note and the cap. Every sentence carries information, though the 'Read only' fragment adds little given the 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?

With no output schema, the description steps in to characterize the return ('each line ends with the video_id') and the 50-item limit, which is enough for an agent to call and consume it. It could go one step further on what a 'line' contains besides video_id, but nothing critical is missing for a single-optional-param read tool.

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

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

There is only one parameter and schema coverage is 100% – 'days' with its default 28 and maximum 90 are fully documented in the schema. The description adds no syntax or format detail for 'days' beyond what the schema states, so the baseline 3 applies.

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

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

The description names the exact resource subset ('scheduled or ready but not yet published'), states ordering ('soonest first'), and clarifies why the tool exists ('the running order: what is going out and when'). This is specific enough to separate it from siblings like runsheet_get_library and runsheet_get_watchlist without opening either schema.

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

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

It gives downstream chaining guidance by naming runsheet_schedule_video, runsheet_update_metadata and runsheet_file_to_playlist as consumers of the returned video_id, which tells the agent where this tool fits in a workflow. It does not, however, state when to prefer this over other listing tools (e.g. get_library) or any exclusion conditions.

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

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

Annotations already declare readOnlyHint=true, and the description's closing 'Read only' restates that rather than adding to it. It does add genuinely useful non-obvious context: the numbers are Runsheet's stored copy of public YouTube data, refreshed in the background and held for at most 30 days, so results may be stale rather than live. That is solid disclosure, but it says nothing about empty watchlists, error behavior, or cost.

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 what the tool returns, and the definition of 'breakout videos' earns its space because no output schema exists to explain it. Three dense sentences with little waste, though the parenthetical definition is slightly long.

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 describing returns, and it does so well: per-channel metrics, the creator's own baseline numbers, and the watch_id/video_id handles. It still omits edge cases such as what an empty watchlist returns or any access prerequisites.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description instead documents the shape of the returned IDs, which is a reasonable substitute.

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 ('the other YouTube channels this channel watches') and enumerates the exact metrics returned (uploads/week, Shorts share, breakout videos). It is clearly distinguishable from siblings like runsheet_get_channel because it describes the comparison against the creator's own numbers and names the downstream consumer of the IDs.

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?

Clearly establishes the context of use: it returns watch_id and video_id values that runsheet_break_down_breakout takes, effectively routing the agent to the next tool. However, it gives no explicit exclusions or when-not-to-use guidance relative to siblings such as runsheet_get_channel.

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 no annotations, the description carries the full disclosure burden, and it does establish the read-only safety profile ('Reads nothing except file metadata'). However, it says nothing about behavior on a nonexistent path, permission requirements, or result size for large/recursive folders.

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 delivers purpose and return shape, the second delivers usage and the read-only guarantee. No filler, and the key scope constraint ('THIS machine') 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?

There is no output schema, but the description compensates by naming the returned fields (size, duration, vertical/landscape) plus the thumbnail-spotting benefit. Combined with full schema coverage on the two inputs, this is nearly complete, only missing error/edge-case behavior.

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 folder and recursive parameters are already well documented in the schema. The description adds no additional meaning about path formats or what 'recursive' changes in the output, 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) plus resource (video files in a folder) and scopes it to 'THIS machine', which cleanly separates it from remote-library siblings like runsheet_get_library. It also enumerates the returned attributes (size, duration, orientation), so an agent knows exactly what it gets.

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 positions the tool in a workflow: 'Use this before runsheet_upload_video' and notes the thumbnail-matching use case. That is clear situational context with a named sibling, though it does not explicitly state when not to use it or name the alternative for remote files.

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?

readOnlyHint=true and openWorldHint=true already declare the safety profile, so 'Read only' is largely redundant with the annotation. The description does add useful behavioral context by describing the shape of what comes back (ids plus per-playlist video counts), but it says nothing about pagination, limits, or auth requirements on a potentially large remote listing.

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 that lead with what the tool returns and follow with the downstream use case. The trailing 'Read only' is a minor redundancy with the annotation rather than wasted space.

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

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

With no output schema, the description compensates by summarizing the return payload (playlist ids and video counts) and the intended follow-up tool. For a zero-parameter read tool this is nearly complete, though it omits any note on result size or pagination for an open-world channel listing.

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 per the rubric the baseline is 4. The description correctly implies no input is needed and instead points at the returned id field the caller will want to consume.

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

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

The description names a specific verb and resource (list the playlists on the connected channel) and even summarizes the payload (ids and video counts), which is more than the title conveys. It is clear enough to distinguish from the other runsheet_get_* readers, though it does not explicitly contrast with them.

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

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

It gives a concrete trigger: 'Use this to find the id for runsheet_file_to_playlist.' That tells the agent exactly when to reach for this tool over the other listing/reading siblings. It stops short of stating when not to use it or naming alternative listers.

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 readOnlyHint and openWorldHint already covering the safety profile, the description adds genuinely useful behavioral context: the return value is a URL, two aspect-ratio files are produced, and they are non-interchangeable on YouTube. It stops short of covering failure modes or what happens when layout is omitted.

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

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

Two sentences, zero waste, front-loaded with the action and result before the caveat. Every clause earns its place.

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

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

For an 8-parameter rendering tool with no output schema, the description supplies the missing return-shape information (URLs, two aspect ratios) that an agent otherwise could not infer. Minor gap: it does not say what layout is used when the optional layout parameter is omitted.

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

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

Schema description coverage is 100%, so every parameter including the enum vocabularies for tone and layout is already fully documented in the schema. The description only names headline and layout as the drivers, adding nothing the schema does not already say.

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 output ('Render a YouTube thumbnail as a PNG') plus the two inputs it is driven by (headline, layout), and distinguishes itself from every sibling, which are all get/list/upload/style tools. The 16:9 vs 9:16 output split further pins down exactly what this produces.

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 purpose but never stated: there is no 'use this when...' or 'do not use this for...' clause, and no named alternative or prerequisite. The relationship to runsheet_draw_thumbnail_art only appears in the schema, not 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 only declare readOnlyHint=true and openWorldHint=false, so the description adds real value: it discloses the exact character used (U+2060), states it returns paste-ready text, guarantees idempotency (no stacking), and notes no cost/allowance is consumed. It stops short of describing edge cases such as input with no blank lines, but the behavioral picture is strong.

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 tightly packed sentences, each earning its place: what it does, what it returns, and the idempotency/no-cost guarantees. The purpose is front-loaded 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 simple one-parameter transform with no output schema, the description covers purpose, the exact mechanism, the return value ('text ready to paste'), idempotency, and cost. Nothing an agent needs in order to call it correctly is missing.

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

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

There is a single parameter at 100% schema description coverage, which already documents 'text'. The description implies the input is text containing blank lines but adds no format or syntax detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Insert the invisible character (U+2060 WORD JOINER)') and names the exact problem it solves for YouTube descriptions, comments and community posts. This is clearly distinguishable from siblings like runsheet_style_text or runsheet_count_characters 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?

The description gives clear context for when to use it: text destined for YouTube that contains blank lines. It does not explicitly name alternative tools or state when NOT to use it, but the trigger condition is unambiguous.

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 readOnlyHint=true already covering safety, the description adds real behavioral context: it returns both native markdown-ish syntax and Unicode mathematical letters, warns that Unicode variants are not searchable and are problematic for screen readers, and notes there is no cost or allowance consumed. It does not describe the exact response payload, which keeps it from a 5.

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

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

Three sentences, each load-bearing: the capability, the dual output format with usage preference, and the cost note. The most decision-relevant fact (what it returns) 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?

No output schema exists, so the description must carry the return-value burden; it explains the two output formats conceptually but not the response structure (field names/shape). Given the low complexity and only two required params, this is nearly 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?

Schema description coverage is 100%, so both parameters and the enum values are already documented in the schema. The description reinforces style behavior (which styles lack native syntax or Unicode digits) but adds little tool-call syntax beyond the schema's 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 and resource ('Produce bold or italic text for YouTube') and immediately contrasts itself with tools like runsheet_count_characters or runsheet_preserve_line_breaks by being the styling transform. An agent can identify the function 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 conditional guidance on output choice: prefer native syntax where it works, Unicode only where syntax renders literally (titles/descriptions). It does not name an alternative styling sibling (there is none) or state exclusions for when not to call it, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does so richly: local disk read streamed directly to YouTube (never touching Runsheet servers), always PRIVATE, never published immediately, the 15-minute publish_at floor, ffprobe-based kind detection, automatic thumbnail pickup, and explicit rate limits (25/day per account, 80/day global, channel-specific allowance).

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 on the long side, but nearly every sentence carries a distinct behavioral fact and the core action is front-loaded. The quota paragraph is flagged IMPORTANT, which is justified given the operational consequence of a batch silently stopping.

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

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

For a 7-param mutation tool with no annotations and no output schema, it covers behavior, scheduling semantics, and quota constraints thoroughly. The one gap is that it never says what the call returns or how partial-batch failure is surfaced programmatically, which matters without an output schema.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real semantics the schema lacks: that kind is usually unnecessary because it is auto-detected, and that thumbnail_path is often unnecessary because a co-located/thumbnail.png image is auto-adopted.

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 with scope: 'Upload a video file from THIS machine to YouTube through Runsheet, and schedule it.' It also names the key distinction from siblings, which are read/list/utility tools (list_local_videos, make_thumbnail), leaving no ambiguity about what this tool does.

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 conditional guidance: pass publish_at to schedule, omit to leave a private draft, pass kind only to override detection, and thumbnails are auto-picked-up when named or co-located. It does not explicitly name an alternative sibling to use instead, but for an upload tool the main usage decisions are covered.

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