Server Quality Checklist

Tool Scores

• bootout_serviceC
  2.9/5.0
  Behavior2/5

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

  No annotations are present, so the description must disclose behavioral traits. It mentions 'unload or remove' but does not explain consequences: whether the service is stopped immediately, whether removal is persistent across reboots, whether privileges are needed, or whether related resources are affected. This is insufficient for a mutation tool with no safety annotations.

  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 extremely concise with no filler. The action is front-loaded, and the parameter definition is structurally clean. Every word is purposeful, making it easy for an agent to parse quickly.

  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?

  With only one simple parameter and an output schema present, the bar is lower, but the description still omits critical decision-making information. It lacks usage conditions, side effects, and any indication of how this tool relates to sibling service-management tools. An agent cannot confidently choose this tool over disable_service or bootstrap_service based solely on this description.

  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 0%, so the description must compensate. The Args section adds a small amount of meaning: target is a 'service or domain target accepted by launchctl bootout.' This clarifies that the string is not arbitrary, but it remains vague about exact syntax or examples. It provides some value beyond the bare schema, but not enough to fully specify valid inputs.

  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 states a specific action ('Unload or remove a service/domain') and the mechanism (`launchctl bootout`). It identifies the resource (service/domain) and verb, making the purpose clear. However, it does not explicitly differentiate from siblings like disable_service or kickstart_service, so it misses the top score.

  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 alternatives such as disable_service, bootstrap_service, or remove_python_task. There are no exclusions, prerequisites, or contextual triggers. The description implies only that it unloads/removes a service, leaving the agent to infer appropriate situations.

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

• enable_serviceC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full behavioral disclosure burden. It discloses that the tool invokes launchctl enable, but does not describe side effects—such as whether this affects boot-time loading, whether it starts the service immediately, whether privileges are required, or whether it only affects future sessions. The lack of behavioral context is a significant gap for a mutating operation.

  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 short and front-loaded with the operation and command. The Args section is structured and the examples are directly useful. It wastes no words, though it could contain more behavioral or usage context without becoming bloated.

  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 has only one parameter and an output schema exists, so formal call structure is covered. However, the description omits operational context: how this relates to bootstrap/kickstart/disable siblings, when enabling is the right choice, and what the observable result will be. For a system-mutating tool, this is insufficiently 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 schema describes service_target only as a string with no explanation. Schema description coverage is 0%, so the description must compensate. It does provide useful format examples ('system/com.example.daemon' or 'gui/501/com.example.agent'), which adds meaning beyond the raw schema. However, it stops short of explaining what valid targets exist, how to find them, or why the user identifier matters.

  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 states the tool's action: 'Enable a service via `launchctl enable`.' The resource is the service_target, and the examples clarify what kind of service targets are accepted. It is more specific than a pure tautology and distinguishes the operation from sibling disable_service. However, it does not explain what enabling a service actually does in launchctl terms, which limits full purpose clarity.

  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 about when to use this tool versus alternatives like bootstrap_service, kickstart_service, or enable's sibling disable_service. The description only states the mechanism, not the context or conditions under which enabling is appropriate. An agent must infer usage from the tool name and launchctl knowledge.

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

• list_plistsB
  3.4/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 adds only 'from common locations' and the scope values, without explaining what locations are scanned, whether any permissions are needed, or whether the operation is strictly read-only. This is minimal 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.

  Conciseness4/5

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

  The description is concise: one action sentence plus a compact Args line. It is front-loaded with the operation and then presents the only parameter, with no redundant or filler text.

  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 is simple, has an output schema, and the parameter values are stated, so an agent can likely invoke it correctly. However, 'common locations' is left vague and there is no context about when to prefer this tool over sibling tools, making it only partially complete.

  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 schema provides only a string property 'scope' with a default, but the description explicitly lists the allowed values 'all', 'system', or 'user'. Since schema description coverage is 0%, this compensation is valuable and gives an agent the key choices for the parameter, even if the exact meaning of each scope is not fully expanded.

  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 ('List') and a clear resource ('launchd plist files'), with the scope parameter refining the target. It is naturally distinguished from sibling tools like list_services and print_service, which concern services rather than plist files.

  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 when-to-use or alternative guidance is provided. The description only says what the tool does and lists scope values; it does not help an agent decide between list_plists and related sibling tools.

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

• bootstrap_serviceA
  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. It names the operation but does not mention side effects, required privileges, failure conditions (e.g., already-loaded service), or whether the action is reversible. This is minimal for a tool that mutates launchd state.

  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 compact and front-loaded: the purpose is stated in the first sentence, and the Args block adds only essential semantic details. There is no filler or repetition.

  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 description is minimally viable for invoking the tool correctly with the two required arguments, and an output schema exists for return-value context. However, it lacks any mention of side effects, error cases, or operational caveats, which are important for a launchd-mutating 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?

  Schema description coverage is 0%, so the description must add meaning, and it does: it explains domain_target with concrete examples like 'system', 'user/501', and 'gui/501', and clarifies that plist_path must be an absolute path. This meaningfully goes beyond the bare string type in the 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 description states a specific action ('Load a launchd plist into a domain') and names the underlying command (`launchctl bootstrap`), making the tool's purpose unambiguous. It also clearly distinguishes this from sibling tools like bootout_service by describing the opposite operation.

  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?

  The description gives no guidance on when to use this tool versus alternatives such as enable_service, kickstart_service, or bootout_service. It provides argument examples but no context about prerequisites, when bootstrap is appropriate, or conditions that should make an agent choose a different tool.

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

• disable_serviceA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full behavioral burden. It states the underlying launchctl command but does not disclose persistence, permission requirements, reversibility, or side effects. 'Disable' implies mutation, but an agent is left to infer what actually changes.

  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 compact and front-loaded. It states the action, mentions the underlying mechanism, and documents the only parameter. There is 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 single-parameter tool with an output schema, the description is minimally viable. However, it lacks usage differentiation, behavioral side effects, and any note about persistence or permissions. These gaps matter for a mutation tool with no annotations.

  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 schema only declares service_target as a string with no description. The tool description compensates with concrete examples: 'system/com.example.daemon' and 'gui/501/com.example.agent'. This adds real semantic value and guides the agent on the expected format.

  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 has a clear verb and resource: 'Disable a service via launchctl disable.' It is immediately distinguishable from siblings like list_services, enable_service, and kickstart_service because it states the exact action and mechanism.

  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 on when to use this tool versus alternatives like bootout_service or enable_service. The description implies the purpose but does not specify when disabling is the right operation, what prerequisites exist, or when to prefer another sibling.

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

• list_python_tasksA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the behavioral burden, but it only states the listing action and the prefix filter. It does not disclose read-only status, side effects, authentication needs, ordering, 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 extremely compact: one purpose sentence plus a minimal Args block. Every part earns its place and the main action is front-loaded.

  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 list operation with one optional parameter and an output schema, the description is mostly adequate. However, it lacks usage context versus sibling list tools and behavioral safety details, leaving some gaps in the absence of annotations.

  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 schema has 0% description coverage, but the description compensates by defining label_prefix as a 'reverse-domain prefix used for managed task labels' and showing how it fits the matching pattern. This adds domain meaning beyond the bare schema type and default.

  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 a specific resource ('managed tasks') with a matching pattern, so an agent knows exactly what operation is performed. It distinguishes from sibling list tools like list_services and list_plists by the 'managed tasks' resource and the label_prefix filter.

  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 exclusions, and no mention of prerequisites or postconditions. The agent must infer usage solely from the operation itself, which is not enough when siblings like list_plists and list_services exist.

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

• list_servicesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It clearly indicates a read-only listing operation and names the underlying launchctl list command, which adds useful context. However, it does not describe output scope, default behavior when no filter is given, or whether only loaded/running services are shown.

  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 extremely concise: one sentence stating the action, followed by one line documenting the single parameter. There is no redundant filler, and the most important information is front-loaded.

  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 list tool with one optional parameter and an output schema present, the description covers the core action and parameter meaning adequately. It does not explain when to prefer this over list_plists or print_service, but the low complexity and available output schema reduce the need for additional detail.

  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 0%, so the description must compensate for the one parameter. It does so by clarifying that label_filter is an 'Optional substring filter for the service label,' adding meaningful semantic information beyond the schema's generic 'Label Filter' title.

  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 uses a clear verb and resource: 'List launchd services from `launchctl list`.' It accurately conveys the tool's function and is distinct from siblings like kickstart_service or bootout_service. It does not explicitly call out differences from siblings such as print_service, but the purpose is 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 about when to use this tool versus alternatives like list_plists or print_service. The name and siblings imply a listing use case, but the description does not state any conditions, exclusions, or preferred selection criteria.

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

• get_python_task_logsA
  3.9/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 behavioral burden. It does disclose useful behavior: omitting task_name returns logs for all matching tasks, and lines reads the 'tail' of each log file, implying truncation. However, it is silent on matching semantics (exact vs partial), behavior when no tasks match, and any prerequisites around label_prefix.

  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 summary line followed by a one-line-per-argument block. Every sentence adds information about a specific parameter or core behavior, with no filler. The most important scoping fact is front-loaded near the top of the Args list.

  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 five-parameter tool with zero annotations and zero schema descriptions, the description covers core invocation details and all parameter semantics, and an output schema exists so the return structure is handled elsewhere. The notable gap is edge-case behavior (no matching task, unmatched label_prefix) and usage positioning, keeping it just short of fully complete.

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

  Parameters5/5

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

  Schema description coverage is 0%, and the description compensates fully by documenting all five parameters. It adds meaning beyond the bare schema titles: task_name gets scoping behavior ('If omitted, return logs for all matching tasks'), lines gets the 'tail' truncation nuance, and label_prefix gets reverse-domain context. This is exactly the compensation a bare schema requires.

  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 line 'Fetch per-task execution logs (stdout/stderr)' names a specific verb, resource, and scope. The purpose is self-evidently distinct from all siblings, which cover service management and task CRUD rather than log retrieval. No ambiguity remains about what this tool does.

  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 given about when to use this tool versus alternatives. The description never references sibling tools or states conditions that would select this over list_python_tasks or the service-management tools. An agent must infer the appropriate context from the tool name and defaults alone.

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

• print_serviceA
  4/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 full burden. It reveals the operation is a print through launchctl, implying a read-only action, but it does not explicitly state the absence of side effects, required permissions, or failure behavior for nonexistent targets.

  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 short and well-structured: the first sentence states the tool's purpose, and the Args block provides parameter detail with examples. No filler, and the key information is front-loaded.

  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, read-only diagnostic tool with an output schema, the description provides the essential call details: what it does and the target format. Minor gaps such as explicit usage guidance or side-effect disclosure do not prevent correct invocation.

  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 0%, so the description must document the parameter. It does so meaningfully by defining 'target' as a launchd target and providing concrete examples in both system and gui forms, adding value beyond the raw string type.

  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 a specific verb and resource: 'Print detailed state for a launchd target' and identifies the underlying command 'launchctl print'. This distinguishes it from sibling tools that list or modify services.

  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 for inspecting detailed state of a specific launchd target, but it does not explicitly state when to use it over list_services or other siblings, nor any exclusions. This is left to inference.

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

• remove_python_taskA
  4.1/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 behavioral burden. It does disclose the destructive action ('Unload and remove') and the file-deletion side effect when delete_files is true. However, it does not state that removal is irreversible or what happens if the task does not exist, which would be valuable for a destructive 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 compact and front-loaded with the primary action. The Args section is concise and necessary, with no filler or redundant statements.

  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 description covers the essential invocation details and clearly ties the tool to its creation counterpart. It omits edge-case caveats such as irreversibility or behavior on missing tasks, but the presence of an output schema reduces the need to describe return values. Overall adequate but not maximally complete for a destructive 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?

  With 0% schema description coverage, the description compensates by explaining all three parameters: task_name as the original name, label_prefix as a reverse-domain prefix, and delete_files as controlling script/plist/log file removal. This adds concrete meaning beyond the bare schema titles, though task_name could be slightly clearer.

  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 action: 'Unload and remove a task created by create_or_update_python_task.' It clearly identifies the resource type and links it to the sibling creation function, distinguishing it from service-management tools like bootout_service or kickstart_service.

  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 'created by create_or_update_python_task' implies this is the inverse/cleanup operation for Python tasks, giving clear context. It does not explicitly list alternatives or exclusions, but the relationship to the creation tool is sufficient for an agent to infer appropriate usage.

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

• kickstart_serviceA
  4.3/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the behavioral disclosure burden. It explicitly discloses that kill_existing=true passes -k and kills a running instance first, which is the main side-effect. It does not mention permission requirements or what happens when the service is not loaded, but the destructive behavior is surfaced.

  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 short and front-loaded with the primary action before the argument explanations. There is no filler, repetition of the schema, or unnecessary detail.

  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 two-parameter tool with an output schema, the description covers the action and both parameters well. It omits prerequisites such as the service needing to be loaded before kickstart versus bootstrap, but this is a minor gap for a relatively simple tool.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate, and it does. The Args section explains target with a concrete launchd example and explains kill_existing's exact effect via -k. This adds meaningful semantics beyond the raw schema's titles and types.

  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 opens with 'Start or restart a service via launchctl kickstart', which is a specific verb and resource. It clearly distinguishes this tool from sibling operations like bootstrap_service, bootout_service, enable_service, and disable_service by naming the exact launchctl action.

  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 states the core operation ('start or restart') but does not explicitly say when to choose kickstart_service over bootstrap_service or bootout_service, nor does it mention exclusions. Usage context is implied by the operation and sibling names, but no direct guidance is provided.

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

• create_or_update_python_taskA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses the main mutation behavior (create/update and load), the destructive 'replace_existing' behavior ('bootout existing service first'), and relevant internals such as plist creation and default working directory. It does not cover permissions or error handling, but the core behavioral surface is well communicated.

  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 opening sentence is immediately informative, and the Arg section is organized, scannable, and free of fluff. Each one-liner adds semantic value without repetition, which is appropriate for a tool with 18 parameters.

  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 high-complexity tool with 18 parameters, the description covers every parameter with practical details and the output schema handles return values. It lacks only explicit edge-case or failre behavior, and could state when not to use it, but as an invocation guide it is substantially complete.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the Arg- list is essential. It covers all 18 parameters with meaningful semantics: format of start_calendar, csv shape of watch_paths_csv/queue_directories_csv, default for python_bin and working_directory, '022'/'0o022' umast format, and the destructive meaning of replace_existing. This fully compensates for the 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 first sentence states a specific action, resource, and side effect: 'Create/update a LaunchAgent from a Python script string and load it.' This makes the tool's purpose immediately clear and distinguishes it from the sibling operations like remove_python_task, list_python_tasks, and bootout_service.

  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 does not explicitly say 'use this when...' or list alternatives, but the action sentence plus sibling tool names make the context unambiguous: this is the tool for creating or updating a Python-script LaunchAgent. It is clear enough for an agent to choose correctly without further guidance.

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