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

No annotations are supplied, so the description carries the full burden. It implies a write ('Put an idea'), but says nothing about persistence, whether the idea can later be removed (kill_idea exists), whether fields are editable, or any auth/rate constraints — critical gaps for an unannotated mutation tool.

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

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

A single short sentence with no filler, and the core action is front-loaded. It is efficient but borders on under-specification for a five-parameter tool.

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

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

With five parameters, 0% schema coverage, no annotations, and no output schema, the description should explain the pitch-style field set and what creating an idea yields. It explains neither, leaving the agent to guess at the semantic intent of four of the five fields.

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

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

Schema coverage is 0% and the parameters use non-obvious pitch-template names (why_now, how_much, who_pays, first_step) that the description never mentions. Only the required 'idea' field is loosely reflected in the wording; the four optional fields are entirely unexplained in both schema and description.

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 ('Put an idea... on the idea board') that an agent can distinguish from list_ideas and kill_idea by name alone. The phrase 'of your own' signals authorship, though it does not explicitly name the siblings it differs from.

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

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

No when-to-use or when-not-to-use guidance and no alternatives named. The agent must infer from sibling names (list_ideas, kill_idea) that this is the creation path, and gets no hint about whether check_channels or judge_video should precede it.

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

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

No annotations exist, so the description carries the full burden, and it does substantial work: no transcript fetch, no model invocation, and a cost disclosure ("one polite YouTube request" per channel, capped at max_channels). It does not say what happens if channels.txt is missing or what the returned items look like.

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

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

Three short sentences, zero filler, with the core action first and the cost/pagination constraints following. Every sentence adds a fact the agent needs.

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, cost, and pagination adequately for a no-output-schema tool, but leaves the days parameter undefined and gives no indication of what fields each listed video carries. For a 2-param tool with no annotations and no output schema, that is adequate but not 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 coverage is 0%, so the description must define both parameters. It explains max_channels well ("at most max_channels are listed per call") but never mentions days at all — the recency window is left entirely implicit, which is a meaningful gap for a 'new videos' tool.

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 new videos from the channels in your channels.txt") plus the ordering rule ("priority channels first"). The clause "fetches no transcript and calls no model" implicitly separates it from get_transcript and judge_video, so an agent can route correctly without opening schemas.

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

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

Gives clear operational context: it only reads channels listed in channels.txt, caps work at max_channels per call, and explicitly says "call again to go on through the rest," which is real pagination guidance. It stops short of naming when to prefer a sibling such as todays_digest instead.

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

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

With no annotations, the description does add useful behavioral context: it discloses the local-first fallback to YouTube captions and that refusal should be handled by waiting. It still omits details about permissions, rate limits, or what a transcript response looks like, leaving gaps for a no-annotation 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?

The description is a single compact sentence with the core resource information front-loaded. The phrasing 'politely' and 'A refusal means wait' is slightly informal but still communicates operational guidance without bloat.

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

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

For a one-parameter tool with no output schema or annotations, the description covers input format, retrieval fallback, and refusal handling. It is mostly complete, though it could explicitly note that the return value is the transcript text.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the single parameter. It does so meaningfully by stating that the video input can be a video link or an 11-character ID, which adds format guidance beyond the bare schema.

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

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

The description clearly identifies the resource as one YouTube video's transcript and specifies accepted input forms (link or 11-character ID). It is distinguishable from siblings like judge_video or check_channels, though it phrases the purpose as a noun phrase rather than an explicit verb.

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 indicates the source fallback behavior (local cache first, then YouTube captions) and notes that a refusal means to wait. However, it does not state when an agent should call this tool versus alternatives or whether there are prerequisites like authentication.

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 add one genuinely useful trait: 'worthwatch calls no model here: you do the judging', which tells the agent this returns instruction material rather than a computed verdict. However, it never clarifies side effects — whether step 3 saves anything itself or merely instructs, and whether the call is read-only — which matters for a tool with a save_verdict sibling.

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

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

Front-loaded with the core purpose and structured as a numbered breakdown, with no filler sentences. The nested colon-list is slightly dense 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?

Because there is no output schema, the description usefully tells the agent roughly what comes back (decision rules, write-up format, save instructions), which is strong. But it leaves the single input's format unspecified and the save behavior ambiguous, so it is not fully complete for a no-annotation 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 single required parameter 'video' has 0% schema description coverage and the description adds nothing: it does not say whether the value is a URL, video ID, or title. This is the one field the agent must supply, and its format is undocumented in both places.

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

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

States a specific verb and resource ('judge one video for the user') and enumerates the verdict outputs (YES, OPPORTUNITY, MAYBE, NO), so the agent knows exactly what the call produces. Sibling differentiation is partial: step 3 ('how to save it') overlaps with the save_verdict sibling, leaving it unclear which tool actually persists the result.

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 step 1/2/3 framing implies a workflow (judge, then write up, then save) and step 2's 'with the full transcript' hints the transcript should already exist, but no sibling is named and there is no explicit when-not or 'call get_transcript first' 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?

With no annotations, the description carries the behavioral burden and does clarify the key effect: the idea stops being suggested rather than necessarily being deleted. However, it omits permissions, reversibility, and whether the kill can be undone.

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

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

A single front-loaded sentence with no wasted clauses. The resource, required reason, and outcome are all stated compactly.

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

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

For a simple two-parameter mutation tool with no annotations or output schema, the description covers the core operation and reason parameter. It remains incomplete on permissions, permanence, and idea_id semantics.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that a reason is supplied, but adds no detail about idea_id, identifier format, or constraints on the reason string.

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 ("Kill an idea on the board") and states the resulting effect ("so it stops being suggested"). That is enough to distinguish it from siblings like add_idea and list_ideas without needing to name them.

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

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

Usage is implied by the stated outcome: use this when an idea should stop being suggested. There are no explicit when-not conditions or named alternatives, so it is only minimum-viable guidance.

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

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

With no annotations, the description carries the behavioral burden and does well by disclosing the returned idea fields and the default exclusion of killed ideas. It does not explicitly state read-only behavior, ordering, or pagination, but for a listing tool it provides substantial useful context.

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

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

The description is a compact, front-loaded sentence that immediately establishes the resource and then summarizes contents and filtering. There is no wasted text.

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

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

For a simple one-parameter listing tool with no output schema, the description explains the returned idea contents and the killed-idea filter. It omits minor details like ordering or pagination, but is sufficiently complete for correct invocation.

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

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

Schema description coverage is 0%, so the description must explain the only parameter. The phrase "Killed ideas only when asked for" directly clarifies the include_killed behavior and implies the default exclusion, though it does not name the parameter explicitly.

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 specific resource as the idea board and scopes it to ideas found in videos or added by the user. It also lists the core idea metadata and notes that killed ideas are excluded by default, which distinguishes it from add_idea and kill_idea without naming those siblings directly.

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 condition for including killed ideas: only when asked for. However, it does not explicitly say when to use this tool versus siblings like todays_digest, add_idea, or kill_idea, so usage is mostly implied by the name and 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?

With no annotations, the description carries the full burden and does real work: it discloses that verdicts are validated in code against the user's own rules — quotes must be in the transcript, a YES requires a live project and an action, standing decisions cannot be broken — and that the returned verdict may be normalized before the digest shows it. The gap is failure semantics: it does not say whether a rejected verdict raises an error, returns a corrected one, or is silently dropped.

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

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

Three sentences, front-loaded with the action, then validation rules, then return behavior. Dense and mostly free of waste, though the clause about 'exactly as it checks a model's' is atmosphere more than guidance.

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

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

No output schema exists, and the description does partially cover the return ('the verdict that comes back is the one the digest will show'). But for a three-required-parameter mutation with no annotations and no schema documentation, the missing parameter formats and failure behavior leave it only adequate.

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

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

Schema coverage is 0%, so the description must explain all three parameters and does not. It hints that write_up contains transcript quotes and that verdict can be 'YES', but the allowed verdict vocabulary is never enumerated and the 'video' parameter is entirely opaque — no indication whether it is an ID, URL, or title.

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: store a verdict plus write-up for one video. That is clearly a persistence operation distinct from judge_video or get_transcript. It stops short of naming the sibling it complements (judge_video), so the split of responsibility is inferred rather than stated.

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

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

The description implies this is the step where a judgment is committed, and it enumerates the rules that must hold before a save succeeds. But it never says explicitly 'call this after judge_video' or what to do if validation fails, leaving sequencing 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?

No annotations are provided, so the description carries the full burden. It does disclose the return contents (videos, verdicts, ideas), which implies a read-only aggregate, but it never explicitly states that the tool is non-mutating, nor anything about ordering, empty days, or error 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?

A single sentence with the default behavior and format in parentheses, zero filler, and the core identity of the tool front-loaded before the qualifier.

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

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

With no output schema and no annotations, the description does the essential work: it enumerates the digest's components and pins down the only parameter's format. Minor gaps remain around output shape/ordering and what an empty or future day yields, but an agent has enough 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 description coverage is 0% and the schema's default is the opaque empty string, so the description must compensate — and it does, defining the parameter's format (YYYY-MM-DD) and its default semantics (today when omitted). It stops short of stating accepted range or validation rules.

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

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

The description states a specific resource (a one-day digest) and enumerates its contents: every video read that day, its verdict, and the day's ideas. That distinguishes it from siblings like list_ideas or get_transcript, though it never uses an explicit verb such as 'returns' or 'retrieves'.

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

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

The parenthetical 'today unless day is given as YYYY-MM-DD' conveys the default/override condition, which is useful context. However, there is no guidance on when to prefer this aggregate over the sibling primitives it summarizes (list_ideas, get_transcript, judge_video), and no exclusions are stated.

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