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

With no annotations, the description carries the full burden and does meaningful work: it discloses that execution happens via signed-in Chrome (an auth/environment requirement), that the question and result are persisted to a local task file (a side effect), and that attachments are constrained to allowed roots. It omits failure/timeout behavior and rate limits.

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 and answer return in the first sentence, then two compact follow-ups on persistence and URL/PDF constraints. No filler, though the persistence note is slightly tangential to invocation decisions.

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 must cover behavior and returns. It handles continuation semantics and attachment constraints well, but is silent on three non-obvious parameters (thinking_mode enum, timeout_seconds, minimum_response_characters), leaving an agent unable to reason about latency and answer-completeness controls.

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 6 parameters, so the description must compensate. It clarifies attachment_path (absolute, inside allowed roots) and conversation_url (canonical https://chatgpt.com/c/... URL, omit for new chat), but leaves thinking_mode, timeout_seconds, and minimum_response_characters 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?

Specific verb and resource: 'Send one question ... and return ChatGPT's answer,' with the Chrome-signed-in mechanism named. It implicitly separates itself from the read-only sibling read_chatgpt_conversation by describing both submission and answer retrieval, though it never names that sibling explicitly.

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 decision rule for the conversation_url parameter: supply a canonical URL to continue an existing chat, omit it for a new one. It also states the precondition for PDF attachments (absolute path inside the bridge's allowed roots). It stops short of naming alternative tools or exclusions, so no explicit when-not 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 full burden. It usefully discloses two side effects: a collection plus a source.yaml are written, and no job is started (the key behavioral distinction). It says nothing about permissions/authentication, whether an existing collection is overwritten, or what identifiers are returned.

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, and the core action plus its 'no job started' constraint are front-loaded. The second sentence is slightly clunky ('After this, call start_collection only when...') but earns its place by establishing the workflow order.

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 5-parameter creation tool with no annotations, no output schema, and zero schema descriptions, the definition is under-specified. It never explains the enum strategy, optional limits like max_items, or what the call returns, so an agent cannot confidently populate or act on 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 description coverage is 0% and the description offers no parameter meaning at all. Five parameters exist (url, name, the strategy enum, max_items, instructions) and the agent gets no hint about what url points to, what the strategy values mean, or how instructions shape collection behavior.

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: create a WebContent collection (plus a source.yaml) without starting a job. It explicitly contrasts with the sibling start_collection, so the agent can separate creation from execution. 'Safe WebContent collection' is slightly opaque jargon, but the action is unambiguous.

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 sequencing rule with a condition: create first, then call start_collection only when the user asks to begin. That is real when-to-use guidance for the follow-up step. It does not address alternatives other than start_collection (e.g. discover_site or list_collections) or any explicit when-not-to-use case.

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 usefully discloses what is deliberately excluded (page bodies, logs, screenshots, repeated tool results, hidden reasoning), which is real behavioral context, but says nothing about side effects, permissions, whether the snapshot is stored or returned, or what it contains positively.

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 purpose sentence followed by a compact usage rule and an omission list, all of which earn their place. 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?

Adequate for a one-parameter tool with no annotations, but with no output schema the description should say what the snapshot looks like or how the agent consumes it in a new Chat. That return-value gap leaves an agent without a clear next step after calling 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?

There is a single parameter, run_id, with 0% schema description coverage, so the description must compensate. It implies a run-scoped operation via 'durable run state', but never explains what run_id identifies or what form it takes.

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: compress durable run state into a small snapshot for continuing in a new Chat. It is clearly distinguishable from siblings like get_run_status or resume_run, but it never names an alternative, so the differentiation is conceptual rather than explicit.

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 condition: use once when a Chat becomes long or before a long background wait, including frequency guidance ('once'). It does not state when not to use it or which sibling to prefer 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 carries full burden; it does disclose the key scope limit (single public page, no collection download), which implies a read-only probe. It says nothing about authentication, rate limits, or how the returned links are ranked, leaving notable behavioral gaps.

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, front-loaded with the action and immediately followed by the scope constraint and usage ordering. 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?

With no annotations and no output schema, the description should describe what 'list likely content links' actually returns and what 'instructions' does. The core workflow is conveyed, but these gaps leave an agent guessing on return shape and the second parameter.

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. 'url' is self-evident, but 'instructions' (with a default of 'Find likely content collections.') is a non-obvious parameter whose effect on the inspection is never explained in the 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 (inspect) and resource (one public page) plus the delivered artifact (likely content links), which cleanly separates it from start_collection/create_collection siblings. It stops short of naming a sibling explicitly, so it isn't a top-tier 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?

"Use it first for an unfamiliar site, then ask the user which collection they want" gives explicit ordering and a follow-up step, and "never downloads a collection" rules out the obvious wrong expectation. It does not name which sibling to call next, but the when-to-use condition is clear.

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 a meaningful behavioral trait: output is redacted and never includes cookies, authorization headers, credentials, or full logs. That is a genuine security-scoping guarantee beyond the schema. It stops short of covering auth requirements or behavior for non-failed runs.

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, front-loaded with the return content and scoped with the redaction constraint. It is efficient, but the redaction idea is stated twice ('redacted failure summary' and 'Never returns ... full logs'), a small 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?

For a one-parameter getter with no output schema, the description covers what comes back (failure summary, bundle path) and the redaction boundary, which is the key thing an agent needs. Missing only the origin/format of run_id and behavior for a non-failed run.

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 run_id carries no title or description, so the description would need to compensate. It says nothing about run_id format, source, or whether it must reference a failed run, but the single self-explanatory identifier keeps this only a moderate 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 and resource: returns a failure summary and bundle path. It clearly describes the payload shape ('failure summary and bundle path'), which distinguishes it from a status-only tool, though it never names the sibling it differs from, such as get_run_status or validate_run.

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 clause 'for a failed run' implies the triggering condition, so usage is inferable. However, it gives no comparison against get_run_status or validate_run, and does not say what happens if the run did not fail, leaving the agent to guess when this is the right call.

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 burden and does disclose useful behavior: it returns condensed progress rather than logs, and it warns against repeated invocation in a single turn. It omits auth/permission requirements, whether output is cached or live, and what happens with an invalid run_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 short sentences and a constraint, with purpose stated first and the triggering cue immediately after. No filler and nothing redundant.

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 return values need not be described, and the description notes they are concise. However, with zero annotation coverage and an undocumented required run_id, an agent lacks the input sourcing and safety context needed to invoke this confidently.

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 one required parameter (run_id) with 0% schema description coverage, so the schema adds no meaning. The description never explains what a run_id is, its format, or where to obtain it, leaving the sole input undocumented.

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 verb+resource (get progress for a run) and distinguishes it from the full-log retrieval path ('without returning full logs'). It does not name sibling tools like get_failure, so it stops short of full 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?

It gives an explicit triggering condition ('when the user asks how a download is going') and a usage constraint ('Never call it repeatedly in one response'). It does not route to alternatives such as get_failure for error cases, so it is clear but incomplete.

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 supplied, so the description carries the full behavioral burden. 'List' implies a read, and the return fields are hinted at, but there is no statement about pagination, result volume, ordering, or required permissions for what is presumably a bulk-read 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?

Two short sentences, front-loaded with the operation and result contents, with the usage note following. No filler or redundancy, though the second sentence is thin and could carry more routing value.

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 tool with no output schema, the description does supply the key return fields, which is the main thing needed. It stops short of pagination/ordering behavior and of differentiating this list from the run-status siblings, leaving the agent to guess in a crowded toolset.

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 of 4 applies; the description's mention of returned fields is a mild bonus rather than 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?

Names a specific verb and resource ('List collections') and even enumerates the returned attributes (source URL, latest status, content counts), which is more than a tautology. However, it never distinguishes itself from siblings that also surface collection/run data, notably get_run_status and start_collection, so an agent cannot tell from the text alone which to pick.

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 for questions about existing collections or the latest run' gives an implied context for invocation, but offers no explicit when-not guidance and names no alternative tool. With siblings like get_run_status and get_failure covering adjacent run information, the absence of routing guidance is a real gap.

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 that the tool 'never types, submits, or uploads anything,' establishing a read-only safety profile, but says nothing about authentication needs, rate limits, timeout behavior, or what happens when the conversation is missing.

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 the core purpose front-loaded and the safety constraint and URL prerequisite following in priority order. 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?

No output schema exists, so the description reasonably explains the return (latest assistant response), but it leaves three of four parameters unexplained and omits failure/timeout behavior. For a 4-param tool with zero annotation and zero schema-description coverage, more is needed.

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 4 parameters, and the description only clarifies the required conversation_url (canonical chatgpt.com/c/... format). timeout_seconds, expected_message_id, and minimum_response_characters are left entirely undocumented 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 — reading the latest assistant response from an existing ChatGPT conversation — and scopes it narrowly ('latest assistant response'), which distinguishes it from ask_chatgpt's create-and-send behavior. An agent can tell what it retrieves 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?

Explicitly frames the tool as 'recovery-only' and requires the canonical URL returned by a previous ask_chatgpt call, giving both the situation (recovery) and the dependency. It stops short of naming an alternative tool or an explicit when-not-to-use condition.

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 provided, so the description carries full burden. It mentions resuming without repeating completed work, implying idempotence or checkpointing, but does not disclose: required permissions, whether it can be called multiple times, what happens if the run is not resumable, or the return behavior. For a mutation tool with no annotations, this is a significant 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, front-loaded with the core action and constraint, followed by a precise usage condition. No wasted words.

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 no annotations and no output schema, the description should disclose side effects, permission requirements, and failure modes. It only mentions the resumability precondition, which is helpful but insufficient given zero structured behavioral data.

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 doesn't describe the run_id parameter at all beyond the schema's implicit type. Baseline 3 is given because the parameter is self-explanatory (run_id identifies the run), but the description adds no semantic detail.

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 (resume a run) and adds a key constraint: without repeating completed work. This distinguishes it from a hypothetical 'restart' tool. However, it does not explicitly differentiate from siblings like get_run_status beyond usage note.

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 precondition: use only after get_run_status or get_failure says the run is resumable. Names specific sibling tools. Lacks explicit when-not-to-use beyond the precondition, but that's effectively covered.

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 disclose key behavior: the process runs independently in the background and returns a run_id immediately (non-blocking, asynchronous). It omits what happens on failure, whether concurrent starts are allowed, and any resource or permission implications.

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 with no filler, leading with the action and following with the return value and the path constraint. Efficient, though the trailing constraint reads as an afterthought rather than being grouped with the parameter it governs.

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 the description usefully tells the agent it gets a run_id back, so the return-value burden is covered. However, with no annotations on a process-launching tool, more behavioral context (side effects, failure handling, relationship to get_run_status/resume_run) would be needed for full completeness.

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 text ('Source Config', string) is uninformative, so the description's constraint that the value must be a source.yaml path inside WebContent is genuinely valuable. It still leaves path format details (absolute vs relative, extension expectations) unstated, so it only partly compensates.

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 effect: start the existing worker as an independent background process. This distinguishes it reasonably well from siblings like create_collection (creates a new one) and resume_run (continues an existing run), though the description's use of 'worker' against a tool named start_collection leaves a slight terminology mismatch.

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 explicit when-to-use guidance and no mention of alternatives. The phrase 'the existing worker' weakly implies the collection must already exist, but the agent is not told how this differs from create_collection or resume_run when deciding which sibling to call.

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 full behavioral burden. It discloses what is checked (outputs, hashes, image paths), which is genuine behavioral content, but says nothing about side effects, idempotency, required permissions, or what a failed validation yields.

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 compact sentences with no waste; the primary action is front-loaded and the usage cue follows. Appropriately sized for a single-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?

No output schema exists, so the description should ideally describe what validation returns (pass/fail, which artifact failed). It omits return semantics and leaves the run_id parameter unexplained, which is insufficient for a tool whose whole value is its verdict.

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 run_id has 0% schema description coverage, and the description never explains what a run_id is or where to obtain it. It fails to compensate for the schema gap on the one parameter that matters.

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 (validate) and concrete resources: final outputs, hashes, and local image paths. This distinguishes it from siblings like get_run_status and get_failure, which read state rather than verify artifacts. Clear, though it doesn't explicitly name those 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 precondition: 'Use after status reports success,' implicitly referencing the get_run_status sibling. There is no when-not guidance or mention of what to do on failure, but the trigger context is clear enough to select the tool.

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