Figranium MCP Server

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?

The annotations only provide a few boolean hints (readOnlyHint=false, idempotentHint=false), so the description carries the transparency burden and far exceeds it. It discloses that tasks are stored permanently, that new tasks are intended to be validated against a real execution result, that the execution model is a linear sequence requiring closed control-flow blocks, and that Get Content cannot be the final action — all genuinely useful behavioral constraints beyond structured fields.

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 a front-loaded IMPORTANT GUIDELINES block followed by numbered sections and a full JSON example, so key correctness rules appear first. Some redundancy exists — the {$variable} syntax rule and mode guidance are repeated in both the description and the input-schema descriptions — but most sentences earn their place given the tool's complexity.

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 tool with deeply nested objects and no output schema, the description is remarkably complete: it covers purpose, execution model, every step type, selector fallbacks, edge cases/retry logic, and includes a runnable multi-action example. The notable gap is the return value/response format (no output schema exists and the description never states what the tool returns, e.g., task ID), which an agent might need to confirm creation success.

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 substantial meaning: Section 3 documents what each of the ~36 action types does (the schema only says 'The action type to perform'), and the guidelines prescribe the {$variable} templating syntax, workflow boundaries (no Timed Wait/Navigate first, no Get Content last), and selector strategy hierarchy. This materially improves the agent's ability to construct valid parameter values.

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 verb and resource — 'Create a complete, fully-configured Figranium automation task' — and enumerates its scope (sequential action steps, state variables, stealth mechanisms, optional scheduling). Section 1 further distinguishes it from siblings by framing it for recurring/complex web workflows and noting tasks are stored permanently and can be executed later, which separates it from task_execute and schedule_set.

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 gives explicit when-to-use context ('automate any recurring or complex web-based workflows... data extraction, form-filling, dashboard testing, visual monitoring') and the mode-selection guidance inside the IMPORTANT GUIDELINES block tells the agent which mode to choose and when scrape is acceptable. However, it never names alternative sibling tools (e.g., task_update, schedule_set) or states when NOT to use this tool, so exclusions are missing.

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 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 the annotations, which already declare idempotentHint=true and destructiveHint=false, the description adds substantial operational context: omitted fields are left unchanged, compound fields must be sent in full, action sequences have ordering restrictions, variable references must use `{$variable_name}` syntax, and the operation does not execute or delete. None of this contradicts 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 long but well-organized with clear headings—When to use, Required request shape, Important update behavior, and Examples. Each section carries distinct value, and the most important scoping information is front-loaded.

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 and complex nested behaviors, the description is complete: it states the required shape, the optional-field semantics, the compound-field behavior, action ordering rules, variable syntax, idempotence, and routing to sibling tools. Combined with the exhaustive schema, an agent has what it needs to call the tool 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%, so the schema already documents each parameter thoroughly; the baseline is 3. The description adds meaning beyond the schema by explaining the overall partial-update semantics, the compound-field replacement rule, the action-sequence constraints, and the variable templating requirement, which are not obvious from the individual property descriptions alone.

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 opens with a specific verb and resource: 'Update one or more fields on an existing, saved Figranium browser-automation task.' It clearly differentiates this tool from siblings by stating what it does not do—it does not run or delete a task—and by naming create_task, task_execute, and task_delete as related but distinct operations.

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 explicitly says to use this after `task_list` identifies the task to modify, which is strong ordering guidance. It also gives clear exclusions: use `task_execute` to validate a workflow and `task_delete` only for permanent removal, and notes that an ID-only request is rejected because it would make no change.

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