Server Quality Checklist

Tool Scores

• schedule_setB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only says 'create or update'—a mutation—but does not explain whether it is an upsert, how it decides between create and update, what happens if the task does not exist, or whether it replaces the entire schedule. No return value, error, or permission details are provided.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no wasted words. It conveys the core action efficiently. However, given the tool's complexity (10 parameters, two modes), slightly more detail could be warranted without sacrificing conciseness.

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

  Completeness2/5

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

  The tool is complex: 10 parameters, two mutually exclusive scheduling modes (cron vs frequency), and no output schema or annotations. The one-sentence description does not explain the conditional logic between cron and frequency, the effect of an update, or any return/error behavior. It is insufficient for an agent to use the tool confidently without thoroughly inspecting the schema.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, but the schema itself is self-explanatory, including conditional fields and enums.

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

  Purpose5/5

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

  The description clearly states the action (create or update) and the resource (a schedule for a specific task). It effectively distinguishes this from sibling tools like schedule_list, schedule_delete, and schedule_describe, which are read/delete operations.

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

  Usage Guidelines3/5

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

  The description implies usage for creating or updating schedules but offers no explicit guidance on when to prefer this over alternatives or any exclusions. The sibling context suggests it is the only write tool for schedules, but the description itself does not state this.

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

• task_updateB
  3.3/5.0
  Behavior2/5

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

  No annotations exist, so the description carries the full burden, but it only says it updates existing task. It does not disclose whether this is a partial patch or full replacement, what side effects may occur, what happens if the taskId does not exist, or whether the updated task is returned. The schema's testing directive is useful but is not part of the behavioral transparency of the update operation itself.

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

  Conciseness5/5

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

  The description is a single, focused sentence that leads with the action and target resource. It contains no filler and appropriately delegates the extensive field-level detail to the input schema.

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

  Completeness3/5

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

  Given the large schema and no output schema, the description does not fully clarify expected output, error behavior, or whether omitted fields preserve existing values. However, the exhaustive parameter schema and the integrated post-update testing directive provide substantial context, so the overall definition is adequate but with notable unspecified behavioral aspects.

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

  Parameters3/5

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

  Schema description coverage is 100%, and every parameter has detailed descriptions, example values, enums, and defaults within the schema. The tool description itself adds minimal parameter meaning, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly identifies the verb ('Update'), the resource ('fields of an existing task'), and the server context. The phrase 'existing task' differentiates it from create_task, even though the tool does not explicitly name sibling tools.

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

  Usage Guidelines3/5

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

  The description gives clear context about updating an existing task but does not explicitly state when to use it over create_task or when not to use it. The schema-internal directive to execute the task with task_execute after updating adds useful workflow guidance, but the main description does not provide explicit alternatives or exclusions.

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

• schedule_get_all_statusA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description does not explicitly state that no state changes occur, what metadata is included, or any operational limitations. This is a minimal disclosure for a tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, concise sentence that states the action and target. It is front-loaded and contains no filler or redundant information.

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

  Completeness3/5

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

  For a simple read tool with no parameters, a one-line description is mostly adequate. However, without an output schema or annotations, the description could benefit from mentioning that it returns a summary of all schedules' status and metadata, and explicitly noting that it is a safe read operation. Minor gap.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema is trivially complete. The description does not need to explain any parameters; baseline 4 applies due to no parameter complexity.

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

  Purpose5/5

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

  The description clearly states the verb 'Get' and the resource 'overall scheduler status and metadata for all schedules'. It distinguishes from siblings like schedule_get_status by emphasizing 'overall' and 'all schedules', making its scope unambiguous.

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

  Usage Guidelines2/5

  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 schedule_get_status or schedule_list. The description implies it is for broad status viewing, but it does not explicitly state exclusions, alternatives, or prerequisites.

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

• inspector_highlightA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description must disclose side effects, but it only gives the most basic action and a precondition. It does not mention whether providing a URL triggers navigation, whether the highlight mode changes the session UI, when the mode ends, or what error occurs if no active session exists.

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

  Conciseness5/5

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

  The description is a single clean sentence that leads with the primary action and adds the optional-hint qualifier at the end. It is concise and contains no redundant or off-topic details.

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

  Completeness2/5

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

  For a tool with no annotations, no output schema, and three optional parameters, the description is too sparse to fully model invocation. It leaves unclear whether URL and targetHint combined cause navigation, how highlight mode is exited, and what the tool returns or changes in session state.

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

  Parameters3/5

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

  The input schema already covers all three parameters with meaningful descriptions, so the 100% coverage baseline applies. The description's only added phrase, 'optional selector hints,' echoes the targetHint parameter without providing any new style, proof, or interaction guidance.

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

  Purpose5/5

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

  The description identifies a specific verb ('Activate') and resource ('inspect/highlight mode on an active browser session'), immediately making the tool's purpose clear. It distinguishes itself from siblings like browser_open and task_execute by naming the exact mode it activates.

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

  Usage Guidelines4/5

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

  The phrase 'on an active browser session' clearly signals that a browser session must already exist, and thereby implies it should be used after browser_open rather than before it. It does not explicitly state when not to use it, but no direct alternative sibling performs a similar highlighting function.

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

• task_deleteA
  3.6/5.0
  Behavior3/5

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

  The word 'Permanently' is a meaningful behavioral disclosure indicating irreversibility, which is important for a delete operation. However, with no annotations at all, the description does not cover other relevant behavioral aspects such as permissions, cascading effects, or error behavior.

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

  Conciseness5/5

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

  The description is a single, clear sentence. It front-loads the destructive nature ('Permanently') and the required identifier, with no unnecessary words.

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

  Completeness4/5

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

  For a simple single-parameter delete tool, the description covers the essential action and input. It does not delve into edge cases like deleting non-existent tasks or authorization, but the low complexity makes the description largely complete.

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

  Parameters3/5

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

  The parameter taskId is already fully documented in the schema with a description and 100% coverage. The tool description adds no extra parameter-level meaning beyond what the schema already provides.

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

  Purpose5/5

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

  The description states a specific verb ('delete'), a clear resource ('Figranium task'), and the identifier used. It unambiguously differentiates this tool from siblings like create_task, task_update, task_list, and task_execute.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus alternatives, no prerequisites, and no indication of when deletion might be inappropriate. The description simply states the action without clarifying context or exclusions.

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

• browser_openA
  3.7/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full transparency burden. It does disclose an important behavior beyond launching: reattaching an existing managed session. However, it does not explain what 'managed' means in practice, how long sessions live, or what happens to a session when the tool returns.

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

  Conciseness5/5

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

  The description is a single compact sentence with no filler. It front-loads the primary action with launch and adds the important reattach behavior without expanding the description unnecessarily.

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

  Completeness3/5

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

  For a low-complexity tool with a fully described schema, this is mostly adequate. The main gap is that with no output schema and no annotations, the description does not say what the caller receives after successfully launching or reattaching, nor how the session relates to the rest of the tool family.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline applies. The description itself adds little parameter context, but the schema already explains url, mode, devTools, and the VNC limitation on headful mode, so this is acceptable.

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

  Purpose5/5

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

  The description uses specific verbs, 'Launch or reattach', and clearly identifies the resource: a managed headful/interactive browser session. This distinguishes it from the sibling task, schedule, and inspection tools by focusing on browser session lifecycle rather than task or schedule management.

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

  Usage Guidelines3/5

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

  The description implies this is for starting or resuming an interactive headful browser session, but it does not explicitly state when to use this tool versus alternatives. Since the sibling list includes inspector-related tooling, some guidance on when browser session creation is required would clarify selection.

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

• task_executeA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'execute/run' and 'return its result', but does not clarify whether execution is synchronous, can be tracked via execution_list, what side effects occur, or how errors are surfaced. This is minimal disclosure for a mutation-like operation.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that states the action, object, and outcome with zero wasted words. It earns its place efficiently.

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

  Completeness3/5

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

  The tool has a simple parameter set and no output schema, so the description must clarify what the tool returns and how execution behaves. It mentions 'return its result' but omits details like whether the result is a direct value or a reference (e.g., execution ID). Given the presence of execution_list, this ambiguity is significant. A more complete description would state return behavior and any asynchronous aspects.

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

  Parameters3/5

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

  The input schema covers both parameters with meaningful descriptions (taskId is the unique ID, variables are optional key-value pairs). The description adds no extra semantics beyond 'by ID', so the baseline of 3 is appropriate given 100% schema coverage.

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

  Purpose5/5

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

  The description uses a specific verb 'Execute/run' and clearly identifies the resource 'saved automation task' and the key constraint 'by ID'. It also states the outcome 'return its result'. This fully distinguishes it from siblings like create_task and task_list.

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

  Usage Guidelines4/5

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

  The description provides clear context: use this tool when you have a task ID and need to execute it. It does not explicitly name alternatives or exclusions, but the sibling list and 'saved task' imply an execution-specific role, making the intended use obvious.

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

• schedule_deleteA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It states the primary effect (disable and remove the schedule) but does not disclose side effects, reversibility, or behavior when the schedule does not exist. It is not misleading, just minimal.

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

  Conciseness5/5

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

  The description is a single, direct sentence that leads with the action and resource. No superfluous words or repetition.

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

  Completeness4/5

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

  For a simple one-parameter delete tool with no output schema, the description is mostly sufficient. It clearly states what happens and identifies the required input. However, it could briefly mention what happens to existing scheduled executions or how to confirm deletion, but given the simplicity, it is nearly complete.

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

  Parameters3/5

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

  Schema coverage is 100%, and the description adds no additional meaning beyond the schema's description of taskId. The single parameter is already well-documented, so the baseline of 3 applies.

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

  Purpose5/5

  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'), the resource ('schedule configuration'), and the scope ('from a specific task'). It distinguishes itself from siblings like schedule_set (which creates/updates) and schedule_list (which reads).

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

  Usage Guidelines3/5

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

  The description implies this tool is used to delete a schedule for a task, but it does not explicitly describe when to use it versus alternatives or any prerequisites such as whether the task must exist. No exclusions or when-not-to-use guidance is provided.

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

• schedule_get_statusA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the tool gets status, cron config, and next run time, implying read-only behavior via the verb 'Get'. However, it does not mention error handling, required permissions, or response structure beyond the listed items.

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

  Conciseness5/5

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

  A single, front-loaded sentence that efficiently conveys the tool's purpose with no unnecessary words or repetition. Every phrase adds value.

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

  Completeness4/5

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

  For a simple one-parameter tool with no output schema, the description adequately lists the returned information (status, cron config, next run time). It lacks explicit mention of error cases or usage scenarios, but these are less critical for a read-only status checker.

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

  Parameters3/5

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

  The input schema already provides 100% coverage for taskId ('The unique ID of the task to check'). The description adds no additional parameter detail beyond confirming the scope, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool's action ('Get') and resource ('detailed schedule status, cron configuration, and next run time') for a specific task. It distinguishes from the sibling tool schedule_get_all_status by focusing on a single task via taskId.

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

  Usage Guidelines4/5

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

  The description implies usage for checking a specific task's schedule status, which clearly separates it from schedule_get_all_status that presumably returns all statuses. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions.

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

• execution_listA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-only listing operation via the verb 'List' and discloses that the output is a summary of past records, which is useful context. However, it does not mention pagination, ordering, or other potential behaviors, so it is not fully transparent.

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

  Conciseness5/5

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

  The description is a single sentence of eight words, front-loaded with the verb. It is exceptionally concise with no filler, and every word contributes to the meaning.

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

  Completeness3/5

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

  The tool has no parameters and no output schema, so the description is the sole source of information. It clearly states what it does but is vague about the contents of the summary, ordering, or limits. For a simple list tool, this is minimally adequate but leaves gaps.

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

  Parameters4/5

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

  This tool has zero parameters and 100% schema coverage, so the description does not need to explain parameter meanings. The word 'summary' hints at the output, but with no parameters to clarify, the baseline of 4 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool lists a summary of all past execution records, using a specific verb ('List') and resource ('execution records'). It distinguishes from sibling tools like task_list and schedule_list, which handle different entity types. This is a non-tautological and unambiguous purpose.

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

  Usage Guidelines3/5

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

  The description implies use for viewing execution history but provides no explicit guidance on when to use this versus alternatives. It does not mention exclusions or alternative tools, though the sibling context suggests differentiation by entity. The usage context is implied rather than stated.

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

• schedule_describeA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly indicates the non-mutating nature of the operation ('without saving it'), which is the key safety trait. It mentions validation and preview, but lacks details on error responses or the exact return format, which would enhance transparency further.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence of about 12 words. It gets straight to the point with 'Validate and preview/describe' and adds the key qualifier 'without saving it' without any unnecessary words.

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

  Completeness3/5

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

  Given the tool's complexity (9 parameters), lack of annotations, and absence of an output schema, the description is somewhat minimal. It conveys the core purpose but does not explain what a validation failure or successful preview returns, nor does it mention how the schedule modes (cron vs frequency) are handled. The schema provides parameter-level detail, so the description is adequate but not complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The description does not elaborate on individual parameters or their interdependencies, but it contextualizes them as part of a schedule configuration. The schema already provides sufficient explanations for each parameter.

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

  Purpose5/5

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

  The description clearly states the tool's function with specific verbs 'Validate and preview/describe' and identifies the resource as 'a schedule configuration'. The phrase 'without saving it' distinguishes it from sibling tools like schedule_set, which presumably persist the schedule.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool: to validate or preview a schedule before persisting it. The explicit exclusion 'without saving it' signals that this is not for committing changes, but it does not name alternative tools like schedule_set, leaving the comparative guidance implicit.

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

• schedule_listA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses an important behavioral trait: the list includes both enabled and disabled schedules. However, it doesn't mention other behavioral aspects like return format, authentication requirements, or whether disabled schedules are included by default or require filtering.

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

  Conciseness5/5

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

  A single, clear sentence that front-loads the action ('List') and specifies the target ('tasks that have schedules configured'). No wasted words, and the parenthetical '(enabled or not)' adds precision without bloat.

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

  Completeness4/5

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

  Given the tool has no parameters and no output schema, the description is mostly sufficient. It clearly states what is returned (a list of tasks with schedules) and qualifies the scope. A minor gap is not specifying the output structure (e.g., task IDs vs. full details), but this is not critical for a simple list tool.

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

  Parameters4/5

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

  The tool has zero parameters, so the schema provides no parameter descriptions. The baseline for such cases is 4. The description doesn't need to add parameter semantics since there are none.

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

  Purpose5/5

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

  The description uses the specific verb 'List' and clearly identifies the resource: 'tasks that have schedules configured'. It further clarifies scope by adding '(enabled or not)', distinguishing it from sibling tools like task_list (which likely lists all tasks) and schedule_get_all_status.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool: when you want to see which tasks have schedules, regardless of enabled state. It does not explicitly mention alternatives or exclusions, but the context is clear from the wording.

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

• task_listA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of disclosing behavior. The verb 'List' implies a read-only, non-mutating operation, but it doesn't explicitly warn about potential large results, pagination, or performance. It's adequate but sparse.

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

  Conciseness5/5

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

  The description is a single, compact sentence with no filler. It directly states the action and output, making it extremely concise and well-structured.

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

  Completeness4/5

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

  For a zero-parameter tool with simple output, the description provides the essential information: what is listed and from where. It doesn't explain return format or edge cases, but the simplicity of the tool makes this sufficient.

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

  Parameters4/5

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

  The tool has zero parameters, and the schema coverage is trivially 100%. The description doesn't need to elaborate on parameters, earning the baseline score for no-parameter tools.

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

  Purpose5/5

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

  The description uses a specific verb 'List' and clearly identifies the resource: task IDs, names, and descriptions from Figranium. It effectively distinguishes this tool from siblings like create_task and task_execute, which have different purposes.

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

  Usage Guidelines4/5

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

  The description clearly implies when to use this tool: when a list of tasks is needed. While it doesn't explicitly exclude alternatives like execution_list or schedule_list, the unique phrasing 'task IDs, names, and descriptions' makes the context unmistakable.

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

• create_taskA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden and covers a lot: the linear execution model with control-flow steps, the unsupported variable syntaxes that would cause failures, the mandatory post-create testing protocol, and stealth/statelessness behaviors. The main gaps are lack of disclosure about duplicate-name behavior, permission/auth requirements, and creation failure modes.

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

  Conciseness4/5

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

  The description is long but proportional to a 20-field tool with nested objects. Critical agent directives (variable template syntax and mandatory testing) are front-loaded, and remaining sections have clear headings. Minor redundancy exists where the step-type list overlaps with the file schema's action enum, but it adds semantics rather than pure repetition.

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

  Completeness4/5

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

  For a complex 20-parameter create operation with no annotations, the description provides a genuinely complete picture: it covers the purpose, execution model, step semantics, selector strategy, retry behavior, stealth options, and a realistic worked example. The only notable gap is return-value/result semantics—the description does not say what the tool response contains or how success/failure is reported.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3, but the description adds semantics beyond individual field definitions: the action list explains behavior for each step type, the selector hierarchy section operationalizes how selectors should be chosen, and the worked JSON example shows how the many fields compose together. This genuinely crosses the semantics of the bare schema.

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

  Purpose5/5

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

  The opening sentence uses a specific verb and resource ('Create a complete, fully-configured Figranium automation task') and names the key payload components: action steps, state variables, stealth mechanisms, and scheduling. The dedicated 'Purpose' section reinforces exactly when to use it, clearly distinguishing it from siblings like task_update, task_delete, and task_execute.

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

  Usage Guidelines4/5

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

  The '1. Purpose' section gives concrete use contexts (data extraction, form-filling, dashboard testing, visual monitoring), and the mandatory-testing guideline explicitly prescribes calling task_execute after creation. However, it never states when NOT to use this tool or when to prefer siblings like task_update or task_delete for alternate scenarios.

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