Server Quality Checklist

Tool Scores

• td_disconnectC
  2.9/5.0
  Behavior2/5

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

  Annotations already convey readOnlyHint false and idempotentHint true, but the description adds no additional behavioral context such as side effects, error cases, or prerequisites for disconnection. For a mutation tool, the description fails to disclose anything beyond the bare action.

  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, directly to the point with no filler. It earns every word and is optimally concise.

  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 mutation tool with no output schema and incomplete parameter descriptions, the description omits essential details about the connector parameter, default behavior, and edge cases. The tool is under-specified for an agent to reliably use it without further clarification.

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

  Parameters1/5

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

  Schema description coverage is only 33% (only path is described). The description fails to explain the 'connector' integer parameter or the 'direction' enum, leaving the agent without critical information to invoke the tool correctly. No compensation for the schema gap is provided.

  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 'disconnect' and identifies the resource as 'one input or output connector' on an operator, clearly distinguishing it from sibling tools like td_connect. It is concise and unambiguous 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.

  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 td_connect or td_delete_operator. The description only states the action without usage context, exclusions, or prerequisites, leaving the agent to infer applicability.

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

• td_connectA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds a key behavioral constraint ('Both operators must belong to compatible families'), which is useful beyond annotations. However, it does not disclose potential side effects, failure behavior, or any other operational details, so it only marginally exceeds the annotation baseline.

  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 two concise sentences that directly state the action and a critical constraint. Every word is relevant, with no redundancy or filler.

  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?

  Given the tool has 4 parameters, no output schema, and minimal annotations, the description is too sparse. It does not explain the meaning of the optional connector parameters, provide usage examples, or clarify what happens on success/failure. The compatibility note is the only extra context, but it is insufficient for a tool with this complexity.

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

  Parameters2/5

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

  Schema coverage is 50%: source and target have descriptions, but sourceConnector and targetConnector are completely undocumented in both the schema and description. The description does not explain what these integer parameters represent or how to specify connector indices, leaving the user to infer. It fails to compensate for the schema gaps.

  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 a specific verb ('wire an output connector to an input connector') and specifies the resource (TouchDesigner operators). It distinguishes itself from sibling tools like td_disconnect by indicating the action of creating a connection. The compatibility mention adds precision.

  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 the tool is for connecting operators and notes a compatibility constraint, but does not provide explicit when-to-use or when-not-to-use guidance, nor any alternatives. There is no mention of when to prefer this over other connection-related tools or exclude scenarios.

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

• td_create_operatorA
  3.5/5.0
  Behavior3/5

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

  With no useful annotation hints (all false), the description carries the burden of disclosing behavior. It accurately states what the tool does but adds no extra context about side effects, prerequisites, or failure modes. For a simple create operation, this is minimally viable but lacks depth (e.g., no mention of name auto-generation or parameter application).

  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 with no filler. Every word serves a purpose, and the examples provide immediate clarity without unnecessary length.

  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 6 parameters including a nested object, no output schema, and no annotations, the description is too sparse. It does not explain return values, error handling, or how to structure the 'parameters' object, leaving significant gaps for an agent trying to use it correctly.

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

  Parameters2/5

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

  Schema description coverage is only 33% (type and parent have descriptions). The description adds examples for 'type' and implies 'parent' is a COMP, but it ignores x, y, name, and especially the complex 'parameters' object, which supports expression/bindExpr forms. Since coverage is low, the description should compensate but does not.

  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 ('Create') with a clear resource ('one operator in a COMP') and provides concrete type examples (noiseTOP, audioSpectrumCHOP, baseCOMP). This distinguishes it from sibling tools like td_delete_operator or td_batch, and 'one operator' explicitly signals single-operator creation.

  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?

  Usage is implied by the action: create a single operator in a COMP. However, there are no explicit alternatives or exclusions, such as using td_batch for multiple operators or td_set_parameters for post-creation changes. The description gives basic context but no comparative guidance.

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

• td_sample_chopA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds that it reads 'current' values, implying a snapshot at the current frame, but doesn't disclose behaviors like error handling on invalid paths, default channel selection, or return format. This is acceptable given the annotation coverage but not rich.

  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, succinct sentence that front-loads the action ('Read current CHOP channel values') and includes relevant use cases. Every word earns its place, with no redundant information.

  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 four parameters and no output schema, yet the description only covers the overall purpose. It omits crucial details about how to select samples, whether channels are filterable, the default maxChannels behavior, and what the return structure looks like. This is inadequate for a tool with this complexity and missing output schema.

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

  Parameters1/5

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

  Schema description coverage is only 25% (only 'path' is described), and the description itself does not explain any of the four parameters. It doesn't mention 'sample', 'channels', or 'maxChannels' semantics, leaving users without guidance on how to use these parameters. The description fails to compensate for the low 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 clearly states the tool reads current CHOP channel values, with a specific verb 'Read' and resource 'CHOP channel values'. It also lists example use cases (audio levels, envelopes, beats, control signals, diagnostics), which distinguishes it from sibling tools that perform other operations like creation, deletion, or inspection.

  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 for when to use this tool: to read current CHOP channel values for various signal types. It doesn't explicitly contrast it with alternatives like td_inspect_operator, but the use cases imply a focused sampling scenario. No exclusions are given, but the context is sufficient for basic selection.

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

• td_build_audio_reactive_rigA
  3.7/5.0
  Behavior3/5

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

  Annotations show readOnlyHint=false and destructiveHint=false, so the description correctly indicates a write operation without destruction. It adds specific context about what is created (spectrum, bands, etc.) and mentions a 'stable output Null', but it doesn't disclose behaviors like idempotency (e.g., what happens if network already exists) or potential side effects on existing operators.

  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, information-dense sentence that front-loads the core verb and object, then uses a list of components. Every phrase contributes meaning without fluff or redundancy. It is well-structured for quick parsing.

  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 complexity (10 parameters, no output schema), the description provides a strong high-level overview but omits important context such as return values, usage sequence, or dependency notes. It doesn't explain what the tool returns or how to verify the result, which is necessary when no output schema is available.

  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?

  With only 10% schema description coverage, the description needs to compensate. It does add meaning by mapping components to parameters (e.g., 'smoothed low/mid/high bands' relates to lowHz, midHz, highHz, smoothing; 'device/file input' relates to source, device, file; 'beat gate' relates to beatThreshold). However, it leaves several parameters like name and parent without explicit semantic explanation, and the mapping is not complete for all 10 parameters.

  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 'Create' and specifies the resource as 'a reusable CHOP analysis network' with concrete components (device/file input, spectrum, bands, envelope, beat gate, output Null). It clearly distinguishes itself from generic siblings like td_create_operator by indicating it builds a full network rather than a single operator.

  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 its usage through the tool name and listed components, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. For example, it doesn't say 'Use this instead of td_create_operator when you need an audio-reactive analysis setup.'

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

• td_pulse_parameterA
  3.7/5.0
  Behavior3/5

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

  With no annotations indicating safety, the description adds a basic behavioral clue by identifying the action as 'pulse' and giving typical targets. It does not disclose return behavior, side effects, or prerequisites like needing an active connection.

  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 with no redundancy. Every word adds value, and examples improve comprehension without added length.

  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 and the description covers the core action, but no output schema exists and return/error behavior is omitted. The missing schema description for 'parameter' is only partially mitigated by examples, leaving the overall context minimally adequate.

  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 documents 'path' but leaves 'parameter' unexplained. The description partially compensates by offering example parameter names, but it does not explicitly state that 'parameter' should be the parameter name string or define expected formatting.

  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 action verb 'Pulse' and the resource 'momentary parameter' with concrete examples (Reset, Clear, Open). This clearly distinguishes it from sibling tools like td_set_parameters, which persist values.

  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 phrase 'momentary parameter' implies the appropriate use case, and examples clarify the intent. However, it does not explicitly state when not to use it or point to an alternative like td_set_parameters for sustained values.

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

• td_get_errorsA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and idempotentHint, so the description doesn't need to restate safety. It adds the 'after edits' context but does not clarify whether the tool clears errors or only gathers them, which is a minor transparency gap.

  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 with no fluff. It communicates the core action, scope, and timing 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?

  With no output schema, the description does not explain what the returned errors look like (e.g., format, count, or structure). It covers the tool's purpose and timing well but lacks detail on output or recursion behavior, making it adequate but not complete.

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

  Parameters2/5

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

  Only 50% of parameters are documented in the schema (path has a description; recurse does not). The description does not compensate for the missing recurse semantics, and only indirectly references path via 'under a network'. This leaves the recurse parameter meaning unclear.

  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 'collect' with clear resources ('errors, warnings, and script errors') and scope ('under a network'), distinguishing it from sibling tools like td_status or td_inspect_operator, which serve 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 phrase 'after edits' provides clear usage context, implying this tool is for checking a network's error state after modifications. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear.

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

• td_inspect_operatorA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and idempotentHint, and the description's 'Read' aligns with that. It adds the set of inspected attributes, providing useful context about the tool's scope. It does not disclose behavior like defaults for parameterLimit or error handling, but given the annotations, this is acceptable.

  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?

  Single sentence, front-loaded with the verb and resource, enumerates attributes without waste. Perfectly concise.

  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 gives a broad overview of what is read, but without an output schema or parameter descriptions, the agent may lack clarity on optional parameters and return structure. It's adequate but leaves gaps.

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

  Parameters2/5

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

  Schema coverage is only 25% with only 'path' described. The description mentions 'parameters' as an output category but does not explain the optional parameters (parameterLimit, includeChildren, includeParameters). Since the description carries the burden for low schema coverage, it falls short.

  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 'Read' and enumerates resource attributes (type, flags, inputs, outputs, parameters, dimensions/channels, errors), clearly distinguishing it from sibling tools like td_get_errors or td_status.

  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?

  No explicit when-to-use or alternative exclusions are provided. Usage is implied by the enumeration of inspected attributes, but the description does not contrast with similar tools such as td_status or td_get_errors.

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

• td_set_dat_textA
  3.8/5.0
  Behavior4/5

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

  The description discloses that this tool 'replaces' content, which is a behavioral trait beyond the annotations (which only state idempotentHint and destructiveHint). It clarifies that the operation overwrites the existing body, adding useful context. However, it does not cover whether the operator must already exist or what happens to missing paths.

  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 is front-loaded with the purposeful verb 'Replace' and lists the affected DAT types. Every word adds value with no unnecessary filler.

  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 moderate complexity (3 parameters, no output schema) and low schema coverage, the description is complete enough for the core action but lacks important context. It does not explain 'expectedText' or specify whether the path must reference an existing operator, leaving gaps for an agent.

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

  Parameters2/5

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

  The input schema has only 33% parameter description coverage (only 'path' is described). The tool description implies that 'text' is the new body content, but it does not explain 'expectedText' or add syntax details. With low schema coverage, the description fails to compensate, leaving parameter meaning incomplete.

  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 a specific verb ('Replace') and specific resource types ('Text DAT, GLSL DAT, Script DAT, or callback DAT body'). It distinguishes itself from sibling tools like td_set_parameters, which target parameter values, and td_create_operator, which creates operators.

  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 by listing the DAT types it applies to, but it does not explicitly state when to use this tool over alternatives or provide exclusions. There is no mention of when not to use it, such as for setting operator parameters or creating operators, leaving the guidance implicit.

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

• td_list_operatorsA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, covering safety. The description adds useful context about operating on COMP children and supports recursion/filtering, which aligns with parameters. However, it does not disclose return format, pagination, or limit behavior, so it adds only moderate transparency 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.

  Conciseness5/5

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

  The description is a single, well-structured sentence that leads with the primary action, then adds optional modifiers. Every phrase conveys key information without redundancy, making it highly scannable for an agent.

  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 there is no output schema, the description does not mention what the tool returns (e.g., list of paths, names, or dicts). It also omits edge cases like depth limits or limit defaults. While the safety annotations cover the read-only aspect, a lightly parameterized introspection tool like this would benefit from a sentence describing return value or list format.

  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 only 20% (only 'parent' has a description), so the description must compensate. It does explain the roles of depth (recursive), family (filter by family), and pattern (name pattern), and implies parent is a COMP. But it does not explain the 'limit' parameter at all, and it leaves the exact meaning of 'children' (immediate vs recursive) to the depth parameter. This is partial compensation, not full.

  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 resource ('children under a COMP'), and clarifies optional behavior (recursive, filtered by family or name pattern). This clearly distinguishes it from sibling tools like td_inspect_operator or td_sample_chop, 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 it: when you need to enumerate children of a COMP with optional filtering. It does not explicitly mention alternatives or exclusions, but the sibling tools are all sufficiently distinct in action that no warning is needed. It provides clear context without explicit when-not guidance.

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

• td_delete_operatorA
  4/5.0
  Behavior4/5

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

  Annotations already indicate destructive behavior (destructiveHint=true). The description adds valuable context beyond annotations by stating 'Root and project components are protected by the bridge,' which informs the agent of safety constraints. It also clarifies that only one operator is deleted, setting expectations for the operation's scope.

  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—two short sentences—with no filler. Each sentence adds functional value: the first states the primary action and scope, the second communicates a key safety constraint. Ideal length for a simple deletion tool.

  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 strong annotations, the description is largely complete. It covers the core behavior and protected cases. However, it does not mention error handling or return behavior, which could be relevant for agents, but given the tool's simplicity and the presence of annotations, this is a minor gap.

  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 the 'path' parameter with a clear description and example. The tool description does not add further parameter-level detail beyond what the schema provides, matching the baseline for high 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 clearly states the tool's purpose with a specific verb and resource: 'Delete exactly one operator.' It also distinguishes itself from sibling tools like create/set by focusing solely on deletion, and the note about protected components adds specificity.

  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 deleting a single operator but does not explicitly compare to alternative tools or state when not to use it. The 'exactly one' qualifier and protected-path note give some context, but there is no explicit 'use this instead of X' guidance.

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

• td_set_parametersA
  4.1/5.0
  Behavior3/5

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

  Annotations already provide idempotentHint=true and destructiveHint=false, and the description does not contradict them. It adds context about supported value types but does not disclose error behaviors, path existence requirements, or how existing parameter values are overridden.

  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 that front-loads the action and clearly enumerates the supported value types. There is no redundant or filler text, making it highly 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 setter with no output schema and robust annotations, the description covers the primary capability and parameter semantics. It does not mention error conditions or the need for the operator to exist, but idempotentHint provides some behavioral coverage, making the description sufficiently 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 only 50% (only 'path' is described). The description explicitly explains the 'parameters' object: simple values are constants, {'expr'} objects are Python expressions, and {'bindExpr'} objects are bind expressions. This directly compensates for the missing schema documentation.

  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 identifies the tool's purpose: setting parameter values on a TouchDesigner operator, explicitly listing constants, Python expressions, and bind expressions. This distinguishes it from sibling tools like td_pulse_parameter (which pulses a parameter) and td_set_dat_text (which sets DAT text).

  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 by mentioning 'in one call' and the accepted value forms, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives like td_pulse_parameter. It lacks clear exclusions or comparisons to siblings.

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

• td_batchA
  4.2/5.0
  Behavior5/5

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

  The description discloses rollback behavior—if one edit fails, completed edits are undone when rollback is enabled. It also emphasizes the ordered execution of edits, which is significant behavioral context beyond the annotations. The annotations only state destructiveHint=true, so the description adds value by specifying failure semantics.

  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 two sentences, front-loaded with the primary purpose and a key behavioral detail. No filler words; every element adds value.

  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 core purpose and rollback behavior but omits details about the operations array structure, the rollbackOnError parameter, and behavior without rollback. For a tool supporting eight methods and multiple operations, this is only minimally complete. However, the schema provides the method enum, and there is no output schema, so some gaps are acceptable.

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

  Parameters2/5

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

  With 0% schema description coverage, the description should compensate by explaining the parameters, but it does not. It fails to mention that 'operations' is an array of method/params objects or that 'rollbackOnError' controls rollback. The description only hints at the concept of edits, leaving parameter usage undocumented.

  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: applying up to 100 ordered graph edits. The phrase 'Apply up to 100 ordered graph edits' distinguishes it from sibling tools that handle individual operations such as td_create_operator or td_set_parameters. The title reinforces the batch nature.

  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 indicates the tool is for applying multiple edits in order with optional rollback, which implies its use case for batch operations. However, it does not explicitly mention alternatives or when not to use it, though the context of a batch tool vs individual tools is clear.

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

• td_capture_topA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description does not contradict this. It adds value by disclosing that the result is returned as MCP image content, which is not obvious from the schema. It does not elaborate on failure modes or timing, but this is acceptable given the read-only annotation.

  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 sentence that conveys the core function without redundancy. Every word contributes to understanding the tool's purpose and output.

  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 capture tool that returns an image, the description covers the essential information: what is captured, the output format, and the return type. The absence of an output schema is mitigated by mentioning 'MCP image content'. It does not discuss resolution or error handling, but these are secondary for this tool.

  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 low (33%); only 'path' is described. The description mentions the PNG/JPEG formats, adding meaning to the 'format' parameter, but it does not explain 'quality'. Thus it partially compensates for the schema gap but leaves the quality parameter under-specified.

  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 (Capture), the resource (TOP), the output formats (PNG/JPEG), and the return type (MCP image content) for visual verification. This distinctly separates it from sibling tools like td_sample_chop (CHOP data) and td_inspect_operator (operator properties).

  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 a clear usage context: 'for visual verification'. It implies when this tool is appropriate, but does not explicitly mention alternative tools or when not to use it, which would earn a 5.

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

• td_statusA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, lowering the bar. The description adds context by listing the specific status items (build, project, timeline, capability flags), which goes beyond the annotations. It does not contradict annotations and provides a clear behavioral scope.

  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 front-loads the verb and lists the items checked. It contains no fluff or redundant information, making it highly efficient.

  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 simplicity of the tool (no parameters, no output schema, and clear annotations), the description adequately covers its purpose. A minor gap is that it does not describe the return format, but the listed items give a good sense of what to expect. The description is complete enough for a status check 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 full coverage. The description adds no parameter information, but with no parameters, a baseline score of 4 is appropriate. The description's focus on what the tool checks is sufficient.

  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 a specific verb ('Check') and enumerates the distinct resources it covers: bridge health, TouchDesigner build, project, timeline, and capability flags. This distinguishes it from sibling tools like td_get_errors (which specifically retrieves errors) and td_list_operators (which lists operators).

  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 checking overall status but does not explicitly state when to use it versus alternatives, nor does it mention when not to use it. The context suggests it is a general health/status check, but there is no direct guidance on alternatives or prerequisites.

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