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

With no annotations, the description carries the full burden and does disclose meaningful traits: the call returns immediately with a check_id, no scheduler is created, and delivery history only advances on a complete reviewed report. It omits permission requirements and whether checks can expire or be cancelled.

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, with the core action and required follow-up front-loaded. No filler or repetition 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?

There is no output schema or annotations, so the description must carry heavy load. It covers the async flow and the check_id return, but leaves all three parameters semantically undefined and says nothing about authentication or failure modes, so it is only partially complete.

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

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

Schema description coverage is 0% across three parameters. The phrase 'creator-name/ID/profile check' loosely hints at the creator and profile parameters, but refresh_identity is never mentioned and no format, default, or effect is explained. The description does not compensate for the coverage gap.

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

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

States a specific verb (start) and resource (creator-name/ID/profile check) and clarifies it is asynchronous, returning a check_id. It distinguishes itself from the reporting sibling by naming get_report, though it does not clarify how it differs from resolve_creator_from_videos.

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

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

Explicitly tells the agent to poll get_report after starting, giving a concrete next step. However, it provides no condition for when to prefer this over the sibling resolve_creator_from_videos, so exclusions are absent.

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 must carry the behavioral burden. It does disclose the return surface and, usefully, the semantics of status flags (done+complete vs delivery_complete), which is real context. However, it says nothing about read-only safety, permissions, error states, or what happens for an unknown/expired check_id.

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 no filler, and the core payload is front-loaded before the status-flag clarification. Efficient, though the status explanation is compressed to the point of being cryptic.

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?

The description partially substitutes for the missing output schema by enumerating returned fields, which is genuinely helpful. But with no annotations, no output schema, and an undocumented required identifier, gaps remain around input sourcing, auth, and failure 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 0% and the single parameter check_id is undocumented in both schema and description. Since coverage is far below 50%, the description is expected to compensate for the opaque identifier, and it does not — no hint of where a check_id comes from or its format.

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 (Get) and enumerates the concrete payload: live status, newest link, sampled engagement counts, and raw/reviewed file paths. It is clearly a read/retrieval of a per-check report, distinguishable from get_transcript and submit_review, though it never defines what a 'report' or 'check' actually is.

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

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

There is no when-to-use guidance and no mention of any sibling alternative. The second sentence explains how to interpret status values, which is output semantics rather than a trigger condition, so an agent gets no help deciding when to call this versus get_transcript or submit_review.

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 it does disclose pagination behavior (next_offset terminator) and asserts the content is unpaginated-original ASR rather than a derived summary. It omits permissions/auth requirements, error behavior, and what happens if paging stops early, so it is only partially transparent.

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, no filler, with the core read action front-loaded. The final sentence is compact but cryptic, so it costs a little clarity for its brevity.

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 annotations and no output schema mean the description has to cover both behavior and return shape; it does name return fields (indices, source_sha256, next_offset), which partly substitutes for the missing output schema. It still leaves check_id's provenance and the limit parameter 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 0% across three parameters (check_id, limit, offset), so the description must compensate and largely does not. 'next_offset' and the paging instruction gesture at offset, but limit and check_id — including where check_id comes from — are left entirely unexplained.

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?

Names a specific verb ('Read') and resource ('ordered original ASR segments') and lists what the segments carry (indices, source_sha256). It is clearly distinguishable from siblings like get_report and submit_review, though it never names an alternative tool for the same need.

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 procedural rule ('Follow next_offset until null before reviewing') and a prohibition ('Never summarize the title as speech'), which is more than implied usage. However, it never says when to reach for this tool instead of get_report or submit_review, and the 'title as speech' warning is terse enough to require domain 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?

With no annotations supplied, the description carries the full burden and does add real behavioral context: it scopes the return to QR path plus session status, warns that saved state can expire, and states a security constraint that browser credentials are never returned. It still omits whether the call requires an existing session or what status values can appear.

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, each doing work: the first defines the return scope and the second supplies the expiry caveat and the credential-safety guarantee. Nothing is padded or 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 zero-parameter, no-annotation tool with no output schema, the description covers purpose, return scope, and the key operational caveat. It is slightly incomplete in not enumerating possible session statuses or linking back to start_login, but nothing critical to invoking it is missing.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to clarify beyond the schema's empty argument object.

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 ('Return') and precise resources ('QR path and dedicated-session status'), so an agent knows this is a read-only status probe rather than an action tool. It does not explicitly distinguish itself from the closely related sibling start_login, which weakens differentiation.

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 caveat 'Saved state can expire' implies the tool should be re-invoked to refresh a stale login session, but there is no explicit when-to-use statement or comparison to start_login. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the full burden. It does disclose real behavioral traits — halting on captcha or ambiguity, and the epistemic limit that index results are not proof of newest work or counts — but says nothing about authentication requirements, rate limits, or what a successful resolution returns.

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 dense sentences with the fallback condition front-loaded and no filler. The telegraphic style ('Stops on captcha/ambiguity') is efficient but borders on cryptic for an agent with no other context.

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 and no annotations, so the description is the only source of truth. It covers invocation preconditions and failure modes but never describes the return value or how a positive/negative match is represented, which is the key gap for a resolution tool.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: candidate_video_urls is bounded to 1-5 observed official Douyin URLs (cardinality and source), and creator is constrained to an exact identity match rather than fuzzy matching. The expected format of 'creator' (handle vs ID) remains unspecified.

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 concrete operation: verify that the live author of supplied Douyin video URLs matches the exact requested identity, framed explicitly as a fallback path. That is specific enough to distinguish it from a primary lookup, though the actual output of 'resolve' (creator ID? profile? boolean?) is never 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?

'Fallback:' front-loads the condition that selects this tool (only when the host web search has produced observed URLs), and it sets a clear exclusion: the search index is discovery only, never proof of newest work or counts. It stops short of naming the primary sibling (check_creator) that it falls back from.

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 behavioral burden. It usefully discloses an isolation guarantee ("no other browser profiles or cookie contents are read"), but omits what start_login itself returns, QR lifespan/expiry behavior, and error or retry conditions.

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?

Short and front-loaded: the core action comes first, followed by the scanning behavior and the follow-up call. The final privacy clause is a semicolon-joined aside that borders on clutter but still 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 a no-parameter, no-annotation, no-output-schema tool, the description covers the start-to-poll workflow and isolation scope but leaves the return value of start_login undefined — an agent cannot tell whether it receives a QR image, a path, or a session handle. Adequate but with a clear gap.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies since the description doesn't need to compensate for any parameter semantics.

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 ("Prepare a dedicated local Douyin login QR"), which is clearly distinguishable from siblings like check_creator or get_report. It also names login_status as the companion call, though it doesn't explain what "dedicated local" means relative to other possible login flows.

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 next-step guidance by naming login_status for polling the image path, and "User scans normally" sets expectations for the human-in-the-loop flow. It stops short of stating when-not to use it or any prerequisites (e.g., existing session handling).

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 behavioral burden. It does disclose two valuable traits: originals are left immutable (non-destructive) and uncertain text stays in a pending state rather than being resolved. However, it says nothing about idempotency, whether a repeat submission overwrites a prior review, auth requirements, or failure behavior, which are significant gaps for a write tool with zero annotation coverage.

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

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

The purpose and the key constraint are front-loaded in the first clause, and the field enumeration, while long, packs real structural information into a single compact list. The trailing sentence about immutability and pending text earns its place. Minor cost: the opening sentence is dense enough to require careful parsing.

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

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

There is no output schema and no annotations, and the review object is a free-form nested structure, so the description is doing a lot of work. It documents the payload shape well and states the immutability/pending semantics, but it never explains what check_id is, what the tool returns, or what happens on repeat or invalid submissions, leaving the agent unable to fully predict the call's outcome.

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, and it largely does by enumerating the nested review payload field-by-field (source_sha256, edits with index/before/after/reason/evidence/evidence_level/confidence, pending_review, overview with sections and limitations). The notable omission is check_id, a required parameter that is never mentioned or explained, so the compensation is substantial but incomplete.

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 ('Save a semantic review') and scopes it to content produced by the current host AI, so an agent immediately knows it is the persistence step for its own analysis rather than a fetch or query. It is unambiguous against siblings like get_report or get_transcript, though it never explicitly names an alternative, which is what separates a 4 from a 5.

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?

Provides a clear negative directive ('never call another LLM'), which tells the agent this is the terminal write step in the review workflow and not a delegation point. It gives solid context for when to call it, but names no sibling alternative or preconditions (e.g. requiring a prior check_id from check_creator), so it stops short of 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.