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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's contribution is the diagnostic detail: it probes local binaries, anonymous network access, the video stream, and a local STT model, and reports timings. It does not say how failures are surfaced or what the report looks like, but for a read-only check that is a minor gap.

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

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

Two sentences, no filler. The scope enumeration is front-loaded and the usage trigger is packed into the second sentence, so both payloads land before an agent stops reading.

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

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

For a zero-param, read-only diagnostic with no output schema, the description covers what is checked, when to run it, and the failure path. Only the interpretation of results (pass/fail shape) is unspecified, which is acceptable given the low complexity.

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 no parameter meaning to convey and the baseline of 4 applies. The description correctly signals a no-argument, run-and-see invocation.

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 ('Check') plus the exact scope: yt-dlp, ffmpeg, anonymous Reel access, the video stream, and Parakeet Redux speech-to-text. That enumeration makes it unmistakably a dependency-diagnostic tool and clearly distinct from reels_fetch and reels_links.

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 trigger conditions: 'Run it after installing or when reels_fetch fails.' The failure-recovery routing names a sibling and the condition that selects this tool, leaving nothing to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, and the description adds real behavioral context beyond them: no login required, batch limit of 20 Reels, and that per-Reel failures are returned inline with a reason code rather than dropped. It also warns that Instagram exposes only a handful of comments without login, which sets expectations on result completeness.

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 purpose, then Best-for, Returns, and Tips — a clean scannable order with no filler sentences. It is slightly long for the payload, and the 'Best for' list partially restates the Tips section, but every block 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?

There is no output schema, yet the description covers the return shape (per-Reel header plus requested parts, inline failure reporting with reason codes), which is the main gap such a tool would otherwise have. Combined with the no-login and citation guidance, an agent has everything needed to call it correctly and report results.

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 would be 3; the description earns extra credit by showing how parameters combine for the hook workflow (start/end range plus parts plus frames count) and by flagging that burned-in subtitles make frames the reliable way to read on-screen text. It does not explain 'query' or 'frameAt' beyond the schema, so it stops short of a 5.

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

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

States a concrete verb and resource ('Read Instagram Reels from their URLs, without a login') and enumerates the payload (details, transcript, frames, comments, cover). It also draws a boundary with the sibling reels_links by positioning it as the URL-discovery tool, so an agent can route between them without opening either schema.

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

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

The 'Best for' section names concrete use cases (hooks, quoting creators, comparing openings, reading on-screen text), and the Tips give a concrete recipe (start=0, end=5, parts=['details','transcript','frames'], frames=3). It also states a precondition — Instagram has no anonymous search, so URLs must come from the user or from reels_links — which is exactly the when/when-not guidance the dimension asks for.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new context: Instagram has no anonymous search, so the tool is 'keyless' (no auth/credentials needed), and it discloses the return shape including that /p/ posts are listed separately and may be images rather than video. No rate-limit or pagination behavior is described, keeping it from a 5.

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

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

Front-loaded with the core action, then clearly labeled 'Best for:' and 'Returns:' blocks. Every sentence carries information and nothing is repeated from the schema 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?

No output schema exists, and the description compensates by describing the return (unique Reel URLs per page, posts separated). Combined with annotations covering safety and the reason the tool exists (no anonymous Instagram search), an agent has everything needed to select and 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 100% for both parameters, so the schema already documents the URL array and includePosts default. The description adds only the rationale for separating /p/ post links, not new syntax or constraints, 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 and resource ('Collect Instagram Reel links from web pages') and enumerates the sources it targets (articles, newsletters, best-of lists, link-in-bio pages). It also distinguishes itself from the sibling reels_fetch by positioning that tool as the reader of the links this one discovers.

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?

'Best for: after a web search for a topic, pull every embedded or linked Reel out of the result pages in one call' gives an explicit trigger condition, and the reference to reels_fetch tells the agent which tool takes over next. The agent knows when to reach for this tool and what the follow-up is.

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