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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds the useful 'reattach' behavior and 'managed' context, but it does not explain side effects, cleanup, or what happens on repeated calls beyond reattaching.

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 concise sentence with no filler. It front-loads the core action and resource and contains only information that helps characterize the 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?

For a simple optional-parameter tool with rich schema and annotations, the description is largely adequate. However, with no output schema, it does not mention what the tool returns or how the 'reattach' behavior relates to the supplied url parameter, leaving a minor but real 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?

Schema description coverage is 100%, so the schema fully documents url, mode, and devTools. The description adds no additional parameter-level meaning, so it stays at the baseline and does not compensate beyond the 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 uses specific verbs ('Launch or reattach') plus a clear resource ('managed headful/interactive browser session'). It clearly identifies the tool's operation and is distinct from the sibling task/schedule/cabinet tools, even without naming a browser-specific alternative.

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 intended use is implied by the name and description, but there is no explicit statement about when to use this tool versus alternatives, nor any preconditions such as requiring the VNC stack. An agent gets only indirect routing 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?

Annotations already declare this is a non-read-only, non-idempotent, non-destructive mutation, so the safety profile is covered. The description adds the 'durable download queue' framing but does not disclose additional behavioral details like duplicate handling, authentication, or response behavior. There is no contradiction with annotations.

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, front-loaded sentence with no filler. The parenthetical 'durable download queue' adds useful context without bloating the 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 one-parameter create operation, the description and annotations are mostly sufficient: the agent knows the action, resource type, and mutation profile. The only notable gap is that no return value or follow-up behavior is described, and there is no output schema, but this is a minor omission 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 only parameter, 'name', is fully described in the schema with type and example, so schema coverage is 100%. The description itself adds no extra meaning about the parameter beyond what the schema already provides.

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 uses the specific verb 'Create' and identifies the resource as 'Cabinet', further clarifying it as a 'durable download queue' on the Figranium server. This clearly distinguishes it from sibling tools like create_task or list_cabinets.

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 no explicit guidance about when to use this tool versus alternatives, prerequisites, or exclusions. An agent must infer selection context solely from the tool name and the generic action statement.

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?

Beyond the annotations, it discloses persistence ('stored permanently'), the execution model, the intended post-creation validation against real results, and hard failure constraints around variable templating. It does not mention rate limits or auth requirements, but the annotations already carry the basic read/write and destructiveness profile.

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 long, but the critical variable-syntax and mode rules are front-loaded and the rest is organized by headings with a concrete JSON example. Slight repetition of the templating rule across multiple fields is intentional and earns its place in a complex schema.

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 22-parameter task-creation tool, it covers purpose, execution model, all action types, selector strategy, edge cases, and provides a full example. It does not describe the tool's return value or response shape, but the creation semantics and boundaries are otherwise 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?

The schema already documents all 22 parameters, but the description adds real semantics: what each action type does, selector precedence, when to use wait_selector, and the mandatory {$var} templating syntax. It goes beyond the schema without having to carry the whole load.

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 opening line states a specific action and object: 'Create a complete, fully-configured Figranium automation task' and enumerates its components (actions, variables, stealth, scheduling). It clearly differentiates create_task from task_update/task_delete and gives purpose context in section 1.

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?

Section 1 explicitly says 'Use this tool when you need to automate...' and the mode-selection guidance tells when agent/scrape/headful are appropriate. However, it does not explicitly name sibling tools or say when NOT to use create_task versus task_update/task_execute.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal context by noting it returns a 'summary' but does not disclose pagination, ordering, or limits, which are common for list tools. With annotations present, the added value is limited.

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, efficient sentence that is front-loaded with the core action and scope. No redundant or extraneous 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?

For a simple read-only list with no parameters and no output schema, the description is sufficient to understand the tool's purpose. It does not mention return format or pagination, but these are not critical for a basic summary listing. The absence of explicit usage guidance slightly lowers completeness, but the tool is straightforward.

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 has zero parameters, so the baseline is 4. The description adds no parameter-specific details, which is acceptable since there are none to document.

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 'List' and a clear resource 'all past execution records', which unambiguously differentiates it from sibling tools like task_list and schedule_list. It is specific and not a tautology.

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 usage for viewing execution history but does not explicitly state when to use it versus alternatives. There are no exclusions or conditions given, leaving the agent to infer from the name and context.

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 indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description doesn't need to repeat those. However, it adds minimal context—mentioning 'optional selector hints' but not what happens to the session when mode is activated, whether navigation occurs, or if there are side effects. Given the low bar from annotations, this is acceptable but not enriched.

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 fluff. The action and subject are immediately clear, and it avoids redundant detail. This is a model of conciseness.

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 omits key contextual details: it assumes an 'active browser session' but doesn't state that a session must already exist or how to ensure one. There is no mention of return values or what the agent should do after activation. Given no output schema and no required parameters, the description leaves the agent with gaps about preconditions and expected outcomes.

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%, with each parameter already having a clear description. The tool description's phrase 'optional selector hints' aligns with targetHint but adds no new meaning beyond the schema. Since the schema does the heavy lifting, a baseline of 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?

The description clearly states a verb ('Activate') and a resource ('inspect/highlight mode') tied to a browser session. It distinguishes from siblings like browser_open and task_execute by focusing on a mode activation rather than opening or executing. However, 'inspect/highlight mode' is slightly underspecified—what it does beyond highlighting isn't elaborated, but the purpose is still discernible.

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 guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an existing browser session), nor does it contrast with browser_open or task_execute. The agent must infer context from the description and sibling names, which is insufficient.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral scope ('all Cabinets configured on the Figranium server') and specifies the output fields (IDs, names, item counts), which is useful given there is no output schema.

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 front-loaded sentences provide the action, scope, return content, and intended use case with no redundancy or filler. Every clause adds 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 simple no-argument, no-output-schema list tool, the description is complete: it names the resource, the defining clarification ('durable download queues), the returned fields, and the practical use case for finding a Cabinet ID.

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 has zero parameters, so the baseline of 4 applies. The description does not need to explain parameter semantics, and the input schema already fully captures that no arguments are required.

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 uses a specific verb and resource: 'List all Cabinets (durable download queues) configured on the Figranium server. It also states what is returned (IDs, names, item counts), which makes the tool's function unmistakable and distinguishes it from sibling tools like create_cabinet.

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 explicit use context: 'Use this to find a Cabinet ID to reference in a Task's downloadCabinetId field or an upload action.' It does not explicitly mention when not to use it, but the use cases are clear enough; there are no competing list-cabinet alternatives among the siblings.

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 destructiveHint=true and idempotentHint=true, which cover the destructive and repeatable nature. The description adds the phrase 'disable and remove' which is consistent but does not provide additional behavioral context beyond what annotations offer. No contradiction exists.

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, tightly written sentence that conveys the action and scope immediately. It is front-loaded and contains no fluff or redundant wording.

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 deletion tool with one parameter, no output schema, and annotations covering safety, the description is adequate. It could mention that only the schedule is affected (not the task itself), but that is implied by 'schedule configuration'. Overall, nothing critical 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 schema describes taskId fully, and the description does not add any extra semantic detail about the parameter. With 100% schema coverage, the baseline is 3; the description does not improve on it.

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 states the action (disable and remove) and the resource (schedule configuration from a specific task). It distinguishes from siblings like schedule_set (which likely sets a schedule) and schedule_list (which lists schedules). However, it does not explicitly mention the distinction from schedule_delete or other schedule-related tools, but the purpose is clear enough.

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 provides no guidance on when to use this tool versus alternatives. It does not state conditions for use, prerequisites, or when to avoid it. An agent must infer that this tool is for deletion, but there is no explicit routing to or away from siblings.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the 'validate and preview' behavior, which goes beyond the read-only hint by indicating it returns a validation result or preview. This is consistent with annotations and adds 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 single, front-loaded sentence that conveys the purpose and key constraint ('without saving it') with no wasted words. It is concise and efficient.

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 should clarify what the tool returns. It says 'preview/describe' but does not specify the format, whether validation errors are thrown, or how results are presented. This is a notable gap for a validation tool, though the read-only and idempotent hints mitigate some ambiguity.

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 all 9 parameters are documented in the schema. The description does not add any parameter-specific meaning 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?

The description clearly states the action (validate and preview/describe) and the resource (schedule configuration), and explicitly notes it does not save. This differentiates it from schedule_set (which saves) and schedule_delete (which removes). The verb+resource is specific and 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?

The description implies the tool is for validation/preview before committing, via the phrase 'without saving it'. It gives clear context for when to use it, though it does not explicitly name alternatives like schedule_set. This is adequate but lacks explicit exclusionary 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety expectations. The description adds that this returns overall status and metadata, but it does not disclose any additional behavioral details such as response shape, error cases, or what 'metadata' includes. This is acceptable for a simple read-only aggregate call, but the description itself adds only modest context beyond the annotations.

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 sentence with no filler, and the key scoping information ('for all schedules') is front-loaded. Every word 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, read-only aggregate status tool, the description is largely complete: it states what is returned (overall scheduler status and metadata) and annotations cover safety and idempotency. A minor gap is the lack of detail about the returned metadata shape, but that is not necessary for invoking the tool correctly given its simplicity.

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 are zero parameters and the input schema is empty with 100% coverage, so the baseline is 4. There is no parameter meaning that the description would need to clarify.

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 uses a specific verb ('Get') and a specific resource ('overall scheduler status and metadata for all schedules'). It clearly distinguishes itself from the sibling schedule_get_status by clearly indicating this is the aggregate/all-schedules variant.

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 phrase 'for all schedules' gives clear context for when to use this tool versus a per-schedule tool. It does not explicitly name alternatives or provide exclusions, but the aggregate scope implied by the description is enough for an agent to make a reasonable selection.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral detail by specifying exactly what information is returned (schedule status, cron configuration, next run time), going beyond the bare read-only hint and helping the agent know what to expect.

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 that front-loads the core action and scope, with zero filler. Every word earns its place, and the most important qualifier ('for a specific task') is placed at the end but still clear.

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 read-only tool with one well-documented parameter and no output schema, the description is complete. It tells the agent what the tool returns and what it targets. No additional context is needed 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?

The schema provides a complete description for taskId (coverage 100%), so the baseline is 3. The description reinforces that the parameter identifies a specific task, which adds a small semantic layer beyond the schema. It doesn't provide format constraints, but the schema is sufficient.

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 ('Get'), a clear resource ('detailed schedule status, cron configuration, and next run time'), and a scope ('for a specific task'). This distinguishes it from sibling schedule_get_all_status, which covers all tasks. The purpose is unambiguous and immediately understood.

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 usage for a single task by explicitly saying 'for a specific task', which contrasts with the all-tasks sibling. However, it does not name alternatives or provide explicit when/when-not guidance. The context is clear enough for an agent to infer appropriate use, but explicit routing would be stronger.

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, idempotentHint, and destructiveHint, covering safety profile. The description adds that it includes schedules regardless of enabled state, which is useful context. However, it does not disclose output format, pagination, or any other behavioral traits beyond the given, so it does not exceed the baseline for annotation-backed transparency.

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, concise sentence that is front-loaded with the action ('List') and subject ('all tasks that have schedules'). It includes the 'enabled or not' qualifier compactly. There is no fluff, making it highly efficient.

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?

This is a simple, parameterless list operation. The description fully explains its scope and includes the important nuance about enabled/disabled states. There is no output schema, but the description suffices for an agent to know what to expect. The presence of siblings does not create a need for more information because the purpose is clear.

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?

With zero parameters and 100% schema coverage (empty schema), the baseline is 4 per rubric. The description adds nothing about parameters because there are none, but this matches the baseline exactly.

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 states the verb 'List' and the resource 'all tasks that have schedules configured', with an explicit qualifier '(enabled or not)' that disambiguates from potentially similar tools. This makes the tool's purpose unambiguous and distinct from siblings like schedule_get_all_status or schedule_get_status, which focus on status rather than the task list.

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 usage when one needs to know which tasks have schedules, but it does not explicitly mention when to use this over schedule_get_all_status or schedule_get_status. The differentiation is implicit from the wording, but there is no direct guidance, so it earns a 3 rather than a 4 or 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?

Annotations already establish that the tool is mutating, idempotent, and not destructive. The description adds the upsert semantics of create-or-update, but gives no detail on side effects, overwrite behavior, or validation. There is no contradiction with annotations.

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, front-loaded sentence with no filler or repetition. It is concise, though slightly too sparse to fully support a 10-parameter scheduling 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?

The tool has 10 parameters, two mutually exclusive schedule modes, and no output schema, but the description provides no guidance on cron versus frequency, per-mode required fields, or how an existing schedule is affected. The schema helps, but the description alone is not complete enough for reliable tool selection and 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?

All 10 parameters have schema-level descriptions, so the schema carries the semantic burden. The description adds little beyond the notion of 'specific task,' which maps to taskId, but does not compensate for any missing schema 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?

The description states a clear verb-resource pair: 'Create or update a schedule for a specific task.' This unambiguously identifies the operation and distinguishes it from read/delete schedule siblings like schedule_list and schedule_delete.

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 is provided. The description does not mention alternatives, nor does it explain when to choose cron mode versus frequency mode, leaving the agent to infer the correct usage context.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds 'permanently' which reinforces destructiveness but does not disclose idempotency behavior (though idempotentHint=true is in annotations) or side effects like cascading deletes. It provides minimal extra behavioral context beyond annotations.

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, efficient sentence with the verb and object front-loaded. No filler or redundant phrases beyond the minor redundancy of 'by taskId' which is acceptable.

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 delete operation with no output schema, the description covers the essential action and target. It does not mention potential errors or prerequisites, but given the simplicity and annotation coverage, it is sufficiently complete for an agent 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 coverage is 100% and the schema already explains taskId clearly. The description's 'by taskId' is redundant and adds no semantic detail beyond the schema. Baseline 3 is appropriate when the schema fully documents parameters.

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 states the action (delete), the resource (Figranium task), and the scope (permanently, by taskId). It distinguishes from siblings like create_task, task_update, and task_list without ambiguity.

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 guidance is provided on when to use this tool versus alternatives. It does not mention conditions for deletion, prerequisites, or contrast with update or list operations. An agent must infer appropriate usage from the action name alone.

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 destructiveHint=true and idempotentHint=false, signaling mutation and non-idempotency. The description adds that it returns a 'real run result' and is useful for validating against 'actual browser behavior', which conveys that the tool performs a real browser execution with side effects. This adds context beyond the annotations without contradicting them.

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 two sentences: the first states the core action, the second adds a practical use case. Both are concise and directly relevant, with no fluff or redundant information. The main purpose is front-loaded, making it easy for an agent to scan.

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 covers the primary purpose and a use case, and the annotations handle the safety profile (destructive, non-idempotent). It mentions returning a 'real run result' but does not specify the exact output structure, which could be useful. However, given the tool's simplicity and lack of an output schema, it is adequately complete for an agent to decide to call 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?

The input schema fully describes both parameters: taskId is the unique ID, and variables are key-value pairs for execution variables. The description does not add any parameter-specific details. With 100% schema coverage, the baseline of 3 is appropriate—no extra value is provided beyond what the schema already offers.

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 states the action: 'Execute a saved automation task by ID and return its real run result.' This is specific with a verb and resource, and it distinguishes from siblings like execution_list (which lists runs) and browser_open (which opens a browser). No ambiguity about what the 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?

The description provides a clear use case: 'This is also useful for validating newly created or updated tasks against actual browser behavior and output.' This implies when to use it—when you need a real execution result. It does not explicitly mention alternatives or exclusions, but the context is sufficient to guide selection. A stronger definition would name a sibling like execution_list for viewing past runs.

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, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the scope ('all') and the specific fields returned, which provides useful context beyond the annotations, though it doesn't mention any edge cases or side effects.

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, well-structured sentence that front-loads the action and resource. It contains no unnecessary words and fully conveys the tool's purpose.

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 read-only list tool with no parameters and no output schema, the description is complete. It specifies what will be returned (task IDs, names, descriptions) and the scope (all tasks), which is all an agent needs to know to use 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?

The tool has zero parameters, so there is nothing for the description to explain beyond what the schema already shows. The schema description coverage is trivially 100%, and the baseline for zero-parameter tools is 4, which is appropriate here.

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 states the verb 'List' and the resource 'task IDs, names, and descriptions from Figranium', making the tool's purpose unambiguous. It distinguishes itself from sibling tools like create_task, task_update, and task_delete by focusing on listing.

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 usage when you need an overview of all tasks. While it doesn't explicitly mention alternatives or when not to use it, the context is clear enough given the simple nature of the tool and its distinct action.

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?

Beyond annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description elaborates on idempotency ('Repeating the same request is safe'), non-execution, and compound-field replacement semantics. It also details variable syntax and action ordering, adding substantial behavioral 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 long but well-structured with clear sections: When to use, Required request shape, Important update behavior, and Examples. It front-loads the core purpose and each section provides essential information without redundancy. Every sentence 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 tool with 23 parameters, nested objects, and no output schema, the description covers key behaviors, usage, examples, and parameter semantics comprehensively. An agent has all necessary information to call it correctly, including what not to do and how to validate 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?

Although schema coverage is 100%, the description adds crucial guidance not present in individual field descriptions: the complete-value requirement for compound fields (actions, variables, stealth, translation, schedule), the ordered replacement nature of actions, and the variable reference syntax generalized across URLs, headers, bodies, and action values. This goes well beyond the 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 states the action: 'Update one or more fields on an existing, saved Figranium browser-automation task.' It names the specific verb and resource, and immediately distinguishes itself from siblings by noting it does not execute or delete the task, and references task_list for retrieval.

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 explicit when-to-use guidance: 'Use this after task_list identifies the task to modify.' It also lists alternatives: 'Use task_execute to validate an updated workflow and task_delete only when permanent removal is intended.' This clearly routes the agent to the correct sibling.

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