Server Quality Checklist

Tool Scores

• td_connectB
  3.4/5.0
  Behavior2/5

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

  Without annotations, the description carries the full burden of behavioral disclosure, but only provides the basic action. It does not mention if existing connections are overwritten, what happens with invalid paths, error handling, or the state after connection. This is insufficient for a mutation tool.

  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 conveys the core purpose efficiently. No unnecessary words, and it is front-loaded with the essential verb and objects.

  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 no output schema and no annotations, the description should provide more context to be complete. It lacks details about the effect on the TouchDesigner network, prerequisites, or return behavior. A connecting tool often has nuances about ordering or validation that are missing.

  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 has 100% description coverage, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not clarify the ordering or specifics of output/input indices. The schema already documents this adequately.

  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 'connect' and the specific resources: 'output of one operator' to 'input of another operator' in TouchDesigner. It is distinct from sibling tools like td_create_operator (creation), td_list_operators (listing), td_run_python (execution), and td_set_parameter (modification), making the purpose unambiguous.

  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 stating what the tool does, but provides no explicit guidance on when to use it, when not to use it, or alternatives. Given the straightforward nature of connecting operators, the implicit guidance is adequate, but lacks depth.

  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.7/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only says 'Create a new operator' without explaining side effects, error handling, or whether it overwrites existing operators. Minimal behavioral disclosure.

  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 concise: one sentence followed by a clear bulleted list of examples. No extraneous 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 description covers basic creation but lacks details on return value, error conditions, or default behavior. Given the absence of annotations and output schema, more context would be helpful.

  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 100%, so each parameter is already documented. The description adds value by listing example operator types, which clarifies the op_type parameter beyond 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 clearly states 'Create a new operator in TouchDesigner' and provides concrete operator type examples. This distinguishes it from sibling tools like td_connect, td_list_operators, etc.

  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 provides operator type examples and required parameters (op_type, name) but does not explicitly state when to use this tool vs alternatives, nor does it mention prerequisites like existing parent path.

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

• td_run_pythonA
  3.8/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 burden. While it explains how to write code, it does not disclose potential risks, such as destructive operations or security implications. As a code execution tool, more transparency about side effects is needed.

  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 concise and front-loaded with the purpose, followed by relevant examples. Every sentence serves a clear purpose, and the structure is efficient without 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?

  Given the tool's complexity (code execution) and lack of output schema, the description adequately explains how to interact (op() usage, full paths). It could mention error handling, but overall it is sufficiently complete for an agent to invoke correctly.

  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 already describes the 'code' parameter with 100% coverage, but the description adds value by providing examples and best practices (e.g., full paths, common operations). This goes beyond the schema's basic description.

  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 'Execute Python code inside TouchDesigner', which is a specific verb+resource. It distinguishes itself from sibling tools like td_connect, td_create_operator, td_list_operators, and td_set_parameter, which handle specific operations rather than arbitrary code execution.

  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 provides examples and guidance on using op() and full paths, implying when to use the tool (for custom Python execution). However, it does not explicitly state when not to use it or provide alternatives, leaving the agent to infer usage context.

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

• td_list_operatorsA
  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 correctly implies a read-only operation ('list'), but does not explicitly state it is non-destructive or describe any limitations (e.g., depth of listing). The description is adequate but not detailed.

  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?

  Two concise sentences that front-load the core purpose and follow up with a usage hint. Every sentence is valuable with no redundant phrasing.

  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?

  With one parameter and no output schema, the description adequately explains what the tool does and when to use it. It could mention the output format (e.g., returns operator names) or depth behavior, but overall it is sufficient for a simple list operation.

  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 has 100% description coverage for the single parameter 'path' (default '/project1'). The description adds no additional semantics beyond the schema's parameter description, meeting the baseline expectation.

  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?

  Explicitly states it lists child operators at a given path in TouchDesigner, clearly distinguishing it from siblings like td_create_operator (create) and td_set_parameter (set). The verb 'list' combined with the resource 'child operators' is specific and unambiguous.

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

  Usage Guidelines4/5

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

  Provides a clear usage context: 'Useful for inspecting the current state of a network.' While it doesn't explicitly mention when not to use or name alternatives, the context is sufficient for an AI agent to understand when to invoke this tool over others.

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

• td_set_parameterA
  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 full burden. It indicates mutation ('set') but lacks details on side effects, permissions, or recomputation behavior. The list of common parameter names adds context but not behavioral depth.

  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 brief and front-loaded with the core action. The subsequent list of examples is structured and concise, with no extraneous information.

  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's simplicity and lack of output schema, the description covers the primary usage well. Minor gaps exist: no mention of error behavior or return value, but the tool's purpose is sufficiently conveyed for typical use.

  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% with descriptions for all parameters. The description adds value by providing categorized common parameter examples (TOPs, SOPs, CHOPs, General), which aids the agent in selecting valid param_name values beyond 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 explicitly states 'Set a parameter on a TouchDesigner operator' which is a clear verb+resource. Sibling tools like td_create_operator and td_run_python are distinct, so the purpose is well differentiated.

  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 guidance on when to use this tool versus alternatives. The sibling names hint at different tasks, but the description does not specify conditions or exclusions, leaving the agent to infer usage context.

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