Server Quality Checklist

Tool Scores

• connect_environmental_sensor_busC
  2.7/5.0
  Behavior3/5

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

  The description adds context by naming the scaffold's components, which goes beyond annotations already provided (readOnlyHint=false, destructiveHint=false). It implies a write operation that creates artifacts, but it does not disclose potential side effects, network usage (adapter_url), or effects on existing nodes. With annotations present, the bar is lower, but more behavioral clarity would be beneficial.

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

  Conciseness4/5

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

  The description is a single sentence and front-loads the core action (create scaffold) followed by a list of included artifacts. It is compact and avoids repetition, though the packed list of specialized terms could be clearer. Overall, it earns its place without wasting words.

  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 creation tool with eight parameters, no output schema, and minimal schema descriptions, a one-sentence description is inadequate. It conveys the high-level outcome but leaves out usage guidelines, parameter semantics, and behavioral caveats. The agent is under-informed to correctly select and invoke this complex scaffold tool.

  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% (2 of 8 parameters have descriptions), and the description provides no additional parameter-level information. It does not explain adapter_mode, sensor_profile, zone_count, or sensor_count. The listed artifacts (e.g., adapter source) are too vague to infer parameter meanings. 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.

  Purpose4/5

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

  The description uses a specific verb+resource: it 'creates an environmental sensor scaffold' and lists concrete artifacts (normalized readings, sensor maps, adapter source, building-control safety notes). This distinguishes it from generic connect/create tools. However, the tool name is 'connect' while the description says 'create', causing slight ambiguity about the primary action.

  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. It does not state prerequisites, typical scenarios, or situations where another tool would be better. The single sentence describes the output but provides no contextual usage direction.

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

• connect_houdini_engine_bridgeC
  2.7/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, and the description's 'Create' aligns with a write operation. It adds useful context by listing what is scaffolded (manifests, parameter maps, cook-status ingest, cache notes). However, it does not disclose potential network behavior implied by server_url and receive_port parameters, nor does it describe side effects or prerequisites, so transparency is only partially addressed beyond annotations.

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

  Conciseness4/5

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

  The description is a single sentence with no fluff, effectively using a list of technical components. However, it is dense and jargon-heavy, which can obscure rather than clarify. Overall, it is appropriately sized for the information it contains.

  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?

  This is a complex tool with 10 parameters, no output schema, and only 20% parameter documentation. The one-sentence description does not explain the scaffold's behavior, how to use it, or what the parameters control. It is inadequate for an agent to correctly select and invoke the tool in diverse scenarios.

  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 20% (only 2 of 10 parameters have descriptions), and the tool description does not mention any parameter names, meanings, or relationships. It adds no value beyond the minimal schema defaults, leaving the agent with little guidance on how to set parameters like asset_format, handoff_mode, or receive_port.

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

  Purpose4/5

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

  The description clearly identifies a specific verb ('Create') and resource ('Houdini Engine/HDA/cache handoff scaffold') and lists concrete components (manifests, parameter maps, cook-status ingest, cache notes). It distinguishes itself from sibling 'connect' tools by focusing on scaffold creation rather than a live bridge, though it doesn't explicitly contrast with them.

  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 on when to use this tool versus alternatives. The description implies it is for setting up a Houdini Engine handoff scaffold, but does not mention when not to use it, prerequisites, or how it compares to the many other bridge and connectivity tools in the sibling list.

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

• connect_runway_video_bridgeC
  2.7/5.0
  Behavior3/5

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

  Annotations already cover readOnlyHint=false and destructiveHint=false, so the creation behavior aligns. The description adds context about scaffold components (prompt maps, contracts, polling status, adapter notes) but does not disclose potential side effects, external dependencies, or whether it overwrites existing content.

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

  Conciseness4/5

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

  The description is a single sentence with no filler, front-loading the main action and then listing deliverables. It is dense but somewhat jargon-heavy ('handoff scaffold'), though still 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?

  With 9 parameters, no required params, no output schema, and low schema coverage, the description is too sparse to convey the full scope. It does not explain return values, setup prerequisites, or how the scaffold is connected or used after creation, leaving significant gaps for a tool of this complexity.

  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 22%, and the description does not elaborate on any of the 9 parameters. It mentions high-level scaffold components but no mapping to specific parameters like endpoint_url, prompt_count, or generation_mode. 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.

  Purpose4/5

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

  The description clearly states it creates a Runway-style video generation handoff scaffold, with specific components listed. The verb 'Create' is specific, though the tool name says 'connect' which creates minor ambiguity. It does distinguish from sibling bridge tools by the Runway-specific context.

  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 explicit guidance on when to use this tool versus alternatives such as connect_replicate_prediction_bridge or connect_comfyui. The description only states what it does, not when it should be preferred, nor any prerequisites or exclusions.

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

• connect_rvc_voice_conversion_busC
  2.7/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description aligns by saying 'Create'. It adds modest context by mentioning consent warnings and latency notes, but doesn't reveal side effects like network connections despite openWorldHint=true. This is a minor gap but not a contradiction.

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

  Conciseness4/5

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

  The description is a single sentence that efficiently lists the scaffold components without extraneous words. It is properly sized and front-loaded with the action and resource, though the list of items is somewhat lengthy.

  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 11 parameters, low schema coverage, no output schema, and a complex creation task, the description is too terse. It doesn't explain the scaffold's integration with TouchDesigner, what the tool returns (e.g., a component path), or how parameters like server_url and request_url are used. The mention of consent warnings and latency notes adds some value but fails to provide a complete picture.

  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 18%, with 11 parameters and almost no descriptions. The description does not explain any parameter's meaning beyond vague references like 'source audio' which could relate to audio_file, but no explicit mapping or semantic help for parameters such as source_mode, speaker_count, or transpose_semitones.

  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 creates an RVC-style voice conversion scaffold, specifying components like source audio, model maps, output contracts, latency notes, and consent warnings. This goes beyond a tautology and is specific to the resource, though it doesn't explicitly differentiate from sibling bus-creation tools.

  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. It doesn't mention prerequisites, exclusions, or which sibling tools (e.g., connect_whisper_transcription_bus, create_voice_prompt_pipeline) might be more appropriate for different use cases. The description only states what it creates.

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

• create_ncam_camera_tracking_busC
  2.7/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is known. The description adds that it creates a scaffold with certain maps, but does not disclose any side effects, prerequisites, or runtime behavior beyond creation. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is a single concise sentence that front-loads the core purpose. It earns its place without unnecessary verbosity, though it sacrifices informative detail for brevity.

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

  Completeness1/5

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

  With 7 parameters, only 29% schema coverage, no output schema, and a large sibling set, the description is far too sparse. It does not explain what a 'scaffold' entails, how parameters affect the result, or what the agent should expect after invocation. The agent cannot confidently invoke this tool correctly.

  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 29% (2 of 7 parameters have descriptions). The description mentions map types (pose, lens, video-preview, calibration) but does not explain any parameter semantics. With low schema coverage, the description should compensate by explaining key parameters like port, active, camera_count, and lens_profile_count, but it does not.

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

  Purpose4/5

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

  The description clearly identifies the resource (NCAM camera-tracking scaffold) and lists the included maps (pose, lens, video-preview, calibration). It is specific to this tool and distinguishes it from other tracking-bus tools by name and content, though it does not explicitly contrast with siblings such as create_blacktrax_tracking_bus.

  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 provides no guidance on when to use this tool versus alternative tracking-bus creation tools. Given the large number of sibling tools (e.g., create_optitrack_tracking_bus, create_blacktrax_tracking_bus), the lack of explicit usage context or exclusions is a notable gap.

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

• create_window_output_matrixC
  2.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the create semantics are implied. The description adds that it produces a 'scaffold' with specific internal elements, but does not disclose side effects, whether existing nodes are modified, or performance implications. It is consistent with annotations and adds modest 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 a single, front-loaded sentence with no filler words. It is efficient but arguably too terse given the tool's complexity; however, for what it covers, every word earns its place.

  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 7 parameters, no output schema, low schema coverage, and many competing create_* siblings, a one-sentence description is insufficient. It does not cover usage scenarios, parameter roles, or expected results, leaving significant gaps for an agent to infer.

  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 29%, with descriptions for just name and parent_path; the remaining five parameters (active, perform_mode, window_count, resolution_width, resolution_height) are undocumented in the schema. The description does not explain any parameter behavior or relationships, so an agent is left without meaning for the majority of 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 uses a specific verb ('Create') and identifies the resource ('Window COMP output matrix scaffold') along with its key components ('window maps, source maps, status, and setup notes'). It clearly conveys the tool's purpose but does not explicitly differentiate it from similar sibling tools like create_multi_output or setup_output.

  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. The description only states what it creates, without mentioning conditions, prerequisites, or exclusions such as 'use this instead of create_multi_output when...'.

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

• connect_geojson_feature_busC
  2.8/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false and openWorldHint=true, but the description only says 'Create a scaffold' without additional behavioral context. It does not explain side effects, external connections, overwrite behavior, or anything beyond what annotations already imply, adding little transparency.

  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. It communicates the core purpose and key deliverables efficiently, every phrase adds value.

  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 10 parameters, no output schema, and minimal annotations, the description lacks essential context such as prerequisites, post-conditions, or what the scaffold is used for. It does not explain the 'connect' aspect of the tool name or the impact of the openWorldHint, leaving the operation contextually incomplete.

  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 20% (name and parent_path have descriptions), leaving 8 parameters undocumented. The description lists high-level components like 'feature rows, property maps, style rules' but does not map these to specific parameters or explain defaults, enums, or relationships, so it 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.

  Purpose4/5

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

  The description uses a specific verb 'Create' and names the resource 'GeoJSON feature scaffold' with enumerated components (feature rows, property maps, style rules, adapter source, projection/privacy notes). This distinguishes it from most siblings, though the tool name says 'connect' while description says 'create', causing slight ambiguity.

  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 provides no guidance on when to use this tool versus alternatives. With a large sibling list including many 'connect_*' and 'create_*' tools, there is no mention of preferred scenarios, exclusions, or alternative tools.

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

• connect_adsb_aircraft_busC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate openWorldHint=true and readOnlyHint=false, warning of side effects, but the description does not elaborate on what those side effects are. It does not mention that the scaffold may connect to an external adapter URL, fetch live data, or that existing components might be modified. The phrase 'sanitized aircraft rows' hints at data processing but not at runtime behavior or dependencies.

  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 primary action and then lists the scaffold's contents. It is concise, scannable, and contains no filler or duplication of structured data.

  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 10 parameters, no output schema, and an openWorldHint, the description is insufficient for an agent to anticipate the tool's full impact. It does not explain what the agent should expect after creation, whether it returns a reference, how the adapter is used, or how the privacy notes are applied. The tool likely has network and lifecycle implications that are left undisclosed.

  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 (20%), so the description needs to compensate. It provides thematic links: 'altitude bands' to altitude_band_count, 'track history metadata' to track_history_count, 'adapter source' to provider/adapter_url/adapter_mode, and 'aircraft rows' to aircraft_count. However, parameters like 'active', 'airspace_label', and 'adapter_mode' remain unexplained, and the mapping is implicit rather than explicit.

  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 ('Create an ADS-B aircraft scaffold') and lists key components (aircraft rows, altitude bands, track history, adapter source, feed/privacy notes). This distinguishes it from most sibling tools. However, the tool name/title use 'connect' while the description says 'create', creating a minor mismatch about whether the tool connects to an existing bus or builds a new scaffold.

  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 alternative bus-creation tools. There are dozens of similar tools (e.g., connect_ais_vessel_bus, create_blacktrax_tracking_bus), and the description does not state the intended context, prerequisites, or that this is the tool for ADS-B aircraft data. It relies solely on the domain in the name.

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

• connect_ais_vessel_busC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate that this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds context about 'sanitized vessel rows' and 'receiver/privacy notes', which hints at data sanitization and privacy handling, but it does not elaborate on side effects, permissions, or reversibility.

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

  Conciseness4/5

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

  The description is a single sentence that is front-loaded with the primary action and resource, and it enumerates scaffold components compactly. It is concise without unnecessary filler, though the list format could be clearer.

  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 10 parameters, no output schema, and limited annotation detail, a high-level one-sentence overview is insufficient. The description does not explain what the scaffold includes beyond a few components, nor does it describe return values or how the scaffold is structured, leaving gaps for a tool of 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 description coverage is only 20% (2 of 10 parameters have descriptions). The description mentions concepts like 'zone maps' and 'route hints' that loosely map to zone_count and route_count, but it does not explain individual parameters such as adapter_mode, adapter_url, vessel_count, or waterway_label. The description does not compensate for the low schema coverage.

  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 specific verb 'Create' and identifies the resource as an 'AIS vessel scaffold', listing key components (sanitized vessel rows, zone maps, route hints, adapter source, receiver/privacy notes). It clearly distinguishes the tool's purpose from generic 'connect' tools, though the name says 'connect' while description says 'create', causing slight ambiguity.

  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 connect_adsb_aircraft_bus or other connect_* bus tools. No exclusions or prerequisites are mentioned, so the agent must infer usage from the name alone.

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

• connect_calendar_schedule_busC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate non-readonly, non-destructive, and open-world behavior, and the description's 'create' aligns with those. The description adds some context by enumerating scaffold contents and mentioning credential/privacy safety notes, but it does not disclose side effects, reversibility, or whether existing components are modified. This is acceptable 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.

  Conciseness4/5

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

  The description is a single sentence that efficiently lists key components without fluff. It is front-loaded with the primary action and resource, though the dense chain of technical terms could be more readable. Overall, it is appropriately concise for a scaffolding tool.

  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 10 parameters, no output schema, and minimal annotations, the description is too brief to provide a complete picture. It omits return values, side effects, common usage patterns, and parameter semantics. Given the complexity, a longer description with structured examples or parameter explanations would be necessary for reliable invocation.

  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 20% (2 of 10 parameters have descriptions). The description provides a high-level mapping to some concepts (adapter source, reminder maps) but does not clarify the meaning or expected format of most parameters (e.g., provider, timezone, event_count, adapter_mode). With such low coverage, the description does not adequately compensate for the missing parameter documentation.

  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 ('Create') and resource ('venue calendar scaffold'), listing several concrete components (event rows, reminder maps, blackout windows, adapter source, credential/privacy safety notes). It is distinct from sibling connect_* tools that focus on external integrations, though the term 'scaffold' is somewhat domain-specific.

  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 such as create_scheduler or other calendar-related creation tools. There are no explicit use cases, prerequisites, or exclusion criteria, leaving the agent to infer usage from the name alone.

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

• connect_casparcg_serverC
  2.9/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds context by specifying the scaffold includes command templates and manifest notes, but it does not disclose any side effects, external interactions, or post-conditions beyond what the annotations imply. This is minimal but not contradictory.

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

  Conciseness4/5

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

  The description is a single, concise sentence that front-loads the primary action. It avoids unnecessary words, though it could be more informative without becoming verbose. It is appropriately sized for a simple statement of purpose.

  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 8 optional parameters, no output schema, and limited schema descriptions, the description is insufficient. It does not explain the expected outcome, how parameters affect the scaffold, or how to determine if this tool is appropriate. The openWorldHint annotation suggests potential side effects, but the description does not clarify them.

  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 schema description coverage at only 25%, the description should compensate for the undocumented parameters. However, it does not explain the meaning or usage of amcp_port, caspar_host, layer_count, channel_count, active, or media_root_hint. The mention of 'channel/layer templates' hints at layer_count/channel_count but does not clarify their syntax or role.

  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 states a specific verb ('Create') and resource ('CasparCG AMCP/playout scaffold'), with additional detail about channel/layer command templates and media manifest notes. This distinguishes it from sibling tools that target other systems (vmix, resolume, etc.), though the term 'scaffold' remains somewhat ambiguous.

  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 like connect_vmix_production or connect_obs_recorder. The description lacks any context about prerequisites, use cases, or exclusions, leaving the agent to infer applicability solely from the tool name.

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

• connect_discord_interaction_busC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive. The description adds some useful context by mentioning 'bot-token/signature safety notes,' implying security-related behavior. However, it does not disclose side effects, reversibility, or what actually gets created beyond a vague list of components.

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

  Conciseness4/5

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

  The description is a single sentence that is reasonably concise and front-loaded with the primary action ('Create a Discord interaction scaffold'). The list of components is compact and not overlong. It earns its place with useful detail, though it could be slightly more structured.

  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 10 parameters and no output schema, the description is insufficiently complete. It does not explain the scaffold's structure, purpose, or how the parameters control the result. The one-sentence overview leaves major gaps for an agent attempting to invoke the tool with meaningful arguments, especially regarding adapter configuration and safety notes.

  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 20% of the input schema parameters are described (name and parent_path). The description vaguely references 'command rows,' 'message rows,' and 'approval policy,' which hint at command_count, message_count, and approval_required, but does not explicitly map them to schema parameters or explain their meaning. With eight undocumented parameters and low schema coverage, the description fails to compensate adequately.

  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 creates a Discord interaction scaffold, enumerating key components like command rows, message rows, approval policy, adapter source, and safety notes. It is specific about the resource and action, though it does not explicitly distinguish from sibling tools. This is a clear purpose statement.

  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 provides no guidance on when to use this tool, what prerequisites exist, or how it differs from alternatives. It simply says 'Create' with no context for selection among the many sibling tools. There is no mention of when this scaffold would be preferred over other integration tools.

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

• connect_grafana_annotation_bridgeC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate this is not read-only, not destructive, and may interact with the external world (openWorldHint). The description adds 'token-safety notes' which is useful context, but does not explain side effects like file creation or whether Grafana credentials are required. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is a single, concise sentence that front-loads the action. It includes relevant details without excessive verbosity. Loses a point because the phrase 'scaffold' is also in the tool name and the list of maps could be clearer.

  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 8 optional parameters, no output schema, and minimal annotations, this description is too brief. It does not explain what the maps represent, what the scaffold produces, or how parameters like adapter_mode and base_url affect behavior. The tool is more complex than the description conveys.

  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 25% (2 of 8 parameters described). The description mentions dashboard, panel, tag, and annotation maps but does not connect these to specific parameters like base_url, dashboard_uid, tag_count, or panel_count. It 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.

  Purpose4/5

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

  The description clearly states the tool creates a Grafana annotation/event-marker scaffold with maps and token-safety notes. The verb 'create' and specific resource distinguish it from generic siblings, though it doesn't explicitly contrast with similar connect tools.

  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 on when to use this tool versus alternatives. No mention of prerequisites, typical use cases, or exclusions. Siblings include many connect_* tools, so context for when to choose this scaffold would be valuable.

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

• connect_map_tile_overlayC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds a useful feature list and mentions 'token/cache safety notes' as part of the scaffold, but does not explain the actual behavior, side effects, or what the adapter source entails. This is acceptable given the annotation coverage.

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

  Conciseness4/5

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

  The description is a single sentence that starts with the core action ('Create a map-tile overlay scaffold') and then lists what is included. The list is somewhat long but each item contributes meaning. It is reasonably concise and front-loaded, though the long en-dash list makes it dense.

  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 11 parameters and no output schema, the description provides only a high-level outline of the scaffold's contents. It omits critical context such as return values, where the scaffold is created, how to configure it, or what 'token/cache safety' entails. For a complex scaffolding tool, this is insufficient.

  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 18%, so the description carries a heavy burden. While it lists high-level constituents like viewport metadata and attribution rows, it does not map them to the 11 parameters (provider, style_id, center_lat, etc.) or explain their meaning. The description is far from compensating for the sparse schema documentation.

  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 creates a map-tile overlay scaffold and enumerates its key components (tile layer maps, viewport metadata, attribution rows, adapter source, token/cache safety notes). This distinguishes it from the many other connect_* and create_* sibling tools. However, the name says 'connect' while the description says 'create', causing slight ambiguity.

  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 explicit guidance on when to use this tool versus alternatives. The description implies it is for creating a map-tile overlay scaffold, but it does not mention prerequisites, exclusions, or similar tools to consider instead. The openWorldHint annotation hints at general usability but is not leveraged in the text.

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

• connect_matrix_room_busC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description only needs to add context beyond safety. It does add some value by mentioning 'sanitized room events' and 'token/encryption safety notes,' which hint at data hygiene and security considerations. However, it does not disclose the actual side effects of creation, such as whether external systems are contacted, whether existing room data is modified, or what the scaffold's runtime behavior will be. The description adds moderate context but is 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.

  Conciseness4/5

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

  The description is a single sentence that packs in the key components without redundancy. It is front-loaded with the main action and resource, and then lists included features. It could be slightly clearer with breaking into two sentences, but it is efficient and free of 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?

  With 10 parameters, no output schema, and low schema description coverage, the description carries a heavy burden that it does not fulfill. It omits details about where the scaffold is created (beyond the parent_path parameter), what the adapter source implies, how the approval policy works, and what the token/encryption safety notes actually do. The description is a high-level summary but leaves many operational questions unanswered for an agent attempting to invoke 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 20%, with only 'name' and 'parent_path' having descriptions. The tool description does not map its mentioned components (sanitized events, reaction maps, approval policy, etc.) to specific parameters like room_alias, adapter_mode, reaction_count, room_event_count, or approval_required. With 10 parameters and minimal schema descriptions, the description should compensate by explaining parameter roles; it fails to do so, leaving most parameters semantically opaque.

  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 ('Create') and identifies the resource ('a Matrix room scaffold'), and further specifies the scaffold includes sanitized room events, reaction maps, approval policy, adapter source, and token/encryption safety notes. This makes the tool's purpose fairly specific and distinct from generic connect/create tools, though it doesn't explicitly differentiate from sibling tools that also create scaffolds or buses.

  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. There are many sibling tools with similar names (e.g., connect_websocket_control_bus, create_blacktrax_tracking_bus, connect_mqtt_iot_bus), but the description does not mention any of these or specify conditions for selecting this Matrix-specific tool. No exclusions or alternative scenarios are given.

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

• connect_midi_mpe_controllerC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate readOnly=false, openWorldHint=true, and destructiveHint=false, so the 'Create' action is consistent. The description adds that it builds an expressive scaffold with zone/expression maps, but does not disclose side effects like whether it modifies the project, requires a physical device, or creates outputs beyond a scaffold.

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

  Conciseness4/5

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

  The description is a single sentence that is reasonably concise and immediately states the core action. It is front-loaded with 'Create an expressive MIDI MPE input/output scaffold', though the term 'expressive' is somewhat subjective and adds little semantic value.

  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 7 parameters, no output schema, and no usage guidance, the description is insufficient for an agent to fully understand tool behavior. It does not explain what happens after creation, how the scaffold is exposed, or what the parameters mean, leaving significant 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 description coverage is only 29%, and the description compensates poorly. It does not explain any parameter by name; 'device_name', 'include_output', 'expression_count', and 'lower_zone_channels' remain unclear beyond their names, and the description only vaguely hints at zones and expression maps.

  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 specific verb ('Create') and names the resource ('MIDI MPE input/output scaffold') with concrete elements like zone/expression maps for pressure, timbre, pitch bend, and note channels. This distinguishes it from the many sibling connect/create tools, though the verb 'Create' slightly clashes with the tool name's 'Connect'.

  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 provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It does not mention the openWorldHint or any conditions for connecting an MPE controller, leaving the agent to infer usage from the name alone.

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

• connect_prometheus_metrics_panelC
  2.9/5.0
  Behavior3/5

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

  Annotations (readOnlyHint=false, destructiveHint=false) are consistent with the description claiming creation. The description adds some context by mentioning 'operator-dashboard safety guidance' and 'alert routes', but does not disclose side effects, external dependencies (e.g., endpoint_url), or whether existing files are modified. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is a single sentence, which is concise. It front-loads the main action ('Create a Prometheus metrics scaffold') and then lists contents. It earns its place without unnecessary fluff, though the long list of items makes it slightly dense.

  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 9 optional parameters and no output schema, the description is too high-level. It doesn't specify what the scaffold consists of in concrete terms, how parameters affect the output, or what the user should expect after invocation. It needs more detail on functionality and parameter influence to be 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?

  Schema description coverage is only 22% (2 of 9 parameters have descriptions). The description mentions high-level concepts (metric maps, alert routes) but does not explain key parameters like alert_count, adapter_mode, metric_count, or scrape_interval_seconds. It 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.

  Purpose4/5

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

  The description clearly states the tool creates a Prometheus metrics scaffold with specific components (PromQL/client adapter notes, metric maps, alert routes, safety guidance). It distinguishes itself from sibling connect_* tools by focusing on Prometheus metrics panel scaffolding, though the title says 'Connect' while the description says 'Create', causing slight ambiguity.

  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 explicit guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, scenarios, or exclusions. It's a single declarative sentence with no context on selection among the many similar connect_* tools.

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

• connect_public_alerts_busC
  2.9/5.0
  Behavior3/5

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

  The description adds useful context beyond annotations by listing specific scaffold elements (advisory alert rows, severity maps, routing policy, adapter source, safety/escalation notes). However, it does not disclose behavioral implications such as creating external connections, modifying project structure, or any side effects beyond what the annotations (readOnlyHint=false, destructiveHint=false) already imply. It is adequate 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.

  Conciseness4/5

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

  The description is a single sentence that front-loads the main action and then lists the scaffold components. It is concise and each component adds information, though the list is somewhat packed and could be split for clarity. No wasteful words.

  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 10 parameters, no output schema, and an openWorldHint indicating external interactions, the description is too minimal. It does not explain what a 'scaffold' consists of in TouchDesigner terms, whether it creates a node, returns a reference, or how the adapter source is configured. The context provided is only partially complete, leaving many operational details unspecified.

  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 20% (only name and parent_path have descriptions). The description provides high-level hints that map loosely to parameters (e.g., 'adapter source' relates to adapter_url/provider/adapter_mode, 'routing policy' to route_count), but it does not explicitly explain any of the eight undocumented parameters. This is insufficient 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.

  Purpose4/5

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

  The description states a specific action (Create a public-alert scaffold) and enumerates the components included (advisory alert rows, severity maps, routing policy, adapter source, safety/escalation notes). It clearly distinguishes this from sibling tools by focusing on public alerts, though the name uses 'connect' while the description says 'create,' introducing slight ambiguity about whether it connects an existing bus or creates a new one.

  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. It does not mention exclusions, prerequisites, or alternatives such as other connect_* or create_* tools for different data sources. The intended use case is only implicit from the name and description.

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

• connect_qr_scan_busC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate non-read-only and non-destructive behavior. The description adds context about sanitized events and safety notes but does not disclose side effects like where the scaffold is created, whether it overwrites existing components, or any external network interactions implied by 'adapter source'.

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

  Conciseness4/5

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

  The description is a single sentence without redundant fluff, front-loaded with the primary action. The list of components is slightly unwieldy but remains 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 tool with 9 parameters, no output schema, and minimal annotations, the description is too thin. It omits what the tool returns, prerequisites, and how the scaffold integrates into a project, leaving significant 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?

  Schema coverage is only 22%, and the description offers only conceptual hints (sanitization policy, adapter source) that loosely map to parameters. It fails to explain specific parameter behavior, enums, or how values like route_count and scan_event_count affect the scaffold.

  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 creates a QR scan scaffold and enumerates key components (sanitized scan events, route maps, sanitization policy, adapter source, token/URL safety notes). This is specific enough to distinguish from generic 'bus' tools, though it doesn't explicitly differentiate from similar named sibling tools.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. With many sibling bus-creation tools, the absence of use-case context or prerequisites makes selection difficult.

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

• connect_redis_pubsub_busC
  2.9/5.0
  Behavior2/5

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

  Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), with which the description is consistent. However, the description adds little behavioral context: it mentions 'keyspace safety notes' and 'read-first operations policy' but does not explain side effects, whether existing components are modified, or what the scaffold actually does at runtime.

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

  Conciseness4/5

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

  The description is a single compact sentence with a meaningful list of features. It is front-loaded with the main verb and resource, and most words add value. However, the jargon-heavy phrasing ('adapter ingest', 'keyspace safety notes') could be clearer.

  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 12 parameters, no output schema, and sparse annotations, the description is incomplete. It does not explain the scaffold's purpose, configuration, return value, or how it integrates with the broader system. The high parameter count and low schema coverage make this description insufficient for an agent to use the tool confidently.

  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 17% (name and parent_path have descriptions), so the description must compensate. It does not: none of the 12 parameters (e.g., stream_mode, adapter_mode, channel_root, database_index) are explained beyond their names. The phrase 'channel maps' hints at channel-related params but is too vague.

  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 specific action ('Create a Redis Pub/Sub/Streams scaffold') and the resource. It lists key components (adapter ingest, channel maps, keyspace safety notes, read-first operations policy), which distinguishes it from sibling connect/create tools.

  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 on when to use this tool versus alternatives like connect_mqtt_iot_bus or create_external_io. There is no mention of prerequisites, exclusions, or preferred use cases. The description only implies it is for creating a Redis scaffold.

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

• connect_slack_ops_bridgeC
  2.9/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and openWorldHint=true, so the tool is expected to create/modify. The description adds value by enumerating what gets created (adapter, alert rows, command rows, safety notes), which is useful behavioral context. However, it does not disclose whether existing components are overwritten, side effects beyond the scaffold, or permission requirements.

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

  Conciseness4/5

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

  The description is a single sentence, efficient and free of redundancy. It front-loads the main action and lists key components compactly. Minor phrasing like 'operator-alert' could be clearer, but overall it is concise and structured well.

  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 11 parameters, no output schema, and no sibling differentiation, the description is too sparse. It does not explain what a 'Slack ops bridge' is, when it is needed, what the scaffold includes beyond a list, or how to interact with it. The tool appears to be a creation/scaffold action requiring more context about its role and outputs.

  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 18% (2/11 params described). The description loosely maps to some parameters (adapter_mode via 'webhook/socket adapter', alert_count via 'alert rows', approval_required/command_count via 'approval-gated command rows') but leaves many params (socket_url, adapter_url, channel_name, workspace_label, active, etc.) unexplained. Given the low schema coverage, the description should compensate more but does not fully.

  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 creates a 'Slack operator-alert scaffold' with specific components (webhook/socket adapter, alert rows, approval-gated command rows, token/signing safety notes), identifying a distinct resource and purpose. However, the name/title say 'connect' while the description says 'Create', creating slight ambiguity, and 'operator-alert scaffold' is somewhat jargon-heavy.

  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 explicit guidance is provided about when to use this tool versus alternatives (e.g., other bridge creation tools like connect_discord_interaction_bus). The description implies usage via 'Create a Slack operator-alert scaffold' but gives no context on scenarios, prerequisites, or exclusions.

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

• connect_spout_syphon_routerC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate this is not read-only and not destructive, so the bar is lower. The description adds that it is a 'scaffold' and 'platform-gated,' providing some context. However, it does not disclose any side effects, permissions needed, or behavioral nuances beyond creation, so it only partially covers the burden with annotations present.

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

  Conciseness4/5

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

  The description is a single sentence, front-loaded with the verb 'Create,' and uses concise language. It is appropriately sized but includes jargon like 'platform-gated' that might need elaboration. Still, it earns a high score for efficiency.

  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 7 parameters, no output schema, and a complex domain (Syphon/Spout), the description is too minimal. It does not explain what the scaffold entails, how route maps are structured, platform requirements, or what 'explicit setup notes' contain. An agent would lack sufficient context to invoke this tool confidently.

  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 57% (4 of 7 parameters have descriptions), which is moderate. The description does not explain any parameters directly, only mentioning 'route maps' which could be related to route_count but is not explicit. Since coverage is below 80%, 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.

  Purpose4/5

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

  The description clearly uses the verb 'Create' with a specific resource: 'a platform-gated Syphon/Spout texture-sharing router scaffold with route maps and explicit setup notes.' This is distinct from generic actions and mentions platform gating. However, it does not differentiate from similar sibling tools like connect_ndi_router_matrix or osc_router_matrix.

  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, no mention of prerequisites, and no scenarios provided. The description simply states what it does without any context for selection.

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

• connect_ticketing_checkin_busC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds some context by naming the scaffold's contents and PII/token safety notes. However, it does not disclose side effects, where the component is created, or how the adapter source is wired, so it adds only moderate value 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.

  Conciseness4/5

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

  The description is a single front-loaded sentence with no filler words. It efficiently captures the primary action and key deliverables, though the long list of scaffold components makes it somewhat dense and could benefit from better structuring.

  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 11 parameters, no output schema, and minimal schema descriptions, the description only offers a high-level summary. It omits default behavior, what the returned component represents, and how parameters interact. For a complex generation tool, this is incomplete.

  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 2 of 11 parameters have schema descriptions (18% coverage). The description references high-level concepts like gate counts, ticket-tier maps, and adapter source, but it does not map these to specific parameters or clarify meanings of enums like provider and adapter_mode. This 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.

  Purpose4/5

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

  The description clearly states the tool 'Create[s] a ticketing/check-in scaffold' and lists concrete scaffold contents like aggregate gate counts, ticket-tier maps, gate status, adapter source, and PII/token safety notes. This is specific enough to distinguish it from generic node creation tools, though the tool name says 'connect' while the description says 'Create', creating a minor verb inconsistency.

  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 provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, nor does it compare with sibling tools like connect_pos_sales_telemetry or create_blacktrax_tracking_bus. Usage is only implied by the scaffold topic.

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

• connect_whisper_transcription_busC
  2.9/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds that it creates a scaffold, which is consistent with these annotations, but does not disclose additional behavioral traits such as side effects, required permissions, or what the scaffold entails at runtime. It adds some context but not rich detail.

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

  Conciseness4/5

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

  The description is a single sentence that is direct and front-loaded with the main action. It efficiently lists the key components without excessive fluff. However, it is slightly dense with multiple clauses, but still 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?

  With 8 parameters, no output schema, and only 25% schema coverage, the description is too brief to provide a complete understanding. It does not mention return values, how the scaffold is connected, or the significance of parameters like server_url or active. The description gives high-level intent but lacks essential operational context.

  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 25% (only name and parent_path), so the description must compensate. The description mentions 'audio/file/chunk ingest' and 'segment maps' which loosely map to source_mode and segment_count, but it does not explain parameters like audio_file, server_url, active, language_hint, or their meanings. The description adds minimal value beyond the schema.

  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 creates a Whisper-compatible transcription scaffold with specific components (audio/file/chunk ingest, segment maps, status tables, privacy notes). This distinguishes it from other connect_* and create_* tools. However, the verb 'Create' conflicts slightly with the tool name 'connect', and it doesn't explicitly differentiate from any sibling alternatives.

  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. There is no mention of prerequisites, use cases, or when not to use it. The description only states what it does, leaving the agent to infer appropriate usage from the name and context.

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

• connect_isadora_patchB
  3/5.0
  Behavior3/5

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

  Annotations indicate a non-readonly, open-world, non-destructive operation. The description adds that it creates a scaffold with stable namespace mapping, but does not disclose side effects like node creation, network modifications, or whether existing components are affected. It is consistent with annotations but not enriching.

  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 with no redundant wording. It front-loads the action (Create) and key components, making it easy 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?

  For a tool with 10 parameters and complex integration scope, the description is too minimal. It does not explain what the scaffold entails, how actor/watcher/scene elements interact, or what the output of the operation is. The agent would lack essential context for correct invocation.

  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 20% (2 of 10 parameters), and the description does not explain critical parameters like send_port, receive_port, actor_count, watcher_count, scene_count, isadora_host, or active. The description adds no meaningful parameter semantics and 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.

  Purpose4/5

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

  The description clearly identifies the tool as creating an Isadora OSC scaffold with actor, watcher, and scene exchange components, and references stable namespace mapping. This distinguishes it from other connect_* tools by specifying Isadora and OSC, though 'scaffold' is somewhat abstract and doesn't fully detail the operations.

  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 on when to use this tool versus alternatives such as other connect_* or create_* tools. The description lacks any mention of prerequisites, exclusions, or typical scenarios, leaving the agent without explicit usage context.

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

• connect_nfc_tap_busB
  3/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false, and the description's 'Create' action aligns with these. The description adds context by listing the scaffold components, but it does not disclose potential side effects like network connections, modifications to existing components, or what the scaffold will be used for. It is consistent with annotations but adds only moderate behavioral context beyond them.

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

  Conciseness5/5

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

  The description is a single sentence of 16 words, front-loaded with the action and resource, followed by a compact list of components. Every word earns its place, 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?

  With 9 parameters, no output schema, and only basic annotations, this one-sentence description is insufficient to fully inform an agent about the scaffold's structure, return value, or post-conditions. It doesn't explain what 'scaffold' entails, how the resulting component is organized, or what the agent can do with the result. The description is too minimal for a tool of 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 description coverage is only 22% (only name and parent_path have descriptions), so the description should compensate for the remaining 7 parameters. It mentions high-level concepts like consent policy and adapter source, which loosely map to consent_mode and adapter_url, but it does not explain individual parameters such as active, installation_label, or tap_event_count. The description offers only vague semantic clues and does not adequately compensate for the low schema coverage.

  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 the specific verb 'Create' and identifies the resource as an 'NFC tap scaffold' with a clear list of included components (sanitized tap events, station maps, consent policy, adapter source, tag-privacy notes). It is clear and specific, though it does not explicitly distinguish this from sibling bus-creating tools like connect_rfid_badge_bus or connect_ble_beacon_bus, so it doesn't fully achieve sibling differentiation.

  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. The description only states what it creates, leaving the agent to infer usage from the tool name. There are no prerequisites, exclusions, or references to alternative tools, which is a significant gap given the large number of sibling bus/scaffold tools.

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

• connect_notion_show_rundownB
  3/5.0
  Behavior3/5

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

  Annotations already indicate write behavior (readOnlyHint=false, openWorldHint=true) and non-destructiveness (destructiveHint=false). The description adds some value by enumerating scaffold contents (e.g., approval policy, token-safety notes), which suggests internal structure, but it does not disclose side effects, API dependencies, or how the scaffold is materialized beyond 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 entire description is a single, front-loaded sentence that immediately names the action and resource, followed by a compact list of key features. No filler, no repetition, and every clause adds 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?

  With 10 parameters, no output schema, and minimal annotations, the description is underspecified. It does not explain prerequisites (e.g., Notion API credentials), return values, failure modes, or how the scaffold integrates with other COMPs. The brief list of components is not enough to give an agent full operational context.

  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 20%, with only 'name' and 'parent_path' described. The description names high-level components that map loosely to parameters (scene maps -> scene_count, property maps -> property_count, approval policy -> approval_required, adapter source -> adapter_mode), but it doesn't explain default values, allowed enums, or relationships. The agent must infer parameter meanings from defaults and names, which is insufficient for a 10-parameter tool.

  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 action ('Create') and the resource ('Notion show-rundown scaffold') and lists specific components (scene maps, property maps, approval policy, adapter source, token-safety notes), making it distinguishable from generic 'connect' tools. However, it doesn't explicitly differentiate from related scaffold/creation tools in the sibling list, so it stops short of a 5.

  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 sibling scaffold/connect tools. No alternatives, exclusions, or prerequisite context are provided. The description merely states what it does, leaving the 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.

• connect_opcua_industrial_busB
  3/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds context about scaffold contents including safety-policy notes. However, it doesn't disclose what exactly gets created or modified (e.g., COMPs, node network) or any side effects beyond 'create', which is still vague 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, front-loaded sentence with no redundant words. It efficiently communicates the tool's purpose and primary inclusions, making it easy to scan.

  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 12 parameters, no output schema, and minimal schema descriptions, one sentence is insufficient. The description doesn't explain return values, expected behavior, or the relationship between parameters and the scaffold's functional parts, leaving an agent under-equipped to invoke the tool 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 17% (2 of 12 parameters have descriptions), and the description does not compensate by explaining key parameters like poll_ms, namespace_index, security_policy, or adapter_mode. It mentions high-level features like 'adapter ingest options' but provides no mapping to actual parameters or guidance on how to set them correctly.

  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 creates an OPC UA industrial telemetry scaffold and lists its contents (node maps, adapter ingest options, status tables, read-only safety-policy notes). This is a specific verb+resource combination that is easy to understand, though it doesn't explicitly distinguish itself from sibling connect_* tools in the same domain.

  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 only implies usage (when you need an OPC UA scaffold) but provides no explicit guidance on when to choose this tool over alternatives like connect_mqtt_iot_bus or connect_udp_telemetry_bridge. There are no exclusions, prerequisites, or alternative references.

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

• connect_parking_occupancy_busB
  3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the 'Create' action is consistent and non-destructive. The description adds that it builds a scaffold with certain components, but it does not explain potential side effects, idempotency, or what actually changes in the TouchDesigner network.

  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 verb and resource, then lists the scaffold components in a compact series. It contains no filler or repetition and is appropriately concise for a scaffold-creation tool.

  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 10 parameters, no output schema, and sparse annotations, the description is insufficiently complete. It gives a high-level component list but lacks usage context, alternative tool differentiation, and parameter semantics, leaving the agent without enough information to invoke the tool correctly for a complex scaffold.

  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 20% (only name and parent_path have descriptions). The description mentions concepts like 'adapter source' and 'sensor maps' but does not map them to the actual parameters, and it leaves active, capacity, provider, zone_count, adapter_url, adapter_mode, and sensor_count unexplained. It 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.

  Purpose4/5

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

  The description uses a specific verb 'Create' and names the resource 'parking/queue occupancy scaffold', listing components like zone occupancy, sensor maps, and signage policy. However, it does not explicitly distinguish this tool from sibling tools such as connect_queue_length_bus or connect_people_counting_bus, and 'parking/queue' introduces some ambiguity.

  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 offers no guidance on when to use this tool versus alternatives. Sibling tools include many similar connect_* bus creators, but the description never states why an agent should choose this one over connect_queue_length_bus or connect_people_counting_bus, nor does it mention conditions or exclusions.

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

• connect_websocket_control_busB
  3/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false, so the mutating but non-destructive behavior is already known. The description adds context by listing scaffold contents (command maps, message schema hints, status, safety notes), but no deeper behavioral details like permissions or side effects.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no unnecessary words. It immediately states the action and key output characteristics.

  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 8 parameters and no output schema, the description is too sparse. It does not clarify how the scaffold is created, what 'command maps' and 'safety notes' mean, or how the parameters affect the result. This is inadequate 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.

  Parameters2/5

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

  Schema description coverage is only 25%, and the description does not explain any of the 8 parameters. It mentions high-level scaffold features but adds no meaning to parameters like port, path, tls, active, net_address, or command_count. The description should compensate for low schema coverage but does not.

  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 creates a WebSocket DAT scaffold, which is a specific verb+resource. It slightly distinguishes from siblings by mentioning WebSocket and control bus, but does not explicitly contrast with other connection tools.

  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 on when to use this tool versus alternatives. The name implies WebSocket control bus usage, but there are no explicit exclusions or alternative tool references.

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

• create_mocap_stream_bridgeB
  3/5.0
  Behavior3/5

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

  Annotations already indicate a creation action (not read-only, not destructive), and the description adds the concept of a 'scaffold' with mapping surfaces, implying a network structure setup. However, it doesn't disclose side effects, external dependencies, or what the scaffold actually does beyond the vague mapping surface mention, which is a moderate 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, focused sentence that immediately conveys the action and scope using specific terminology. It contains no redundant words or filler, making it highly efficient for an agent to parse.

  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 9 parameters and no output schema, the description provides only a high-level overview. It fails to explain what a 'bus scaffold' entails in a TouchDesigner context, how the mapping surfaces are used, or how this tool compares to similar sibling tools, leaving the agent under-informed for correct invocation.

  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 low (22%), so the description was expected to compensate, but it only vaguely references 'joint and rigid-body mapping surfaces' without connecting these to specific parameters like skeleton_count or rigid_body_count. Parameter names and enums are somewhat self-explanatory, but nuanced aspects such as source_mode differences and coordinate_space implications are left unexplained.

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

  Purpose4/5

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

  The description clearly identifies the tool as creating a generic mocap bus scaffold with joint and rigid-body mapping surfaces, naming multiple supported systems (OptiTrack, Rokoko, Axis Studio, VRPN). It somewhat distinguishes itself from sibling tools like create_optitrack_tracking_bus by emphasizing 'generic' and multi-protocol, though it doesn't explicitly point to alternative tools.

  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 provides no guidance on when to use this tool versus the many sibling mocap bridge tools (e.g., create_optitrack_tracking_bus, connect_xsens_mvn_mocap). There are no exclusions, prerequisites, or preference indicators, leaving the agent without decision criteria for tool selection.

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

• create_scalable_display_busB
  3/5.0
  Behavior3/5

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

  Annotations already indicate non-read-only, non-destructive, and open-world behavior. The description adds context about the scaffold's contents (tile maps, status, calibration notes) but does not disclose potential side effects like overwriting existing nodes or relying on a config file. This is adequate 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, front-loaded sentence with no redundant words. Every word adds value, and it avoids repeating schema or annotation 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?

  For a tool that creates a complex scaffold with 7 parameters and no output schema, the description is too terse. It does not explain the config_file's role, the structure of the scaffold, or what the agent can expect as a result. Given the low schema coverage, more context is needed.

  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 43%, and the description does nothing to explain the undocumented parameters (active, canvas_width, canvas_height, display_count). It loosely relates 'display tile maps' to display_count/canvas dimensions but 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.

  Purpose4/5

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

  The description states a specific verb ('Create') and resource ('Scalable Display TOP scaffold'), and lists key components (display tile maps, status, calibration setup notes). This clearly distinguishes it from sibling tools like create_blacktrax_tracking_bus, though it could be more explicit about what the 'bus' entails.

  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 the many similar create_*_bus tools, nor any mention of prerequisites or alternatives. The description only states what it does, not when to choose it.

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

• create_vcv_rack_bridgeB
  3/5.0
  Behavior3/5

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

  The annotations already indicate non-read-only and non-destructive behavior. The description adds the 'scaffold' concept and mentions channel mapping/setup notes, but does not disclose potential side effects such as network port usage or external interactions, which would be valuable given the openWorldHint.

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

  Conciseness5/5

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

  The description is a single sentence of 15 words, front-loaded with the verb 'Create,' and contains no redundant or filler language. It is concise and to the point.

  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 10 parameters, no output schema, and low schema coverage, the description is far too sparse. It omits how the bridge works, what 'scaffold' entails, setup prerequisites, and parameter relationships, making it insufficient for confident invocation.

  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 20% (2/10 parameters documented). The description does not compensate by explaining parameter semantics; it only vaguely references 'channel mapping' without detailing how parameters like mode, send_port, or channel_count relate.

  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 it creates a VCV Rack bridge scaffold with specific modulation types (OSC/MIDI/CV) and includes channel mapping and setup notes. This distinguishes it from generic bridge tools, though it does not explicitly differentiate among sibling bridge-creation tools.

  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. It does not mention scenarios, prerequisites, or exclusions, leaving the agent without context for selecting it over similar bridge tools.

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

• connect_a1111_webui_bridgeB
  3.1/5.0
  Behavior3/5

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

  Annotations indicate a non-read-only, non-destructive, open-world operation. Description adds context by listing scaffold contents but does not disclose side effects like filesystem writes, component creation, or modifications to existing project structure. Some value beyond annotations but limited.

  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, no redundancy, immediately states the primary action and target. Every phrase carries meaning.

  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?

  Complex tool with 8 parameters, no output schema, minimal annotations; description omits parameter semantics, invocation context, and return behavior. Incomplete for correct usage.

  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 coverage is only 38%, and the description does not explain any parameters. Terms like prompt slots and ControlNet hints vaguely map to prompt_slot_count and include_controlnet, but no specific parameter meanings, defaults, or relationships are described.

  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?

  Description clearly specifies the verb 'Create' and the resource 'AUTOMATIC1111/Forge Stable Diffusion WebUI handoff scaffold', enumerating specific components (prompt slots, result maps, ControlNet hints, adapter notes). This uniquely identifies the tool among many connect_* bridge siblings by naming the target system.

  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 on when to use this tool vs alternatives. Does not specify prerequisites, use cases, or exclusions. Context only implied by name and title.

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

• connect_disguise_stageB
  3.1/5.0
  Behavior3/5

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

  The annotations declare readOnlyHint=false and openWorldHint=true, which is consistent with the description's 'Create' action. The description adds scaffold components (timeline, layer, approval maps) and protocols (HTTP, OSC), but does not disclose side effects like network listeners or project modifications. With annotations covering the safety profile, the added context is moderate 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 sentence that front-loads the primary action 'Create a disguise/d3 HTTP and OSC show-control scaffold'. It contains no filler or redundancy, and the length is appropriate for a high-level purpose. However, its brevity comes at the cost of detail, which is captured in other dimensions.

  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 8 parameters, no output schema, and an open-world annotation, the description is too minimal to fully orient an agent. It doesn't explain the scaffold's structure, what the returned result is, or how parameters like active, api_host, and osc_port are used. The description leaves significant gaps for a tool this complex.

  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% (just name and parent_path have descriptions), and the description does not explain any parameters. It mentions 'timeline, layer, and approval maps' but does not map them to parameters like timeline_count or layer_count, and there is no approval_map parameter. 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 creates a disguise/d3 HTTP and OSC show-control scaffold with timeline, layer, and approval maps, which is a specific verb+resource combination. It differentiates from sibling connect_* tools by naming the target system (disguise/d3) and the scaffold's components. The title is ambiguous but the description resolves it.

  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 provides no guidance on when to use this tool versus alternatives or any prerequisites. There is no mention of conditions for use, exclusion criteria, or references to sibling tools. The usage context is only implied by the tool name and the generic 'Create' action.

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

• connect_figma_design_tokensB
  3.1/5.0
  Behavior2/5

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

  The annotations already indicate the tool is a write operation with potential external side effects (readOnlyHint=false, openWorldHint=true). The description only lists scaffold contents and does not disclose operational behavior such as how it interacts with Figma, whether it requires authentication, or what gets modified outside the scaffold. It adds minimal behavioral insight 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.

  Conciseness4/5

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

  The description is a single, understandable sentence that leads with the action and resource. It lists key output elements without excess verbiage, though it is slightly dense with listing.

  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 reasonable overview of what the tool creates, but for a tool with 10 parameters and no output schema, it lacks context about the target environment (TouchDesigner), prerequisites, and how parameters affect the scaffold. It is adequate but has clear 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?

  With only 20% schema description coverage, the description should compensate by explaining parameters, but it does not. The listed scaffold components vaguely correspond to parameters like token_count and token_format, but no parameter is explicitly tied to the scaffold elements, leaving most of the 10 parameters unexplained.

  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 creates a Figma design-token scaffold and enumerates the specific components included (token rows, component-review rows, style preview metadata, adapter source, access-token safety notes). This distinguishes it from the many sibling tools by naming the exact resource and action.

  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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The intended use can be inferred from the resource name, but the text does not help the agent decide between this and other connect/create scaffolding tools.

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

• connect_power_meter_busB
  3.1/5.0
  Behavior2/5

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

  Beyond annotations, the description only mentions 'read-only meter readings' and 'electrical-control safety notes' as scaffold contents, but it does not disclose tool behavior such as side effects, overwriting of existing components, external network connections, or required setup. Given openWorldHint is true, more transparency about the adapter_url connection and scaffold creation side effects would be valuable.

  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, front-loaded with the action and resource, and includes a compact list of scaffold contents. No waste, easy to read.

  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 9 parameters and no output schema, the description is far too brief. It does not explain how the parameters affect the scaffold, what the resulting component looks like, or what the tool returns or modifies. Missing context likely leaves the agent uncertain about how to invoke 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 coverage is very low (only 22% of parameters have descriptions). The description loosely references 'circuit maps' and 'adapter source' which hint at circuit_count and adapter_url, but it fails to explain the semantics of most parameters like warning_kw, meter_count, venue_label, active, and adapter_mode. The description does not compensate for the missing schema descriptions.

  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 creates a 'power-meter telemetry scaffold' with a specific list of contents (read-only meter readings, circuit maps, adapter source, electrical-control safety notes). The verb 'Create' is specific and the resource is well-defined, distinguishing it from the many other 'connect_*' sibling tools by focusing on power-meter telemetry.

  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. It does not mention use cases, prerequisites, exclusions, or scenarios where a different connect tool would be more appropriate. The description only states what it does, not when to apply it.

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

• connect_reaper_transportB
  3.1/5.0
  Behavior2/5

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

  Annotations already indicate non-read-only, non-destructive, open-world behavior. The description adds the context that this creates a 'scaffold' rather than a live connection, which is useful, but it does not disclose side effects such as whether existing components are overwritten, whether REAPER must be running, or what 'operator-approved recording templates' actually entails.

  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 or redundant phrasing. It is concise and to the point, though 'operator-approved' is unexplained jargon.

  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 10-parameter tool with no output schema and sparse annotations, a one-sentence description is insufficient. It leaves out key behavior such as return values, error conditions, port/host semantics, how recording templates are selected, and whether this tool actually connects to REAPER or only creates a scaffold.

  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 20% of the 10 parameters have schema descriptions, and the tool description adds almost no parameter-specific meaning. It loosely aligns with track/marker counts but does not explain send_port, receive_port, reaper_host, include_record, project_name, or active.

  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 starts with a specific verb 'Create' and identifies a clear resource: a 'REAPER OSC transport, track, and marker bridge scaffold.' It clearly distinguishes this tool from the dozens of sibling connection tools by naming the exact target system and the scaffold components.

  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 provides no guidance on when to use this tool versus the many sibling connect_* tools, such as connect_ableton_link_session or connect_qlab_cue_stack. It does not mention prerequisites, exclusions, or when an alternative should be preferred.

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

• connect_uwb_anchor_busB
  3.1/5.0
  Behavior4/5

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

  The description adds meaningful behavioral context beyond annotations: it explicitly mentions 'sanitized tag positions' and 'tag-privacy notes', indicating the tool applies privacy sanitization and generates privacy-related documentation. This is more specific than the readOnly/destructive hints and aligns with them. It does not contradict annotations, though it stops short of detailing network side effects or idempotency.

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

  Conciseness4/5

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

  The description is a single, information-dense sentence that front-loads the core action ('Create a UWB RTLS scaffold') and then lists the key components. It avoids redundancy and is well-structured, though the use of jargon like 'sanitized' and 'spatial policy' slightly reduces immediate clarity.

  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 10 parameters, low schema coverage, and no output schema, the description is too high-level. It does not specify what the tool returns, how to configure the scaffold, or any prerequisites or side effects. The privacy-related context is useful but insufficient for an agent to invoke the tool correctly without additional guidance.

  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 only 20% schema description coverage, the description needed to clarify parameter meanings but does not. It loosely references concepts like 'anchor maps' and 'spatial policy' that might map to anchor_count or space_label, but it never explicitly links them or explains how to choose values for fields like tag_count, zone_count, adapter_mode, or position_units. The 10 parameters are left mostly unexplained.

  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 creates a UWB RTLS scaffold and enumerates its contents (sanitized tag positions, anchor maps, spatial policy, adapter source, tag-privacy notes), which distinguishes it from other tracking/bus tools. However, the title says 'Connect' while the description focuses on 'Create a scaffold', introducing mild ambiguity about whether it directly connects to hardware or just sets up the system.

  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. The description does not mention prerequisites, use cases, or contrast with sibling tools like create_optitrack_tracking_bus. Usage is only implied by the tool name and the scaffold elements listed.

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

• connect_wifi_presence_busB
  3.1/5.0
  Behavior4/5

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

  The description adds behavioral context by enumerating what the scaffold includes (aggregate occupancy rows, dwell buckets, etc.), going beyond the basic openWorldHint and readOnlyHint annotations. It correctly implies a create operation (matching openWorldHint true) with no destructive side effects. No contradictions found, but it does not mention side effects like existing node modifications or failure modes.

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

  Conciseness4/5

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

  The description is a single sentence that front-loads the action and resource, then lists key components. It is concise with no filler words. However, the list of components is dense and lacks expansion, making it efficient but potentially unclear without external context.

  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 9 parameters, no required fields, low schema coverage, and no output schema, the description is insufficient for an agent to understand how to customize the scaffold or predict its return value. The tool relies heavily on defaults, but the agent has no way to know which parameters matter for a given use case. The description does not explain parameter relationships, constraints, or what happens after creation.

  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 22% (2 of 9 parameters described). The description mentions concepts like 'dwell buckets' and 'adapter source' which map to parameters (dwell_bucket_count, adapter_url, adapter_mode), but it also introduces 'privacy policy' and 'device-privacy notes' that have no corresponding schema properties. It fails to explain most parameters (active, site_label, zone_count, parent_path, etc.) and does not compensate for the low schema coverage.

  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 it creates a Wi-Fi presence scaffold with specific components (aggregate occupancy rows, dwell buckets, privacy policy, adapter source, device-privacy notes). This distinguishes it from sibling tools like generic bus connectors. However, the tool title says 'Connect' while the description says 'Create', creating a minor verb mismatch that could confuse agents looking for connection tools.

  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 on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or scenarios where other tools (e.g., create_blacktrax_tracking_bus) would be more appropriate. The agent receives no context for choosing this over similar scaffold/connect tools.

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

• connect_youtube_live_chat_busB
  3.1/5.0
  Behavior3/5

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

  Annotations already signal a non-read-only, non-destructive write operation. The description adds detail about scaffold contents (e.g., moderation policy, API/quota safety notes) but does not disclose side effects like overwriting existing COMPs, need for YouTube API credentials, or rate limiting behavior. This is consistent with annotations but adds limited 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.

  Conciseness5/5

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

  The description is a single sentence that efficiently lists the key scaffold features. It is front-loaded with the verb 'Create' and contains no redundant phrases.

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

  Completeness3/5

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

  The tool has 10 parameters and no output schema, yet the description only offers a high-level component list. It omits configuration details (e.g., adapter_mode options, moderation_level semantics) and does not describe the resulting COMP structure or project impact, leaving gaps 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.

  Parameters2/5

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

  Schema description coverage is only 20%, and the description references components like 'sanitized message rows' and 'Super Chat tiers' without clarifying how they map to parameters such as message_count or super_chat_tier_count. The description does not explain parameter meanings, allowed values, or relationships, so the low schema coverage is not compensated.

  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 specific verb ('Create') and identifies a concrete resource ('YouTube Live Chat scaffold'), listing key components like sanitized message rows and Super Chat tiers. It is clear about the tool's goal, but does not explicitly distinguish it from the many similar scaffold/bus creation sibling tools.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool over alternatives. It does not mention prerequisites, scenarios, or exclusions. Usage is only implied by the tool name and component list.

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

• create_depthai_oak_pipelineB
  3.1/5.0
  Behavior3/5

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

  Annotations cover the not-read-only and not-destructive nature, and the description adds that it generates placeholders and hardware-gated notes. However, it does not disclose whether existing nodes might be modified, if a specific component selection is required, or what happens when hardware is absent.

  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?

  One focused sentence that front-loads the core purpose and lists key deliverables. No filler or redundancy.

  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 7 parameters, minimal schema descriptions, and no output schema, the tool needs richer context. The description provides only high-level scaffolding intent, not enough for an agent to confidently pass parameters or understand the generated structure.

  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 29% (2 of 7 params described), yet the description adds no meaning for key parameters like stream_count, include_depth, include_tracking, or device_name. It 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 it creates a DepthAI/OAK camera scaffold with specific components (OAK Device, OAK Select placeholders, stream maps, hardware-gated notes). This differentiates it from sibling tools like create_realsense_depth_bus or create_zed_depth_bus by identifying the exact hardware and scaffold elements.

  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 versus alternatives, prerequisites, or exclusions are provided. The description only states what the tool creates, leaving the agent to infer when to choose this over other camera/device scaffolding tools.

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

• create_unreal_livelink_bridgeB
  3.1/5.0
  Behavior3/5

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

  The description adds context beyond the annotations by mentioning that the scaffold includes subject maps, an event queue, and runtime setup warnings, which are not in the structured data. However, it does not disclose details about side effects, network modifications, or external dependencies. No contradiction with annotations exists.

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

  Conciseness5/5

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

  The description is a single, focused sentence that front-loads the core purpose and lists key features. It contains no redundant information and is well-structured.

  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's complexity (11 parameters, no output schema) and the rich context of sibling tools, the description is insufficient. It lacks information on how the scaffold integrates, what the different modes do, and any operational prerequisites. The absence of parameter explanations further reduces completeness.

  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?

  With schema description coverage of only 18%, the description needed to compensate by explaining parameter semantics, but it does not. It mentions high-level concepts like 'subject maps' and 'event queue' that do not map to any of the 11 schema properties, leaving most parameters 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 it creates an Unreal Engine Live Link/OSC/NDI handoff scaffold, with specific features like subject maps, event queue, and runtime setup warnings. This distinguishes it from sibling bridge tools by naming Unreal Engine and the protocols involved.

  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 provides no guidance on when to use this tool versus alternatives. It does not list any prerequisites, exclusions, or references to other bridge creation tools, leaving the agent to infer usage from the name and description alone.

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

• connect_ble_beacon_busB
  3.2/5.0
  Behavior3/5

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

  Annotations already convey readOnly=false and destructive=false. The description adds a concrete list of created scaffold elements, which goes beyond the schema. However, it does not disclose side effects such as whether existing components are overwritten, whether connections are established, or what 'device-privacy notes' implies behaviorally.

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

  Conciseness4/5

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

  The description is a single sentence that front-loads the core action and resource, then packs a list of included artifacts without wasted words. It is concise and easy to scan, though it could be structured more explicitly around inputs and outputs.

  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 10 parameters, no output schema, and minimal annotations, the one-sentence description is insufficient for reliable invocation. It omits usage context, return/result behavior, side-effect expectations, and detailed parameter semantics, leaving significant 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 description coverage is only 20%, so the description must compensate. It hints at mappings (zone maps -> zone_count, smoothing policy -> smoothing_window_sec, adapter source -> adapter_url/adapter_mode) but leaves several parameters (name, active, site_label, parent_path, etc.) unexplained and provides no defaults or constraints 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 uses a specific verb and resource: 'Create a BLE beacon proximity scaffold', and then enumerates its key components (sanitized beacon rows, zone maps, smoothing policy, adapter source, device-privacy notes). This clearly differentiates the tool from sibling tracking-bus creators by domain and artifact type.

  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 explicit guidance is provided on when to use this tool versus alternative tracking/scaffold tools. The phrase 'BLE beacon proximity' implies a context, but there are no exclusions, prerequisites, or mentions of sibling tools to help an agent choose this over a similar bus.

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

• connect_door_access_busB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds context about creating a scaffold with sanitized events and lock-control safety notes, aligning with open-world creation. However, it doesn't disclose whether it actually connects to a live door system, modifies existing nodes, or what side effects occur beyond creating a scaffold. No contradictions.

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

  Conciseness4/5

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

  The description is a single sentence with a clear verb and a compact list of scaffold components. It is concise without fluff, though the 'Connect' vs 'Create' inconsistency and vague list could be clearer. It earns its length, but slightly more structure would help.

  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 9 parameters, no output schema, and low description coverage, the description is too brief to be complete. It doesn't explain what the scaffold looks like, how parameters affect the output, or what the return value is. The high-level list of components gives some context but leaves significant gaps for a complex creation tool.

  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 22% (name and parent_path have descriptions). The description references 'adapter source' and 'door maps' but doesn't map them to specific parameters like adapter_url, adapter_mode, or door_count. It leaves event_count, policy_mode, venue_label, and active unexplained, failing 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 creates a door-access monitoring scaffold with specific elements (sanitized door events, door maps, adapter source, lock-control safety notes). This distinguishes it from numerous sibling bus tools. Minor inconsistency: title says 'Connect' while description says 'Create', but the intent 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?

  The description gives no explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare with other bus/scaffold tools. The door-access use case is implied by the name and description, but no clear context or alternatives are provided.

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

• connect_gtfs_transit_feedB
  3.2/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false and openWorldHint=true, implying the tool may create resources and interact with external data. The description adds that the scaffold includes an 'adapter source' and 'public-data notes', suggesting possible external data interactions, but it does not disclose specifics like network calls, file creation, or setup behaviors. With annotations covering the basic safety profile, the description provides modest additional 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 a single, efficient sentence with no fluff. It front-loads the main action and then lists key deliverables. It is appropriately concise, though a bit dense; a structured list could improve readability, but it earns its place.

  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 9 parameters, no output schema, and no nested objects, the description is too brief to cover important context such as return values, the nature of the 'adapter source', whether data is fetched live or simulated, or how the scaffold integrates with the existing network. The description does not explain what the final result looks like or how parameters influence it, leaving significant ambiguity for an agent selecting and configuring this tool.

  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 22% (2 of 9 parameters documented), and the tool description does not mention parameters at all. Parameter names like stop_count, route_count, and prediction_count are somewhat self-explanatory, but 'active', 'feed_mode', and 'adapter_url' lack meaningful context. The description lists output artifacts but does not map them to input parameters, leaving the agent to infer how each parameter affects the scaffold.

  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 action ('Create') and resource ('GTFS static/realtime transit scaffold'), listing concrete components (route maps, stop maps, arrival predictions, adapter source, public-data notes). This distinguishes it from siblings like connect_casparcg_server or create_data_source, as it is uniquely scoped to GTFS transit feeds.

  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, nor any mention of prerequisites, exclusions, or related tools. In a large sibling set of connect_* and create_* tools, the description does not help the agent decide when this is the right choice.

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

• connect_noise_level_busB
  3.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, which covers the safety profile. The description adds useful context about the scaffold's components but does not disclose operational behaviors such as network side effects, return values, or dependencies beyond the schema hints. This is adequate 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.

  Conciseness4/5

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

  The description is a single sentence that efficiently conveys the core purpose without wasted words. However, it could benefit from a brief mention of what the scaffold produces operationally, but it remains appropriately sized for the tool's simplicity.

  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 10 parameters, no output schema, and annotations that only cover safety, the description is incomplete. It does not explain what the scaffold actually creates (e.g., a COMP), how the parameters interact, or what the tool returns. The minimal description may be insufficient for an agent to use this tool correctly in a complex project.

  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 20%, so the description must compensate. It mentions 'aggregate decibel readings', 'sample windows', and 'adapter source', which loosely map to parameters like limit_db, sample_count, and adapter_url/mode, but it does not explain specific parameters such as weighting, zone_count, or venue_label. The description adds only vague semantic hints and fails to fully 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 uses a specific verb ('Create') and a clear resource ('noise-level telemetry scaffold'), and distinguishes itself from siblings by detailing the scaffold's contents (aggregate decibel readings, sample windows, adapter source, PA/safety policy notes). This makes the tool's purpose unmistakable.

  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 does not state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It only says what it creates, leaving the agent to infer the appropriate context from the name and description.

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

• connect_oscquery_namespaceB
  3.2/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, openWorldHint=true, which suggests creation is expected. The description adds that it creates an HTTP namespace and OSC send/receive scaffold, but does not disclose details like network port binding, cleanup behavior, or side effects on existing components. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is a single, concise sentence that front-loads the primary action and resource. It is efficient but omits important context, making it slightly too terse for a tool with 9 optional parameters.

  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 9 parameters, no output schema, and only basic annotations, the description lacks critical context. It does not explain what 'action maps' are, expected return behavior, or what the scaffold includes, leaving the agent without enough information to use the tool effectively.

  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?

  The input schema has 9 parameters with only 44% description coverage. The tool description does not mention any parameter names or meaning, failing to compensate for the schema's gaps. It provides no semantic value for parameters like http_port, action_count, or osc_send_port.

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

  Purpose5/5

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

  The description clearly states the action ('Create') and the resource ('OSCQuery HTTP namespace and OSC send/receive scaffold with action maps'). This distinguishes it from sibling tools like connect_vmix_production or create_touchosc_layout, which target different protocols or applications.

  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 'for live-control apps' implies a use case, but there is no explicit guidance on when to use this tool over other OSC/connect tools, nor any exclusions or alternatives. The usage context is only implied, not clarified.

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

• connect_people_counting_busB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate mutability (readOnlyHint=false) and non-destructive nature (destructiveHint=false). The description adds scaffold content context but does not disclose side effects like where the scaffold is created, whether it modifies the active project, or what the 'scaffold' implies operationally in TouchDesigner.

  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 one concise, front-loaded sentence that immediately states the action and result. It contains no filler and effectively conveys the primary purpose.

  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 9-parameter creation tool with no output schema, the description leaves significant gaps: it doesn't specify return value, where the scaffold is created, or its effect in the TouchDesigner environment. It also doesn't clarify what 'scaffold' entails beyond listing component categories.

  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 (22%), so the description must compensate. It maps key concepts (zone counts, sample windows, adapter source, privacy) to several parameters, but it doesn't explain parameters like active, venue_label, or parent_path beyond schema defaults, nor does it clarify constraints like zone_count max 128.

  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 it creates a people-counting scaffold with specific components (zone counts, sample windows, adapter source, privacy notes), distinguishing it from other bus/connect tools. However, the verb 'Create' mismatches the tool name 'connect', introducing slight ambiguity about whether it connects an existing bus or creates a new one.

  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 provides no guidance on when to use this tool versus alternative connectivity/scaffolding tools. It only states what it creates, with no context about prerequisites, typical use cases, or exclusions.

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

• connect_pos_sales_telemetryB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds context about the scaffold's contents, including privacy policy and PCI/PII safety notes, which is useful but does not disclose side effects such as where the scaffold is created or what files are modified. It does not contradict the annotations, and the added detail is moderate.

  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 uses a compact list to enumerate the scaffold's components. There is no redundant or filler text; every phrase contributes to understanding what the tool does.

  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 10 parameters, only 20% schema coverage, no output schema, and minimally descriptive annotations, the description is not sufficient for an agent to understand invocation details. It does not describe what the tool returns, how the scaffold is structured in the project, or how parameters influence the generated output. For a tool of this complexity, the description is too brief to ensure correct use.

  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 20% (only 2 of 10 parameters have descriptions), so the description has a low baseline to work from. It mentions 'revenue buckets' and 'adapter source' which loosely correspond to revenue_bucket_count and adapter_url/adapter_mode, but it does not explain the meaning or relationships of most parameters (e.g., store_label, aggregation_window, metric_count). The description only partially compensates for the sparse schema, leaving many parameters underspecified.

  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 ('Create a POS aggregate-telemetry scaffold') and identifies the resource ('POS sales telemetry'). It lists key components (sales metrics, revenue buckets, privacy policy, adapter source, PCI/PII safety notes) that distinguish it from sibling integration tools. However, the 'connect_' prefix is misleading since this is a creation/scaffold tool, and 'scaffold' could be more concretely defined.

  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 specifying the domain (POS sales telemetry), which differentiates it from sibling connect tools that target external services (e.g., connect_resolume_arena, connect_vmix_production). However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or conditions. The guidelines are inferred rather than explicit.

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

• connect_resolume_arenaB
  3.2/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and openWorldHint=true, which align with the description's 'Create' action. The description adds some behavioral context by listing scaffold components (command maps, status DATs, preview handoff notes) and noting that runtime validation against Resolume is explicit. However, it doesn't disclose side effects, prerequisites, or failure behavior beyond that.

  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, with two sentences and front-loaded purpose. The phrase 'Runtime validation against Resolume remains explicit' is somewhat cryptic but doesn't bloat the text. It earns a solid score for efficiency, though it could be clearer.

  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 11 parameters, no output schema, and open-world semantics, the description is under-specified. It names three output types without relating them to parameters or explaining the scaffold's structure. Missing prerequisites like whether Resolume must be running, and no details on validation behavior, leave the agent with insufficient context for correct invocation.

  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 45%, so the description should compensate for the undocumented parameters. It doesn't mention any of the 11 parameters (e.g., send_port, clip_count, preview_mode) or explain how they influence the scaffold. The description adds no parameter-level meaning beyond the sparse 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 the tool's purpose: 'Create a Resolume Arena/Avenue OSC control scaffold with command maps, status DATs, and preview handoff notes.' The verb 'Create' and specific resources distinguish it from siblings like connect_vdmx_workspace or scaffold_vj_deck.

  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 on when to use this tool or how it compares to alternatives. It doesn't mention cases like 'use this when connecting to Resolume' or exclude similar tools such as resolume_vdmx_output_chain. The description only defines the action, leaving usage context implicit.

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

• connect_touchengine_notchB
  3.2/5.0
  Behavior3/5

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

  The annotations already communicate that this is a mutating (readOnlyHint=false) but non-destructive (destructiveHint=false) operation. The description adds some behavioral context by mentioning NDI/Syphon fallback modes and 'explicit licensing/runtime warnings,' which are real scaffolds behaviors. However, it does not disclose side effects such as whether existing comps are overwritten, where objects are created, or what specific warnings are added, leaving meaningful gaps beyond what annotations provide.

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

  Conciseness4/5

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

  The description is a single sentence that front-loads the verb and object, then lists the key features without filler. It is dense and packed with multiple ideas, but it remains readable and efficient. It could be slightly better structured with separate clauses, but it earns a strong score for no wasted words.

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

  Completeness3/5

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

  Given 8 parameters, no output schema, and modest annotation coverage, the description provides a solid high-level summary of the tool's purpose and key features. However, it omits usage context, return behavior, prerequisites (e.g., licenses), and side-effect details, leaving notable gaps for an agent attempting to use the tool correctly in a real workflow.

  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 high (88%), so the baseline is 3. The description reinforces the mapping between high-level features and parameters (output TOP→output_name, control channels→control_channels, fallback modes→mode), but it adds no new syntax or format details. The undocumented parameters (mode, input_top_path) are not fully explained by either the schema or the description.

  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 action ('Create') and the resource ('TouchEngine/Notch bridge scaffold'), and it lists specific deliverables (stable output TOP, control channels, NDI/Syphon fallback modes, licensing/runtime warnings). However, it does not explicitly distinguish this tool from the sibling 'notch_touchengine_bridge' or other bridge-creation tools, so it falls just short of fully differentiating among similar options.

  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, nor any mention of prerequisites, exclusions, or fallback conditions beyond the feature names themselves. The only implied context is 'if you need this kind of scaffold,' which provides little help for an agent choosing among the many sibling connect/create tools.

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

• connect_webrtc_browser_inputB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and openWorldHint=true, so the mutation and external side effects are known. The description adds that it creates a 'scaffold' and that data is supplied by an external signaling app, but it does not disclose concrete side effects like adding a COMP at parent_path or attempting to connect to signaling_url. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is a single sentence with no filler, front-loaded with the verb 'Create' and the resource. It efficiently packs the key aspects: scaffold type, data sources, and the external signaling dependency, making it very 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 tool with 7 parameters and no output schema, the description is too thin. It does not explain what the tool returns, what 'scaffold' concretely entails, or prerequisites like browser-side setup. The external signaling app note is useful, but the description leaves too much to inference for an agent 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 29%, so the description must compensate. It clarifies input_mode by listing data types (webcam, screen, pointer, sensor) and indirectly references signaling_url, but it leaves active, room_id, include_data_channels, and name without meaningful explanation. The description adds partial value but is insufficient for several parameters.

  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 creates a browser/WebRTC input scaffold for webcam, screen, pointer, and sensor data. It uses a specific verb and resource, and the mention of 'external signaling app' adds scope. It does not explicitly distinguish from sibling tools like connect_video_stream_receiver, but the name and description are specific enough.

  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 when browser-based media input is needed, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The context about an external signaling app hints at a use case, but there is no direct comparison to other connect_* tools.

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

• connect_companion_surfaceB
  3.3/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds behavioral context by listing the components it creates and mentioning that target parameters are expression-bound, which is a side effect. However, it does not disclose whether existing expressions are overwritten or how reversible the changes are, though the non-destructive annotation mitigates this concern.

  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 primary purpose ('Build an OSC Companion-style button surface'). It uses a compact two-part structure that efficiently conveys the internal workflow and the mapping table purpose, with no wasted words.

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

  Completeness3/5

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

  The tool is moderately complex (7 parameters, nested objects) and has no output schema. The description explains the build process but does not mention what the function returns (e.g., the created baseCOMP path) or any follow-up steps. Given the openWorldHint and complexity, it would benefit from clarifying the output or return value.

  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 provides 100% coverage with descriptions for all 7 parameters, so the baseline is 3. The description adds some context by explaining how buttons and the mapping table are used, but it does not significantly enhance the parameter meaning beyond what the schema already provides.

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

  Purpose4/5

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

  The description clearly states the tool builds a Companion-style OSC button surface and outlines the internal structure (OSC In CHOP, Select CHOP/Null CHOP rows, expression binding, OSC Out CHOP, mapping table). However, it does not differentiate itself from the similarly named sibling tool 'create_companion_surface', which likely also creates a Companion surface, causing potential ambiguity.

  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 explicit guidance is provided on when to use this tool versus alternatives like 'create_companion_surface' or 'create_control_surface'. The description explains what it does but does not state prerequisites, exclusions, or contrasting use cases, leaving the agent to infer the appropriate context.

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

• connect_google_sheets_cue_tableB
  3.3/5.0
  Behavior3/5

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

  The description adds some behavioral context beyond annotations by mentioning 'OAuth/writeback safety notes,' which hints at authentication and write-safety implications not covered by readOnlyHint=false and openWorldHint=true. However, it does not provide concrete details about side effects, reversibility, or prerequisites, so the extra disclosure is limited.

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

  Conciseness5/5

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

  The description is a single, dense sentence that front-loads the core action and lists key components without unnecessary words. Every phrase adds value, and the structure is efficient and scannable.

  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's complexity (10 parameters, no output schema, sparse annotations), the description is far too high-level for an agent to invoke correctly. It does not explain what a 'scaffold' entails, what 'column validation' involves, or how the sync policy is configured. It also fails to distinguish itself from many similar creation tools in the sibling list, making the missing context critical.

  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 20%, and the description does not compensate by explaining any of the ten parameters. It mentions abstract concepts like 'source adapter' and 'sync policy' but does not map them to parameters such as adapter_mode or sync_direction, leaving the agent without meaningful parameter-level guidance.

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

  Purpose5/5

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

  The description uses a specific verb ('Create') and resource ('Google Sheets cue-table scaffold'), clearly distinguishing it from sibling connect_* tools that merely establish connections. It enumerates key deliverable components (source adapter, cue rows, column validation, sync policy, OAuth/writeback safety notes), making the tool's 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It does not reference sibling tools such as create_cue_sequencer or manage_cue, leaving the agent without a clear decision framework for selecting this tool.

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

• connect_huggingface_inference_bridgeB
  3.3/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds that it creates a scaffold with specific artifacts, which implies side effects, but it does not explain what gets created, where, or if external resources (e.g., Hugging Face API) are accessed. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is a single sentence that front-loads the core action ('Create a Hugging Face Inference Endpoint scaffold') and then lists the scaffold's components. No redundant words or excessive detail.

  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 8 parameters, no output schema, and minimal parameter descriptions, the description leaves significant unknowns: expected values for task/output_mode, the meaning of 'output contracts,' whether endpoint_url is required, and what the tool returns. It is not sufficient for reliable invocation.

  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% (2 of 8 parameters have descriptions). The description mentions 'task input maps' and 'token-env hints', loosely relating to task and token_env_name, but it does not clarify parameter meanings or how they should be set. It 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's function: 'Create a Hugging Face Inference Endpoint scaffold' and enumerates what it includes (task input maps, output contracts, token-env hints, adapter notes). This specific verb+resource combination distinguishes it from other connect/create tools in the sibling list.

  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 on when to use this tool versus alternatives. It does not state prerequisites, whether this is for initial setup or reconfiguration, or how it differs from other connect_* bridges. The description only implies usage through the tool name.

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

• connect_influxdb_timeseries_bridgeB
  3.3/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds context about token-safety warnings and adapter notes, which gives some behavioral insight. However, it omits side effects, permission requirements, or reversibility. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is a single, focused sentence that leads with the action verb and lists the key deliverables without redundant or extraneous wording.

  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 10 parameters, no output schema, and a nontrivial operation, the description is under-specified. It does not describe expected results, return values, prerequisites, or how the parameters collectively shape the scaffold. It also lacks integration guidance among the many similar tools.

  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 20% (2 of 10 parameters documented). The description mentions constructs like measurement maps and field maps that roughly relate to measurement_count, field_count, and adapter_mode, but it does not explain any parameter directly or compensate for the missing schema descriptions.

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

  Purpose5/5

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

  The description clearly states the action ('Create') and the resource ('InfluxDB telemetry scaffold') with specific components (measurement maps, field maps, query/write adapter notes, token-safety warnings). This distinguishes it from other connectors by explicitly targeting InfluxDB and its scaffold contents.

  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 offers no guidance on when to use this tool versus the many sibling connector/bridge tools. It does not state prerequisites, use cases, or recommend alternatives, leaving the agent to infer based solely on the name.

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

• connect_madmapper_surfaceB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and openWorldHint=true, so the agent knows this is a creation operation. The description adds that it creates a scaffold with handoff notes, but does not disclose side effects, prerequisites, or what the scaffold entails. Given the annotations cover the mutation aspect, this is adequate but minimal.

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

  Conciseness5/5

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

  The description is a single, focused 18-word sentence that is front-loaded and contains no filler. It conveys the essential purpose without redundancy.

  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 10 parameters, no output schema, and minimal annotations, the description is too terse to be complete. It doesn't explain what the scaffold will include, how to configure the handoff, or what the function returns. For a creation tool of this complexity, more context is needed.

  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 40% (4 of 10 params described). The description mentions OSC and Syphon/Spout/NDI handoff, which maps to handoff_mode and ports, but does not explain media_count, surface_count, active, or other parameters. It does not 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 specific action (Create) and resource (MadMapper OSC surface/media control scaffold), and adds detail about source handoff options (Syphon/Spout or NDI). This distinguishes it from sibling tools that connect to other software or create generic control surfaces.

  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 offers no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or reference any sibling tools, which is a gap given the large number of similar connect/create tools in the sibling list.

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

• connect_queue_length_busB
  3.3/5.0
  Behavior3/5

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

  Annotations already signal that this is a non-read-only, open-world operation. The description adds that the result is a scaffold with certain components, which is useful. However, it does not disclose side effects such as whether it opens a websocket connection, requires an external adapter, or modifies existing components, leaving much to inference.

  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, tightly worded sentence that front-loads the primary action and resource, then enumerates key included features without redundancy. Every phrase earns its place, and the structure is appropriately compact.

  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 9-parameter scaffold tool with no output schema, the description gives a high-level summary of the scaffold's contents but omits important context: prerequisites, connection behavior, and what exactly the scaffold does after creation. It is adequate for a simple builder but leaves gaps that an agent would need to resolve through defaults or assumptions.

  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 schema description coverage only at 22%, the description partially compensates by grouping parameters into conceptual categories (sample windows -> sample_count, adapter source -> adapter_url/adapter_mode, alert policy -> alert_threshold_people). However, it does not map all parameters (e.g., active, queue_count, queue_label) and leaves some ambiguity about their precise roles, so it adds moderate value beyond the sparse schema.

  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 action ('Create') and the resource ('queue-length scaffold'), and it lists the scaffold's key components (aggregate queue metrics, sample windows, adapter source, alert policy notes), giving a specific picture. It does not explicitly differentiate from sibling bus-connection tools, but the unique resource name and listed components make the purpose recognizable.

  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. It neither states typical use cases nor mentions related tools like connect_people_counting_bus or connect_parking_occupancy_bus. The description is purely about what the tool creates, so an agent must infer appropriate usage context from the tool name alone.

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

• connect_rfid_badge_busB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate the tool is not read-only and not destructive; the description adds that it 'creates a scaffold' and lists the scaffold's contents, which provides some context. However, it does not disclose side effects or specific behavioral traits such as project modifications, file generation, or configuration implications beyond the scaffold itself.

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

  Conciseness5/5

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

  The description is a single concise sentence that front-loads the primary action and enumerates the scaffold's contents without redundancy. It earns its place with every word.

  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 nine parameters, no required fields, and low schema coverage, a one-sentence description is insufficient. It does not address return values, how the scaffold is delivered, or any post-creation behavior, leaving the agent without crucial operational context.

  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 22%, and the description does not explicitly explain the meaning of the nine parameters. It lists components like 'sanitized badge events' and 'reader maps' which vaguely map to parameters, but offers no concrete guidance on parameter usage or defaults.

  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 creates an RFID badge-reader scaffold and enumerates key components (sanitized badge events, reader maps, privacy policy, adapter source, access control safety notes). This distinctive focus differentiates it from the many sibling connect/create tools.

  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 only states what it does, with no context about prerequisites, preferred scenarios, or exclusions.

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

• connect_twitch_eventsub_busB
  3.3/5.0
  Behavior3/5

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

  Annotations already establish readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the safety profile is known. The description adds a list of scaffold contents but does not disclose side effects, permission requirements, or what happens to existing components. This adds moderate context without contradiction.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently lists the scaffold's major components without wasted words. It is appropriately sized and clear.

  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 11 parameters, no output schema, and only 18% schema description coverage, the description leaves significant ambiguity. It does not explain parameters, return values, or operational context, making it incomplete for an AI agent to invoke the tool 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 18% (just name and parent_path). The description does not explain any of the 11 parameters, though it vaguely references 'reward maps' and 'moderation policy' that could map to reward_count and moderation_level. It 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 uses the specific verb 'Create' and identifies the resource as a 'Twitch EventSub/chat scaffold' with enumerated components (sanitized event rows, reward maps, moderation policy, adapter source, OAuth/webhook safety notes). This clearly distinguishes it from the many sibling connect_* bus tools and makes the tool's function 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 siblings like connect_youtube_live_chat_bus or connect_tiktok_live_events_bus. The description only states what it does, not when to choose it, and no alternatives or exclusions are mentioned.

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

• connect_weather_forecast_busB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate a non-read-only, non-destructive open-world operation. The description adds context about what the scaffold includes, which is useful, but it does not disclose side effects, generated structure details, or runtime behavior beyond listing component categories.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys the core purpose and key components without wasted words. It is appropriately sized for its role.

  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 10 parameters, no output schema, and minimal annotation context, this short description is insufficient. It does not explain the meaning of parent_path, active, provider, or count parameters, nor what the created scaffold will look like or how to verify success.

  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 only 20% schema description coverage, the description needed to compensate, but it does not mention any parameter names or map its component words to schema properties. The phrase 'forecast rows' hint at forecast_hour_count and 'adapter source' at adapter_url/adapter_mode, but this is too vague to guide correct values for the eight undocumented 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 a specific verb ('Create') and identifies a clear resource ('weather forecast/station scaffold') with enumerated components (forecast rows, sensor maps, alert maps, adapter source, safety-policy notes). This makes it distinct from broader 'create' and 'connect' siblings.

  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 the many similar bus/scaffold creation tools in the sibling list. There are no exclusions, prerequisites, or alternative tool references, leaving the 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.

• create_blender_scene_bridgeB
  3.3/5.0
  Behavior2/5

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

  Given the annotations already indicate this is a write operation (readOnlyHint false) with potential external effects (openWorldHint true), the description adds little behavioral context. It does not describe what the scaffold consists of (e.g., a baseCOMP, CHOP/DAT nodes, or external files), nor does it mention side effects or prerequisites. The description only restates the general purpose without elaborating on the actual behavior 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 front-loads the verb and resource. It includes the key scope (Blender-to-TouchDesigner handoff) and the three workflow modes with zero wasted words. 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?

  With 10 parameters, no output schema, and no nested objects, the description is far too minimal. It does not explain what a 'handoff scaffold' comprises, what the agent can expect after execution, or how the modes and parameters interact. The description provides only the high-level concept, leaving an agent without enough information to correctly configure or validate the tool's behavior.

  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 20% (2 of 10 parameters documented), so the description should compensate. It mentions 'file-watch, OSC, or WebSocket' which loosely maps to the handoff_mode enum, but it does not explain any of the other parameters (asset_format, sync_camera, receive_port, etc.) or how the workflows relate to the bridge's operation. This leaves the agent with little guidance for parameter selection.

  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 names a clear resource: a 'Blender-to-TouchDesigner scene handoff scaffold'. It also specifies the supported workflows (file-watch, OSC, or WebSocket metadata), which clearly distinguishes it from sibling bridge tools like create_unreal_livelink_bridge or create_shared_memory_bridge.

  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 use case by naming the integration (Blender-to-TouchDesigner) and the three handoff modes, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The context is present but not fully developed.

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

• create_monitor_layout_panelB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive write operation. The description adds that it creates a scaffold with specific parts, which gives some context about what actions it performs, though it doesn't disclose details about side effects, permissions, or network modifications.

  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 is front-loaded with the primary action ('Create a Monitors DAT inventory scaffold') and then lists the included components. Every word adds value, 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?

  The tool has 5 parameters, no output schema, and only a 40% schema description coverage. The description leaves significant gaps: it doesn't explain what a 'Monitors DAT inventory scaffold' is, what 'preflight checks' entail, or how parameters influence the result. The agent would likely be uncertain about expected behavior and output.

  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 40%; the description does mention 'monitor maps' and 'GPU maps' which loosely relate to monitor_count and gpu_count, but it doesn't explain parameter semantics such as what include_direct_display_hint does or how parent_path is used. 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's purpose: 'Create a Monitors DAT inventory scaffold' and lists specific components (monitor maps, GPU maps, preflight checks, setup notes). This specific verb+resource combination distinguishes it from sibling tools like create_control_panel or inspect_gpu_and_displays, which focus on different aspects.

  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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, contexts (e.g., when setting up multi-monitor systems), or scenarios where other tools would be more appropriate. No exclusions or alternative tool names are given.

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

• create_multitouch_panel_busB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and openWorldHint=true, so the description does not need to restate mutation or world creation. It adds context by mentioning the scaffold contains panel maps, touch-slot maps, and platform notes, which implies multi-component creation. However, it does not disclose potential side effects, required permissions, or interaction with existing networks, leaving some gaps.

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

  Conciseness5/5

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

  The description is a single, compact sentence that conveys the core purpose and key inclusions without any filler. It is well-structured and easy to parse.

  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 creates a scaffold with multiple components, yet the description is minimal. There is no output schema, so the description should explain what the scaffold looks like, what parameters control, and what the expected result is. It does not provide enough detail for a complex creation tool, especially given the large sibling list with similar names.

  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%, with only 'name' and 'parent_path' described. The description does not elaborate on any parameters or how they influence the scaffold. It mentions 'panel maps' which could relate to panel_count, but this is not explicit. 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's function: 'Create a Windows Multi Touch In DAT scaffold' with specific contents (panel maps, touch-slot maps, platform notes). This distinguishes it from sibling creation tools by naming the exact resource type and platform. The verb 'Create' is specific and the scope is clear.

  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 on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or related tools. The description only states what it does, leaving the agent to infer appropriate usage from the name and context.

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

• macro_recorderB
  3.3/5.0
  Behavior2/5

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

  Annotations indicate destructiveHint=true, but the description does not elaborate on what destructive behaviors may occur (e.g., overwriting files or stopping recordings). It adds actions and the JSON format, but no behavioral details about side effects, safety of stop/load, or handling of sensitive data. The description contradicts no annotations, but fails to add meaningful transparency beyond the flags.

  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 core purpose, and lists actions efficiently. It adds a pointer to the replay tool without fluff, earning a high score.

  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 five parameters and four actions plus destructive hints, the description is insufficiently complete. It lacks parameter meanings, action-specific behavior, and side-effect warnings. The absence of an output schema further increases the need for explanation, which is not met.

  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 20%, so the description must compensate, but it does not explain parameters like file, name, or redactSensitive. The action enum is self-explanatory and allowUnsafeRecording has a schema description, but the rest remain ambiguous, making it hard to invoke correctly.

  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 records MCP tool calls to a JSON macro file, listing specific actions (start/stop/list/load). It distinguishes from sibling run_macro_script by noting replay ships separately. This is a specific verb+resource scope.

  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?

  It provides clear context that this is for recording macros and points to run_macro_script as the replay alternative. However, it does not explicitly state when not to use this tool or compare to other macro-related tools like create_macro, so exclusions are absent.

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

• connect_blackmagic_atemB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate this is not read-only and not destructive, and the description adds useful context about creating placeholders and maps. However, it does not disclose potential side effects like overwriting existing components or whether network access is required, which would enhance transparency beyond annotations.

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

  Conciseness4/5

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

  The description is a single sentence that packs substantial detail without excessive verbosity. It could be more structured (e.g., separated into two sentences) but remains efficient and front-loaded with the core purpose.

  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 9 parameters, no output schema, and no mention of return values or prerequisites, the description is incomplete for a tool of this complexity. It does not state what the scaffold will include in relation to the parameters or what the agent should expect after invocation, leaving significant 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 description coverage is only 33%, and the tool description does not compensate by explaining individual parameters. While some parameter names are self-explanatory, ambiguous ones like 'include_cut_auto' and 'active' remain undocumented, providing minimal guidance for agents.

  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 creates a Blackmagic ATEM command-map scaffold, specifying the verb 'Create' and the resource. It distinguishes itself from sibling tools like 'atem_switcher_control' by noting it builds a scaffold with placeholders, input maps, macro maps, and operator approval notes.

  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 initial scaffolding rather than direct control, but it does not explicitly state when to use it versus alternatives. No alternatives or exclusions are mentioned, leaving the agent to infer the intended context from the tool name and sibling list.

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

• connect_homeassistant_state_busB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare the tool as non-read-only, non-destructive, and open-world. The description adds that it creates a scaffold with specific components and includes safety notes, but it does not disclose side effects, authentication requirements, or what happens if the scaffold already exists. Some value is added beyond annotations, but depth is limited.

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

  Conciseness4/5

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

  The description is a single sentence that is front-loaded with the core action and target, containing no filler or redundant details. It efficiently conveys the high-level purpose, though it sacrifices depth for brevity.

  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 9 parameters, no output schema, and no return-value documentation, the description is too sparse. It lists scaffold components but does not explain what the tool returns, prerequisites like a reachable Home Assistant instance, or how the scaffold integrates with the existing project. The description leaves significant gaps for an agent trying to invoke the tool 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 22% (2 of 9 parameters have descriptions). The description hints at adapter_mode via 'REST/WebSocket adapter nodes' but does not explain the meaning of any parameters, their defaults, or how they relate to the scaffold. It 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 action ('Create') and the specific resource ('Home Assistant state/service scaffold'), and details the scaffold's components (REST/WebSocket adapter nodes, entity maps, service maps, safety notes). This distinguishes it from sibling connect_* tools that target other systems like MQTT or serial devices.

  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 intended use is implied by the name and description (connecting to Home Assistant), but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The description does not say 'Use this when...' or 'For other integrations, use...'.

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

• connect_rss_feed_busB
  3.4/5.0
  Behavior3/5

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

  Annotations already set readOnly=false and destructive=false, indicating a non-destructive write operation. The description adds some context by enumerating scaffold contents (sanitized rows, category maps, refresh policy, adapter source, copyright notes), but it does not disclose side effects, required environment, or return behavior. This partial addition warrants a middle score.

  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 action and resource, then efficiently lists key components. Every word contributes to the understanding, and there is no wasted verbiage.

  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 9 parameters, no output schema, and minimal annotations, the description is too sparse. It does not mention return values, how to observe the created scaffold, prerequisites, or how it fits into the broader system. The lack of this information makes it incomplete for a tool of this complexity.

  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 (22%), so the description must compensate. It hints at parameter meanings through phrases like 'refresh policy' (refresh_interval_sec), 'adapter source' (adapter_url/adapter_mode), and 'category maps' (category_count), but leaves many parameters (active, feed_label, item_count) unexplained. It adds some meaning but not enough for a 9-parameter tool.

  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 it creates an RSS/Atom/editorial feed scaffold, specifying both the verb (Create) and the resource (feed scaffold). It lists several distinctive features such as sanitized item rows, category maps, and refresh policy, which distinguishes it from other connect_* tools in the sibling list.

  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 provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions, prerequisites, or context. It simply states what the tool creates, leaving the user without criteria for selecting it.

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

• create_blacktrax_tracking_busB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's 'Create' is consistent. The description adds context by listing the components created (receiver, trackable maps, etc.), but it does not elaborate on side effects like network modifications or whether it overwrites existing components. This is adequate 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, directly worded sentence. It is front-loaded with the action and resource, and every word contributes to the meaning. No fluff or redundancy.

  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 conveys the core purpose and components, but for a tool with 6 parameters and no output schema, it is thin. It does not explain what the tool returns (e.g., created COMP path) or how parameters like counts and port affect the scaffold. More detail would be needed for a complete picture.

  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% (two of six parameters have descriptions). The description provides zero information about parameters like port, active, zone_count, or trackable_count. Since low schema coverage requires the description to compensate, and it does not, parameter semantics fail to add value.

  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') and a specific resource ('BlackTrax tracking scaffold') and details the key components it will include (receiver, trackable maps, zone maps, calibration notes). This clearly distinguishes it from sibling tools like create_optitrack_tracking_bus or create_ncam_camera_tracking_bus.

  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: if you need a BlackTrax tracking setup, this tool creates the scaffold. However, it does not explicitly state when to use it over alternatives (e.g., other tracking bus tools), nor does it mention any prerequisites or exclusions.

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

• create_optitrack_tracking_busB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate mutation and non-destructive intent. The description adds that it builds a scaffold with specific parts, but does not disclose side effects like number of nodes created, collision behavior, or external system dependencies.

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

  Conciseness5/5

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

  The description is a single, direct sentence with no filler. It efficiently communicates the tool's scope while listing the critical scaffold components.

  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 return behavior is unexplained. The description gives a high-level overview but lacks details on the scaffold's structure, node hierarchy, or post-creation configuration. Adequate for initial selection but not for full operational understanding.

  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 2 of 8 parameters are described in the schema (25% coverage). The description vaguely references concepts like rigid-body maps and marker maps but does not explain parameters such as data_port, server_address, or marker_count, leaving most settings underspecified.

  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 specifies a concrete resource (OptiTrack/NatNet tracking scaffold) and enumerates its key components (receiver, rigid-body maps, marker maps, calibration notes). This clearly differentiates it from sibling tools like create_blacktrax_tracking_bus.

  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 create_blacktrax_tracking_bus or create_ncam_camera_tracking_bus. There is no mention of prerequisites, integration scenarios, or exclusions.

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

• create_zed_depth_busB
  3.4/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, aligning with the 'Create' action. The description adds the behavioral detail of 'runtime-gated warnings,' which is beyond the annotations, but it does not explain what conditions gate the warnings or what consequences the scaffold creation may have. No contradiction exists.

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

  Conciseness4/5

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

  The description is a single sentence with no filler, front-loading the action and resource. However, it relies on domain jargon ('TOP/CHOP/SOP placeholders') that may confuse users, slightly reducing clarity without adding 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?

  With 7 parameters and no output schema, the description is too sparse to fully contextualize the tool's behavior, parameter relationships, or the nature of the runtime warnings. It does not explain what the scaffold contains, how it is used, or why a user would invoke this tool over simpler alternatives.

  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 29% (only 'name' and 'parent_path' have descriptions), and the tool description provides zero parameter-level explanations. Parameters like 'body_count', 'stream_count', and 'include_pointcloud' remain ambiguous, and the description does not bridge the gap left by the sparse schema descriptions.

  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: 'ZED camera depth/body/point-cloud scaffold.' It also mentions ZED TOP/CHOP/SOP placeholders and runtime-gated warnings, which distinctly identifies the tool's function and separates it from similar depth-bus creation tools for other cameras (e.g., realsense, azure_kinect).

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

  Usage Guidelines3/5

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

  The description implies usage for creating a ZED-based depth/body/point-cloud scaffold, but it does not explicitly state when to prefer this tool over alternatives or provide any exclusions. The context from sibling tools suggests a family of camera bus creators, yet the description offers no guidance on selection criteria.

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

• generative_classics_packB
  3.4/5.0
  Behavior3/5

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

  The description discloses that list_only=false writes a portable bundle JSON at install_path, and the overwrite parameter in the schema indicates potential file replacement. This aligns with the destructiveHint annotation. However, the description does not go beyond the schema to warn about side effects or clarify the impact on the active library, so it adds moderate value 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.

  Conciseness4/5

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

  The description is two sentences with a clear front-loaded purpose. It lists examples that aid understanding and includes essential behavioral details without excessive verbosity. The structure is efficient and easy to scan 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?

  The description provides a good overview of inputs and outputs, mentions compatibility with import_recipe_bundle, and notes the Node-only requirement. However, it does not explain what 'active library' means, nor does it detail the contents or structure of the bundle, which could be relevant for a destructive operation. Given the tool's moderate complexity and absence of an output schema, it is adequate but has gaps.

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

  Parameters3/5

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

  Schema coverage is 100%, so the parameters are already well documented. The description reinforces the list_only behavior and mentions the bundle format is import_recipe_bundle-compatible, but it does not add significant new meaning about the parameters themselves. This matches the baseline for high schema coverage.

  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 this tool provides a curated pack of canonical generative looks, listing specific examples. It distinguishes itself from sibling tools by focusing on a pack/bundle rather than creating individual effects. The list_only vs. write bundle behavior is described, making the tool's function 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 Guidelines3/5

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

  The description implies when to use this tool (when you want a curated collection of generative techniques) and provides a key technical constraint ('Pure Node — no TouchDesigner bridge required'). However, it does not explicitly name alternatives or state when NOT to use this tool, relying on the agent to infer from context.

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

• connect_ableton_link_sessionA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate readOnly=false, openWorld=true, and destructive=false, and the description's 'Create' aligns with these. However, the description adds no extra behavioral context such as side effects, required external connections, or what specifically is generated. It does not contradict the annotations, but also does not go beyond them.

  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 one short sentence that gets straight to the point. No filler, no redundancy, and the main action is front-loaded. It earns high marks for conciseness.

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

  Completeness2/5

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

  Despite having 7 parameters, no output schema, and moderate annotation coverage, the description provides only a one-line purpose. It omits information about what the scaffold includes, how parameters interact, expected return, and when to use it. The combination of low schema coverage and brief description leaves significant 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?

  With only 29% schema description coverage (2 of 7 parameters described), the description needed to compensate but does not. It only vaguely hints at 'beat/bar maps' which loosely relates to signature and tempo, but provides no clarification for parameters like active, export_bars, or start_stop_sync. The agent is left without enough meaning for correct invocation.

  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 action ('Create'), a target resource ('Ableton Link timing scaffold'), and a purpose ('tempo-locked visual systems'). This distinguishes it from generic sync tools like create_tempo_sync or sync_external_clock, and is not a tautology of the tool name.

  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 'for tempo-locked visual systems' implies a use case, but the description does not explicitly say when to use this tool over alternatives, nor does it mention prerequisites or exclusions. No sibling tool is referenced, so the agent must infer context from the name.

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

• connect_airtable_content_busA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate non-readOnly and openWorld behavior, so the description is not required to restate that. It does add 'token/rate-limit safety notes' as a scaffold component, which is extra context. However, it doesn't detail actual side effects (e.g., external Airtable access, local file creation) beyond what annotations imply.

  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 or redundancy. Every phrase adds information about what the scaffold includes, making it appropriately concise for the purpose.

  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 11 parameters, no output schema, and only 18% schema coverage, a one-sentence description is insufficient. It lacks prerequisites, expected outputs, and clarification of what 'content scaffold' actually entails, leaving significant gaps for an agent to select and invoke the tool 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 18%, and the description provides no parameter-level explanations. It references high-level components like 'record maps' and 'sync policy' but never connects them to the 11 parameters (e.g., base_id, sync_direction), so it 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 uses a specific verb 'Create' and identifies the resource as 'Airtable content scaffold' with explicit deliverables (record maps, field maps, sync policy, adapter source, and token/rate-limit safety notes). This clearly differentiates it from generic 'connect' sibling tools and states a clear 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?

  Usage context is implied by the name and description ('create an Airtable content scaffold'), but there is no explicit guidance on when to use this tool versus alternatives, nor any when-not-to-use exclusions. The description says what it does but not when to choose it.

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

• connect_arkit_face_captureA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate this is a mutating operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it creates a scaffold with OSC maps, but does not disclose side effects like network changes or dependencies. This is adequate 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, focused sentence that front-loads the verb and essential details. It contains zero filler words and earns its place.

  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 7 parameters, no output schema, and only 29% schema description coverage, the description does not provide enough context about what the scaffold includes, how parameters affect the result, or what the output looks like. It is too sparse for a tool of 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 description coverage is only 29%, so the description must compensate for lack of parameter documentation. It vaguely references 'blendshape and head-transform maps' but does not explain key parameters like face_count, receive_port, active, or name. The description adds little beyond the schema fields.

  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') and resource ('ARKit Face Capture OSC scaffold') with concrete details (blendshape and head-transform maps, iPhone-driven). This clearly distinguishes it from siblings like setup_face_tracking, making the purpose unmistakable.

  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 'for iPhone-driven facial performance' implies the intended use case, but there is no explicit statement of when to use this tool versus alternatives, nor any exclusions or prerequisites. Context is clear but guidance is minimal.

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

• connect_kafka_event_busA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and openWorldHint=true, indicating mutation and external side effects. The description adds that this creates a scaffold with certain elements, but it doesn't disclose concrete behaviors such as creating a base COMP under parent_path, whether a broker connection is required at creation time, or any side effects on existing components. No contradiction with annotations exists.

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

  Conciseness4/5

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

  The description is a single dense sentence with a front-loaded purpose and no filler. It efficiently covers the core deliverable and included features, though terms like 'policy-gated producer notes' add jargon without explanation, so it is not perfect.

  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 10 parameters (all optional), no output schema, and a variety of sibling tools, the description is too sparse for an agent to fully understand the tool's scope. It omits prerequisites (e.g., whether parent_path must exist), behavior details, return values, and how the scaffold is materialized, leaving significant ambiguity for a complex scaffolding 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?

  Only 5 of the 10 parameters have schema descriptions (50% coverage). The description provides thematic hints that map to parameters — 'adapter ingest' suggests adapter_mode, 'topic maps' suggests topic_root/topic_count, 'schema hints' suggests schema_format, and 'consumer group metadata' suggests consumer_group — but it doesn't explicitly name or explain these parameters, leaving the agent to infer the mapping. This is partial compensation but not comprehensive.

  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 specifies the verb ('Create') and the resource ('Kafka/Redpanda event-bus scaffold') and lists specific components (adapter ingest, topic maps, schema hints, consumer group metadata, policy-gated producer notes). This distinguishes it from sibling connect_* and create_* tools, especially other event-bus integrations like MQTT or Redis.

  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 use case is implied by the phrase 'Create a Kafka/Redpanda event-bus scaffold' — it is for scaffolding a Kafka/Redpanda event bus, not for connecting an existing one. However, there is no explicit when-to-use statement, no mention of alternatives, and no exclusions, so guidance about selecting this over sibling tools is underdeveloped.

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

• connect_max_msp_bridgeA
  3.5/5.0
  Behavior3/5

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

  Annotations already disclose readOnlyHint=false, openWorldHint=true, and destructiveHint=false, and the description does not contradict these. The description adds that it creates a scaffold with channel maps, which is useful, but it does not detail side effects such as where the scaffold is created, whether existing components are modified, or network/port implications. It provides basic transparency but lacks 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 a single sentence with a clear verb and object, no redundant wording, and gets straight to the point. It is compact and easy to scan, which is ideal for an agent evaluating tool options.

  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 9 parameters, no output schema, and a complex operation (creating a scaffold), this one-sentence description is too sparse. It omits critical details about what exactly is created, where (parent_path), how ports are used, and what constitutes the channel maps. An agent would not fully understand the tool's behavior or prerequisites from the description alone.

  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 44%, with 5 of 9 parameters lacking descriptions. The description mentions parameter and audio-feature channel maps, hinting at include_audio_features and channel_count, but it does not explain send_port, receive_port, active, parent_path, or other fields. This insufficiently compensates 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 uses a specific verb 'Create' and names a concrete resource: 'Max/MSP OSC bridge scaffold' with 'parameter and audio-feature channel maps.' This clearly distinguishes it from sibling bridge tools like connect_unity_osc_bridge or connect_vmix_production by targeting a specific system and purpose.

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

  Usage Guidelines3/5

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

  No explicit guidance on when to use this tool versus alternatives such as connect_unity_osc_bridge or connect_resolume_arena. The name and description imply it is for Max/MSP integration, but there is no stated context, exclusions, or comparison to other tools. Usage is inferred rather than explained.

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

• connect_millumin_showA
  3.5/5.0
  Behavior3/5

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

  Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) already cover safety and mutability. The description adds that the tool creates command maps and setup notes, but does not disclose additional behavioral traits like side effects or prerequisites. No contradiction exists, and the description supplements annotations minimally.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that communicates the action, target, and key deliverables without wasted words. It is appropriately sized for the information provided.

  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 9 parameters and no output schema, the description is too sparse. It does not clarify what the scaffold contains, how command maps function, or what setup notes cover, leaving the agent without sufficient understanding of the tool's output and behavior.

  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% (3 of 9 parameters have inline descriptions), and the tool description does not explain any parameter meanings. It fails to compensate for the low coverage, leaving layer_count, ports, and other fields without added context.

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

  Purpose5/5

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

  The description clearly states the tool's action ('Create') and the specific resource (Millumin OSC layer, column, dashboard control scaffold), adding details like command maps and setup notes. This distinctly separates it from sibling connect_* tools by naming Millumin and the scaffold elements.

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

  Usage Guidelines3/5

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

  The description implies use for creating a Millumin OSC scaffold, but it does not explicitly state when to use it or mention alternatives. No exclusions or comparisons to other connectivity tools are provided, leaving context-dependent usage unaddressed.

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

• connect_tuio_touch_surfaceA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's mention of 'create' is consistent and adds that it produces a scaffold with specific components. However, it does not disclose side effects (e.g., whether existing nodes are overwritten) or setup prerequisites, leaving the description to carry minimal added 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.

  Conciseness5/5

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

  This is a single, front-loaded sentence that efficiently communicates the tool's essence without wasted words. It lists the key components and the optional raw OSC feature, making it both concise and informative.

  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 sufficient for a simple scaffold-creation tool. It identifies the components and parameters but does not explain the purpose of the TUIO DAT or maps in a broader TouchDesigner context, nor any post-creation steps. Given no output schema, this is adequate but could be richer.

  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 only 29%, so the description needs to compensate. It does by mapping 'optional raw OSC' to include_raw_osc, 'cursor maps' to cursor_count, and 'surface maps' to surface_count. However, listen_port, active, and parent_path are not elaborated, though they are relatively self-explanatory. The description partially compensates for the low coverage.

  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 creates a TUIO touch-surface scaffold and lists the components included (TUIO DAT, optional raw OSC, cursor maps, surface maps). This distinguishes it from other connect/create tools for different protocols or touch surfaces.

  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 setting up a TUIO touch surface but does not explicitly state when to use this tool vs. alternatives or any exclusions. Given the large number of sibling tools, this lack of explicit guidance is a notable gap.

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

• connect_udp_telemetry_bridgeA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, which the description does not contradict. The description adds minimal context beyond the annotations, noting it creates a 'scaffold' and listing the intended data categories (packets, replies, status maps, diagnostics), but does not detail side effects, permissions, or lifecycle behavior.

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

  Conciseness5/5

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

  The description is a single, focused sentence that starts with the action verb 'Create' and directly states the object and scope. It contains no filler or redundant information, earning full marks for conciseness.

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

  Completeness2/5

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

  With 7 parameters, low schema coverage, and no output schema, the description is too thin to fully equip an agent. It does not explain what the resulting scaffold looks like, how parameters affect the outcome, what success/failure returns, or any prerequisites. The description is adequate for a high-level overview but insufficient for safe and correct invocation.

  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 29% (only 'name' and 'parent_path' have descriptions). The tool description does not explain any of the seven parameters, such as listen_port, remote_port, packet_count, or active, nor how they relate to the UDP scaffold. This is a significant gap for a 7-parameter tool.

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

  Purpose5/5

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

  The description clearly states the tool's action: 'Create a UDP In/Out DAT scaffold' for telemetry-related data. It distinguishes itself from sibling bridge tools by specifying the UDP protocol and telemetry purpose, making it unmistakable among many connect_* alternatives.

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

  Usage Guidelines3/5

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

  The description implies use for setting up a UDP telemetry bridge scaffold, but provides no explicit guidance on when to prefer this tool over other bridge/connect tools (e.g., connect_oscquery_namespace or connect_websocket_control_bus). No exclusions or alternative recommendations are mentioned.

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

• connect_unity_osc_bridgeA
  3.5/5.0
  Behavior3/5

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

  With annotations indicating openWorldHint=true and destructiveHint=false, the description adds some context by specifying it creates a scaffold for transforms, events, and NDI/Syphon notes. However, it does not disclose what a 'preview handoff' entails, whether it creates a COMP in the network, or any side effects beyond the creation.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that clearly communicates the core action and purpose. It contains no redundant or filler words, making it concise and easy to parse.

  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 10 parameters and no output schema, the description is too terse to be complete. It does not explain the overall workflow, what the scaffold consists of, how preview handoff works, or any prerequisites. An agent would need significant additional information to invoke this tool correctly for real-world scenarios.

  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 20%, and the description barely compensates. It only hints at parameters like object_count, event_count, and preview_mode through 'object transforms, events, and NDI/Syphon notes', but does not explain send_port, receive_port, namespace, active, etc. The description adds minimal value beyond the schema, leaving most parameters under-documented.

  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 creates a Unity OSC bridge scaffold, specifically mentioning object transforms, events, and NDI/Syphon preview handoff. This distinguishes it from sibling bridge tools like those for Unreal or other external systems, 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 tool's usage is implied by its name and description: it is for connecting to Unity via OSC with preview support. However, it does not explicitly state when to use this versus alternative bridge tools (e.g., Unreal LiveLink) nor any prerequisites like running Unity, which would be helpful given the large set of sibling bridge creators.

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

• connect_vdmx_workspaceA
  3.5/5.0
  Behavior3/5

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

  The description states that it creates a scaffold with specific maps, which adds some context beyond the annotations. However, it does not disclose potential side effects such as adding nodes to the network, requiring a running VDMX instance, or what 'setup maps' entail. The openWorldHint signals external effects, but the description could be richer.

  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 action and resource. Every word contributes meaning without waste, making it easy 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?

  For a tool with 9 parameters and no output schema, the description is too sparse. It does not explain return values, prerequisites, or the structure of the scaffold. The agent lacks guidance on how the scaffold is laid out, what maps are created, or how the parameters influence the result, making it incomplete for complex usage.

  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 only 22% schema description coverage, the description must compensate for undocumented parameters. It only vaguely references 'layer, clip, preview' which can map to layer_count, clip_count, and preview_mode, but it does not explain critical parameters like send_port, receive_port, vdmx_host, or parent_path. This adds minimal value over the raw 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 uses the specific verb 'Create' with a clear resource: 'VDMX OSC/Syphon workspace scaffold' and lists key components (layer, clip, preview, setup maps). This clearly identifies the tool's function and distinguishes it from sibling integration tools by explicitly naming VDMX and its scaffold components.

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

  Usage Guidelines3/5

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

  The description implies usage for creating a new VDMX workspace scaffold, but it does not explicitly state when to use this tool versus alternatives like connect_resolume_arena or connect_oscquery_namespace. No prerequisites or exclusions are mentioned, leaving the agent to infer from the name and context.

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

• connect_vmix_productionA
  3.5/5.0
  Behavior3/5

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

  Annotations already convey readOnlyHint=false and destructiveHint=false, so the agent knows it is a mutating but non-destructive operation. The description adds that it creates a scaffold of command templates, but does not disclose side effects, prerequisites, or what the scaffold entails. The openWorldHint=true and mention of HTTP/API imply external interaction, but without detail.

  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 is front-loaded with the primary action and succinctly enumerates key features. It contains no fluff or redundancy.

  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 8 optional parameters and no output schema, the description is too thin. It does not explain what 'scaffold' means, what result the user should expect, or any setup requirements. More context about the tool's creation behavior and return value is needed to be 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?

  Schema description coverage is low (25%), so the description should compensate for undocumented parameters. It loosely maps capabilities (input switching, overlays, recording, streaming) to some parameters (input_count, overlay_count, include_record_stream), but it does not clarify important parameters like api_port, vmix_host, active, or parent_path. This is minimal compensation.

  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'), names the resource ('vMix HTTP/API production-control scaffold'), and lists the key capabilities (input switching, overlays, recording, streaming command templates). This clearly distinguishes it from sibling connect_* tools targeting other systems.

  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?

  There is no explicit guidance on when to use this tool versus alternatives. The purpose implies usage for vMix production control, but no clear context for selection is provided, and alternative tools are not referenced.

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

• create_artnet_discovery_panelA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false, destructiveHint=false). The description adds the concept of a 'scaffold' with optional components, but does not disclose behaviors like whether existing components are modified or if network/hardware access is required. No contradiction with annotations.

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

  Conciseness5/5

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

  A single sentence with no filler, front-loading the core action and artifact. Every word adds meaning.

  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 8 parameters and no output schema, the description fails to explain what the scaffold contains, how the parameters interact, or what the tool returns. It is sufficient only as a high-level intent cue, not as a complete operational guide.

  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 has only 25% description coverage, yet the description provides no parameter explanations. It mentions 'DMX In monitor, device maps, and universe maps,' which loosely correspond to include_dmx_monitor, device_count, and universe_count, but does not clarify net, subnet, active, or parent_path semantics.

  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' and clearly identifies the resource as an 'Art-Net DAT discovery scaffold' with optional features. This distinguishes it from sibling tools like create_control_panel or create_led_mapper by naming the exact artifact.

  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 context is implied by the name and description, but there is no explicit guidance on when to choose this tool over alternatives, nor any exclusions. The agent must infer that this is for Art-Net/DMX discovery panels, but no alternative tools are mentioned.

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

• create_azure_kinect_body_busA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds that it creates a scaffold with placeholders and calibration notes, which gives some context about what gets generated. However, it does not disclose side effects, requirements (e.g., a connected device), or what 'stream maps' entail, so it adds only modest context beyond the annotations.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that immediately states the core function and includes key components. There is no filler or redundancy, making it highly concise and easy to parse.

  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?

  Despite having 7 parameters and no output schema, the description provides only a high-level overview. It does not explain how parameters influence the scaffold, what the generated network includes beyond vague 'stream maps,' or any required setup or environmental context. The one-sentence description is insufficient for the complexity of the tool.

  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 29% (2 of 7 parameters have descriptions), and the tool description provides no additional parameter explanations. It does not clarify the role of body_count, device_index, include_color_top, or include_depth_top. With low schema coverage, the description should compensate but does not, leaving parameter semantics inadequate.

  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 ('Create') and resource ('Azure Kinect body/depth scaffold'), and adds concrete details (TOP/CHOP placeholders, stream maps, calibration notes). This distinguishes it from other depth-camera or body-tracking tools like create_zed_depth_bus or create_nuitrack_body_bus.

  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 name and description imply the tool is for Azure Kinect hardware scaffolding, but there is no explicit guidance on when to use it over alternatives (e.g., other depth buses) or when not to use it. Usage is implied by the hardware-specific wording but lacks clear exclusions or alternative references.

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

• create_decklink_io_routerA
  3.5/5.0
  Behavior3/5

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

  Annotations already signal a write operation (readOnlyHint=false) and potential external effects (openWorldHint=true). The description adds the behavioral detail of 'hardware-gated safety notes,' but does not disclose what happens without hardware, whether it modifies the project, or what the scaffold contains.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that names the verb, object, and key features without extraneous words.

  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 7 parameters and no output schema, yet the description only provides a high-level purpose. It leaves unanswered questions about return values, parameter behavior, and the meaning of 'hardware-gated safety notes,' making it insufficient for fully informed invocation.

  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 schema description coverage at only 29%, the description does little to compensate. It references 'route maps' which maps loosely to route_count, but does not explain name, active, parent_path, input_device, output_device, or signal_format beyond their defaults.

  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 ('Create'), a specific resource ('Blackmagic DeckLink video-device input/output router scaffold'), and elaborates with 'route maps and hardware-gated safety notes.' This clearly distinguishes it from sibling router tools like create_ndi_router_matrix or create_osc_router_matrix.

  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 DeckLink hardware routing but provides no explicit guidance on when to use versus alternatives, nor any prerequisites or exclusions. The mention of 'scaffold' hints at initial setup, but no direct comparison to sibling tools.

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

• create_hokuyo_lidar_busA
  3.5/5.0
  Behavior3/5

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

  Annotations (readOnlyHint=false, destructiveHint=false) are not contradicted by the description. The description adds detail about what is created (hardware-gated CHOP setup, scan-zone maps, calibration notes), which goes beyond the annotations. However, it does not disclose potential side effects such as hardware probing, network interaction, or how the scaffold is structured, limiting transparency.

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

  Conciseness5/5

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

  The description is a single, focused sentence that begins with the verb 'Create' and lists specific deliverables. It contains no filler, redundant phrases, or repetition of schema content, making it highly efficient.

  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 10 parameters, no output schema, and only 20% schema documentation, the one-sentence description is insufficient. It does not explain how parameters affect the resulting scaffold, what the hardware-gated CHOP setup entails, or any prerequisites such as network/serial configuration. The presence of many sibling LiDAR creation tools further increases the need for clearer differentiation, which is missing.

  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 20% (name and parent_path are described). The description mentions 'scan-zone maps,' which relates to the scan_zones parameter, but it fails to explain key parameters like start_step, end_step, net_address, serial_port, interface_mode, and high_sensitivity. With low schema coverage, the description was expected to 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 clearly states it creates a Hokuyo LiDAR scanner scaffold, listing specific components (hardware-gated CHOP setup, scan-zone maps, calibration notes). This distinguishes it from sibling tools like create_ouster_lidar_bus and create_livox_lidar_bus by specifying the Hokuyo brand and key features.

  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 intended use (setting up a Hokuyo LiDAR scanner) is implied by the description's mention of 'Hokuyo LiDAR' and 'hardware-gated CHOP setup.' However, there are no explicit statements about when to choose this tool over alternatives, no exclusions, and no mention of prerequisites, so guidance remains implicit rather than explicit.

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

• create_leap_motion_hand_busA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds that it creates a scaffold with placeholders, which clarifies the non-destructive, generative intent. However, it does not disclose any further behavioral traits such as whether it overwrites existing nodes, requires a Leap Motion device, or creates a baseCOMP at a specific path beyond parent_path.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently conveys the tool's purpose with no filler. Every phrase adds meaningful detail about the scaffold contents.

  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 creation tool with 6 parameters and no output schema, the description is too brief to be contextually complete. It does not explain prerequisites, expected behavior after creation, how the scaffold is used, or what 'setup notes' contain. The openWorldHint annotation suggests potential side effects, but the description lacks context to fully understand the tool's role in a workflow.

  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% (2 of 6 parameters have descriptions). The description mentions 'CHOP/TOP placeholders, hand maps, gesture maps' but does not explicitly map these to parameters like hand_count, gesture_count, or include_image_top. It fails to compensate for the undocumented parameters, leaving their meanings ambiguous.

  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: 'Create a Leap Motion hand/gesture scaffold'. It further enumerates distinct elements ('CHOP/TOP placeholders, hand maps, gesture maps, and setup notes') that distinguish it from sibling tools like 'setup_hand_tracking' or 'create_hand_gesture_bus'.

  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 scaffolding a Leap Motion hand/gesture setup, but does not explicitly state when to prefer this over alternatives or mention exclusions. No direct comparison with sibling tools is provided, so usage guidance is only implied.

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

• create_openxr_controller_bridgeA
  3.5/5.0
  Behavior3/5

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

  The description adds context beyond annotations by noting the scaffold is for controller input streams supplied by an external adapter. However, it does not disclose the full behavioral implications of 'creating a scaffold' (e.g., what nodes are created, whether existing network elements are modified, or setup steps). Annotations already indicate non-read-only, non-destructive, open-world behavior, so the description contributes moderate extra context.

  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 with zero filler, starting with the action verb 'Create' and listing specific stream types. It is appropriately front-loaded and every word contributes to conveying the tool's purpose.

  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 an 8-parameter tool with no output schema, the description is too sparse. It does not explain the scaffold's structure, configuration requirements, expected return, or how to use the result after creation. This leaves the agent without enough context to select and invoke the tool correctly in varied scenarios.

  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 25% (name and parent_path have descriptions). The description does not compensate: it provides no explanation of parameters like source_mode, controller_count, coordinate_space, or receive_port, nor how they relate to the scaffold's function. Given the low coverage, this is a significant gap.

  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') and resource ('OpenXR/SteamVR controller input scaffold'), further detailing the stream types (pose, trigger, grip, thumbstick, button) and the external adapter source. This clearly distinguishes it from other bridge-creation tools in the sibling list, which focus on mocap, scene bridges, or other integrations.

  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 rather than explicitly stated: the description indicates it is for OpenXR/SteamVR controller input from an external adapter, but does not mention when to prefer this over alternatives or any exclusion criteria. Sibling tools like create_mocap_stream_bridge exist, but no comparative 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_ouster_lidar_busA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and openWorldHint=true, meaning the tool creates new objects. The description adds what components are created (TOP, range selection, zone maps, calibration notes), but does not disclose side effects, behavior on repeated runs, or any dependencies beyond the listed parameters.

  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 is direct and front-loaded. It efficiently communicates the core purpose without superfluous words or repetition of schema details.

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

  Completeness2/5

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

  For an 8-parameter creation tool with no output schema and low schema coverage, the description is too sparse. It doesn't explain the resulting scaffold's structure, prerequisites, or how the parameters influence the output. It is minimally sufficient but lacks completeness relative to the tool's 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 description coverage is only 25% (2 of 8 parameters described). The description mentions 'range selection' and 'zone maps' which loosely relate to ring_count and zone_count, but it does not clarify imu_port, lidar_port, device_address, active, or how these parameters are used. It adds little meaning beyond the schema's minimal descriptions.

  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 creates an Ouster LiDAR scaffold, listing specific components (Ouster TOP, range selection, zone maps, calibration notes). This distinguishes it from sibling tools like create_hokuyo_lidar_bus or create_livox_lidar_bus which handle different sensor types.

  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 context is implied by the tool name and the mention of Ouster-specific components, but there is no explicit statement of when to use this tool versus alternatives, nor any exclusions or prerequisites. It lacks clear guidance on when to choose this over other bus creation tools.

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

• create_replicatorA
  3.5/5.0
  Behavior1/5

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

  The description explicitly states that 'Re-replicating is destructive to previously generated clones' and that 'the replicator deletes and re-creates on cook', yet the annotations declare destructiveHint=false. This is a direct contradiction, forcing a score of 1 per the rubric despite the description's otherwise rich behavioral detail.

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

  Conciseness4/5

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

  The description is long but every sentence contributes meaningful behavioral or contextual information (fallback creation, parameter probing, destructiveness). It is front-loaded with the core purpose and remains structured, though slightly verbose.

  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 and lack of output schema, the description covers creation fallbacks, callback stubs, parameter-version workarounds, and destructive re-replication. It partially explains the report contents ('which parameter took plus the live parameter list') but does not fully specify the return structure, preventing a perfect score.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description's parameter mentions (e.g., 'omit template_path → a minimal container with a Text') largely duplicate the schema descriptions without adding new semantic meaning beyond what the structured properties already provide.

  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: 'Wire a Replicator COMP that clones a template COMP once per row of a Table DAT'. It immediately distinguishes itself from sibling tools by describing the idiomatic 'N copies from data' mechanism and listing concrete use cases like menus and scoreboards.

  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 usage context through examples ('menus, scoreboards, per-track decks, instanced panels') and explains when the tool is appropriate. However, it does not explicitly mention alternatives or when not to use it, so it slightly misses the 'exclusions' portion of a perfect score.

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

• create_touchosc_layoutA
  3.5/5.0
  Behavior3/5

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

  Annotations indicate a non-read-only, world-interacting creation tool. The description adds context by noting the output includes a JSON manifest DAT and that .tosc generation is intentionally not performed. However, it does not disclose side effects, whether existing objects are overwritten, or other behavioral traits beyond the .tosc exclusion.

  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: the first states the core action, the second clarifies an important boundary. Every word earns its place with no fluff or repetition.

  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 8 parameters, no output schema, and a description that only covers high-level purpose, the agent lacks guidance on the manifest structure, controls array semantics, network defaults, and the overall output shape. This incomplete context is insufficient for correct invocation, especially given the low schema coverage.

  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 38%, leaving key parameters like send_host, send_port, receive_port, page_name, and create_manifest_dat undocumented. The description does not compensate by explaining any parameters, defaults, or relationships, so the agent has insufficient information to correctly set 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 clearly states the tool creates a 'TouchOSC-oriented OSC mapping surface and JSON manifest DAT' and explicitly notes it does not generate .tosc documents. This provides a specific verb and resource while distinguishing itself from touchOSC file generation tools.

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

  Usage Guidelines3/5

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

  The description gives context (TouchOSC-oriented, not for .tosc) and a negative exclusion, but does not explicitly state when to use this tool versus alternatives like create_control_surface or create_companion_surface. The .tosc caveat implies a boundary, but no direct usage guidance is provided.

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

• manage_presetsA
  3.5/5.0
  Behavior1/5

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

  Annotation Contradiction: The description explicitly includes 'delete' as a core action, implying destructive side effects, while annotations declare destructiveHint=false. This is a serious inconsistency. The description does disclose persistence and pairing, but the contradiction with the destructiveHint annotation warrants a score of 1.

  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?

  Three sentences, led by the action list and followed by integration and persistence context. No filler or repetition of the schema.

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

  Completeness3/5

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

  The description covers the tool's core purpose, integration and persistence, but with no output schema it leaves unclear the return format of 'list' and the exact effects of 'recall' (e.g., whether it overwrites only specified params). The annotation contradiction also undermines completeness for assessing risks.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all four parameters (action, name, params, comp_path). The description adds only metaphorical context ('snapshot the knob positions') and does not clarify parameter formatting or required 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 opens with a specific verb list ('Store, recall, list, or delete') and identifies the exact resource ('named snapshots of a COMP's parameter values'), making the tool's scope unmistakable. It also distinguishes itself from generic storage tools by framing it as the live-performance preset system and pointing to create_control_panel as a companion.

  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 gives clear usage context—snapshot knob positions from a control panel and jump between looks—and explicitly pairs it with create_control_panel. It lacks explicit exclusions or when-not-to-use guidance versus sibling tools like manage_cue or create_preset_morph.

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

• scaffold_recipe_templateA
  3.5/5.0
  Behavior3/5

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

  The description adds 'Writes a file (destructive)' which restates the destructiveHint annotation but adds that it writes a file to disk. It also notes the template is RecipeSchema-valid. However, it doesn't disclose what happens if the file already exists or how overwrite works.

  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 sentences, front-loaded with the core action of writing a template file. Every sentence adds value, and there is no padding.

  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 4-parameter tool with no output schema and zero schema description coverage, the description is too thin. It omits parameter guidance, overwrite behavior, and only hints at the recipe format. The mention of apply_recipe is helpful but insufficient.

  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?

  With 0% schema description coverage, the description carries the full burden for explaining parameters, but it names none of them. It does not explain id, name, out_file, or overwrite, leaving the agent to guess at their meaning from the schema alone.

  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?

  Clearly states the tool writes a minimal valid recipe JSON template to disk as a starting point. Distinguishes from similar scaffold tools by emphasizing hand-authored recipes, passing RecipeSchema, and the follow-up apply_recipe step.

  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 clear usage context: use to bootstrap a hand-authored recipe that already passes RecipeSchema, then fill in nodes/connections and instantiate with apply_recipe. Does not explicitly mention when not to use or name alternatives like scaffold_recipe_from_network, but the hand-authored angle implies it.

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

• connect_qlab_cue_stackA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate a non-read-only, non-destructive, open-world operation. The description adds that it creates a scaffold with specific components, which aligns with annotations. However, it does not disclose prerequisites, side effects, or any system changes beyond what is obvious from 'Create'. No contradiction exists.

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

  Conciseness5/5

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

  The description is a single sentence, front-loaded with the core action and resource, with no filler or repetition. Every word contributes to understanding.

  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 provides the basic purpose and some content details, but omits prerequisites, behavioral nuances, and parameter clarifications. With 9 parameters and no output schema, it is minimally adequate but lacks depth for informed usage decisions.

  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 description adds no information about the nine parameters. It only mentions high-level scaffold contents. Since schema coverage is 67%, three parameters (cue_count, send_port, workspace_id) remain undocumented both in the schema and the description, forcing the agent to guess their semantics.

  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 identifies a precise resource: 'QLab OSC cue-stack scaffold'. It further enumerates contents (cue command maps, status, rehearsal-focused setup notes), clearly distinguishing it from sibling connectivity tools like connect_vmix_production or qlab_osc_bridge.

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

  Usage Guidelines3/5

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

  The description implies use when scaffolding a QLab cue stack is desired, but it offers no explicit when/when-not guidance or alternatives. It does not mention when to prefer this over related tools like qlab_osc_bridge or compose_cue_list, leaving the choice to the agent's inference.

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

• connect_replicate_prediction_bridgeA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), aligning with 'Create'. The description adds what the scaffold contains (e.g., credential-safety notes) but does not disclose whether the tool calls the Replicate API, requires credentials, or has other side effects. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence starting with the verb 'Create'. It efficiently lists the scaffold components without filler, earning its place.

  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?

  This is a 9-parameter tool with no output schema and no required parameters. The description does not explain the tool's return value, what executing it actually does (e.g., does it build files, modify a project?), or prerequisites like Replicate API credentials. The listed artifacts give some context but are insufficient for an agent to fully understand the 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?

  Schema description coverage is 56%, with key params (name, model_ref, parent_path, webhook_url, endpoint_url) already described. The description's mention of 'polling/webhook maps' provides loose context for poll_seconds and request_mode, but it does not explain individual parameters beyond what the schema already provides.

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

  Purpose5/5

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

  The description is specific: 'Create a Replicate-style prediction handoff scaffold' with concrete artifacts (request templates, polling/webhook maps, output contracts, credential-safety notes). It clearly distinguishes from sibling connect_* tools by naming Replicate predictions.

  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 use case (Replicate prediction integration) via the name and 'Replicate-style' wording, but there is no explicit 'use when' context or comparison to alternative bridges. No exclusions or alternative tool names are given, so guidance is only implied.

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

• connect_tidalcycles_livecodingA
  3.6/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, which align with the description's 'Create' action. The description adds context about scaffold contents (pattern and orbit maps) but does not disclose whether it creates new components or modifies existing ones, how it interacts with parent_path, or other side effects. No contradiction with annotations, so the lower bar is met with modest additional detail.

  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, densely informative sentence. It front-loads the action ('Create') and the resource, with no filler or repetition. Every word contributes to conveying the tool's function.

  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 8 parameters and no output schema, the description gives a reasonable overview but leaves questions about what the scaffold actually looks like in TouchDesigner, how the parameters interact, and what the tool returns. The description is adequate for a scaffolding tool but lacks structural details that would fully inform 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?

  Schema description coverage is only 38%, so the description should compensate for undocumented parameters. It mentions 'pattern and orbit maps', which loosely relates to pattern_count and orbit_count, but provides no meaning for send_port, receive_port, tidal_host, or active. Parameter names are self-explanatory, but the description adds little semantic value 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 a specific action ('Create') on a specific resource ('TidalCycles/SuperDirt OSC scaffold') and includes the distinctive elements of pattern and orbit maps. This distinguishes it from many 'connect_*' and 'create_*' sibling tools, making its purpose immediately clear.

  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 live-coded audiovisual sets but does not explicitly state when to choose this tool over alternatives like connect_supercollider_synth or connect_oscquery_namespace. There are no exclusions or comparisons to other connect tools, so guidance is only implied rather than explicit.

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

• connect_tiktok_live_events_busA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation aspect is known. The description adds that it creates a scaffold with sanitized rows and safety notes, but does not disclose specific side effects like file creation or network access. No contradiction with annotations.

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

  Conciseness5/5

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

  A single, dense sentence that packs all the key information without fluff. Every phrase adds value; it is appropriately front-loaded with the main action.

  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 scaffold-creation tool with no output schema, the description gives a good high-level overview of the output composition. However, it omits any mention of return values, side effects, or usage context, which is a gap for a complex 9-parameter 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 coverage is only 22%, so the description must compensate. It does map some parameters to concepts (gift tiers, moderation policy, adapter source) but leaves others (event_count, active, creator_label) unaddressed. This gives a partial semantic layer 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 the tool's action: creating a TikTok Live-style event scaffold. It lists specific components (sanitized event rows, gift tiers, moderation policy, adapter source, auth/client safety notes), which distinguishes it from sibling bus-creation tools. Even though the tool name says 'connect', the description's 'create' 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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or compare with other live-event bus tools. An agent would not know if this is the right choice for a TikTok Live integration scenario.

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

• create_direct_display_outputA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare non-read-only and non-destructive, but the description adds the important safety trait that the scaffold is created inactive-by-default, which is beyond annotation info. It also implies a scaffold (incomplete structure), which is useful 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.

  Conciseness5/5

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

  One sentence, immediate verb, no filler. All three content items (inventory, maps, safety notes) are packed into a concise clause.

  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 creation tool with 7 parameters and no output schema, the description gives a high-level idea but omits how parameters affect the scaffold, what 'monitor inventory' entails, and what the agent/return should expect. It's sufficient for a knowledgeable user 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 description coverage is only 29% (only name and parent_path have descriptions), and the description does not mention any parameter or explain how the listed features map to parameters like output_count, display_index, or resolution. Thus it 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 states a specific action ('Create') on a specific resource ('Direct Display Out TOP scaffold') and lists key contents (monitor inventory, display maps, safety notes), which clearly distinguishes it from sibling creation tools like create_multi_output or create_dome_output.

  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 on when to use this tool vs alternatives; no mention of when not to use or what makes this preferred. The description only states what it does, leaving usage decisions to the agent.

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

• elicit_missing_argsA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint and openWorldHint, so the description does not need to restate safety. It adds the method context ('use the schema + LLM') and clarifies it 'proposes' rather than executes, but it does not describe output shape, failure behavior, or limits, leaving behavioral detail to the schema and output schema.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that communicates the core purpose with no wasted words. It is direct and efficient, earning a high score on conciseness.

  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 rich schema, clear annotations, and presence of an output schema, the description is sufficient to understand the tool's primary role. It could be slightly more complete by stating it does not execute the target tool, but 'propose values' already implies this, so the overall description is reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline applies. The description itself does not add parameter-level nuance; all parameter meaning is carried by the input schema. It neither harms nor significantly augments the schema.

  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 function: using the schema and an LLM to propose values for missing required arguments in a tool call. It identifies a specific verb ('propose') and resource ('missing required args'), but it does not explicitly contrast it with sibling tools, so it stops short of full differentiation.

  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: use this when a tool call has missing required args. There is no explicit 'when to use' or 'when not to use' guidance, nor mention of alternative approaches, so the guidance is minimally viable but not robust.

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

• connect_gps_fleet_trackerA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare the tool as write-oriented (readOnlyHint=false), non-destructive, and open-world. The description adds context by listing the scaffold's contents (privacy policy, credential notes, geofence maps), which clarifies what the side effects create. It does not contradict annotations and provides useful artifact-level detail.

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

  Conciseness4/5

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

  The description is a single sentence that front-loads the primary verb and resource ('Create a GPS/fleet tracking scaffold'). The enumeration of contents is somewhat dense but each phrase is meaningful. It is appropriately sized without redundant wording.

  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 scaffold tool with 10 parameters and no output schema, the description gives a high-level overview but leaves key questions unanswered: what exactly are 'sanitized asset rows'? What does 'adapter source' entail? What are the prerequisites or side effects on the project? Annotations cover the safety profile, but the description could provide more operational context.

  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 20%, with only name and parent_path described. The tool description does not explain most parameters (provider, adapter_mode, geofence_count, update_rate_hz, tracked_asset_count, adapter_url, fleet_label, active). It offers only implicit hints like 'geofence maps' for geofence_count and 'adapter source' for adapter_url/adapter_mode, which is insufficient for a 10-parameter tool with 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 creates a GPS/fleet tracking scaffold and enumerates its components (sanitized asset rows, geofence maps, privacy policy, adapter source, credential/privacy notes). The verb 'Create' and specific resource distinguish it from sibling integration tools like connect_blackmagic_atem or create_blacktrax_tracking_bus.

  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 when a GPS fleet tracking scaffold is needed, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. No sibling comparisons or conditionals are provided.

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

• connect_lighting_console_oscA
  3.7/5.0
  Behavior3/5

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

  The description discloses that the tool creates a scaffold and does not send direct DMX, complementing the annotations (readOnlyHint=false, destructiveHint=false). It mentions 'safety-gated' but does not elaborate on side effects like network connections or port binding—important given openWorldHint=true. No contradiction with annotations exists.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that packs essential information (verb, resource, console types, safety gating, no direct DMX) without wasting words. It is concise yet informative, making it easy 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?

  For a complex tool with 10 parameters, no output schema, and minimal annotation context, the description is too high-level. It does not describe what the scaffold contains, how it should be configured, or what the agent can expect as a result, leaving significant gaps for correct invocation.

  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 20% (2 of 10 parameters have descriptions), and the tool description does little to compensate. It only gives domain context (lighting consoles, safety-gating), which helps infer console_family and safety_mode, but it leaves parameters like cue_count, executor_count, send_port, receive_port, and console_host unexplained.

  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 ('Create') and resource ('OSC command scaffold for lighting consoles'), and adds exclusions ('without sending direct DMX') and safety qualifiers ('safety-gated'). It distinguishes itself from sibling tools by naming the specific console families it supports, making its purpose unmistakable.

  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 explicit context for when to use the tool (for grandMA3, ETC Eos, ChamSys, Avolites, or generic lighting consoles) and implies a limitation (does not send direct DMX), which helps rule out scenarios where direct DMX is needed. However, it does not explicitly name alternatives or state when-not-to-use relative to sibling tools.

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

• connect_mqtt_iot_busA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, providing the safety profile. The description adds the 'policy-gated operator commands' nuance and 'scaffold' language, but does not disclose side effects such as broker connectivity requirements, component creation details, or error handling.

  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 wasted words. It concisely communicates the primary action and purpose.

  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's complexity (9 params, no output schema), the description is too terse. It does not explain what a 'DAT bus scaffold' entails, what happens on execution, or what the effects are. The low schema coverage further increases the need for a more detailed description.

  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 description does not explain any of the 9 parameters. Schema description coverage is only 44%, leaving qos, active, client_id, broker_port, and topic_count without descriptions. The high-level purpose does not compensate for the missing parameter explanations.

  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 an MQTT Client DAT bus scaffold' with specific use cases (IoT sensors, installation telemetry, policy-gated operator commands). This distinguishes it from sibling tools like connect_kafka_event_bus or connect_redis_pubsub_bus.

  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 the tool (IoT sensor data, telemetry, operator commands) but does not explicitly mention when not to use it or name alternative tools. It implies usage rather than stating exclusions.

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

• connect_omniverse_usd_bridgeA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, which aligns with the 'Create' action. The description adds specific scaffold contents but does not disclose additional behavioral traits like side effects, prerequisites, or impact on the current TouchDesigner session. It provides some context but not rich behavior 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 sentence, approximately 20 words, with the verb and resource front-loaded. It is efficient and contains no unnecessary words or repetition of the tool name or title.

  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 9 parameters, no output schema, and low parameter descriptions, the one-sentence description is insufficient. It does not explain return values, side effects, prerequisites, or how the scaffold integrates into the environment. The enumeration of scaffold features gives some idea, but missing critical operational details makes it incomplete for such a parametrized tool.

  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 22% (2 out of 9 params have descriptions). The description must compensate but only vaguely references concepts like Nucleus, layer maps, and variant maps, without explaining specific parameters (e.g., sync_mode enum values, server_url, active). This leaves the agent under-informed about most parameter meanings and valid options.

  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') and resource ('NVIDIA Omniverse/USD stage sync scaffold'), and enumerates distinct components like Nucleus/stage metadata, layer maps, variant maps, and live-session notes. This clearly differentiates it from other bridge tools in the sibling list (e.g., Unreal, Blender) by naming the Omniverse platform and USD format.

  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 usage context by naming Omniverse/USD and scaffold components, making it evident when to choose this tool. However, it lacks explicit 'when not to use' guidance or mention of alternatives, such as other bridge creation tools, so it falls short of a 5.

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

• connect_s3_media_bucketA
  3.7/5.0
  Behavior4/5

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

  Beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description adds meaningful behavioral context by mentioning 'credential/signing safety notes' and 'adapter source', signaling important security and integration details. It does not contradict the annotations and provides extra depth about the scaffold's contents.

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

  Conciseness4/5

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

  The description is a single sentence that front-loads the primary action and resource, then lists included features. It is concise and efficient, though slightly dense with compound items; overall no wasted words.

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

  Completeness3/5

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

  With 10 optional parameters and no output schema, the description captures the scaffold's purpose and key components, but it lacks guidance on configuration choices and the meaning of several parameters. It is adequate as a high-level summary but not complete enough for an agent to confidently decide how to use the tool without additional schema exploration.

  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 20% (name and parent_path), so the description must compensate for the other eight parameters. It references cache_policy, adapter_mode, and manifest-related concepts, but it does not explain parameters like provider, prefix, or active. The vague term 'ingest status' does not map directly to a schema field, so parameter meaning remains 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 uses the specific verb 'Create' and clearly identifies the resource as an 'S3-compatible media-bucket scaffold'. It enumerates constituent elements (manifest rows, cache policy, ingest status, adapter source, credential/signing safety notes), making it distinct from sibling connect_* tools that target different systems. The purpose is unmistakable.

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

  Usage Guidelines3/5

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

  The description implies use when an S3 media-bucket scaffold is needed, but it offers no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or exclusions, leaving the agent to infer applicability from the name and description alone.

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

• connect_serial_device_busA
  3.7/5.0
  Behavior3/5

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

  The description adds context beyond annotations by mentioning 'DAT/CHOP scaffold' and 'parse maps', but it does not disclose side effects, prerequisites, or what exactly gets created. With annotations already indicating a mutating operation and open-world behavior, this is acceptable 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, front-loaded sentence with no wasted words. It states the action, the resource type, and the intended use cases efficiently.

  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 7-parameter creation tool with no output schema, the description is too thin. It gives a high-level purpose but lacks guidance on parameter semantics, configuration choices, or expected results, leaving the agent under-informed for accurate invocation.

  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 29%, and the description does little to compensate. Parameters like device, baud_rate, include_chop, and message_count are left unexplained; the only vague connection is 'parse maps' potentially relating to message parsing, but this is not explicit.

  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') and names the exact resource ('Serial DAT/CHOP scaffold'), including the target device types and parse maps. This clearly distinguishes it from sibling connect/create tools, which target other protocols or systems.

  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 gives clear context by indicating the tool is for microcontrollers, sensors, and show-control devices over serial. It does not explicitly state when not to use it or mention alternatives, so it stops short of full guidance, but the intended use case is reasonably clear.

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

• connect_supercollider_synthA
  3.7/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false, and the description adds a meaningful safety guarantee: 'no code-evaluation behavior'. This goes beyond the annotations by clarifying a critical behavioral boundary. However, it does not mention side effects or permissions, so it is not a 5.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that conveys key information efficiently. Every clause adds value: what is created, for what, what it includes, and a critical constraint. There is no wasted verbiage.

  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 an 8-parameter scaffold tool with no output schema, the description is too sparse. It does not explain what the scaffold contains, how the port maps are structured, or any prerequisites or side effects. The 'no code-evaluation' note is useful but insufficient for an agent to fully understand the tool's behavior and return expectations.

  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 only 25% schema description coverage, the description must compensate for the 6 undocumented parameters, but it does not. It mentions 'port maps' which relates to send_port/receive_port but provides no details on syntax, defaults, or relationships. The parameter names are somewhat self-explanatory, but the description adds minimal value.

  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 specific verb 'Create' and the resource 'SuperCollider OSC synth/bus bridge scaffold', with additional distinguishing details like 'explicit port maps' and 'no code-evaluation behavior'. It differentiates from the many sibling connect_* bridge tools by naming SuperCollider directly.

  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 use for creating a SuperCollider bridge scaffold but does not explicitly state when to use it versus alternatives or mention any prerequisites/exclusions. Since the purpose is clear from the name and description but lacks explicit guidance, it falls into 'implied usage'.

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

• connect_video_stream_receiverA
  3.7/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false and openWorldHint=true, indicating a mutating creation operation, which the description aligns with ('Create a Video Stream In TOP scaffold'). The description adds value by specifying the protocol types and the inclusion of stream maps and setup notes, giving more concrete behavioral context beyond the annotations.

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

  Conciseness5/5

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

  The description is a single concise sentence that communicates the core purpose without redundancy. Every phrase adds information: the action, the target component, the protocol list, and the included artifacts.

  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 6 parameters and no output schema, the description is insufficient for an agent to understand how to correctly configure the tool. It does not explain parameter semantics, default behaviors, or what the scaffold will look like. While the annotations provide safety cues, the description leaves significant gaps 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 only 33%, with descriptions only for 'name' and 'parent_path'. The description mentions protocols (RTSP, HLS, SRT, WebRTC) that map to the 'mode' enum, but it does not clarify the meaning or expected values for 'url', 'active', 'latency_ms', or 'parent_path'. Given the low schema coverage, the description fails to compensate for the lack of parameter clarity.

  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 specific action ('Create a Video Stream In TOP scaffold') and resource, listing supported protocols (RTSP, HLS, SRT, WebRTC) and additional outputs (stream maps, setup notes). This distinguishes it from broader 'connect' siblings by naming the specific TOP type and purpose.

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

  Usage Guidelines3/5

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

  The description implies usage for setting up video ingestion via a Video Stream In TOP, but it does not explicitly state when to use this tool versus alternatives like connect_webrtc_browser_input or other connect_* tools. There are no exclusions or alternative recommendations, leaving some ambiguity.

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

• create_depth_pop_fieldA
  3.7/5.0
  Behavior4/5

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

  Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description discloses side effects: it creates a container, may auto-spin-up a setup_segmentation MediaPipe chain, and returns a JSON block with warnings. It also warns that POPs are experimental and fail-forward, adding risk context not captured by annotations.

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

  Conciseness4/5

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

  The description is a single paragraph that packs core purpose, auto-spin behavior, scatter modes, forward-compat, and an experimental warning into a few sentences. It is well-structured and front-loaded, though slightly dense for a 12-param 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 tool with 12 params, no output schema, and no required params, the description covers the essential workflow, input handling, return value, and risk. It doesn't provide examples or prerequisites, but the schema fills the parameter gaps. The openWorldHint and experimental note enhance completeness.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters are documented. The tool description adds minimal parameter-level detail beyond the schema; it mentions scatter modes at a high level but the schema already explains them in comparable detail. Therefore baseline 3 is appropriate.

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

  Purpose4/5

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

  The description opens with 'Build a depth-driven GPU POP scatter field' – a specific verb and resource. It further clarifies it consumes a depth/mask TOP and uses lookup_texture_pop, distinguishing it from generic POP creation tools, though it doesn't explicitly name alternatives.

  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 explains the conditional behavior when depth_top_path is omitted vs provided, and mentions forward-compatibility with create_depth_from_2d. However, it does not explicitly specify when to use this tool over sibling tools like create_pop_field or create_gpu_particle_field.

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

• create_livox_lidar_busA
  3.7/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false, consistent with a 'create' operation. The description adds value by listing what the scaffold includes, but does not disclose side effects such as whether files are written, whether a new COMP is instantiated at parent_path, or whether existing components are modified.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that packs core features without waste. Every phrase adds meaningful information about what the scaffold contains.

  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 moderately complex tool with 9 parameters and no output schema, the description captures the high-level purpose but omits details about return values, preconditions, project placement, or how the scaffold is structured internally. The parameter defaults and ranges in the schema help, but the description alone would be insufficient for advanced use.

  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 33%, so the description must compensate. It loosely maps to parameters via 'UDP/WebSocket/file-replay ingest' (adapter_mode) and 'zone maps' (zone_count), but leaves many parameters (active, server_url, receive_port, device_address, point_rate_hint) unexplained beyond schema defaults.

  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 verb ('Create') and resource ('Livox LiDAR adapter scaffold'), and enumerates specific components (ingest modes, point-stream schema, zone maps, calibration notes). It distinguishes itself from sibling lidar bus tools by specifying Livox as the target hardware.

  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 when creating a Livox LiDAR adapter within TouchDesigner, but provides no explicit when-to-use or alternative guidance. It does not mention similar tools for other lidar types (e.g., Ouster, Hokuyo) or when file_replay vs UDP would be preferred.

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

• create_ltc_timecode_bridgeA
  3.7/5.0
  Behavior4/5

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

  The description adds meaningful behavioral context beyond the annotations by specifying that the tool creates a scaffold with placeholders and routing notes, implying it does not produce a fully functional LTC bridge. This is useful for setting agent expectations. Annotations only indicate readOnly=false and destructive=false, which the description does not contradict.

  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 ('Create') and the object ('LTC receive/generate scaffold'), with the supporting components listed in a compact phrase. No wasted words.

  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 8 parameters, no output schema, and minimal annotations, the description is incomplete. It explains what the scaffold contains but does not mention prerequisites, return values, or the meaning of key parameters like active or frame_rate, leaving an agent with significant ambiguity for a relatively complex creation tool.

  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 schema has low description coverage (25% of 8 parameters), so the description must compensate. It partially does by mentioning 'receive/generate' (mode) and 'LTC In/Out' (devices), but it does not explain the semantics of active, cue_count, frame_rate, input_device, output_device, or parent_path beyond what the sparse schema provides.

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

  Purpose5/5

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

  The description clearly states the tool creates an LTC receive/generate scaffold with specific components (LTC In/Out CHOP placeholders, cue maps, routing notes). The verb 'create' and resource 'LTC receive/generate scaffold' are specific and distinguish it from sibling creation tools like 'create_cue_sequencer' or 'sync_timecode'.

  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 by stating what it creates (an LTC receive/generate scaffold), so an agent can infer it is for setting up LTC timecode bridges. However, there is no explicit when-to-use guidance or differentiation from alternatives like 'sync_timecode' or 'add_timecode_overlay'.

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

• create_mpcdi_projection_mapperA
  3.7/5.0
  Behavior3/5

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

  Annotations already indicate this is a non-read-only, non-destructive write operation. The description adds the specific scaffold contents, which provides useful context beyond the annotations, but it does not disclose potential side effects such as overwriting existing nodes or requiring a pre-existing MPCDI config file.

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

  Conciseness5/5

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

  The description is a single, focused sentence that front-loads the core action and output. Every element adds value without unnecessary detail.

  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 tool with 6 parameters and no output schema, the description offers a high-level overview of the scaffold's contents but omits parameter-specific behavior and any operational caveats. It is adequate for basic understanding but not fully complete for an agent to invoke correctly without additional inference.

  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 descriptions cover only name, config_file, and parent_path; active, region_count, and projector_count lack explanatory text. The description indirectly links projector_count and region_count to 'projector maps' and 'region maps', but does not clarify parameter constraints or how config_file is used, leaving gaps that the description only partially compensates for.

  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 creates an MPCDI projection-calibration scaffold and lists specific contents (MPCDI TOP/DAT, projector maps, region maps, setup notes). This distinguishes it from sibling tools like create_projection_mapping or projector_calibration_wizard by focusing on MPCDI-specific calibration structures.

  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 term 'MPCDI projection-calibration scaffold' implicitly conveys when to use this tool, but there is no explicit guidance on alternatives or exclusions. The description does not mention when to prefer this over similar creation tools, leaving the agent to infer from the MPCDI keyword.

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

• create_realsense_depth_busA
  3.7/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description's 'Create' action is consistent. The description adds minor context by mentioning the modes and routing notes, but does not disclose potential side effects, prerequisites (e.g., camera connection), or the structure of the created scaffold beyond what is implied.

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

  Conciseness4/5

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

  The description is a single, dense sentence that efficiently communicates the tool's purpose and key modes without excessive verbosity. It is reasonably front-loaded with the main action, though the long list of modes makes it slightly less scannable than ideal.

  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?

  There is no output schema, and the description does not explain what the scaffold produces or how the routing notes are delivered. For a creation tool with 10 parameters and multiple modes, the description is adequate but leaves gaps about the resulting component structure and configuration specifics.

  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 50%, and the description does not compensate for the undocumented parameters (active, resolution, source_mode, include_color, include_pointcloud). It hints at modes and color/point-cloud, which vaguely aligns with source_mode and include_color/include_pointcloud, but lacks explicit explanations of parameter meaning, especially resolution options and defaults.

  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 'Create' and the specific resource 'Intel RealSense depth-camera scaffold'. It further distinguishes the tool by enumerating modes (RealSense TOP, NDI, WebSocket, sample-source) and the included depth/color/point-cloud routing, setting it apart from sibling depth buses like create_zed_depth_bus.

  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 gives clear context that this tool is for creating a RealSense depth-camera scaffold, which implies usage for Intel RealSense hardware. However, it does not explicitly name alternatives or state when not to use this tool over other depth buses, so it stops short of full exclusion guidance.

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

• create_vioso_warp_panelA
  3.7/5.0
  Behavior3/5

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

  The description discloses what the scaffold contains, which is useful context beyond the annotations (readOnlyHint=false, destructiveHint=false). However, it does not mention potential side effects like name conflicts, the need for an existing config file, or how parameters affect the output. With annotations covering the safety profile, this is acceptable 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 concise sentence that front-loads the core action and output components. No redundant or filler words.

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

  Completeness3/5

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

  For a creation tool with six parameters and no output schema, the description gives a high-level overview but omits details about return values, parameter effects, or prerequisites. It is adequate for basic selection but insufficient for confident invocation without schema help.

  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 50%, with three parameters (active, projector_index, blend_zone_count) lacking descriptions. The description mentions 'blend-zone maps' and 'projector metadata,' which vaguely relate to blend_zone_count and projector_index, but it does not explicitly map parameters or explain their behavior. It provides some context but leaves 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 ('Create') and resource ('VIOSO projection-warp scaffold'), and lists output components (VIOSO TOP, blend-zone maps, projector metadata, setup notes). This distinguishes it from sibling tools like create_projection_mapping or create_mesh_warp.

  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 when a VIOSO warp scaffold is needed, but it does not explicitly state when to choose this tool over alternatives or mention any exclusions. No alternative tools are referenced, so an agent must infer the context from the name and description.

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

• watch_nodeA
  3.7/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond annotations: it explicitly states that missing TD attributes/channels are reported as warnings rather than failing, and that CHOP channels are only returned 'when available'. This goes beyond the readOnlyHint/destructiveHint annotations and helps the agent set expectations.

  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 and front-loaded, with the first sentence stating the core action. The third sentence details the return structure, which is slightly redundant given the output schema, but it is well-organized and every sentence contributes meaning.

  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 read-only sampling tool with an output schema, the description is fairly complete. It covers the purpose, the warning behavior, and the return format, and the annotations handle safety. It does not mention any prerequisites or limitations beyond the warning behavior, but none are necessary for this simple 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 all 5 parameters, so the description does not need to add parameter details. It mentions parameter values and channel values in the output but does not describe individual parameters, matching the baseline 3 for high schema coverage.

  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 samples one TouchDesigner operator over a short interval and returns runtime state, readable parameters, and CHOP channels. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like get_node_state_runtime, so it slightly 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 Guidelines3/5

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

  The description implies usage for sampling operator state over time, and the read-only hint suggests safe monitoring. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites, so guidance is only implicit.

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

• component_link_healthA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds behavioral context by specifying what is probed (live COMPs, external .tox paths) and what is reported (missing or broken files). This goes beyond the annotations without contradicting them.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core action ('Probe live COMPs...'), then a brief usage note. Every sentence earns its place with no redundancy.

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

  Completeness3/5

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

  For a simple read-only diagnostic, the purpose and usage are clear, and annotations cover safety. However, the lack of parameter explanations and return format details (no output schema presents additional burden) leaves gaps for an agent to use it correctly without further inference.

  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 0%, and the description provides no meaning for the two parameters (paths, parent_path). The description does not compensate for the lack of schema documentation, leaving parameter semantics entirely 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 clearly states the tool probes live COMPs for external .tox paths and reports missing or broken linked files. It distinguishes itself from siblings like inspect_component_manifest and make_portable_tox by focusing on link health specifically.

  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?

  It gives a clear when-to-use context: 'run it when externally-linked .tox components may have moved or gone stale, before relying on them in a build.' It does not name explicit alternatives, but the context is sufficient to guide selection.

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

• attach_docs_as_assetsA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true, but the description adds that the tool 'writes into the package folder (destructive)' and registers docs in the manifest, specifying exactly what gets modified. This goes beyond the annotation and provides useful behavioral context with no contradiction.

  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, action-first, with usage context and a destructive warning. Every sentence earns its place with no redundancy.

  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?

  While purpose and usage are clear, the description leaves significant gaps around parameter semantics, especially for the help_snapshot object and the expected format of docs paths. With no output schema and only 25% schema coverage, an agent lacks sufficient detail to confidently invoke the tool with all parameters.

  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 25%, and the description does not explain the meaning of docs, asset_dir, or manifest_path beyond the vague 'documentation files.' It fails to compensate for the low schema coverage with parameter-level guidance.

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

  Purpose5/5

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

  The description states 'Copy documentation files into a package and register them in its manifest's docs list,' which is a specific verb+resource combination. It distinguishes the tool from siblings by explicitly referencing make_portable_tox and the package manifest context.

  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 explicitly says 'Use after make_portable_tox' and explains the intended outcome (so docs travel with the component), giving clear context. However, it does not specify when not to use the tool or mention alternatives like bundle_dependencies or collect_project_assets.

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

• checksum_and_verify_packA
  3.9/5.0
  Behavior4/5

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

  With sparse annotations, the description carries the burden of explaining side effects and outputs. It states that 'action=compute walks a path and writes a tdmcp-checksums.json manifest' and 'action=verify re-hashes files and reports ok/mismatch/missing/extra'. This discloses the write behavior and report format. It does not mention potential overwrites or error conditions, but the provided detail is solid.

  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 three sentences, each providing essential information: what it does, how compute behaves, and how verify behaves. No filler or redundant phrasing. It is front-loaded with the core purpose.

  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's complexity (9 params, nested manifest object, no output schema), the description is too sparse to be complete. It does not mention the manifest format beyond the filename, nor the meaning of 'strict', glob filters, size limits, or symlink behavior. For a sophisticated tool with no output schema, more detail is needed.

  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 0%, so the description must compensate. It only explicitly explains 'action' and 'path' (the required params). The other seven parameters (strict, manifest, manifest_out, exclude_globs, include_globs, max_file_bytes, follow_symlinks) are left completely unexplained. This is a significant gap for a tool with 9 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 clearly states the tool's purpose: 'Compute or verify SHA-256 checksums for tdmcp artifacts'. It specifies the resource (tdmcp artifacts) and the two primary actions (compute/verify). This distinguishes it from siblings that deal with other artifact operations.

  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 the tool: for checksum computation or verification of tdmcp artifacts. It also notes 'No TD bridge required', which is a pertinent usage constraint. However, it does not explicitly name alternatives or state when not to use it, so a perfect score is not warranted.

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

• connect_comfyuiA
  3.9/5.0
  Behavior4/5

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

  The description discloses key behavioral details beyond the annotations: the fallback logic between tox_drop and webclient modes, and the exposed Null TOP output. It adds useful context about what the tool does internally, though it omits potential side effects like overwriting existing components or network-level 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 two sentences long and front-loaded with the primary action and outcome. Every phrase earns its place without redundancy, making it concise and well-structured.

  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 13 parameters and no output schema, the description provides a high-level overview but does not fully explain the workflow, prerequisites, or failure modes of the webclient path. The schema supplements this, but the tool description alone feels incomplete for such a complex 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 coverage is 100%, so the baseline is 3. The description references the mode and output behavior (tox drop, webclient, Null TOP) but does not add parameter-level meaning beyond the already thorough schema descriptions. The schema carries the semantic load.

  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: to bridge a running ComfyUI server. It specifies the two distinct approaches (dropping TDComfyUI .tox or building a stock webclientDAT skeleton) and the resulting output (Null TOP at <container>/out), which distinguishes it from other connection tools like connect_a1111_webui_bridge.

  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 context is clear (for connecting to a running ComfyUI server), but the description does not explicitly say when to use this tool over alternatives, nor does it provide exclusions or prerequisites. The guidance is implied by the tool's name and opening phrase, not explicitly addressed.

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

• create_ndi_router_matrixA
  3.9/5.0
  Behavior4/5

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

  Annotations already indicate non-read-only, open-world, and non-destructive, but the description adds key behavioral context: this creates a scaffold and deliberately avoids live NDI discovery. This goes beyond the annotations and helps the agent understand the tool's limitations.

  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 purpose, scope, and a key limitation without unnecessary words. Every part of the sentence adds value, making it highly concise and readable.

  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 six parameters, no output schema, and sparse annotations, the description should explain what the scaffold consists of and what the parameters affect. It only provides a high-level statement, leaving significant ambiguity about the actual result and behavior. The description is too terse for complete understanding.

  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 schema has only 33% parameter description coverage, with four of six parameters undocumented. The tool description does not mention any parameter semantics, leaving the agent without guidance on what 'output_count', 'source_count', 'include_preview', or 'active' actually control. The description 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 a specific verb (create) and resource (NDI source/output routing matrix scaffold), and explicitly scopes it as 'stable' and 'without claiming live NDI discovery.' This distinguishes it from related sibling tools that might imply live discovery or different router types.

  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 'stable scaffold without claiming live NDI discovery' provides clear context on when to use this tool: when a scaffold is needed and live discovery is not desired. However, it does not name alternatives or explicitly say 'use this instead of X,' so it falls short of a full 5.

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

• create_raytk_sdf_graphA
  3.9/5.0
  Behavior3/5

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

  Annotations already indicate a non-read-only, non-destructive operation (readOnlyHint=false, destructiveHint=false). The description adds the staging dependency and the fact that it copies ROP masters, which is useful context. It does not mention potential side effects like overwriting existing components or what happens if RayTK is not staged, but the annotations cover the basic safety profile.

  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 two sentences, front-loaded with the main action ('Build a RayTK SDF graph') and no redundancy with the schema. The second sentence is long but packs the essential prerequisite info. It is dense but not wasteful, though the long list of components could be slightly restructured for readability.

  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 10 parameters and no output schema, the description effectively covers the graph structure and the critical RayTK staging prerequisite. The schema fills in parameter details and confirms a container COMP is created. It could explicitly state the creation of a new container COMP and the default location, but combined with the schema, the information is complete enough for an agent to invoke the tool correctly.

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

  Parameters3/5

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

  Schema coverage is 100% with each parameter individually described (e.g., 'Add a RayTK pointLight wired to renderer input 2'). The description gives a high-level summary of the graph components but adds no extra detail beyond what the schema already provides, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it 'Build a RayTK SDF graph' and enumerates the exact components (primary SDF, optional secondary through simpleUnion, basicMat, lookAtCamera, pointLight, raymarchRender3D, and Null TOP output). This specific verb+resource+scope distinguishes it from siblings like create_raytk_op or create_raytk_scene.

  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?

  It provides clear context: creating a full SDF graph from staged RayTK masters. It explicitly states the prerequisite, 'Requires RayTK to be staged with manage_packages install raytk and loaded from the staged .tox.' However, it does not name alternative tools or exclusion conditions, so it lacks explicit when-not-to-use guidance.

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

• create_test_patternA
  3.9/5.0
  Behavior4/5

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

  Annotations already mark the tool as non-read-only and non-destructive. The description adds meaningful behavioral context by explaining that it builds a baseCOMP with a GLSL TOP and Null TOP, and that the shader is baked per pattern with no live bindings or custom uniforms required. This goes beyond simple create/build phrasing, though it doesn't discuss overwrite or side-effect behavior in detail.

  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 front-loaded with purpose and uses four sentences to cover behavior, patterns, use cases, and configurability. Some filler such as 'every media server ships and tdmcp was missing' is not strictly necessary but does not undermine clarity.

  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 10-parameter creation tool with no output schema, the description adequately conveys the built network's structure, the configurable pattern types, and the intended application contexts. It does not explain every parameter, but those are fully documented in the schema, and the high-level behavior is sufficiently complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema carries full parameter details. The description adds only a general statement that pattern, resolution, divisions, overlay number/label, and colours are configurable, which restates what the schema already provides without deeper semantic value.

  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?

  Description names a specific verb ('Generate') and resource ('standalone test-pattern network') for projector calibration/alignment, and enumerates pattern types and output structure. It distinguishes itself from generic shader creation by emphasizing baked-in static patterns and a Null TOP output handle, though it does not explicitly name sibling alternatives like projector_calibration_wizard.

  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?

  Clear usage context is provided: 'Use the output as a routing source during projector alignment, LED mapping calibration, or camera registration.' This tells the agent when to invoke the tool, but it stops short of explicit exclusions or named alternatives, so it misses the top score.

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

• create_voice_prompt_pipelineA
  3.9/5.0
  Behavior4/5

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

  Annotations only indicate read/write and destructiveness; the description adds meaningful behavioral context not captured there: 'dry-run/approval-gated' mode and the safety guarantee 'never dispatches raw hardware effects; policy and operator approval remain authoritative.' This goes beyond what annotations provide, even though it doesn't detail other side effects or return 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?

  Two sentences, front-loaded with the primary action and resource, and every phrase provides unique value. No redundancy with the schema or annotations, and it is appropriately concise for the information it conveys.

  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 description covers the core purpose and a key safety characteristic, but with 9 parameters, 0 required, low schema coverage, and no output schema, it omits many important details: what parameters do, what the scaffold contains, what 'dry-run/approval-gated' means for invocation, and what the return value or side effects are. It leaves a significant context gap for an agent to correctly invoke and interpret the tool.

  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 22% (only name and parent_path have descriptions), and the description does not compensate by explaining any of the parameters, their enums, or how they relate to the tool. The enums like stt_mode, llm_target, and approval_mode have some inherent meaning, but the description adds no guidance, leaving most parameters semantically 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?

  Description has a clear verb ('Create') and a specific resource ('voice-to-prompt TouchDesigner scaffold'), further qualified by 'dry-run/approval-gated' and 'for AI Party-style workflows.' It explicitly states what the tool does and distinguishes it from sibling tools by emphasizing the approval-gating and the constraint that it never dispatches raw hardware effects.

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

  Usage Guidelines4/5

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

  The description implies usage for AI Party-style workflows and for scenarios requiring dry-run or approval-gated voice-to-prompt scaffolding. It includes an exclusion ('never dispatches raw hardware effects') which helps the agent avoid using this when hardware dispatch is intended, but it does not explicitly name alternatives or provide a clear when-not-to-use statement beyond the hardware constraint.

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

• import_recipe_bundleA
  3.9/5.0
  Behavior4/5

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

  Beyond the destructiveHint annotation, the description adds the validation behavior: each recipe is validated before write, so a malformed bundle fails loudly instead of corrupting the directory. This is useful behavioral context. The final sentence reinforces the destructive nature already noted in annotations.

  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 three sentences and front-loads the core purpose. The last sentence ('Writes files (destructive)') is somewhat redundant with the destructiveHint annotation, but overall the description is concise and without unnecessary fluff.

  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 purpose, validation, and destructive behavior, but it lacks details on the overwrite parameter's behavior and any return value. Given the sparse schema and absence of an output schema, a bit more explanation of these operational aspects would make it 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?

  Schema description coverage is 0%, and the description only indirectly maps 'bundle' to bundle_file and 'directory' to out_dir. The optional 'overwrite' parameter is not mentioned at all, leaving the agent without guidance on its semantics or the consequences of setting it true.

  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 imports recipes from a portable JSON bundle into a recipe directory. It explicitly identifies the inverse relationship with export_recipe_bundle, which differentiates it from sibling tools.

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

  Usage Guidelines4/5

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

  The description names export_recipe_bundle as the counterpart, giving clear context for when to use this tool. It also implies limitations by specifying 'portable JSON bundle', which separates it from URL-based imports, though it doesn't explicitly list exclusions.

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

• manage_cueA
  3.9/5.0
  Behavior1/5

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

  Despite a rich behavioral disclosure of morph timing, easing, Execute DAT, and quantize scheduling, the description directly contradicts the annotations: it explicitly lists 'delete' as an action and mentions deleting cues, while destructiveHint is false. This is a clear annotation contradiction and warrants the lowest score per the rubric.

  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 several sentences long, but every sentence earns its place: it front-loads the purpose and action set, then explains the differentiating morph behavior, quantize options, and workflow in a compact, logical flow. There is no filler or redundancy; it is appropriately sized for the tool's complexity.

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

  Completeness5/5

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

  For a tool with five parameters, multiple action modes, and no output schema, this description is remarkably complete. It covers the system's purpose, the exact actions, prerequisites (create_control_panel), the morph mechanism including tempo-synced quantize, and differentiators from siblings. The absence of list return details is acceptable given no output schema, and the description fills the context needed for an agent to select and invoke this tool effectively.

  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 100% schema description coverage, the baseline is 3, and the description adds little beyond the schema. It mentions 'eased' crossfading and references Execute DAT, but the schema already details all parameters including action enum, duration default, quantize semantics, and comp_path. The description does not significantly improve parameter understanding beyond what the schema provides.

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

  Purpose5/5

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

  The description clearly states the tool's role as a live-performance scene system with a specific verb+resource: store/recall/morph/list/delete named cues (snapshots of a COMP's custom-parameter values). It distinguishes itself from the sibling manage_presets by explicitly naming the differing morph capability, making the purpose obvious and well-scoped.

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

  Usage Guidelines5/5

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

  The description explicitly contrasts with manage_presets, explaining that cues support timed morphing for stage use and suggesting when this tool is preferable. It also gives workflow guidance: 'Build cues with create_control_panel, then jump or morph between them.' The quantize parameter's musical timing use case is clearly described, providing strong contextual usage guidance.

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

• notch_touchengine_bridgeA
  3.9/5.0
  Behavior4/5

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

  Annotations declare readOnly=false, openWorld=true, and destructive=false. The description adds meaningful behavioral context: 'This does not validate a Notch license or target runtime; live validation remains explicit.' This discloses a limitation beyond the annotations. No contradiction; openWorldHint aligns with the explicit-validation caveat.

  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: the first states the main purpose and elements, the second a key caveat. Every sentence earns its place, no redundant wording, and the structure front-loads the primary action.

  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 10-parameter scaffold builder with no output schema, the description covers the core purpose and one limitation, but leaves ambiguities: what 'guarded' means concretely, side effects on existing nodes, or relationship to siblings like create_engine_comp. Annotations provide the safety profile, but the description could clarify more about behavior and prerequisites.

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

  Parameters3/5

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

  Schema coverage is 100% with per-parameter descriptions, so the schema carries the parameter documentation burden. The description adds only a general mention of 'optional Notch play/speed controls' which maps to expose_controls, but does not add new semantics 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 uses a specific verb ('Build') plus resource ('Notch TOP or Engine COMP/TouchEngine bridge scaffold') and lists key contents ('notes, output, optional play/speed controls'). It clearly distinguishes from siblings like create_engine_comp or connect_touchengine_notch by framing it as a 'guarded scaffold' creation tool.

  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 through the tool name and scaffolding frame, but gives no explicit when-to-use guidance or alternative tool exclusions. The caveat about not validating licenses/runtime hints at a use case (pre-validation scaffolding), but the description does not clearly state 'use this instead of X when you need Y'.

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

• apply_glsl_top_mappingA
  4/5.0
  Behavior3/5

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

  Annotations already indicate non-read-only and non-destructive behavior. The description adds that it builds a 'self-contained' network but does not disclose potential side effects like whether it overwrites an existing container, requires specific prerequisites, or validates the mapping. With annotations covering the safety profile, a 3 is appropriate.

  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-loads the core action, and contains no fluff. Every phrase earns its place by clarifying scope ('self-contained', 'pre-translated', 'foundation primitive', 'power users').

  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?

  Despite the complexity of the mapping object and 7 parameters, the rich schema covers parameter semantics. The description provides the missing high-level purpose and usage context. It could mention that a container COMP is created under parent_path, but that is already in the schema, so the description is complete enough for a well-documented 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 100%, with each parameter having its own description. The tool description repeats high-level components (fragment, uniforms, channels, controls) that map to the mapping object, but adds little beyond what the schema already documents. Baseline 3 is correct.

  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: 'Build a self-contained GLSL TOP network from a pre-translated mapping', with explicit components (fragment + uniforms + channels + controls). It distinguishes itself from siblings by positioning as a foundation primitive for Shadertoy/ISF importers and as a direct tool for power users, making it clear it is not the importer itself.

  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 gives clear context on when to use: when a pre-translated mapping already exists, particularly via importers or hand-translated fragments. It does not explicitly name alternatives or state when not to use it, but the reference to importers implies that translation happens elsewhere, providing adequate usage guidance.

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

• author_script_operatorA
  4/5.0
  Behavior4/5

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

  No contradiction with annotations (readOnlyHint=false, destructiveHint=true). The description adds valuable context beyond annotations: it creates the op plus callbacks DAT, returns a structured dict, and warns about cooking behavior. However, it doesn't clarify what destructive actions might occur (e.g., overwriting existing ops), which would be useful given the destructiveHint.

  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 lean and well-structured: it opens with the action and resource, lists key outputs, and closes with a behavioral caveat. Every sentence serves a purpose without redundancy.

  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 moderate complexity (5 params, no output schema), the description covers the main workflow, return values, and a key runtime nuance. It lacks details on edge cases like existing node overwrites or the meaning of 'warnings', but overall it is sufficiently complete for an agent to use correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The description adds no new parameter semantics beyond what the schema already explains (e.g., type inference for custom_params, on_cook_body injection). It mostly restates schema info.

  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 scaffolds a Script CHOP/DAT/SOP/TOP with an onCook stub and custom parameters. It distinguishes itself from sibling creation tools by detailing the companion callbacks DAT and per-family stub generation.

  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 describing the creation process, but does not explicitly mention when to use this tool versus alternatives like create_td_node or add_custom_parameters. The cooking note provides some context, but no clear exclusions or 'when-not-to-use' guidance.

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

• connect_obs_recorderA
  4/5.0
  Behavior4/5

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

  The description adds security-relevant context by stating the OBS password is passed only to the bridge payload and redacted from reports, which is not in the annotations. It also discloses what the scaffold includes, complementing the readOnlyHint=false and destructiveHint=false annotations without contradiction.

  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 sentences, front-loaded with the action verb and a clear object, with no filler. Every phrase adds value, covering the scaffold contents and the password redaction behavior.

  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 9-parameter scaffold tool with no output schema, the description conveys the core purpose, security handling, and publishing options. It does not detail return values or the exact scaffold structure, but the schema and openWorldHint annotation fill some gaps, making this adequate if not exhaustive.

  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?

  All 9 parameters are fully described in the input schema, so the description carries minimal additional parameter meaning. It mentions 'optional NDI or Syphon/Spout TOP publishing,' which corresponds to output_mode and source_top_path, but the schema already covers these fields.

  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') and resource ('TouchDesigner-side OBS control scaffold'), listing concrete components (obs-websocket v5 request templates, status/setup DATs, NDI/Syphon/Spout publishing). This clearly distinguishes it from sibling tools like obs_stream_control or connect_vmix_production.

  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—setting up OBS control in TouchDesigner—but does not explicitly state when to use this over alternatives or provide exclusion criteria. No sibling tool is named, so guidance is implied rather than explicit.

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

• connect_pangolin_beyondA
  4/5.0
  Behavior4/5

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

  Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description adds key behavioral context: it creates a scaffold, not a live-output system, and includes safety gating. This clarifies that the tool does not claim to provide real-time laser output, which is valuable behavioral information not captured in 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, concise sentence that front-loads the primary action ('Create a safety-gated Pangolin Beyond laser-control scaffold') and then lists key features. Every phrase earns its place, with no redundant or filler content.

  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?

  The description covers the essential purpose, safety characteristics, and key outputs (zone maps, cue maps, blackout notes). It also clarifies the 'no live-output' limitation, which is critical for agent decision-making. However, it does not detail the scaffold's structure or return value, and with no output schema, some additional information could be expected.

  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 (22%), so the description has a burden to clarify parameters. It adds some meaning by linking 'zone maps' to zone_count, 'cue maps' to cue_count, and 'blackout notes' to safety_blackout. However, it does not explain individual parameter values, defaults, or relationships in detail, leaving gaps for 9 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 clearly states the tool's function: 'Create a safety-gated Pangolin Beyond laser-control scaffold' with specific features like zone maps, cue maps, and blackout notes. It uses a specific verb ('Create') and resource ('Pangolin Beyond laser-control scaffold'), distinguishing it from other connect/create tools in the sibling list.

  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 context by mentioning 'safety-gated' and 'no live-output claim', suggesting it is for building a controlled scaffold rather than actual live control. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any competing tools or exclusions.

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

• create_audio_glsl_uniformsA
  4/5.0
  Behavior4/5

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

  The description discloses behavioral traits beyond the annotations: it is idempotent, creates no operators, and the binding takes effect every cook. These details add value over the readOnlyHint/destructiveHint annotations, which only state it is non-read-only and non-destructive. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is extremely concise: two sentences that front-load the core action and then provide a couple of high-value behavioral notes (no operators, idempotent/composable). No fluff, every clause earns its place.

  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 4-parameter tool with 100% schema coverage and no output schema, the description covers the key non-obvious details: it writes to existing glslTOP slots, is idempotent, and composes with create_glsl_shader. It does not mention return values, but for a parameter-binding operation this is not critical. The description is sufficiently complete for its complexity.

  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 provides 100% parameter description coverage, including details for bindings, expand_capacity, source_chop_path, and target_glsl_path. The description adds high-level context (e.g., named channels drive uniform slots) but does not elaborate on parameter syntax or semantics beyond what the schema already covers. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly specifies the action ('Writes CHOP-reference expressions onto the seq.vec uniform slots'), the target resource ('existing glslTOP'), and the effect ('drive shader uniforms every cook'). It distinguishes itself from sibling tools by emphasizing it creates no operators and is a pure parameter binding, which differentiates it from create_glsl_shader.

  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 implicitly conveys when to use it (with an existing glslTOP and a CHOP source) and mentions composability with create_glsl_shader, but it does not explicitly state exclusions or name alternative tools for other binding scenarios (e.g., bind_to_channel or bind_audio_reactive). The usage context is clear but not fully explicit.

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

• create_chroma_reactiveA
  4/5.0
  Behavior3/5

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

  Annotations already flag readOnlyHint=false, so the fact that the tool creates something is not new. The description adds useful behavioral detail: the output is a Null CHOP ready for bind_to_channel, and the audioSource convention is shared with certain siblings. It does not disclose side effects like behavior on repeated runs or conflict with existing nodes, but given the annotations cover safety, a 3 is appropriate.

  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?

  Three sentences, each earning its place: the experimental tag, the core build function and output type, and the relationship to sibling tools. Front-loaded with the main purpose, no wasted words.

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

  Completeness4/5

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

  For a 5-parameter creation tool with no output schema, the description does enough: names the output (Null CHOP ready for bind_to_channel), mentions the FFT fold, and establishes the audioSource pattern. The experimental tag is noted. It could add more about prerequisites or error conditions, but given the schema covers audioSource's permission issue, it's fairly complete.

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

  Parameters3/5

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

  Schema coverage is 60%, so the description needs to compensate partially. The description mentions the audioSource convention and the FFT-to-pitch-class mechanism, which adds meaning to audioSource and fftSize. However, name and parent remain undocumented, and the description does not elaborate on fftSize choices or smoothing 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 the tool's function: it builds a 12-channel pitch-class chroma vector from an audio bus via FFT bin folding. It also distinguishes itself from related tools by naming create_transient_reactive and create_energy_reactive and noting the shared audioSource convention, making it unmistakable 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 Guidelines4/5

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

  The description provides clear context on when to use this tool: when you need a chroma vector for pitch-class analysis, ready for bind_to_channel. It also references sibling tools and a shared audioSource convention, implying alternatives exist. However, it does not explicitly state when NOT to use it or contrast use cases beyond the mention of the two siblings.

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

• create_hand_hologramA
  4/5.0
  Behavior4/5

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

  With annotations declaring non-readOnly and openWorldHint, the description adds significant behavioral detail: the default synthetic cube, open-palm visibility, float anchor positioning, opposite-hand pinch controlling scale/glow, and optional audio. It does not contradict annotations and enhances understanding of how the tool behaves in real use, though it doesn't cover every side effect (e.g., component creation path).

  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 totaling 59 words, with the primary purpose front-loaded. Every sentence contributes meaningful behavior, defaults, or dependencies, with no fluff or repetition of schema information. It is an exemplar of concise, information-dense description.

  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 high complexity (21 parameters, no output schema, no parameter descriptions), the description is notably incomplete. It fails to mention prerequisites (e.g., does create_hand_gesture_bus need to already exist?), return values, or effects on existing components. The interactive behavior is well-covered, but an agent would still be unaware of many configuration options and potential side effects, making it insufficient for a tool of this complexity.

  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 has 0% parameter description coverage, so the description must compensate. It provides meaning for key parameters: 'synthetic' (source), 'holographic cube' (preset), pinch controlling scale/glow (size, glow, pinch_scale_amount), 'float anchor' (float_height), and audio modes (audio_mode). However, with 21 parameters, many remain unexplained (e.g., color, accent_color, resolution, comp_name), so the compensation is partial.

  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: 'Build a palm-anchored hologram visual' with the resource being a hologram visual. It also distinguishes itself from siblings by highlighting the driving dependency ('create_hand_gesture_bus') and describing concrete interactive behaviors, making it clear this is not a generic creation tool or a bus builder.

  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 gives clear context on when to use the tool: when you need a palm-anchored hologram driven by hand gestures. It implies prerequisite usage by mentioning 'driven by create_hand_gesture_bus' and outlines default and interactive behaviors. However, it doesn't explicitly state alternatives or exclusions, so it falls short of a 5.

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

• create_interactive_projection_mappingA
  4/5.0
  Behavior4/5

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

  Annotations already indicate a mutating, non-destructive, open-world operation. Description adds specifics: 'synthetic-safe', default source behavior, and returns 'explicit warnings for camera, blob tracking, and physical calibration states' — useful behavioral context not present in 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?

  Three sentences, front-loaded purpose, zero filler. Lists key components and behavioral notes efficiently.

  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?

  Complex 23-parameter tool with no output schema; description informs about return paths and warnings, plus source-mode decision. Slight gap: no explicit guidance on interpreting warnings or when to use existing_top, but schema and description together are sufficient.

  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 covers 100% of parameters with descriptions. Description adds high-level context (defaults, warnings) but does not detail individual parameter syntax beyond what schema provides.

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

  Purpose5/5

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

  Description opens with a specific verb 'Build' and resource 'interactive projection mapping rig for a USB webcam plus projector', enumerating components. This clearly differentiates from siblings like create_projection_mapping by emphasizing interactivity and webcam/synthetic source.

  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?

  Provides context on source default and synthetic preview, but does not explicitly name when to use this vs alternatives like create_projection_mapping or projector_calibration_wizard. Exclusion criteria are absent.

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

• create_node_chainA
  4/5.0
  Behavior4/5

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

  Beyond the annotations (non-read-only, non-destructive), the description discloses that on failure it stops and reports partial progress without deleting anything, and that it returns all created paths. This adds valuable behavioral context about error handling and return behavior that annotations do not cover.

  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 core action, and the second sentence adds critical failure/return behavior without excess. Every sentence serves a purpose, 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?

  The rich schema fully documents parameters, and the description covers failure semantics and return values, making the tool adequately specified for an agent. It lacks explicit prerequisites (e.g., parent_path must exist), but overall it is sufficient for correct invocation.

  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 provides 100% coverage with detailed descriptions for all three parameters, including the nodes array structure, parent_path, and connect_sequentially. The tool description adds little beyond what the schema already states, only reiterating the optional connection behavior; no new parameter semantics are introduced.

  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 resource 'multiple nodes', with the optional 'connect them in sequence' clearly distinguishing it from singular create tools like create_td_node. It states exactly what the tool does and its scope, leaving no ambiguity about its purpose.

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

  Usage Guidelines3/5

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

  The description implies usage when creating a chain of nodes, but it does not explicitly state when to use this tool over alternatives like create_td_node or connect_nodes. No exclusions or alternative tool references are provided, leaving the usage context somewhat implicit.

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

• create_nuitrack_body_busA
  4/5.0
  Behavior4/5

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

  The description adds useful behavioral context beyond the annotations: it says the tool 'Produces a stable body_bus CHOP contract and setup notes' and warns that 'live SDK/device calibration must be validated separately.' This tells the agent about the output format and a critical limitation. The annotations only indicate read/write/destructive flags, so this extra context is valuable.

  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, concise and front-loaded. The first sentence states the action and scope, the second sentence describes the output and a key caveat. No redundant or filler content.

  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?

  The description is reasonably complete for a scaffold tool: it covers what is created (scaffold, CHOP contract, setup notes), the transport modes, and a necessary caveat about calibration. It does not explain return values in detail, but there is no output schema. Given the 9 parameters and lack of output schema, the description provides enough context to understand the tool's outcome and limitations, though it could have elaborated on sample mode or the 'stable' contract.

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

  Parameters3/5

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

  Schema description coverage is 100% (every parameter has a description), so the baseline is 3. The tool description does not add significant extra parameter semantics beyond what the schema already provides; it only lightly references transport modes and output contract, which map to existing parameters like 'source' and 'channel_prefix'.

  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: 'Create a TouchDesigner scaffold for Nuitrack skeleton data' with explicit transport modes (OSC, WebSocket, TCP JSON, sample). It names the resource (TouchDesigner scaffold for Nuitrack skeleton data) and the verb (Create), distinguishing it from sibling tools like create_azure_kinect_body_bus or create_optitrack_tracking_bus.

  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 Nuitrack skeleton data scenarios, but does not explicitly mention when to use it versus alternatives, nor provide exclusions. It does not name sibling tools or say 'use this instead of X'. The caveat about calibration being validated separately is more of a warning than a usage guideline.

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

• create_orbbec_depth_silhouetteA
  4/5.0
  Behavior4/5

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

  With annotations already indicating non-readonly (false) and non-destructive (false), the description adds valuable behavior details: synthetic/file fallbacks, stable output TOP names, and explicit hardware/SDK validation warnings. This helps the agent predict outcomes even when hardware is absent, though it does not disclose every potential side effect.

  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, dense sentence that front-loads the core purpose and packs in the key differentiators (hardware compatibility, fallbacks, stable outputs, validation warnings). Every phrase earns its place, with no wasted words or redundancy.

  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 tool with 10 parameters and no output schema, the description gives a solid overview: it explains what is created, fallback behavior, stable TOPs, and validation warnings. However, it doesn't elaborate on the scaffold structure or prerequisite setup, but the rich schema compensates. Overall, it is reasonably complete for an agent to select and invoke the 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?

  The input schema provides 100% coverage with descriptions for all 10 parameters, so the description need not repeat them. The description's mention of 'synthetic/file fallbacks' touches on the source parameter behavior, but it does not add meaningful semantic detail beyond what the schema already offers. Thus the baseline of 3 applies.

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

  Purpose5/5

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

  The description clearly states a specific action (create), the resource (Orbbec/Kinect-compatible depth silhouette scaffold), and key features (fallbacks, stable TOPs, validation warnings). It distinguishes itself from the generic sibling create_depth_silhouette by specifying the hardware compatibility. This gives the agent a precise understanding of 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 Guidelines3/5

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

  The description implies usage for Orbbec/Kinect depth setups and mentions fallbacks, but it does not explicitly state when to use this tool over alternatives like create_depth_silhouette or other depth-source tools. No exclusions or conditional guidance is provided, leaving the decision somewhat implicit.

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

• create_sam2_segmentation_bridgeA
  4/5.0
  Behavior4/5

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

  Annotations already indicate non-read-only and non-destructive behavior. The description adds useful behavioral detail by listing the created subcomponents and explicitly noting that no model is bundled, setting accurate expectations. It does not mention potential side effects like overwriting existing containers or network calls, but the annotation coverage reduces the burden.

  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: the first states the high-level action, the second lists deliverables and the no-model caveat. Every word earns its place with no redundancy.

  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?

  The rich schema and annotations cover most operational details. The description gives a good overview of what will be created but omits information about return values or prerequisites (e.g., external service must be running), which is not covered elsewhere. For a tool with 9 parameters and external service integration, slightly more context would be helpful, but the current level is 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?

  All 9 parameters are fully described in the schema (100% coverage), so the description does not need to elaborate. It provides context that the bridge is for an external SAM2/FastSAM service but does not add syntax or format details beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool builds a TouchDesigner bridge surface for an external SAM2/FastSAM segmentation service and enumerates the specific components it creates (source input, mask receiver, mask_out, matte_out, preview_out). This precise verb+resource combination distinguishes it from sibling creation tools.

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

  Usage Guidelines3/5

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

  The description implies usage for external SAM2/FastSAM segmentation integration but does not explicitly state when to use it over alternatives or provide exclusions. No comparison with similar bridge tools such as connect_comfyui or create_external_io is provided.

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

• create_set_navigatorA
  4/5.0
  Behavior3/5

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

  Annotations indicate non-read-only and open-world behavior; the description adds that the navigator 'drives manage_cue recall' on the target, revealing a side effect, and mentions optional beat quantization. However, it doesn't disclose potential failure modes, prerequisites beyond the stated workflow, or what exactly changes on the target, leaving some behavioral gaps.

  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 at three sentences, front-loaded with the main purpose, then features, then usage context. Every sentence contributes unique value with no redundancy or filler.

  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?

  The description covers the tool's purpose, interaction model, integration with manage_cue, and when to use it. It lacks an explicit return value description, but the schema's parameter descriptions and the absence of an output schema make this a minor omission. Overall, it's sufficiently complete for a creation 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?

  The input schema has 100% parameter coverage with descriptive text for each parameter. The description adds minimal parameter-level detail, only referencing 'quantize GO' which aligns with go_on_beat. Since the schema already handles parameter semantics, the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it builds a 'hands-light stage navigator' with specific interactions (Next/Prev/Go/Index), and distinguishes it from other create tools by referencing the QLab model and its reliance on manage_cue. The verb 'Build' and resource are explicit.

  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?

  It gives clear usage context: 'Use after building a control panel with manage_cue cues stored' and contrasts with 'instead of recalling by name.' It doesn't explicitly name alternative tools, but provides a clear workflow and an alternative approach, meeting the threshold for good guidance.

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

• create_transient_reactiveA
  4/5.0
  Behavior3/5

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

  Annotations already indicate this is a write operation (readOnlyHint: false) and non-destructive. The description adds useful output location details and mentions the custom parameter page on the parent COMP, but does not disclose all side effects like creating a container COMP or wiring an internal audio device when audioSource is empty.

  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?

  Three sentences, each earning its place: definition, companion usage, and parameter tweaking location. No fluff or redundancy.

  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 (8 parameters, no output schema), the description covers the core purpose, output location, channel names, and a usage suggestion. It does not detail every parameter interaction, but the schema handles those. Reasonably complete for a mid-complexity creation 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 coverage is 100%, so the description does not need to explain parameters. It mentions 'Sensitivity + per-envelope attack/release' as a high-level grouping, but this adds no new meaning beyond the schema descriptions. Baseline 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Layer-1 audio splitter: differences a fast and a slow envelope follower to expose two normalized 0..1 channels — transient and sustain — on a Null CHOP at {comp}/out.' This specifies a unique action and output, distinguishing it from generic audio envelope tools.

  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?

  It provides a specific usage context: 'Pair with bind_to_channel to drive visuals from percussion vs sustain independently.' However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.

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

• create_yolo_onnx_trackerA
  4/5.0
  Behavior4/5

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

  Annotations already indicate this is a non-destructive, writable operation with potential external interaction. The description adds valuable behavioral context by specifying the exact operators it creates and the dependency on an external detector or validation, which goes beyond what the annotations provide. It does not fully disclose overwrite behavior or permissions, but the bar is lower due to existing 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 two sentences with high information density: the first sentence names the action and deliverables, and the second notes the critical live-detection dependency. Every word contributes value, with no redundancy.

  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 (10 parameters, creation tool, no output schema), the description adequately covers the scaffold's components and the external-runtime constraint. It could be enhanced by stating what the tool returns (e.g., container path or manifest), but this is not essential for a create operation that likely returns a standard result.

  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?

  All 10 parameters have full descriptions in the JSON schema (100% coverage), so the tool description does not need to add parameter-level detail. The description adds no extra semantics beyond the schema, making the baseline score of 3 appropriate.

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

  Purpose5/5

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

  The description states a specific action ('Build a deterministic TouchDesigner scaffold') and resource ('YOLO-style object tracking'), and lists the concrete deliverables (source input, backend receiver placeholder, detections DAT, stable tracks_out CHOP channels, annotated_out TOP, setup notes). This clearly distinguishes it from sibling tools that handle other tracking types or general 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?

  The description mentions that 'Live detection requires an external detector or validated TouchDesigner Python ONNX runtime,' which implies the tool is for scaffolding rather than producing a live tracking system. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so usage direction remains implicit rather than explicit.

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

• diff_snapshotsA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with 'Pure analysis — touches nothing in TouchDesigner,' but adds no substantial new behavioral disclosure beyond what annotations provide. It does not mention potential performance or memory implications.

  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 three sentences, front-loaded with the main action, and each sentence adds value: purpose, usage scenarios, and safety. No fluff or redundant details.

  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?

  The description covers the tool's purpose, usage workflow, and safety, and the schema provides input structure. It is fairly complete for an analysis tool with no output schema, though it could mention limitations or expected output format. Overall, it gives enough context for an agent to select and invoke the tool correctly.

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

  Parameters3/5

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

  Schema coverage is 100% and the schema descriptions for 'before' and 'after' already explain their role and origin (e.g., 'Earlier snapshot (from snapshot_td_graph, include_params for param diffs)'). The description does not add new input-specific semantics beyond referencing the source of snapshots.

  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 ('Compare'), resource ('two network snapshots from snapshot_td_graph'), and output ('readable diff' with added/removed nodes, connection changes, parameter changes with before/after values). It distinguishes itself from sibling tools like compare_td_nodes by focusing on network snapshots rather than individual nodes.

  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 explicit usage scenarios: 'Snapshot before an edit and after to see exactly what changed, or to version a patch over time.' This implies when to use the tool and what to prepare. It does not mention specific alternatives or exclusions, but the context is clear and actionable.

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

• draft_recipe_from_operator_chainA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, but the description adds specific context beyond that: 'without writing files or touching the TD bridge'. This clarifies the non-destructive and non-interactive nature of the tool, which is valuable context not fully captured by 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 front-loads the most important information ('Read-only') and clearly states the action and output. Every word earns its place, with no unnecessary details or repetition.

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

  Completeness4/5

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

  Given that an output schema exists, the description need not explain return values. It adequately covers the tool's purpose, read-only nature, and output being a 'draft', which is sufficient for an agent to understand the high-level behavior. It does not mention error cases or strict mode, but those are covered by the schema and parameters.

  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 high (78%), and the description does not add parameter-level details beyond what the schema already provides. The only mention of 'ordered TouchDesigner operator chain' aligns with the 'chain' parameter description in the schema, so the description adds no new semantic value for 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 clearly states the tool converts an 'ordered TouchDesigner operator chain' into a 'RecipeSchema draft', using a specific verb and resource. This distinguishes it from sibling tools like draft_recipe_from_technique or draft_recipe_from_tutorial by focusing on operator chains as input.

  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 framing the operation as 'Read-only' and noting it avoids writing files or touching the TD bridge, which suggests safe use for conversions without side effects. However, it does not explicitly mention when to use this tool versus alternatives or provide exclusions, so guidance is only implicit.

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

• draft_recipe_from_techniqueA
  4/5.0
  Behavior4/5

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

  The description explicitly says 'Read-only' and 'without writing files or touching the TD bridge,' which adds safety context beyond the annotations (readOnlyHint, destructiveHint). It also clarifies the input scope ('embedded' technique) and the nature of the operation (conversion to a draft). This goes beyond simple annotation repetition, though it doesn't cover error paths or edge cases.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that starts with the safety annotation ('Read-only') and then states the action and output. Every part of the sentence adds value without redundancy or fluff, 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?

  The description provides clear purpose and safety profile, and the output schema covers return values. However, it does not mention when to choose this tool over sibling recipe-drafting tools, and it doesn't discuss failure modes (e.g., what happens if conversion fails, which is relevant to the strict parameter). Given the overall complexity (10 params, output schema), it is adequate but not fully exhaustive.

  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 all 10 parameters, each with meaningful details. The tool description does not add parameter-specific semantics beyond the schema, but it doesn't need to; the schema already provides the necessary information. The only minor addition is the inference that include_glsl_code relates to the 'GLSL source' mentioned in the 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 the verb and resource: 'convert an embedded TouchDesigner technique with GLSL source into a RecipeSchema draft.' It also differentiates from siblings like draft_recipe_from_operator_chain and draft_recipe_from_tutorial by specifying the source type (embedded technique with GLSL). The 'without writing files or touching the TD bridge' adds scope 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 usage for drafting recipes from embedded techniques, but it does not explicitly state when to use it vs alternatives like draft_recipe_from_operator_chain or draft_recipe_from_tutorial. No when-not conditions or alternative guides are provided, so it relies on the reader to infer the appropriate context.

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

• export_render_presetA
  4/5.0
  Behavior3/5

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

  Annotations already establish readOnly=false and destructive=false, so the description only needs to add behavioral context. It discloses that the tool records a TOP to a file via TouchDesigner and documents expected codec/extension/fps for downstream playback, which adds value beyond the annotations. However, it doesn't mention overwrite behavior or whether starting a new export replaces an existing one, so the transparency is adequate but not exhaustive.

  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 exactly two sentences, front-loaded with the core action and preset list, then adding the recorder relationship and downstream documentation purpose. Every clause earns its place with no redundancy or fluff.

  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 start/stop tool, the schema covers parameter requirements, and the description explains the recording mechanism, presets, and downstream documentation benefit. There is no output schema, so return values aren't expected, but the description doesn't mention whether the call blocks or signals completion; this minor gap is offset by the strong schema coverage.

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

  Parameters3/5

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

  Schema coverage is 100% with detailed parameter descriptions, so the description need not explain parameters. The prose lists presets by name, but that only echoes the enum values without adding new semantics. Baseline 3 is appropriate when the schema fully carries parameter meaning.

  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: start/stop a movie export using named VJ/editorial presets, listing specific presets and explicitly distinguishing it by reusing record_movie's Movie File Out TOP recorder. The verb-resource relationship is precise and scope is well-defined.

  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 this tool is a preset-driven wrapper around record_movie's recorder, offering clear context for when to use it (for named delivery presets). It doesn't explicitly state when not to use it or provide exclusions, but the relationship to record_movie is implicitly a usage guideline.

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

• get_technique_detailA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with 'Read-only' and adds the context of 'embedded' technique packs, but does not disclose additional behavioral details such as return format or potential errors. No contradiction with annotations.

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

  Conciseness5/5

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

  Single sentence, front-loaded with the read-only safety qualifier, and precise with no filler 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 simple read-only nature, the presence of an output schema, and annotations covering safety, the description is largely complete. It could be more explicit about what constitutes a 'technique pack' or navigation between category and technique_id, but it suffices for basic use.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description mentions optional code snippets and setup/workflow details, mapping to include_code and include_setup, but does not add meaning beyond the schema's own property descriptions.

  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 inspects embedded TouchDesigner technique packs and individual techniques, using the specific verb 'inspect' and naming the resource scope. This distinguishes it from sibling tools by focusing on technique pack internals.

  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 clear context for when to use this tool, i.e., for read-only inspection of embedded technique packs and techniques. However, it does not explicitly mention alternatives or when-not to use it, falling short of a 5.

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

• obs_stream_controlA
  4/5.0
  Behavior4/5

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

  Annotations say readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds meaningful context beyond these: it discloses the authentication limitation ('tdmcp never accepts or stores OBS passwords') and instructs manual Identify completion, which is not covered by annotations. It also specifies WebSocket v5 and op:6 request payloads, giving the agent insight into the underlying mechanics.

  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 core action and resource. It includes an actionable list of commands and an important security caveat. Every sentence earns its place 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 complexity of generating a control rig and the absence of an output schema, the description covers the main deliverable (components), supported commands, and the critical authentication requirement. It does not explain the post-generation workflow or lifecycle, but the schema handles parameter context, so the information is sufficient for an agent to understand the tool's scope.

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

  Parameters3/5

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

  Schema description coverage is 100% with all 9 parameters documented. The description does not add parameter-specific details beyond what is in the schema; it reinforces the role of scene and record controls but does not introduce new semantics. Baseline 3 is appropriate when schema carries the descriptive burden.

  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: creating an OBS WebSocket v5 control rig in TouchDesigner. It specifies the exact components (websocketDAT, Constant CHOP, chopExecute DAT) and enumerated commands (StartStream, StopStream, ToggleStream, StartRecord, StopRecord, ToggleRecord, SetCurrentProgramScene), making it distinct from sibling tools like connect_obs_recorder or create_control_surface. The verb 'Create' is specific and the resource is well-defined.

  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 building an OBS control rig but does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or a comparison with siblings such as connect_obs_recorder. The context is clear but exclusions and alternative guidance are missing.

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

• qlab_osc_bridgeA
  4/5.0
  Behavior3/5

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

  Annotations indicate readOnly=false and destructive=false, which align with 'create'. Description adds useful context about not needing QLab during build and exposing routes to a configurable port, but doesn't disclose runtime behavior or potential side effects beyond that.

  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, front-loaded with the core action and resource. Every phrase adds value; no wasted words.

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

  Completeness4/5

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

  For a build tool with all parameters documented, description covers the main purpose, exposed routes, and a key build-time condition. No output schema or return value explanation necessary. Could mention dependencies on other primitives, but the primitive is named.

  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?

  Input schema defines all 6 parameters with descriptions (100% coverage). Description adds slight context by referencing optional cue routes that map to cue_numbers, but doesn't add significant meaning 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?

  Description identifies a specific action (create a QLab OSC control bridge), names the primitive used (OSC router matrix primitive), and lists the exact routes exposed. This distinguishes it from sibling tools like connect_qlab_cue_stack or osc_router_matrix.

  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 clear context on what the tool does (builds a bridge with specific OSC routes) and a key non-requirement (QLab doesn't need to run during build). No explicit alternatives are named, but the use case is unambiguous.

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

• validate_operator_chainA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with 'Read-only' and 'does not create or modify TD nodes' and adds the validation criteria, but does not disclose other behavioral aspects (e.g., error handling, performance). Consistent with annotations.

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

  Conciseness5/5

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

  A single, well-structured sentence front-loaded with 'Read-only' immediately conveys safety. Every phrase adds value without unnecessary repetition.

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

  Completeness4/5

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

  The description covers the tool's purpose, validation scope, and safe behavior. Since an output schema exists, return values don't need description. Minor gaps like the meaning of 'documented connections' are acceptable given the schema's parameter descriptions.

  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?

  Input schema covers all 5 parameters with 100% description coverage. The description mentions 'family/category filters' and 'version compatibility', which maps to the family/category/target_version parameters, but adds little beyond what the schema already describes.

  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 ('validate') and resource ('ordered TouchDesigner operator chain'), and clarifies the validation scope (embedded docs, connections, filters, version compatibility). This distinguishes it from sibling tools like suggest_operator_chain or create_node_chain.

  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 states the context for use: validating an ordered chain against specific criteria. It does not explicitly list exclusions or alternative tools, but the 'validate' framing provides clear context without confusion.

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

• add_custom_parametersA
  4.1/5.0
  Behavior5/5

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

  The description significantly enriches the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=true) with concrete behavioral details: transactional rollback to prior snapshot, EXPORT returning an error without mutation, reversible EXPRESSION/BIND, protected built-ins, and no raw Python fallback. These are not present in structured data and give agents crucial expectations beyond generic mutation hints.

  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 front-loaded with the core purpose in the first sentence, followed by compact behavioral details. It is reasonably concise for the complexity, though some clauses like 'no raw Python or /api/exec fallback is used' and 'Legacy page+params calls remain valid' are peripheral and could be trimmed without losing essential guidance.

  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?

  The tool is complex with nested operations and multiple parameters. The description covers transactionality, auth, supported types, and key safety behaviors, which is substantial. However, it does not explain the response format (no output schema exists) nor dive into the exact semantics of each operation action, leaving some gaps for such a multi-faceted tool. Overall, quite complete but not exhaustive.

  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 0% schema description coverage, the description must compensate for parameter meaning. It provides meaningful details on supported types and mode behavior (EXPRESSION/BIND reversible, EXPORT held), but does not explain the idempotency_key purpose, the precise semantics of operation actions (e.g., sort_page expects an order array), or the role of fields like menu_names vs menu_labels. Partial compensation, not fully 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 a specific verb+resource: 'Transactionally add, edit, delete, sort, and organize a COMP's custom parameters.' It also lists supported types and the authenticated route, distinguishing it from sibling parameter tools like update_td_node_parameters which target existing parameters. The scope 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 Guidelines3/5

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

  The description implies use for managing custom parameters and notes that legacy page+params calls remain valid, offering limited context. However, it does not explicitly contrast with alternative tools like update_td_node_parameters or set_parameter_expression, nor provide when-not-to-use conditions beyond implied protection of built-ins. Only guidance is implied, not explicitly stated.

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

• build_chop_chainA
  4.1/5.0
  Behavior4/5

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

  The description reveals key behavioral traits not in annotations: fail-forward warnings, partial chain returns, and the wiring pattern. It adds useful context beyond the readOnly/destructive hints. No contradiction with annotations.

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

  Conciseness5/5

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

  Three sentences, each earning its place: purpose, usage/wiring, and failure behavior plus a tip. Front-loaded and free of fluff.

  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 schema richly covers inputs, but with no output schema the description only vaguely says 'returns useful info' without specifying the return format. For a side-effecting builder, this is a gap, though fail-forward behavior is helpfully disclosed.

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

  Parameters3/5

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

  Schema coverage is 100%, and the description repeats what the schema already documents (ops list structure, wiring, parent default). It adds no new param-level semantics, so a baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool builds an ordered CHOP processing chain declaratively, identifying the resource (CHOP chain) and distinguishing it from sibling tools like build_pop_chain. The verb 'builder' plus specific 'CHOP' resource makes 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 Guidelines4/5

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

  The description explains the core usage pattern (pass an ops list, wiring output 0 to input 0, parent default) and offers a practical tip about ending with nullCHOP for bind_to_channel readiness. It does not explicitly list alternative tools or when-not-to-use, but the context is clear.

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

• control_timeline_transportA
  4.1/5.0
  Behavior4/5

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

  Annotations already mark it as a mutation (readOnlyHint=false). The description adds valuable context: it returns the timeline state for verification, and it discloses the side effect of pausing freezing downstream chains. This exceeds what annotations alone convey.

  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?

  Three concise sentences: purpose, return value, and a side-effect warning. Every sentence earns its place and information is front-loaded.

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

  Completeness5/5

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

  For a tool with good annotations and 100% schema coverage, the description covers all essential aspects: actions, return behavior, and a notable side effect. No output schema exists, but the return value is described, so no critical gaps remain.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description does not add parameter details beyond what the schema already provides; it only maps high-level actions to parameter names implicitly.

  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 drives the TouchDesigner project timeline with specific verbs (play, pause, seek, jump, set rate), distinguishing it from sibling tools that manage cues or query info.

  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 through the enumerated actions, but the description does not explicitly state when to use this tool versus alternatives like manage_cue or execute_python_script, nor any exclusions.

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

• create_auto_montageA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate non-read-only, non-destructive, and open-world behavior; the description adds valuable context about scanning folders, building the TOP network, exposing custom pars, emitting a state_out CHOP, and handling a missing folder gracefully. This goes beyond the annotations and provides actionable behavioral details.

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

  Conciseness4/5

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

  The description is a single dense paragraph that is front-loaded with the core purpose. It contains technical jargon that may be more than necessary, but every sentence adds meaningful information about behavior, exposed pars, and error handling, making it useful without being overly verbose.

  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 complexity (14 parameters, no output schema), the description thoroughly covers the tool's function, internal architecture, exposed interface (pars and state_out), and failure handling. It does not explicitly state a return value, but the created container and output CHOP are inferable from the context.

  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?

  All 14 parameters are fully documented in the schema with descriptions (100% coverage), so the baseline is 3. The description adds architectural context linking mode and clock to the CHOP execution logic, but it does not significantly redefine parameter semantics beyond what the schema already provides.

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

  Purpose5/5

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

  The description clearly states the tool 'build a self-running clip montage' from a folder, with a specific verb and resource. It distinguishes itself from siblings by focusing on the auto-advance/montage structure, including the TOP network and CHOP-based brain.

  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 usage context: point at a folder to build a montage, and it explains behavior when the folder is missing. However, it does not explicitly compare against sibling tools like create_video_player or create_clip_launcher, nor does it state when not to use it.

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

• create_chrome_blobsA
  4.1/5.0
  Behavior3/5

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

  Annotations already cover readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds context by stating it creates a self-contained baseCOMP and exposes controls, and it describes the internal pipeline. However, it does not disclose potential side effects, required permissions, or behavior when a component with the same name exists, leaving gaps 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 two focused sentences that front-load the core purpose and then explain the technical pipeline and output. Every sentence adds value, with no filler or redundancy.

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

  Completeness5/5

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

  For a creation tool with no output schema, the description explains what is built, how it works, and what controls are exposed. Combined with rich parameter descriptions and annotations, the agent has sufficient information to decide when and how to invoke it. The result of the tool (a baseCOMP) is clearly stated.

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

  Parameters3/5

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

  Schema coverage is 100%, with each parameter having a clear description. The description adds little beyond listing the exposed control names (Speed, Blob_Count, Metal_Color, Background), which are already fully documented in the schema. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

  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 ('Builds') and resource ('liquid-chrome / Y2K metaball generator'), detailing the pipeline from Noise TOP through GLSL TOP and the resulting self-contained baseCOMP with exposed controls. This clearly distinguishes it from sibling creation tools by describing the exact visual effect and output.

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

  Usage Guidelines4/5

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

  The description clearly implies when to use this tool (when you need a chrome metaball generator) and describes the output, but it does not explicitly name alternatives or state when not to use it. The context is clear, yet exclusions or alternative tool references are absent.

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

• create_decksA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnly=false, openWorld=true, destructive=false. The description adds architectural details: per-deck gains, FX-send bus, Switch for cuts, Cross chain, and output as a Null. It also notes test sources are auto-created, giving behavioral insight beyond annotations.

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

  Conciseness4/5

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

  Four dense sentences front-loaded with the main purpose. Each sentence adds architectural information without fluff; could be more scannable but is well within acceptable length.

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

  Completeness4/5

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

  For a complex 8-parameter builder with no output schema, the description explains both modes, the internal network, output type (Null), and test-source fallback. It lacks edge-case error handling but is otherwise sufficient.

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

  Parameters3/5

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

  Schema coverage is 100% with detailed per-parameter descriptions, so the baseline is 3. The description connects parameters to the topology (e.g., cut_mix relates to the Switch and final Cross) but doesn't add new format or syntax details beyond what schemas provide.

  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 'Build a DJ-style VJ mixer' – a specific verb and resource. It then clearly distinguishes two build modes (legacy A/B vs 2-8 deck) and names concrete TOP elements, which separates it from sibling tools like create_layer_mixer.

  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?

  It clearly describes the tool's role in building a mixer and explains when each mode applies (with/without decks[]), but it does not explicitly compare to alternatives like create_layer_mixer or state exclusions, so context is clear but alternatives are not named.

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

• create_detection_reactiveA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate write behavior (readOnlyHint=false), and the description adds valuable context: it creates a Null CHOP with a stable contract (presence, count, bboxes), subscribes to an external WebSocket, scaffolds a CPU Script CHOP, and is ready for bind_to_channel. No contradictions with annotations.

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

  Conciseness4/5

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

  The description is a single, dense paragraph. All sentences contribute: purpose, two backends, output contract, and legal note. It is front-loaded and free of fluff, though slightly longer than ideal. No wasted 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 8 parameters and no output schema, the description compensates well by defining the output contract and the two modes. It could mention prerequisites (e.g., external detector running for websocket) or error handling, but the high schema coverage and detailed description make it reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all 8 parameters. The description offers an overview of backend-specific behavior but does not add meaning beyond what the schema already provides (e.g., '(websocket)' and '(onnx)' annotations in param descriptions). Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description states a specific action ('Turn object/person detection into TouchDesigner control channels'), names the two backends, and highlights a key differentiator ('NO CUDA requirement'). It clearly distinguishes itself from siblings like create_yolo_onnx_tracker and bind_to_channel by detailing the output contract.

  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 on when to use each backend ('websocket' for external processes, 'onnx' for CPU inference) and notes the no-CUDA advantage. It does not explicitly name alternative tools or give 'when not to use' exclusions, but the backend guidance is enough for selection.

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

• create_geo_visualizationA
  4.1/5.0
  Behavior4/5

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

  Annotations already indicate non-read-only and non-destructive, and the description adds substantial behavioral detail: it builds a Script SOP, a Geometry COMP, and a camera+light Render TOP; describes projection and extrusion logic; and includes a licensing note. It stops short of describing exact network side effects (e.g., whether parent_path is overwritten), but the core behavior is transparent.

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

  Conciseness4/5

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

  The description is a single dense sentence that efficiently packs the essential pipeline stages, followed by a short license note. It is not overly verbose, though it could be split into clearer sentences. All content is relevant and earns its place.

  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 there is no output schema, the description compensates by describing the created network structure (Script SOP, Geometry COMP, Render TOP) and the data transformation approach. It omits explicit mention of return values (none expected) but covers the tool's overall functionality and important legal context. It is complete enough for an agent to select and invoke the tool correctly.

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

  Parameters3/5

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

  The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description reinforces the meaning of 'extrude' and 'default_height' by explaining the extrusion of ribbon walls using the 'height' property, but it does not add significant new meaning beyond the schema's existing parameter descriptions.

  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 begins with a specific verb ('Turn') and a concrete resource ('GeoJSON') into a 3D city visualization. It clearly distinguishes itself from generic 'create_visualization' or 'create_3d_scene' tools by detailing the exact pipeline (Script SOP, Geometry COMP, Render TOP) and supported feature types (Point/LineString/Polygon/Multi*).

  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 states clear context: it's for GeoJSON data, especially OSM-derived city data. Though it doesn't explicitly name alternative tools or exclusion criteria, the phrase 'Turn GeoJSON ... into a 3D city visualization' makes the intended use obvious. The note about ODbL licensing also guides responsible use.

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

• create_pose_controlnet_driverA
  4.1/5.0
  Behavior4/5

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

  With annotations already declaring it is not read-only and not destructive, the description adds valuable detail: GPU-rasterized via a single GLSL TOP, sampling via CHOP-to-TOP, optional auto-wiring to external senders, and the explicit clarification that no model inference occurs. It fully supplements the annotation without contradiction.

  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 three sentences and every sentence adds information: rendering output, internal mechanism, and optional output wiring. It is well-structured and front-loaded, though slightly longer than strictly necessary since some details (e.g., per-limb RGB lines, joint discs) are already evident from the title and 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?

  Given the tool's complexity (15 parameters, no output schema), the description is adequate: it explains what is produced (a TOP), how it receives data (pose CHOP), and its role in a ControlNet pipeline. It does not describe return values, but for a node-creating tool this is not a gap. The lack of an output schema is mitigated by the clear statement of the render output.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3 per the rubric. The description does not significantly add parameter-level meaning beyond the schema; it mentions the default 512×512 and the source from an existing pose CHOP, but these are already captured in the property descriptions. No additional compensation needed.

  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 'Render' and clearly identifies the resource (canonical OpenPose-colored stick figure TOP) and purpose (driver conditioning image for ControlNet). It distinguishes itself from sibling tools like create_pose_tracking by stating it consumes the pose CHOP and explicitly says 'No model inference'.

  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 places the tool in a pipeline: it takes a pose CHOP 'produced by create_pose_tracking' and feeds into 'a downstream Stable Diffusion / ComfyUI / StreamDiffusion ControlNet node'. This implies when to use it, though it does not explicitly name alternatives or when-not to use it, so it falls short of a 5.

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

• drive_streamdiffusionA
  4.1/5.0
  Behavior4/5

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

  The description adds meaningful behavioral details beyond the annotations: it creates a fresh baseCOMP, wires inputs, sets custom parameters, optionally rebroadcasts, returns a friendly error, and includes validated_pars in the result envelope. This aligns with the annotations (readOnly=false, openWorld=true, destructive=false) and provides useful operational 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 information-dense with three sentences and no filler. The first sentence is a bit long, but it efficiently covers the setup workflow, error handling, and output envelope. Breaking it into more digestible chunks could improve readability slightly.

  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 (12 parameters, no output schema, open-world external dependency), the description covers the key workflow, error behavior, and result envelope adequately. It does not describe every parameter, but the schema already does, so the description provides enough context for an agent to understand the tool's role and use it appropriately.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents each parameter thoroughly. The description adds only a high-level grouping of prompt/strength/cfg/seed and mentions source/top wiring, but does not add new syntax or semantics beyond what is already 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 clearly states the tool wraps the StreamDiffusionTD.tox into a one-shot Layer 1 setup, enumerating concrete actions: locate .tox, create baseCOMP, wire input, set pars, and optionally rebroadcast. It distinguishes itself from sibling tools by mentioning downstream consumers like create_ai_mirror that rely on validated_pars.

  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 about when to use the tool: for one-shot setup of StreamDiffusionTD, with explicit behavior when the .tox is missing (friendly error). However, it does not explicitly state exclusions or alternative tools that should be used instead.

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

• get_operator_workflow_guideA
  4.1/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only:' at the start. It adds valuable behavioral context by stating that for unknown operators it 'returns candidate guide ids instead of failing,' which is a meaningful edge-case behavior beyond the annotations. This goes beyond 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 sentences, with the most important information front-loaded ('Read-only: return...'). It is concise, free of fluff, and every phrase adds value—the content, the examples, and the fallback behavior.

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

  Completeness5/5

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

  Given that an output schema exists and annotations cover safety, the description is complete for a lookup tool. It communicates the core purpose, the return content, and an important edge-case behavior. No significant gaps remain; the schema handles parameter details and return structure.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides, though it implicitly relates to the 'operator' parameter via the fallback behavior. The schema fully documents each parameter, so no deduction is needed.

  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: 'return an embedded TouchDesigner operator workflow guide with common inputs, outputs, examples, and next-operator suggestions.' This is specific with a verb and resource, and it distinguishes itself from sibling tools like get_td_docs or get_td_info by focusing on workflow guidance. The fallback behavior for unknown operators further clarifies the purpose.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (when needing operator workflow guidance) but does not explicitly mention alternatives or when not to use it. It lacks exclusions or comparison with sibling tools like get_td_docs or search_operators, so the guidance is only implied rather than explicit.

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

• local_marketplace_indexA
  4.1/5.0
  Behavior4/5

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

  The annotation already flags destructiveHint=true, and the description reinforces this with 'Writes a file (destructive)'. It adds the specific information that the tool writes a file, which is more concrete than the generic annotation. However, it does not disclose details like whether existing files are overwritten or what happens if out_file is omitted, so it does not fully exploit the opportunity to add 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.

  Conciseness5/5

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

  The description is extremely concise: three short sentences that each add distinct value. The first states the action, the second provides context and consumers, the third flags side effects. No filler or repetition of annotations, 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?

  The description effectively explains the tool's purpose, its place in the marketplace workflow, and its destructive nature. With simple inputs and no output schema, this is mostly sufficient. The missing explanation of out_file is the only notable gap, preventing a perfect score.

  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 schema description coverage at 0%, the description carries full responsibility for parameter meaning. It implicitly covers package_dir via 'Scan a local package directory', but completely omits out_file—its purpose, default behavior, or relationship to the writing action. This is a significant gap for a two-parameter tool, leaving the agent to guess the second parameter's role.

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

  Purpose5/5

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

  The description clearly states the tool's action: 'Scan a local package directory and write an index of installable tdmcp packages'. It specifies the resource (local package directory) and the output (index). It further differentiates from siblings by naming the consumers (browse_library and install_library_package), making its role in the marketplace workflow explicit.

  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 gives a clear use case: 'Use it to make a folder of components browsable and installable as a simple local marketplace'. It also explains how the output relates to other tools, which implies when this tool is needed (before browsing/installing). However, it does not explicitly contrast with alternative tools like generate_library_index or mention when not to use it, so it lacks full exclusion guidance.

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

• multipass_3d_depthA
  4.1/5.0
  Behavior4/5

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

  Annotations only indicate non-read-only, open-world, non-destructive. The description adds critical wiring details (SSAO must be directly after Render, no TOP between), depth resolution behavior, and the full return payload (summary, JSON block, preview image). This goes well beyond what annotations provide.

  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 dense but front-loaded with the core purpose in the first sentence. Every sentence contributes value, covering components, SSAO constraint, depth usage, instancing, and return format. While lengthy, it is justified by the multi-node complexity; minimal fluff. Could benefit from line breaks, but structure is logical.

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

  Completeness4/5

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

  For a complex tool with 8 parameters and no output schema, the description is remarkably complete: it explains the SSAO wiring constraint, depth output usage, downstream integration, and return payload. The only minor gap is an unexplained 'Zoom' control not present in the input schema, but overall it equips an agent with sufficient context.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents all 8 parameters. The description adds context like 'Exposes Spin, Zoom, and Ssao toggle' and 'GPU-instanced into a grid', but Zoom is not a schema parameter, which introduces a minor inconsistency. Overall, the description adds marginal meaning beyond the schema's per-parameter descriptions.

  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 a specific verb+resource: 'Build a renderable 3D scene with depth cues that read on stage' and enumerates exact components (Geometry COMP, Camera, Light, Render TOP, Null). It explicitly distinguishes itself from sibling create_3d_scene by adding optional SSAO and Depth TOP outputs, making the purpose unmistakable.

  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 says 'like create_3d_scene but with...' which clearly positions this tool as a superset variant for depth/SSAO needs. It also names downstream consumers (create_depth_displacement/create_depth_silhouette) and notes 'no depth camera needed', providing concrete usage guidance. It does not explicitly list exclusions, but the alternatives are clear.

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

• setup_tdabletonA
  4.1/5.0
  Behavior4/5

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

  The description discloses meaningful behavioral details beyond the annotations, such as probing for the Palette, falling back to an OSC fabric, and guaranteeing the same Null CHOP names. Annotations already say readOnly=false and openWorld=true, and the description aligns with those. It could add more about error handling or prerequisites, but the disclosed branch logic is valuable.

  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, front-loaded with the primary purpose, and uses three well-structured sentences to cover the auto-probe logic, fallback, and the consistent output guarantee. Every sentence adds value with no repetition or 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 complexity (11 parameters, two modes, no output schema), the description covers the main setup behavior well but does not mention what the tool returns (important since no output schema exists) or any prerequisites/limitations. It is adequate but has gaps.

  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 descriptions for all 11 parameters (100% coverage). The description adds context about the overall goal (downstream bind_to_channel) but does not individually enrich the parameter meanings beyond what the schema provides. Baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states a specific action ('Wire up an Ableton Live bridge') with a specified scope ('inside a tdmcp-managed container') and explains the auto-probe/fallback behavior. This distinguishes it from similar sibling tools like connect_ableton_link_session and create_hand_ableton_mapper.

  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 the tool (when an Ableton Live bridge is needed in a tdmcp container with binding-ready Null CHOPs) and explains the two modes, but it does not explicitly state when not to use it or point to specific alternatives.

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

• write_agent_guideA
  4.1/5.0
  Behavior5/5

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

  Annotations already indicate write/open-world behavior, and the description adds valuable specifics: writing to disk only when output_dir is provided, the dynamic header prepended to a static body, and the guarantee that the guide is returned in the structured result. No contradictions with annotations.

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

  Conciseness5/5

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

  Three sentences, each earning its place: purpose, content structure, and side-effect/return behavior. Front-loaded, concise, and no wasted 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?

  Description covers purpose, content, optional disk writing, and return behavior. It does not mention overwrite semantics or prerequisites, but annotations and schema cover safety and inputs. Sufficient for a well-scoped write 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 coverage is 100% with descriptive parameter explanations. The description reinforces output_dir behavior but does not add meaning beyond the schema, so baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the tool emits a project-local CLAUDE.md/AGENTS.md with specific conventions and coordinate rules. The verb 'emit' and resource are specific, but it does not explicitly distinguish from sibling documentation tools like generate_readme or document_network.

  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 intended use case is clear: to seed a future agent with a project mental model. It explains the optional disk write via output_dir and that the guide is always returned. No explicit exclusions or alternatives, but the context is well-defined.

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

• atem_switcher_controlA
  4.2/5.0
  Behavior4/5

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

  The description adds behavioral context beyond annotations by clarifying that it does not use the Blackmagic SDK directly, builds an offline-safe matrix, and includes specific functions (cut/auto/FTB, program/preview selection). This is useful since annotations only indicate non-read-only, non-destructive, and open-world hints. No contradiction.

  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. The first sentence states the primary action and routing options, the second clarifies the technical approach and scope. No filler or redundancy.

  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 six parameters fully described in the schema and no output schema, the description explains the tool's purpose, method (OSC relay), and key capabilities. It is complete enough for an agent to understand what the tool does and when to use it, though it could briefly mention the 'inputs' parameter's effect on the created matrix.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description does not add specific parameter semantics beyond what the schema already provides for host, port, inputs, etc. It mentions 'cut/auto/FTB and program/preview' which implies input selection but does not elaborate on parameter syntax or constraints 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 the tool's function: 'Create an OSC control preset for an ATEM switcher routed through atemOSC, Bitfocus Companion, or another OSC relay.' It specifies the verb (create), the resource (OSC control preset), and distinguishes itself from direct SDK tools and sibling tools like 'connect_blackmagic_atem' by emphasizing it builds an offline-safe TouchDesigner OSC matrix.

  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: when routing through atemOSC, Companion, or another OSC relay, and when you need an offline-safe preset without SDK access. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear to guide selection.

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

• auto_ui_from_paramsA
  4.2/5.0
  Behavior4/5

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

  The description discloses concrete mutation behavior: 'appends them as custom parameters on comp_path (default source_path), and optionally binds each control back to the source parameter.' It also reveals inference behavior ('infers sliders/toggles/text fields'). Annotations only state non-readonly/non-destructive, so the description adds meaningful behavioral context beyond them, though it doesn't cover edge cases like existing controls or overwriting.

  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?

  Three sentences, all dense and front-loaded. The first sentence states the core action, the second explains mechanics, and the third gives usage context. No filler or redundancy.

  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 7 parameters and no output schema, the description covers the core workflow (read, infer, append, bind) and primary use case. It doesn't specify return values or behavior with pre-existing controls, but within the open-world context it is sufficiently complete for an agent to decide when and how to invoke it.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds context for source_path (read from), comp_path (defaults to source_path), and bind (optional binding), but does not elaborate on page, exclude, parameters, or max_controls, which are already fully documented 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 starts with a specific verb and resource: 'Generate a performable control panel from an existing node/COMP's primitive parameters.' It clearly distinguishes this tool from siblings like create_control_panel by emphasizing automatic inference from existing parameters and optional binding.

  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 final sentence gives explicit usage context: 'Use when a generated component has useful parameters but no playable UI yet.' This provides clear guidance but does not state explicit exclusions or name alternatives, making it a clear context without exhaustive exclusions.

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

• blender_scene_importA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive. The description adds value by disclosing that it warns when a .blend may need export from Blender first, and that it falls back to a primitive if no scene_path is provided. These behaviors go beyond what annotations convey, though it does not detail side effects like potential node creation at parent_path or any prerequisites beyond file format support.

  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, each earning its place. The first front-loads the purpose and component list; the second concisely covers formats and the warning behavior. No redundant phrases or filler, making it easy to scan and understand quickly.

  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?

  The tool is complex (11 parameters, no output schema), yet the description covers the main deliverable (render scaffold), supported formats, and a behavioral warning. It does not explicitly state what the tool returns (e.g., the container path), but given the rich schema and annotations, the description is reasonably complete. Missing explicit output/return information is a minor gap in an otherwise thorough 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 description coverage is 100%, so every parameter already has a meaningful description. The tool description does not add additional parameter-level semantics; it mentions supported file formats which maps to scene_path, but the schema already lists the same formats. Baseline 3 is appropriate since the schema carries the full burden and the description does not enhance it.

  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 ('Create') and resource ('self-contained TouchDesigner render scaffold for a Blender scene or Blender-exported asset'). It enumerates the major components (File In SOP, Geometry COMP, PBR material, lights, Camera, Render TOP, Null TOP) which distinguishes it from simple model import tools like 'import_model'. The supported file formats and caveat about .blend export further clarify its scope.

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

  Usage Guidelines4/5

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

  The description provides clear context: use this when you need a full render scaffold for Blender scenes or exported assets. It implies the scenario (importing Blender geometry into TouchDesigner for rendering) but does not explicitly contrast with alternatives like 'import_model' or 'create_3d_scene'. There are no exclusions or 'when not to use' notes, but the context is unambiguous enough to guide selection.

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

• check_operator_availabilityA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare read-only and non-destructive behavior. The description adds valuable context beyond annotations: it retrieves data from a live API endpoint, works even when TDMCP_BRIDGE_ALLOW_EXEC=0, and indicates which operators are deprecated or unavailable. This enriches the behavioral picture without contradicting 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 four concise sentences, each contributing unique information: the reconciliation purpose, the flagging behavior, single-operator usage, and the environment-survival note. No wasteful repetition; information is front-loaded with the core purpose.

  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?

  The description covers the main function, optional modes, and a special environment condition, making it reasonably complete for a reporting-style tool. It lacks an explicit description of the output format (e.g., flag structure), but given the simple nature of the tool and lack of an output schema, 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 schema already describes both parameters thoroughly (100% coverage). The description adds a small usage note about passing a single operator name, but largely restates what the schema already conveys, so it meets the baseline without adding significant new semantic meaning.

  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: reconciling the operator knowledge base against the live TouchDesigner creatable-optype list. It uses a specific verb ('Reconcile') and names both the knowledge base and the running TouchDesigner, distinguishing it from sibling tools like search_operators.

  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?

  It provides clear context for when to use the tool (checking documentation against a running build) and how to use the single-operator mode. However, it does not explicitly mention alternative tools or exclusions, so it stops short of a full when/when-not explanation.

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

• clip_audio_transportA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate this is a non-read-only, non-destructive operation. The description adds behavioral specifics: 'synchronized', 'deterministic layout', 'Null outputs', and 'Play/Loop/Speed controls bound across both lanes.' It also notes the audio lane is optional, matching the include_audio parameter. No contradictions with annotations. It could go further by noting what happens when file paths are missing or whether existing container paths are overwritten.

  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 sentences with zero filler. The first sentence front-loads the primary action and components; the second sentence provides usage context. Every phrase contributes value, making it a model of concise, structured description.

  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 tool with 9 parameters, full schema documentation, and annotations providing safety cues, the description is largely complete. It explains what is created and when to use it. However, since there is no output schema, the description does not disclose whether the tool returns a path or reference to the created container, and it omits potential failure conditions (e.g., invalid file paths). Still, it is well above the minimum viable level.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents each parameter with descriptions. The description only lightly references parameters conceptually (e.g., 'Play/Loop/Speed controls' maps to loop/speed/autoplay, 'optional Audio File In CHOP lane' maps to include_audio/audio_file) but adds no technical detail beyond the schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb and resource: 'Create a synchronized clip transport container.' It enumerates the core components (Movie File In TOP video lane, optional Audio File In CHOP lane, Null outputs, deterministic layout, Play/Loop/Speed controls), distinguishing it from generic create tools and sibling tools like create_clip_launcher or create_video_player.

  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 use case: 'Use it as a reusable building block before clip launchers, VJ decks, or stream/output chains.' This indicates when to apply the tool and implicitly positions it as a foundation for those downstream systems. However, it does not explicitly state when not to use it or name specific alternative sibling tools, so it falls short of a full 5.

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

• compose_cue_listA
  4.2/5.0
  Behavior4/5

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

  The description discloses the LLM vs deterministic parser fallback, which is a behavioral trait beyond the annotations. It also mentions optional chaining into create_cue_sequencer, indicating potential side effects. Annotations already cover readOnly/destructive hints, so this adds value.

  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?

  Three sentences, front-loaded with purpose, no redundant content. Every sentence adds information about behavior or chaining.

  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?

  The tool has 8 parameters but all are well-documented in the schema. The description clearly states input, output (via schema hint), and fallback/chaining behavior. It lacks explicit return format but is adequate given no output schema.

  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 has 100% coverage, so baseline is 3. The description adds context for apply/containerName by mentioning optional chaining, and for preferLlm by discussing the LLM vs grammar parser. This elevates to 4.

  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 'turn into' and identifies the resource (natural-language show description → validated cue list). It distinguishes from siblings by naming the specific schema variant (scenes[]) and explicitly referencing create_cue_sequencer as a downstream chain.

  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 context (NL show description to cue list) but does not provide explicit when-to-use vs alternatives, nor exclusions. It mentions the LLM/grammar fallback and optional chaining, which are behavioral details rather than usage guidelines.

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

• connect_daydream_cloudA
  4.2/5.0
  Behavior4/5

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

  The description adds substantial behavioral context beyond the annotations: API key is read from the environment and never inlined, live probe is skipped because it requires a Daydream account and outbound HTTPS, and the tool creates a webclientDAT plus receiver TOP. This discloses network activity and setup prerequisites that the annotations (readOnlyHint: false, openWorldHint: true) only hint at. No contradictions with annotations.

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

  Conciseness5/5

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

  Three sentences, each earning its place: purpose, operational flow, and a critical behavioral caveat. No fluff, well-structured, and front-loaded with the main verb and resource.

  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 13-parameter tool with no output schema, the description gives a strong mental model of the bridge architecture and key environmental requirements. It could go further by explicitly stating the return value (e.g., the created container COMP), but the flow description adequately covers the main behavior. The schema handles parameter details, so the description is reasonably 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?

  Input schema covers all 13 parameters with descriptions, so the baseline is 3. The description adds high-level context (e.g., source TOP frames are POSTed, output_mode maps to receiver type), but it does not elaborate on individual parameters beyond what the schema already provides. Thus the description adds marginal value over 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 opens with a specific verb and resource: 'Create a Daydream cloud-hosted StreamDiffusion bridge in TD.' This clearly distinguishes the tool from siblings like connect_comfyui or connect_replicate_prediction_bridge. It further details the data flow (webclientDAT POSTs to REST, receiver pulls back, exposed as null TOP), leaving no ambiguity about what the tool accomplishes.

  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: when a Daydream cloud-hosted StreamDiffusion bridge is needed in TouchDesigner. It also flags a key usage consideration (live probe skipped due to account/HTTPS requirements). However, it does not explicitly mention alternatives or exclusion criteria, so it stops short of the highest rating.

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

• connect_xsens_mvn_mocapA
  4.2/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds what gets created (scaffold with ingest, mapping, tables, notes) but does not disclose deeper behavioral traits such as network side effects, dependencies on external Xsens software, or what happens to existing nodes. This meets the minimum bar but lacks extra context.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that packs essential information without wasted words. It enumerates the scaffold's key components efficiently and avoids filler, making it easy to scan and understand.

  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 creation tool with no output schema and 9 parameters, the description gives a solid high-level picture of what the tool does and what components are included. It does not explain return values or prerequisites, but the main purpose and feature set are clear enough for an agent to decide to invoke it. Given the lack of output schema, a bit more detail on outcomes would be better, but the overall completeness is adequate.

  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 only 22%, with only name and parent_path having descriptions. The description compensates by associating key features with parameters: 'OSC/UDP/TCP ingest' maps to source_mode and receive_port, 'actor/segment mapping' to actor_count and segment_count, and 'coordinate-space notes' to coordinate_space. This adds meaning beyond the bare schema, though it does not cover every parameter explicitly.

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

  Purpose5/5

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

  The description clearly states the action ('Create') and the specific resource ('an Xsens MVN mocap scaffold'), while listing distinguishing features such as OSC/UDP/TCP ingest, actor/segment mapping, normalized skeleton tables, and coordinate-space notes. This distinguishes it from sibling mocap tools like create_optitrack_tracking_bus or create_nuitrack_body_bus.

  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: when an Xsens MVN mocap scaffold with specific ingest protocols and mapping capabilities is needed. It does not explicitly name alternatives or exclusions, but the specificity of 'Xsens MVN' and the listed features make the usage scenario clear.

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

• create_automation_laneA
  4.2/5.0
  Behavior4/5

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

  The description discloses key runtime behaviors beyond the annotations: the two modes, the internal CHOP chain (Beat→Select→Lookup), the fact that re-calling with the same name and different mode flips state without rebuilding, and the return of a summary and JSON block. This complements the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) with actionable details.

  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 dense but every sentence contributes: purpose, modes, re-call semantics, implementation details, and return format. It packs substantial information without redundancy.

  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 6-parameter tool with no output schema, the description covers the workflow, modes, return structure, and state management. It does not list per-parameter details for bpm/parent, but these are self-explanatory and not critical to the tool's core function.

  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 has 50% description coverage, and the description adds conceptual meaning to key parameters: it explains 'record' and 'loop' modes (matching the mode enum) and 'N bars' for the bars parameter. However, it does not elaborate on bpm or parent, which are left to their self-explanatory names and schema defaults.

  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 'Build' and defines a concrete resource: 'a per-parameter automation lane that records... into a circular buffer over N bars, then loops...'. It clearly differentiates from siblings by focusing on the automation lane concept and its two modes.

  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 explains when the tool is appropriate by detailing the record/loop modes and the state-flip behavior on re-invocation, giving clear context for usage. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for an agent to match the tool to the task.

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

• create_autopilotA
  4.2/5.0
  Behavior4/5

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

  The description discloses that it creates a new baseCOMP under parent_path, modifies the target COMP live at runtime, and returns a summary plus warnings. It also clarifies the output is a CHOP engine, not a TOP, adding context beyond the annotations. No contradiction with readOnlyHint/destructiveHint.

  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 multi-sentence but every sentence adds necessary context: purpose, mechanism, runtime controls, reuse, pairing, and return value. It is front-loaded and appropriately sized for a tool of this complexity.

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

  Completeness5/5

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

  Despite no output schema, the description lists detailed return contents (container path, node paths, target, mode, beats, amount, engine path, errors, warnings) and the caveat about no preview image. It covers practical usage and side effects thoroughly.

  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?

  Input schema covers all 5 parameters with descriptions (100% coverage). The description adds context about parameter interactions (e.g., Amount scales randomize drift) but does not significantly extend the schema's semantic detail. Baseline of 3 is appropriate given full schema coverage.

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

  Purpose5/5

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

  The description uses specific verb 'Build' and clearly states the tool creates a beat-driven auto-VJ with a Beat CHOP and CHOP Execute DAT. It distinguishes from siblings by detailing the two operating modes (randomize vs cue) and explicitly references reusing randomize_controls and manage_cue mechanisms.

  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 gives usage context: 'Pair with a generated system (or a control panel) as the target' and explains when each mode is appropriate. It doesn't explicitly state when not to use it, but the reference to reusing randomize_controls and manage_cue implies this is an orchestration layer rather than those direct tools.

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

• create_clip_launcherA
  4.2/5.0
  Behavior4/5

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

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses meaningful behavior: the launcher panel is opened in Perform/Panel mode, tapping a clip fires its cue, and morph_time controls instant vs. eased crossfading using the same engine as manage_cue. This adds useful behavioral context without contradicting 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?

  Three sentences, each earning its place: first states the core purpose and structure, second explains interaction and morph behavior, third gives the prerequisite. The description is front-loaded with the essential 'Build an Ableton-style clip launcher' and contains no filler.

  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 builder tool with no output schema, the description covers the key context: what it builds, how it relates to manage_cue, required prior setup, and the key behavioral options. It could mention overwrite behavior or failure modes, but the essential invocation context is present.

  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 baseline is 3. The description adds some context around cues and morph_time (e.g., 'one per named cue', 'same engine manage_cue uses'), but the schema already documents each parameter adequately. No critical parameter semantics are missing.

  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 the specific verb 'Build' and names a concrete output: 'an Ableton-style clip launcher: a grid panel (Container COMP) of clip buttons, one per named cue.' This clearly distinguishes it from generic control-panel or cue-creation tools by emphasizing the grid-of-buttons scene-switching behavior.

  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?

  It gives clear usage context ('for fast hands-on scene switching during a live set') and a prerequisite ('Store the cues with manage_cue / create_control_panel first'). It does not explicitly list alternatives or say when not to use it, but the context and dependency make the intended use clear.

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

• create_companion_surfaceA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate a non-readOnly, open-world mutation. The description goes beyond by outlining the behavioral steps: inferring primitives, adding bound custom parameters, creating a playable panel, and optionally attaching a read-only preflight report. This gives a solid mental model of side effects, though it doesn't detail exact mutations to source/comp_path.

  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: the first front-loads the main verb and uses a colon-delimited list of concrete actions, the second gives a succinct usage note. Every word earns its place with no redundancy or fluff.

  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 12-parameter tool with 100% schema coverage and no output schema, the description provides an adequate high-level overview of the workflow and expected outcome. It could mention what the tool returns or what the created surface is, but given the schema's richness, it is sufficiently complete.

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

  Parameters3/5

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

  Schema coverage is 100% with well-described parameters, so the description doesn't need to repeat them. It adds workflow-level framing (e.g., 'infer primitive parameters' relates to parameters and max_controls; 'fader/cue panel' to include_faders and cue_buttons), but the heavy lifting is already done by the schema, meeting the baseline.

  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: building a companion performance surface for an existing node/COMP. It lists concrete sub-tasks (infer parameters, add bound custom parameters, create fader/cue panel, optionally append preflight report) and the specific resource ('node/COMP'), which distinguishes it from sibling tools like create_control_surface or auto_ui_from_params.

  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 use case: 'Use after generating a component that needs a human-facing control surface without hand-wiring every parameter.' It indicates when to use the tool but does not explicitly contrast with alternatives or state when not to use it, so it falls just short of a 5.

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

• create_containerA
  4.2/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=false and destructiveHint=false, and the description adds meaningful behavior: it creates one empty COMP, tiles it into the parent grid avoiding existing siblings, and returns node details. It does not contradict annotations and gives useful context about placement and return values, though it stops short of discussing permissions or undo 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 three tight sentences, front-loaded with the core action, and every sentence contributes value: creation, positioning, type semantics, return values, and usage alternative. No filler or redundant restating of the tool name.

  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 moderate complexity (0 required params, full schema coverage, no output schema), the description is complete enough: it explains what it creates, where, how it positions it, what it returns, and when to choose another tool. It does not mention whether parent_path must pre-exist, but that is a minor gap for a simple creation 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 coverage is 100%, so all three parameters are already documented. The description adds a bit of semantic nuance by clarifying that comp_type selects between Container COMP (2D panel) and Base COMP, but it mostly restates what the schema already provides. This is an adequate but not enhanced parameter explanation.

  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 one empty COMP under parent_path', uses a specific verb+resource, and distinguishes from siblings by contrasting with 'higher-level Layer 1 tool' for fully built networks. It also mentions the return values (path, type, name), leaving no ambiguity about the tool's primary scope.

  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 gives a clear usage context: create an empty shell to hold a visual system, tiling it into the network grid clear of siblings. It explicitly advises using a higher-level Layer 1 tool when a fully built, wired network is desired, which is a clear exclusion, though it does not name a specific alternative sibling.

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

• create_control_panelA
  4.2/5.0
  Behavior4/5

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

  The description discloses important side effects beyond the annotations: it appends custom parameters and switches each bind_to target to expression mode. This is valuable behavioral context. The annotations (readOnlyHint=false, destructiveHint=false) are consistent with the description, so no contradiction.

  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 dense, information-rich sentences with no filler. The first sentence states the purpose and capabilities; the second gives actionable instruction. This is an excellent example of front-loaded, economical writing.

  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 rich input schema and absence of an output schema, the description adequately covers the core effect (append controls, bind to parameters, switch to expression mode) and usage context. It does not dive into failure modes or edge cases, but those are not required for this level of complexity.

  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 with detailed descriptions for all parameters and nested control properties. The description mostly restates comp_path and bind_to without adding new syntax or semantics, so it earns the baseline score for schema-heavy tools.

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

  Purpose5/5

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

  The description clearly states the action—expose live controls on a COMP by appending custom parameters—and the resource (a COMP). It also distinguishes itself from generic parameter tools by describing binding to node parameters, which is a specific, differentiating behavior.

  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?

  It provides a clear use case ('drive a generated system in real time') and concrete directives: point comp_path at a system container and use bind_to to wire controls. It doesn't explicitly name alternatives or exclusions, but the context is strong enough for an agent to decide when to invoke it.

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

• create_flow_abstractionA
  4.2/5.0
  Behavior4/5

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

  Annotations only say readOnlyHint is false and destructiveHint is false; the description adds useful behavioral detail: it creates two glslTOPs plus textDATs, uses a Select TOP and ends with a Null TOP, and explains that some parameters are live uniforms while others are baked. It also clarifies that Iterations does not create a ping-pong feedback loop, adding genuine beyond-annotation 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 uses four dense sentences, each covering a distinct aspect: algorithm, output structure, parameter lifecycle, and iteration semantics. It is front-loaded with the core purpose and contains no filler. It is appropriately sized for the complexity, though slightly information-dense.

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

  Completeness5/5

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

  Given the tool's complexity (11 params, no output schema), the description is remarkably complete: it explains the algorithm, the nodes created, the wiring via Select/Null TOPs, which parameters are live vs baked, and the in-shader iteration behavior. Together with the rich schema, this gives an agent everything needed to invoke it 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?

  Input schema documents all 11 parameters (100% coverage), so the baseline is 3. The description goes further by explaining that Strength/Edge/Iterations are live parent-par-bound uniforms, while blur radius, sigmas, and tau are baked at build time, and that Iterations boosts ETF strength in-shader. This adds behavioral meaning beyond the individual field descriptions.

  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 starts with a specific verb and resource: 'Build a two-pass Kyprianidis-style flow abstraction.' It names the exact pipeline stages (ETF bilateral smoother + FDoG line extractor) and the created objects (two glslTOPs + companion textDATs), distinguishing it clearly from generic 'create_npr_filter' or post-processing siblings.

  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 use case via the visual result ('oil-painting smooth interiors with crisp coherent ink edges') and explains build-time vs live parameters, but it does not explicitly state when to prefer this tool over alternatives like create_npr_filter or create_optical_flow. It gives clear context but no explicit exclusions or alternative naming.

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

• create_hand_ableton_mapperA
  4.2/5.0
  Behavior4/5

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

  Annotations already flag readOnlyHint=false and openWorldHint=true; the description adds concrete behavioral details: it outputs four mapped signals, creates a skeleton overlay, and can relink an existing TDA_Mapper to the generated CHOP. It does not describe failure modes or what happens if the target container already exists, but the destructiveHint=false plus the explicitly non-destructive relinking language align with the annotations. No contradiction, and the extra detail earns a 4.

  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 core purpose, and each clause adds value: outputs, overlay, relinking, dependency. No filler or redundant restatement of the title. This is exemplary conciseness.

  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 a complex build action with 20 parameters and no output schema, the description provides a strong high-level summary of what is created and how it connects to existing components. It stops short of documenting return values or detailing the network structure beyond the named outputs, but the schema covers parameters and the annotations cover safety. The balance is reasonable, though a bit more on expected output (e.g., created container path) would push it to 5.

  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?

  All 20 parameters are documented in the schema (100% coverage), so per rubric the baseline is 3. The description itself does not add parameter-specific guidance beyond the schema; it mentions the output maps (pinch/wrist) which relate to invert flags, but that's contextual rather than parameter-level detail. The schema descriptions are self-sufficient, so a 3 is appropriate.

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

  Purpose5/5

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

  The description opens with a specific verb ('Build') and names the exact resource (MediaPipe-hands → TDAbleton TDA_Mapper performance control network). It enumerates concrete outputs (map1–map4, skeleton overlay) and explicitly distinguishes the dependency story ('Uses TDAbleton directly; AbletonMCP is not required'). This separates it clearly from sibling hand-tracking and gesture-bus tools.

  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 specifies the use case—building a hand-driven Ableton mapper—but does not explicitly name alternative tools or state when not to use it. The dependency note ('AbletonMCP is not required') gives a hint, and the mention of optionally relinking an existing TDA_Mapper implies it can augment an existing setup. However, it lacks an explicit 'use this instead of X' statement, so it gets a 4.

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

• create_iphone_depth_sourceA
  4.2/5.0
  Behavior4/5

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

  The description discloses that this is a scaffold, not a complete solution, and that it 'returns warnings where sender-specific metric depth decoding must be validated live.' This adds meaningful behavioral information beyond the annotations (readOnly=false, destructive=false). It also lists what gets created, giving the agent a clear mental model of side effects. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is three sentences, each dense with relevant information. The first sentence immediately states the purpose, the second lists the deliverables, and the third clarifies the scaffolding nature and warning behavior. Every sentence earns its place with no fluff or repetition.

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

  Completeness4/5

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

  Despite having no output schema, the description covers the key outcomes (what components are built) and the critical caveat (sender-specific depth decoding must be validated live). For a creation tool with 10 params but full schema coverage, this is complete enough. It could mention what happens on repeated calls or how to customize the scaffold further, but the description is already strong.

  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 100% schema description coverage, the baseline is 3. The description mentions 'TDLidar, Record3D, or a generic NDI/OSC source' which maps to the source enum, and 'optional point-cloud placeholder' which maps to create_pointcloud_stub. However, it does not add syntax, format, or behavior details for individual parameters beyond what the schema already provides, so it stays at baseline.

  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 specific verb+resource: 'Create a deterministic TouchDesigner scaffold for iPhone depth senders such as TDLidar, Record3D, or a generic NDI/OSC source.' It also enumerates the exact components built (live/video receiver TOPs, color_out, depth_preview, etc.), which distinguishes it from general create tools like create_live_source or create_point_cloud.

  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 (when creating an iPhone depth sender scaffold), but it does not explicitly state when not to use it or name alternative tools. The phrase 'for iPhone depth senders such as TDLidar, Record3D, or a generic NDI/OSC source' gives solid usage context, so it earns a 4 rather than a 3.

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

• create_prob_sequencerA
  4.2/5.0
  Behavior4/5

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

  Annotations only indicate open-world and non-destructive behavior, so the description carries the burden of explaining runtime behavior. It discloses the two output channels ('state' and 'trigger'), the Markov-chain transition mechanism, and the critical requirement of a live TD session with time.play=1. This goes beyond annotations, though it could also mention that a new COMP is created in the network.

  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 three sentences long and every sentence earns its place: the first states the core purpose, the second details the behavior and outputs, and the third provides sibling context, use-case guidance, and an important runtime note. It is front-loaded and free of filler.

  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 an 8-parameter generative tool with no output schema, the description covers the core algorithm, created outputs, runtime prerequisite, and sibling relationships. It omits explicit mention of the created COMP name or parent path, but those are in the schema. The note about time.play is crucial for live-session usage, making the description reasonably complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds context about how the 'states' parameter works ('per-state weighted-transition table') and mentions 'beat boundary' which relates to 'division' and 'bpm', but it does not provide additional syntax or per-parameter detail beyond what the schema already gives.

  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 'Build a Markov-chain step sequencer,' which is a specific verb+resource statement. It further distinguishes itself from siblings by labeling itself a 'generative sibling' and explaining its probabilistic nature, making it clearly different from deterministic sequencer tools.

  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 positions the tool for 'evolving, probabilistic rhythms and generative state machines,' and notes it is a 'generative sibling' of Euclidean and beat-grid sequencers, implying alternative deterministic use cases. However, it does not explicitly state when not to use it or name explicit alternative conditions beyond the sibling reference.

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

• create_projection_mappingA
  4.2/5.0
  Behavior4/5

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

  Beyond the annotations (openWorldHint=true, destructiveHint=false), the description discloses the generated structure: a 'projection' container with a Corner Pin warp, Select TOP, and a Null output 'ready for setup_output'. It also mentions that corner positions are parameters, adding non-obvious behavioral detail about drivability/saving.

  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?

  Three sentences, each adding distinct value: action, workflow (source/output), and parameter flexibility. No fluff or redundancy; front-loaded with the main purpose.

  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 a moderate-complexity create tool, the description covers the workflow (input source, created nodes, output Null) and mentions the key capability (corner params are drivable/savable). It does not discuss edge cases like node naming or overwrites, but given the annotations and schema, this is sufficient.

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

  Parameters3/5

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

  Schema coverage is 100% with clear descriptions for both parameters. The description adds minor value by explaining the source comes via a Select TOP and that corner positions are parameters, but these are not input-schema parameters. The schema already provides the necessary parameter semantics.

  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+resource: 'Wrap a source TOP in a Corner Pin warp for projection mapping' and clearly states the interaction ('drag the four corner handles to line the image up with a physical surface'). This differentiates it from sibling tools like create_led_mapper or create_vioso_warp_panel by naming the Corner Pin technique.

  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?

  It clearly implies the use case (projection mapping with manual corner alignment) and adds context about source flexibility via a Select TOP ('so it can live anywhere'). However, it does not explicitly mention alternatives or when not to use it, so it's clear context without exclusions.

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

• create_raymarch_sceneA
  4.2/5.0
  Behavior4/5

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

  Annotations convey non-readonly and non-destructive behavior. The description adds value by disclosing that it creates a self-contained container, exposes live controls, and previews the output TOP – behavioral details not present in 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?

  Two concise, front-loaded sentences cover the purpose, scene options, and key features. Every word earns its place; no redundancy or filler.

  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 rich input schema and absence of an output schema, the description offers a sufficient overview of behavior. It could mention naming or parent_path specifics, but those are already embedded in the schema, so this is 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?

  Schema coverage is 100% with detailed descriptions for every parameter, so the baseline is 3. The description only merely echoes the exposed control names without adding new depth beyond what the schema already documents.

  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 ('Instantiate') and names the resource ('self-contained GLSL TOP raymarcher'), clearly stating what the tool does. It also explicitly differentiates from a sibling ('3D complement to create_shader_lib') and lists the concrete scene options.

  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 usage context by positioning the tool as the 3D counterpart to create_shader_lib, implying when it should be used. However, it lacks explicit exclusions or guidance on when to choose alternatives like create_raytk_scene or create_sdf_field.

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

• create_reaction_diffusionA
  4.2/5.0
  Behavior5/5

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

  Annotations provide only readOnly=false, destructive=false, and openWorld=true. The description goes far beyond by detailing the build pipeline, shader constant patching, optional LUT chain, control panel creation, and output node. It also transparently discloses that 'iterations>1' is unverified and effective value is 1 with a warning, adding significant 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 a dense single paragraph but front-loads the core purpose and packs in specific pipeline details, LUT presets, and a critical caveat. It is efficient, though slightly verbose and could benefit from structured formatting.

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

  Completeness5/5

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

  For a complex 9-parameter creation tool with no output schema, the description covers the full build pipeline, parameter handling, palette options, control panel, output node, and the unverified iterations field. This gives an agent sufficient context to use the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters already have detailed explanations. The description mentions F/K/Da/Db as uniform names and the patching behavior, but this does not add new meaning beyond the schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description begins with 'Build a Gray-Scott reaction-diffusion GPU simulation as a ready-to-use visual system,' using a specific verb and resource. It clearly distinguishes this tool from sibling creation tools by detailing the unique pipeline (recipe delegation, shader patching, LUT chaining) and output node.

  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 use case is implied by the explicit mention of Gray-Scott reaction-diffusion, but there is no direct comparison to alternatives or exclusions. With numerous create_* sibling tools, the description would benefit from stating when to use this over related simulation tools, but it remains adequate for a specialized tool.

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

• create_sdf_fieldA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnly=false, openWorld=true, and destructive=false. The description adds meaningful behavioral context by mentioning 'Exposes live ... controls and previews the output,' which goes beyond annotation settings. However, it does not mention side effects like the container name or overwriting behavior, though the schema partially covers that.

  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?

  Three sentences, each earning its place: the first gives the core purpose and output type, the second explains the CSG capabilities, and the third summarizes live controls and preview. No fluff or redundancy; it is front-loaded and 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?

  For a tool with 14 parameters and a nested CSG array, the description covers the core workflow—composing primitives with boolean ops, blending, live controls, and preview—without repeating schema details. It does not explain return values or parent_path explicitly, but those are present in the well-described schema. Slightly short of a 5 because ordering semantics and creation path are only implicit.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description enhances the schema by grouping primitives (sphere/box/torus), boolean ops (union/intersect/subtract), smooth blending, and enumerating live controls (CameraZ/Speed/StepCount/Intensity/Rotate/ColorA/ColorB/Background). This helps the agent understand the CSG model and which params are interactive.

  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 starts with a specific verb and resource: 'Build a programmable signed-distance-field (SDF) raymarcher in TouchDesigner as a self-contained GLSL TOP.' It further details the CSG composition and live controls, which clearly differentiates it from siblings like create_raymarch_scene or create_glsl_shader.

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

  Usage Guidelines3/5

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

  The description implies use for self-contained SDF raymarchers with live controls, but it does not explicitly mention alternatives, exclusions, or when-not-to-use scenarios. The 'self-contained GLSL TOP' phrasing hints at a differentiator, but there is no direct comparison to raytk or other shader tools.

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

• create_simulationA
  4.2/5.0
  Behavior3/5

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

  Annotations already indicate this is a mutating (readOnlyHint=false) and non-destructive tool. The description adds context about the visual behavior (e.g., noise-displaced feedback loops) but does not disclose operational details such as container creation in parent_path or whether existing content is overwritten. It provides modest behavioral enrichment beyond the annotations, warranting a mid-range score.

  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 sentences contain all essential information: the tool's function, the three variants with behavioral descriptions, one key control, and an explicit pointer to an alternative. There is no waste, and the critical details are 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?

  Given the 100% schema coverage and adequate annotations, the description is largely complete for the agent to invoke the tool correctly. It covers the core purpose, variant behaviors, and an alternative path. It does not describe the return value or where the container is placed, but those are either in the schema or not critical for a build tool with no output schema, so the overall context is strong.

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

  Parameters3/5

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

  Schema coverage is 100% with detailed descriptions for every parameter, so the baseline is 3. The description repurposes some schema content (e.g., 'trail persistence' for decay) and adds minor conceptual depth (the noise flow field mechanism), but it does not significantly enhance understanding beyond what the schema already states. No parameter information is left 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 uses a specific verb ('Build') and resource ('GPU simulation'), then enumerates three distinct simulation types with concrete visual outcomes (Gray-Scott patterns, drifting trails, advected smears). It also explicitly references an alternative tool ('create_generative_art') for other procedural techniques, clearly distinguishing its scope.

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

  Usage Guidelines5/5

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

  The first sentence establishes when to use this tool (to build GPU simulations of the listed types). The final sentence provides an explicit 'when-not' by directing the agent to create_generative_art for cellular automata, flow fields, and strange attractors. This is a clear, direct alternative with no ambiguity.

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

• create_step_repeatA
  4.2/5.0
  Behavior5/5

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

  The description discloses the output type (nullTOP), the return format (summary + JSON with node paths, live controls, warnings, inline preview), the implementation (single GLSL TOP shader, stock TOPs only), and the fallback to a built-in synthetic Noise TOP. This goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by explaining what gets created and what to expect, without contradicting them.

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

  Conciseness5/5

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

  The description is four concise sentences, each serving a distinct purpose: the first states the core function, the second covers the default source fallback, and the last two describe the output and return value. No filler or redundancy.

  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 9 optional parameters, no output schema, and a tool that creates a network, the description provides sufficient context: purpose, constraints, default behavior, and output format. However, it does not detail the JSON structure or the nature of potential warnings, leaving a minor gap for a tool of this complexity.

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

  Parameters3/5

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

  Schema description coverage is 100%, with each of the 9 parameters already having a robust description. The tool description restates some parameter concepts (gap, jitter, rows/cols, brick offset) in prose but does not add new semantic details beyond the schema. Thus the baseline of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb ('Tile') and identifies the resource ('source TOP'), the pattern ('rows×cols brick/grid'), and key features (gap, jitter, brick offset). This clearly distinguishes it from generic create_* tools like create_td_node or create_replicator.

  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 (tiling a TOP) and gives constraints such as 'stock TOPs only' and the default Noise TOP fallback, but it does not explicitly state when to use this tool versus alternatives or when not to use it. No sibling tools are mentioned.

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

• diagnose_tdableton_mapperA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds valuable context by naming the exact parameters that can be repaired (Oscinputchop, Reorder, Bypass, Min/Max) and the condition that no AbletonMCP/live Ableton connection is required. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary action, and contains no redundant or filler content. Every word earns its place.

  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 no output schema, the description adequately covers the tool's purpose, scope, repair capability, and external constraints. The reference to 'common mapper symptoms' is slightly vague, but it is sufficient for a diagnostic tool and does not mislead.

  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 descriptions cover all 5 parameters (100% coverage), so the description does not need to add parameter-level detail. The mention of 'Oscinputchop, Reorder, Bypass, and Min/Max' refers to internal parameters of the mapper COMP, not the tool's own parameters, so it adds behavioral context rather than parameter semantics. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description uses specific verbs ('Inspect', 'Reports', 'repair') and clearly identifies the resource ('TDAbleton mapper COMP and its source CHOP'). This distinguishes it from sibling tools like setup_tdableton or create_hand_ableton_mapper by focusing on diagnosis and optional repair.

  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 clear context: it diagnoses mapper symptoms and can optionally repair without AbletonMCP or a live connection. However, it does not explicitly name alternatives or state when not to use the tool, so it lacks the explicit exclusions/alternatives that would warrant a 5.

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

• draft_recipe_from_tutorialA
  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 destructiveHint=false, but the description adds valuable context beyond that: 'without writing files or touching the TD bridge' and 'conservative operator chain'. These behavioral traits (in-memory draft only, no bridge interaction, conservative extraction) are not redundant with 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, front-loaded sentence that conveys the purpose, constraints, and output without any filler. Every phrase adds information: 'Read-only', 'conservative operator chain', 'embedded tutorial', 'without writing files or touching the TD bridge'.

  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 tool with 11 parameters and an output schema, the description is sufficiently complete: it states what it does, the read-only nature, the source (tutorial), and the output format (RecipeSchema JSON). The output schema and annotations cover return values and safety, and the description adds the key limiting behaviors. No critical context is 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?

  Schema description coverage is 82%, so the schema already documents most parameters. The description does not add any additional parameter semantics beyond what is in the schema, but given the high coverage, the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('extract', 'draft'), resource ('embedded TouchDesigner tutorial'), and output ('RecipeSchema JSON'), clearly distinguishing it from sibling tools like draft_recipe_from_operator_chain or draft_recipe_from_technique by the 'tutorial' source. The read-only modifier and 'without writing files or touching the TD bridge' further clarify the scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you have an embedded tutorial and want to draft a recipe schema, emphasizing a conservative, read-only process. It does not explicitly name alternatives or exclusions, but the 'from tutorial' phrasing provides sufficient contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• edit_td_node_metadataA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already declare destructiveHint=true, but the description adds substantial behavioral context: atomicity, prevalidation, rollback, parent-move copy-and-validate semantics, and the return format. It also clarifies that it avoids raw Python fallback, going well beyond 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 three sentences, each dense with valuable information. It is front-loaded with the primary action and scope, followed by atomicity/rollback details and return value. No redundant or filler words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers atomicity, rollback, and return results well, but it omits details about the individual boolean flags and does not mention prerequisites or error conditions beyond rollback. For a 14-parameter tool with no output schema, this leaves noticeable gaps for an agent trying to use all parameters 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 coverage is only 50%, and the seven boolean flags (lock, bypass, render, viewer, display, cloneImmune, allowCooking) have no schema descriptions. The description only refers to them collectively as "writable flags" without enumerating or explaining each. For the described parameters (name, path, color, node_x, node_y, comment, parent_path), the schema is already adequate, but the description does not compensate for the undocumented flags.

  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 ("edit") and enumerates the exact metadata fields: name, parent, Network Editor position, color, comment, and writable flags. This clearly distinguishes it from sibling tools like update_td_node_parameters (which edits parameter values) and delete_td_node (which removes nodes).

  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: it is atomic, prevalidates fields, rolls back partial failures, and explicitly states it does not use raw Python fallback, implying it is a safer alternative to execute_python_script. However, it does not explicitly name alternatives or state when not to use it, so it misses the top tier for explicit when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• enhance_buildA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description significantly enriches the annotations by disclosing critical behavioral traits: preview-only defaults, autoApply never bypassing approval, CAS/readback, and compensating restore. It also clarifies that legacy calls are unchanged. This goes far beyond the sparse annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) and provides valuable safety and execution 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 compact—three sentences—and front-loads the core purpose. Each sentence adds value, though the third sentence is dense with specialized terminology (e.g., 'calibrated local vision receipt', 'CAS/readback') that may reduce accessibility. It is efficient but not maximally clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (7 parameters, nested objects, output schema), the description sufficiently covers the high-level workflow, including the role of score_build, the bounded nature of improvements, and critical safety mechanisms. The schema handles parameter details and return values, so the description does not need to repeat them. It provides enough context for correct selection and invocation.

  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 provides 100% coverage with descriptions for all parameters, including detailed explanations for visualCritique, autoApply, and focusCriterion. The tool description itself adds no parameter-specific meaning beyond the schema, so it meets the baseline but does not exceed it.

  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: it runs score_build and uses an LLM to create bounded allowlisted improvements. It differentiates itself from siblings like score_build (which only scores) and optimize_performance by focusing on LLM-driven enhancement with preview and approval. The clause 'Legacy calls are unchanged' further clarifies its scope.

  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 after score_build and mentions safety defaults, but it does not explicitly state when to use this tool versus alternatives like optimize_performance or summarize_td_errors. It relies on the schema's focusCriterion parameter for exclusions, which is not part of the description. Thus, usage context is present but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• exec_node_methodA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds the 'escape hatch' framing and example methods including .destroy(), but does not detail potential side effects, failure modes, or return behavior—though these are inherently unpredictable for arbitrary method calls.

  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 sentences, front-loaded with the core purpose, and every clause earns its place. The 'Escape hatch' opener immediately signals the tool's nature and appropriate usage.

  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 an escape-hatch tool with open-world semantics, the description covers what it does, when to use it, and why. There is no output schema, and return values are inherently method-dependent, so the description is reasonably complete for this class of 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 100%, with all four parameters documented. The description adds example method names but does not meaningfully go beyond the schema's own description of 'method' and the positional/keyword argument arrays.

  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 invokes an arbitrary Python method on a node (operator), framing it as an escape hatch. It distinguishes from structured siblings by positioning this as the fallback for operations they don't cover, with concrete examples.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs to prefer structured tools when one exists and to use this only for operations they don't cover. Provides concrete examples (.cook(), .copy(), .destroy()) and sets context as a last-resort tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_look_toxA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable behavioral context: it creates a .tox and a sibling Markdown note with specific fields, defaults folder to 'Looks', requires TDMCP_VAULT_PATH and a running TouchDesigner bridge, and integrates via frontmatter. It does not contradict annotations, and the prerequisites are disclosed. It could go further by mentioning overwrite behavior or return value, but the additions are meaningful 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 dense paragraph with no wasted words. It front-loads the core action, then details the side effects, defaults, integrations, and prerequisites. Every sentence earns its place, and the structure is easy to scan.

  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 tool with 8 parameters and no output schema, the description is quite complete: it covers the primary operation, sidecar note contents, default folder, integration points, and runtime requirements. It lacks explicit error-handling or overwrite semantics, but for a publishing primitive the key context is present. A comprehensive summary is provided without needing to consult the schema in detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter is already documented. The description reinforces the folder default and mentions slug generation implicitly, but it does not explain relationships between parameters (e.g., license vs license_tier) or add syntax guidance beyond the schema. It provides marginal added value over the structured fields.

  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 begins with 'Save a COMP as a `.tox` inside `<vault>/<folder>/<slug>.tox` and write a sibling Markdown note...', which is a specific verb+resource+output combination. It clearly distinguishes this from siblings like make_portable_tox by positioning it as 'The artist-publishing primitive for portable looks' and by naming its integration with browse_vault_library and tag_and_search_library.

  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: it is the artist-publishing primitive for portable looks and states how it integrates with vault browsing and searching. However, it does not explicitly state when NOT to use it or mention alternative tools like make_portable_tox or save_component_to_vault, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_palette_componentA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare destructiveHint=true and openWorldHint=true, so the description's write-to-filesystem behavior is consistent. The description adds specific behavioral context by explaining the effect (the .tox appears in the Palette browser), which goes beyond the annotations. It doesn't mention overwrite risks, but the annotations carry the safety burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that states action, resource, destination, and benefit without unnecessary words. Every phrase earns its place.

  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 tool with full schema coverage and annotations, the description provides enough context to understand the action and outcome. It doesn't describe return values or error cases, but no output schema is provided and the tool's behavior is straightforward.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with all parameters described in the schema. The description adds minimal parameter-specific meaning, only reinforcing 'native Palette folder' which relates to palette_dir. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 ('Save') with a clear resource (COMP) and output (.tox), and specifies the destination (native Palette folder) and purpose (appears in Palette browser for drag-and-drop reuse). This clearly distinguishes it from siblings like export_look_tox or save_component_to_vault.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies strong usage context: it should be used when you want a COMP to become a reusable palette component. It doesn't explicitly name alternatives or exclusions, but the context is clear and distinct from sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• extend_data_source_fabricA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the output structure (Null DAT and Null CHOP) and the functional behavior of each transport (subscribes, streams, listens). Annotations already provide readOnlyHint=false and destructiveHint=false, so there is no contradiction. The description adds useful context about the downstream integration without over-explaining.

  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 main action, and efficiently covers the three transports and the output shape. No unnecessary filler or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 14 parameters and no output schema, the description adequately explains the output (Null DAT/CHOP) and downstream usage. It doesn't cover prerequisites or failure modes, but the schema provides strong parameter-level detail, making the description sufficient for an agent to invoke it correctly.

  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 covers all 14 parameters with descriptions, so the baseline is 3. The description adds marginal value by noting that 'fields' map to Null CHOP channels, but for the most part it just restates the transport names already in the enum. No significant extra parameter semantics 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 clearly states the tool 'Adds extra transports to the data-source fabric' and enumerates the three transport types (mqtt, ws-binary, midi-mmc), giving a specific verb+resource scope. It explicitly distinguishes itself from create_data_source, so 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context by positioning itself 'beyond create_data_source' and noting the resulting structure is 'ready for bind_to_channel / create_data_visualization.' However, it doesn't explicitly name alternative tools like connect_mqtt_iot_bus or provide when-not-to-use guidance, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• focus_network_editorA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses that it replaces stale selection, sets an explicit current operator, returns a fail-closed suppression readback, and does not steal focus in perform/headless states. This is valuable, though the final phrase about 'live compare-and-swap proof' is vague.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is fairly compact but includes a final sentence about 'Smooth colour highlights remain held pending live compare-and-swap proof' that is jargony and adds little actionable value for an agent. It could be rephrased or removed, so it doesn't fully earn its place.

  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 UI-only focus tool with 5 well-documented parameters, the description sufficiently covers side effects, safety, and return behavior (applied or fail-closed readback). No output schema is present, but the description adequately indicates what the agent can expect.

  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 good per-parameter descriptions, but the tool description adds the 'same-parent operator group' constraint for paths, which is not explicit in the schema, and notes that the action parameter is for auditability. This gives extra meaning 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 uses the specific verb 'follow' with the resource 'operator group in an existing TouchDesigner Network Editor,' and adds the same-parent constraint. This clearly distinguishes it from sibling tools like arrange_network or duplicate_network.

  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 about when it is safe to use: it reuses the active pane, is UI-only, never creates panes or changes topology, and does not steal focus in Perform/headless/disabled states. However, it does not explicitly name alternative tools or state when to prefer them, so it only reaches a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_node_state_runtimeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only'. It adds valuable context beyond annotations: return shape, UNVERIFIED attribute names that vary by TD build, and the `extra` map for live confirmation. No contradiction.

  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 information-dense but every sentence earns its place: scope and fields, sibling context, and return/caveat details. It is front-loaded with 'Read-only' and well-structured, though slightly long for the minimalist ideal.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only telemetry tool with two simple parameters and strong annotation coverage, this description is complete. It covers what fields are returned, the diagnostic use case, safety, and the important UNVERIFIED attribute caveat. The Info CHOP fallback behavior is also documented in the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for both parameters, so baseline 3 applies. The description mentions include_info_chop's purpose at a high level but adds no syntax or constraints beyond what the schema already states. path is straightforward and needs no extra explanation.

  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?

  Description opens with 'Read-only: inspect a single operator's runtime telemetry', giving a specific verb and resource, then lists concrete fields. It explicitly differentiates from sibling get_td_performance by noting the per-op vs network-aggregate scope.

  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?

  It clearly states the diagnostic context ('why is it black / why is it slow') and names get_td_performance as the network-level aggregation tool. However, it presents the relationship as 'complements' rather than an explicit 'use X instead when Y', so it lacks a firm exclusion rule.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• import_recipe_from_urlA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey destructiveness (destructiveHint=true) and write semantics (readOnlyHint=false). The description adds useful behavioral context beyond annotations: it fetches from the network (openWorldHint), validates content, and is subject to 'host-allowlisted, size-capped' limits. It does not mention overwrite behavior or failure modes, but the added constraints are valuable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence that conveys the operation, constraints, and expected input format with zero redundant words. Every element ('fetch', 'validate', 'import', 'host-allowlisted', 'size-capped') earns its place.

  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 relative simplicity, the description combined with full schema coverage and annotations is substantial. It clarifies the URL source, destination directory, and constraints, and the annotations cover destructive/write behavior. The lack of an output schema and absence of return-value description are minor gaps for a straightforward import 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 100%, so the baseline is 3. The description adds some contextual meaning (e.g., 'host-allowlisted' relates to url, 'size-capped' relates to max_bytes), but it does not introduce new syntax or deepen parameter understanding beyond the schema's per-parameter descriptions.

  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 ('Fetch, validate, and import') with a clear resource ('recipe or recipe-bundle JSON from an HTTPS URL') and destination ('local recipes directory'). It also adds distinguishing constraints ('host-allowlisted, size-capped') that differentiate it from sibling tools like 'import_recipe_bundle'.

  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 the use case (importing recipe JSON from a remote HTTPS URL) and notes important constraints (host allowlist, size cap). However, it does not explicitly mention alternatives or when not to use this tool, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• inspect_component_manifestA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint, destructiveHint), the description adds valuable behavioral context: it 'reports validation problems instead of throwing.' This discloses error-handling behavior not captured by the annotations. It also clarifies the input scope ('package folder or file') and what is checked (metadata, declared assets, docs), adding meaningful transparency.

  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 at two sentences, front-loaded with the core action, and every clause adds value. No redundant or filler content exists. It efficiently packages purpose, usage context, and error behavior without wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple validation tool with a single parameter and strong annotations, the description is largely complete. It explains what the tool does, when to use it, and its error-handling approach. The only minor gap is that it does not describe the return value on success, but given the tool's simplicity and no output schema, this is not a major deficiency.

  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 0% schema description coverage, the description needed to explain the 'path' parameter. It does say 'from a package folder or file,' which clarifies that path can reference either a folder or a file. However, it lacks details like accepted formats, relative vs absolute paths, or examples, so it only partially compensates for the absent 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 states the tool's function: 'Read and validate a tdmcp component/library manifest from a package folder or file.' It specifies the verb (read and validate), the resource (manifest), and the scope (package folder/file). It also distinguishes this tool from related tools by framing it as a pre-installation check for install_library_package and make_portable_tox, making its unique purpose evident.

  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 explicitly says to use this tool 'before install_library_package or make_portable_tox', giving clear when-to-use context. It does not explicitly name alternatives or provide when-not-to-use guidance, but mentioning the two dependent tools is sufficient context for an agent to select this over more general inspection tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• library_lineage_graphA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds value beyond the existing annotations by noting the tool is offline, requires no TouchDesigner connection, and lists the specific frontmatter fields it extracts. It also mentions output formats, which the annotations do not cover. Although the return structure is not detailed, the read-only nature is both annotated and described consistently, and the added context raises it above a mere annotation repeat.

  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, stating the core action in the first sentence, then elaborating with output formats and the offline/no-connection detail. No words are wasted, and the structure flows logically from what it does to how it outputs.

  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 6 parameters and no output schema, the description gives a solid overview: it covers the scanned sources, extracted fields, output formats, and the offline nature. However, it does not describe the expected graph structure (nodes/edges) or the safety cap (max_nodes) in the description, leaving some context for the user to infer. Overall, it is sufficiently complete for a read-only analysis 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 100%, so the baseline is 3. The description adds some context for parameters by listing the categories (kinds) and output formats, but it does not add meaning for max_nodes, cluster_by, vault_path, or include_orphans. The schema already provides adequate descriptions for all parameters, so the description provides only marginal additional semantics.

  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: it scans the vault library, extracts lineage frontmatter, and emits a lineage graph. It specifies the resource (Recipes, Shaders, Presets, Components, Setlists) and the output formats, distinguishing it from sibling tools like list_recipes or browse_library that do not provide lineage graph analysis.

  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 the tool: it is read-only, offline, and requires no TouchDesigner connection. It implies usage for analyzing lineage/dependencies among library assets, but does not explicitly state when not to use it or name alternatives. Thus, it meets the 'clear context, no exclusions' level.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lidar_floor_trackerA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With readOnlyHint=false and destructiveHint=false, the description adds valuable context beyond annotations: it builds a scaffold, creates specific CHOP/TOP outputs, and explicitly warns that hardware modes are neither active nor verified until a real sensor is connected. This sets accurate expectations without contradicting any 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?

  Two sentences with no waste: the first front-loads the core purpose and outputs, and the second adds a critical safety/verification note. Every word contributes to understanding the tool's function and constraints.

  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 10-parameter tool with no output schema, the description does well by naming output node types and clarifying hardware verification state. It doesn't explain parameter interactions or preconditions, but the schema covers individual parameters, and the core behavior is adequately described.

  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 with individual parameter descriptions, so the description does not need to add per-parameter explanations. It adds no parameter-specific semantics, but the schema carries the burden fully, supporting the baseline score.

  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 builds a floor-occupancy tracker scaffold, specifies the exact input sources (synthetic, Ouster TOP, Leuze ROD4 CHOP, UDP point input), and names the outputs (tracked_points CHOP, floor preview TOP). This distinguishes it from sibling lidar bus creation tools and makes its purpose unmistakable.

  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 gives clear usage context by naming the intended rehearsal and hardware input modes, and it includes a safety caveat about hardware modes being inactive and unverified. It does not explicitly name alternative tools or exclusion criteria, but the context is sufficient for selection among the broader sibling set.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• lint_recipe_libraryA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description adds critical behavioral details: it states 'never calls TouchDesigner' (no external side effects) and 'Returns a structured report' (output format). It also lists the exact rules checked, providing transparency about what the tool validates. This adds value beyond the annotations and sets expectations for safe, offline execution.

  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 compact, with the first sentence stating the core purpose and the second listing the checks. While the second sentence is long, every item is necessary to convey scope. It is front-loaded with 'Offline semantic linter' and ends with a state guarantee. The structure is acceptable but could be improved by breaking the rule list into a more scannable format.

  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 tool's function and key behavioral traits, but it does not describe the structure of the returned report (e.g., list of issues with severity levels). Although the schema-parameter descriptions explain fail_on and severity, the actual report format remains vague. Given there is no output schema, the description should have elaborated on what the 'structured report' contains for a complete understanding.

  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% coverage: every parameter (rules, fail_on, severity, recipe_id) includes a description with defaults and enums. The tool description itself does not add parameter-level details, but since the schema is thorough, it meets the baseline. No additional compensation is needed.

  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 as an 'Offline semantic linter for recipes/*.json' and enumerates the specific checks it performs (schema, id/filename match, duplicate node names, etc.). It uses a specific verb ('lints') and resource ('recipes/*.json'), and distinguishes itself from siblings by emphasizing offline operation and never calling TouchDesigner.

  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 the tool: it is offline, never calls TouchDesigner, and runs a set of semantic checks on recipe files. However, it does not explicitly name alternative tools or state when not to use it (e.g., 'use validate_recipe_bundle for schema-only validation'). The 'never calls TouchDesigner' hint implies a safe offline choice but lacks explicit comparison to siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• log_performanceA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that the tool both reads and writes, specifies the file naming convention and location, notes the optional thumbnail binary attachment, and mentions the prerequisite TDMCP_VAULT_PATH. This goes beyond the annotations (readOnlyHint=false, openWorldHint=true) by explaining the side effects and external dependency, which is valuable context for an agent.

  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 three sentences: the first clearly explains the action, the second gives the use case, and the third covers return values and prerequisites. Every sentence earns its place, the key verb 'READ'/'WRITE' is front-loaded, and there is no redundant fluff.

  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?

  There is no output schema, but the description explicitly states return values (note path, thumbnail saved, node/issue counts). It also covers prerequisites (vault path) and the core workflow, making it sufficiently complete for a write tool with optional parameters. It doesn't detail error handling or directory creation, but those are minor gaps given the schema and annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each of the 6 parameters having a description. The tool description adds a bit of semantic context (e.g., 'preview image of an output TOP' for output_path, 'node/connection counts' for comp_path), but most parameter meaning is conveyed by the schema. The description doesn't need to compensate extra, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'WRITE a dated journal entry to Performances/<date>-<title>.md' and 'READ a snapshot of a TD network'. It clearly distinguishes this from sibling tools like get_td_performance or snapshot_td_graph by emphasizing the journal-writing purpose, making it unmistakably a logging/writing tool.

  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?

  It explicitly says 'Use this to build a diary of your shows over time', giving a clear context and when to invoke. It doesn't explicitly name alternatives or when not to use, but the purpose is specific enough to avoid ambiguity. A slight deduction for not mentioning sibling tools like get_td_performance as a read-only alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_annotationA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds valuable behavioral context by calling the edit action 'a structured, verified transaction that works with raw Python disabled', which explains safety guarantees and a technical constraint beyond the annotations. It does not contradict any 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?

  The description is two sentences, front-loaded with the primary purpose ('Self-document a network'), followed by a concise list of actions. The second sentence adds important safety/constraint information without redundancy. Every phrase earns its place.

  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 (12 parameters, 5 action types, no output schema), the description covers all major action categories and includes a caveat about raw Python. It does not detail return formats for list/enclosed operations, but this is somewhat inferable from the action names. Overall, it is sufficiently complete for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents every parameter with action-specific descriptions. The description does not add significant new meaning to the parameters beyond summarizing the actions at a high level. Thus the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verbs and resources: 'create a titled annotation box', 'safely edit an existing Annotate COMP's title, body, RGBA background, or exact node-space bounds', 'set an op comment', 'list annotations', or 'inspect geometric enclosure'. This clearly distinguishes it from sibling tools like document_network or edit_td_node_metadata by focusing on Annotate COMPs and annotation-specific operations.

  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 opening phrase 'Self-document a network' provides clear context for when this tool is useful. It also enumerates the supported actions, allowing an agent to infer appropriate scenarios. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of the top score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_component_storageA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructive behavior (destructiveHint=true) and non-read-only (readOnlyHint=false). The description adds context by naming the exact destructive actions (delete removes a key, set writes) and the prerequisite that no operator is created. It does not contradict 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?

  Two concise sentences: the first covers purpose and actions, the second covers a key exclusion/precondition. No filler, front-loaded with the core function.

  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 CRUD tool with 4 well-documented params, the description covers the essential behavior and prerequisites. It could mention return values for set/delete, but given the schema richness and annotations, it is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and the description largely repeats what the schema already states (e.g., key required for get/set/delete). It adds minimal extra semantics beyond the schema, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb-resource pairing ('CRUD operations on a COMP operator's .storage dictionary') and enumerates the exact actions (list, get, set, delete). It clearly distinguishes this tool from sibling tools like manage_component or inspect_op_extensions_storage by focusing on the .storage dictionary.

  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 contextual guidance: it is for reading/writing a COMP's .storage dictionary, and explicitly states a precondition ('target COMP must already exist') and an exclusion ('No operators are created'). It does not name alternative tools, but the scope is unambiguous enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• morph_packA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and destructiveHint=false, so the agent knows this tool mutates state. The description adds useful behavioral context: packs are sha256-verified, the tool reuses the existing engine rather than creating new topology, and unpack can rebuild missing containers. It does not mention merge=replace wiping presets in the description, but the schema covers that and there is no direct contradiction.

  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 three sentences, each earning its place: first defines both modes, second clarifies engine reuse and topology compatibility, third gives the environment prerequisite. It is front-loaded and compact without unnecessary filler.

  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 dual-mode tool with 9 parameters, the description plus rich schema is sufficient for correct invocation. It includes the key prerequisite (TDMCP_VAULT_PATH) and the container-creation behavior. Return values/provenance details are not described, but the absence is not critical given the schema and sibling context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds a high-level mental model (pack vs unpack, inline looks exception) but does not add meaning beyond what the schema already provides for each parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action: export a create_preset_morph container's slots to a sha256-verified vault JSON (pack) or re-hydrate a pack back into a container (unpack). It names the exact resource and distinguishes the two modes, which also differentiates it from sibling tools like create_preset_morph or manage_presets.

  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 gives clear usage context: it explains both actions, states that the tool reuses the existing create_preset_morph engine, and notes the TDMCP_VAULT_PATH requirement unless inline looks are supplied. It does not explicitly name alternative tools or state when not to use it, but the context is strong enough to guide correct selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• one_source_five_waysA
  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 destructiveHint=false, so the description need not repeat those. It adds valuable behavioral context beyond annotations: 'offline' (no external dependencies), 'deterministic' (same input yields same output), and the fixed count of five briefs. These traits are not derivable from annotations or schema, enriching the agent's understanding of what to expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the primary action, and no filler. It efficiently conveys purpose, input, output, determinism, and usage context. Listing the five brief types makes the sentence instructional without being verbose. Every word contributes, and the structure is ideal for quick agent scanning.

  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 an output schema present, the description need not explain return structure. It covers the tool's core function, safety profile, and usage timing. It could briefly clarify what a 'remix brief' contains, but given the output schema and the tool's straightforward purpose, the description is sufficiently complete for an agent to decide when and how to use it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is met by the schema alone. The description does not materially clarify parameter behavior beyond what the schema already states; it mentions the source broadly and the five brief types, but the schema already specifies source_path formats and the other parameters. Therefore, the description adds no significant semantic value beyond the structured field descriptions.

  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 ('Turn...into'), identifies the input (source node, asset, or package entry), and lists the exact output (five deterministic remix briefs with named categories). It also distinguishes itself from sibling mutation tools by explicitly labeling it as a planning tool for use 'before mutating' networks, making it unique among the many creation tools.

  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 usage context: it is an 'offline/read-only planning tool for agents before mutating TouchDesigner networks.' This implies when to use it (as a safe pre-mutation planning step) and, with the read-only annotation, implicitly warns against expecting network changes. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full explicitness.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• osc_router_matrixA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the description is not burdened with those. It adds valuable behavioral context: 'offline-safe' suggests that OSC isn't sent until activation, plus deterministic layout and a report of emitted addresses. It does not mention overwrite or collision behavior, but these are minor gaps given the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: it starts with the action and then lists the key deliverables in a dense, structured sentence. The second sentence situates the tool in its intended ecosystem without wasting 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?

  With no output schema, the description compensates by promising a 'structured report of every emitted OSC address' and by specifying the internal CHOP structure. The schema's min/max constraints and annotations cover edge cases and safety, making the description complete enough for an agent to understand the outputs and scope.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds only high-level pointers like 'target-specific address prefixes' and 'structured report of every emitted OSC address,' but does not provide parameter-level details beyond what the schema already offers. It neither enriches nor contradicts 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 uses the specific verb 'Create' and clearly enumerates the artifacts: one Constant CHOP plus OSC Out CHOP per target, deterministic left-to-right layout, target-specific address prefixes, and a structured report. It distinguishes itself from sibling connect_* integration tools and create_ndi_router_matrix by positioning this as a generic OSC-ready primitive for multiple show-control endpoints.

  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?

  It gives a concrete use case: 'Use it as the primitive for QLab, atemOSC/Companion, Resolume, VDMX, or any OSC-speaking show-control endpoint.' This implies when to choose this tool over more specific integrations, though it does not explicitly state exclusions or alternatives, leaving the agent to infer boundaries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• post_passes_3dA
  4.2/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the minimal annotations (readOnly=false, destructive=false). It discloses fixed execution order, fallback behaviors (SSR skip, motion blur directional fallback), auto-creation of a depthTOP, and the exact return payload (paths, enabled passes, warnings). This is rich contextual behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph where each sentence contributes new information: pipeline construction, per-pass implementation, order, fallbacks, auto-depth creation, and return values. It is efficient and well-structured for the complexity.

  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 tool with 17 parameters and complex chain behavior, the description covers the main workflow, fallback paths, and return values. It lacks detailed explanation for many parameters, but the schema provides names, defaults, and constraints, so the description is mostly complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is low (35%), but the description adds meaningful semantics for the AOV inputs: depth_top auto-derivation, normal_top empty triggers SSR skip, velocity_top empty triggers fallback. However, it says nothing about the many numeric/boolean controls (ssao_radius, dof_aperture, etc.), which rely on self-evident names and schema defaults.

  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 a specific verb and resource: 'Compose a chain of 3D-aware post-processing passes inside a new baseCOMP.' It names the exact passes (SSAO, SSR, DOF, motion blur) and the container type, and the fixed order differentiates it from generic post-processing siblings like apply_post_processing.

  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 building a 3D-aware post-processing chain but never explicitly contrasts it with alternatives or states when to use it vs. other compositing tools. It provides detailed behavior but no exclusions or alternative recommendations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• projector_calibration_wizardA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and destructiveHint=false, which are consistent with a build tool. The description adds useful behavioral context by emphasizing that the tool is rehearsal-safe and does not verify live alignment until run on physical outputs, and by listing exactly what components it generates. This goes beyond what annotations convey.

  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 only two sentences, front-loaded with the main action and an efficient colon-separated list of features. It includes the crucial caveat about unverified alignment without wasted words. Every phrase earns its place.

  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?

  The description covers purpose, main components, and a key limitation (unverified alignment). It implicitly clarifies that the result is a network built inside the parent_path. With all parameters fully described in the schema, this is nearly complete. However, it does not explicitly state the return value (e.g., reference to the created container), though this is typical for such tools.

  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?

  All 9 parameters are described in the schema (100% coverage), so the schema does most of the semantic work. The description adds a high-level context by mentioning 'generated grid/crosshair or selected source TOP' (relating to source_path) and per-projector lanes, but it does not provide significant new details beyond schema descriptions. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Build') and resource ('rehearsal-safe projector calibration network') and enumerates concrete features (grid/crosshair, per-projector crop/corner-pin/level/output lanes, preview layout, notes, brightness/gamma controls). This clearly distinguishes it from sibling tools like create_projection_mapping or create_mpcdi_projection_mapper, which focus on other projection-mapping approaches.

  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 establishes a clear context: it is for building a rehearsal-safe calibration network, with the explicit caveat that 'Live projector alignment remains explicitly unverified until run on the physical outputs.' This implies that this tool is not for final alignment/verification, but it does not name alternative tools or provide explicit 'when not to use' guidance beyond that.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• provenance_stampA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds useful context by listing what the sidecar records (sha256 checksum, file size, mtime, source COMP path, toolchain versions, git metadata, author, tags, notes) and re-emphasizes the offline operation. Annotations already declare write-ish intent (readOnlyHint=false) and non-destructive nature, so no contradiction. Missing is explicit mention of the `overwrite` default behavior, but it's not critical given 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 exactly two sentences: the first front-loads the action and scope, the second lists the recorded data fields. Every clause is informative and there is no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even though there are 9 parameters and no output schema, the description covers the essential context: what is written, to what artifact types, what data it records, and that it works offline. Missing are explicit details on overwrite behavior or return value, but these are either implied by the sidecar concept or present in the schema (e.g., `overwrite` parameter).

  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% (all 9 parameters have descriptions), so the baseline is 3. The description adds value beyond the schema by tying the parameters to the overall purpose (e.g., 'source COMP path', 'originating tdmcp tool', 'best-effort git metadata') which maps to `source`, `include_git`, and `tags`. This supplements the schema without redundancy.

  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 ('Writes') and a specific resource ('.provenance.json sidecar') and clearly lists the artifact kinds it applies to (tox, recipe note, recipe bundle, component bundle). This distinguishes it from generic save/export tools in the sibling list, such as save_recipe_to_vault or export_recipe_bundle.

  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 'next to a saved artifact' gives clear context on when to use the tool, and the 'Offline — no TD bridge required' note indicates an advantage over bridge-dependent tools. However, it does not explicitly name alternative tools or conditions when not to use it, though the context is generally sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• publish_recipe_bundleA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description openly discloses that 'This is a filesystem write tool' and explains the overwrite protection behavior, which complements the destructiveHint annotation. It also states what the return value contains (artifact paths, checksums, count, missing ids), adding useful behavioral context beyond the annotations. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact (three sentences) and front-loads the primary action and purpose. Every sentence contributes value: the output artifact names, the key parameter choices, and the return values. No redundant or filler text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (6 parameters, no output schema, destructive annotations), the description covers all critical aspects: what files are produced, how to select content, the overwrite safeguard, and the return information. It is sufficiently complete for an agent to invoke and interpret results without additional documentation.

  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 100% schema description coverage, the baseline is 3. The description adds meaningful cross-parameter semantics by explaining the selection modes (recipe_ids vs include_all) and overwrite behavior, which clarifies how the parameters interact rather than just repeating each field's schema description.

  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 is highly specific: 'Write a local, versioned recipe-bundle publish artifact for CI upload or handoff' and enumerates the exact output files. It clearly states the verb and resource. However, it does not explicitly differentiate itself from sibling 'export_recipe_bundle' or other bundle-related tools, so it misses the sibling-distinction criterion for a 5.

  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?

  It provides a clear context for use ('for CI upload or handoff') and gives practical guidance on how to select recipes ('Use recipe_ids for selected recipes or include_all=true for the whole library') and protect existing files ('overwrite=false protects existing artifacts'). It does not mention when not to use it or name alternatives, which keeps it from a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• raytk_expr_graph_builderA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-destructive write operation (readOnlyHint=false, destructiveHint=false). The description adds valuable context beyond annotations by explaining that it copies RayTK masters live, lays out nodes deterministically, and explicitly notes that 'offline tests validate payload/registration only, while live render/cook proof remains explicit.' This discloses limitations and behavioral nuances without contradicting 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 three sentences, front-loaded with the primary action, and every sentence contributes meaningful information: what it does, how it relates to siblings, and key prerequisites/limitations. There is no fluff or repetition of schema details, making it efficient 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?

  Given the tool's complexity (12 parameters, no output schema) and detailed schema, the description covers the overall workflow, prerequisites, and limitations. It does not explain return values, but no output schema exists and the schema handles parameter details. The description is sufficiently complete for an agent to understand the tool's scope and constraints, though it could mention potential side effects if any.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds conceptual context for parameters (e.g., 'preset or explicit nodes/edges', 'simple parameter values', 'expose the selected output through out1') but does not provide detailed syntax or additional meaning beyond what the schema already documents. It meets the baseline but does not significantly enhance parameter understanding.

  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 and resource: 'Build an editable RayTK ROP expression graph'. It lists specific capabilities (copy masters, wire connectors, apply parameters, deterministic layout, expose output) and distinguishes itself from siblings by naming create_raytk_scene and create_raytk_op as complements. This makes the tool's purpose unambiguous and differentiated.

  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 usage context by explicitly naming sibling tools ('Complements create_raytk_scene (minimal scene) and create_raytk_op (single ROP)') and states a prerequisite ('Requires RayTK staged and loaded'). It implies when to use this tool (for a full editable graph vs minimal or single-op) but does not explicitly state when not to use it or give strict exclusion criteria, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• read_parameter_modesA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only'. It adds context about what is returned (modes, raw strings) but does not describe error behavior, performance, or other side-effect details. The added value is moderate, consistent with the calibration example where annotations cover the safety profile.

  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 three sentences long, front-loaded with 'Read-only' and a clear summary of what is reported. Every sentence earns its place: the first defines the behavior, the second gives usage scenarios, and the third explains the optional filter parameter. No fluff.

  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 output schema exists and annotations cover safety, the description adequately explains what the tool does and when to use it. It could mention error cases or examples of modes, but the provided information is sufficient for an agent to select and invoke correctly. The `keys` parameter is not discussed in the description, but the schema covers it.

  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 the baseline is 3. The description adds value beyond the schema by explaining the practical meaning of `non_default_only` ('parameters that would be lost in a plain value copy') and the overall purpose of mode reporting, which helps interpret the 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 clearly states the tool reports parameter modes (CONSTANT/EXPRESSION/EXPORT/BIND), evaluated values, and raw expression strings. It uses a specific verb ('report') and resource ('parameters of a node'), and distinguishes itself from sibling tools like get_td_node_parameters by emphasizing mode/expression awareness.

  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 explicitly states when to use the tool: 'Use this to faithfully serialize a network for round-trip editing, diffing, or debugging.' It also explains why (evaluated value hides expression/export bindings). It does not explicitly name alternative tools or state when NOT to use, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• refresh_asset_previewsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint=true and readOnlyHint=false. The description adds useful context beyond annotations: requires a running TouchDesigner bridge, overwrites image files, and returns written previews plus per-target warnings. This enriches the behavioral picture without contradiction.

  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 three sentences, front-loaded with the key action, then use case, then requirements/return. Every sentence is purposeful, no fluff or redundancy, and it remains appropriately sized for the tool's complexity.

  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 no output schema, the description covers return values ('returns written previews plus per-target warnings'), prerequisites (running bridge), and side effects (overwrites image files). It could add details about error handling or edge cases, but it is complete enough for an agent to use the tool safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema fully documents width, height, and targets. The description mostly restates schema details (e.g., 'pass targets as {node_path,file_path} plus optional width/height') without adding new meaning or clarifying semantics beyond what is already present.

  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 captures fresh preview PNG assets from live TOP nodes and writes each to its file_path, which is a specific verb+resource+scope. It distinguishes from siblings like get_preview by emphasizing the write-to-file behavior and the 'regenerate stale thumbnails' use case.

  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 explicit context: 'Use it to regenerate stale thumbnails after a network changes'. It doesn't name alternative tools, but the when-to-use scenario is clear. It also implies prerequisites (running bridge) and the target structure, offering guidance without explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• render_outputA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate a write operation with side effects, and the description adds key context: the file is written by TouchDesigner on the TD machine and an absolute path is required. This helps prevent path confusion. It does not disclose overwrite behavior, but the annotations already signal side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences pack all essential information: action, formats, contrast with sibling, and file location. No wasted words; front-loaded with the core purpose.

  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 2-parameter file-export tool, the description covers purpose, formats, resolution, and machine location. It lacks explicit overwrite semantics, but the schema and annotations fill most gaps, making it sufficiently 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 input schema already provides 100% coverage, including the fact that the file path is on the TD machine and extension picks format. The tool description repeats this information but does not add new meaning 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 uses a specific verb 'Save a TOP to an image file' with resolution detail, and explicitly contrasts with get_preview to clarify its unique role. It clearly identifies the resource (TOP) and the action (exporting full-res image).

  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 states 'unlike get_preview which only transfers a small inline thumbnail', providing an explicit named alternative and context for when to use this tool (exporting a finished frame). It could more explicitly say 'use for full-res export, not for quick previews', but the contrast is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• save_component_to_vaultA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations indicating a write operation and non-destructive behavior, the description adds valuable context: the companion note content, the .tox location format, and the dependency on TDMCP_VAULT_PATH. It doesn't contradict annotations. The only gap is not mentioning overwrite behavior, but the destructiveHint=false already covers safety.

  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 well-structured: a main purpose sentence, a cross-reference to manage_component, and two prerequisite statements. No filler or redundancy, every sentence contributes context.

  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 (8 params, no output schema), the description covers the main workflow, prerequisites, and outputs. It doesn't mention return values or error scenarios, but the detailed schema and annotations fill most gaps. Overall it is sufficiently complete for an agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter having a detailed description, including preview_top's caveat about TOP rendering. The description itself adds minimal parameter-specific meaning beyond restating folder/name in the path, so the baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: saving a TouchDesigner COMP as a .tox in the Obsidian vault and writing a companion markdown note. It uses a specific verb (save) and resource (COMP as .tox), and differentiates from siblings like save_recipe_to_vault and export_network_to_vault by focusing on reusable components and the package-to-library loop.

  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 places this tool within a workflow ('completing the build→parameterize→script→package-to-library loop') and specifies prerequisites (TDMCP_VAULT_PATH, COMP must exist and be a COMP). It also mentions the inverse operation with manage_component. However, it doesn't explicitly contrast with alternative save/export tools, leaving some ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scaffold_extensionA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite annotations already indicating a non-read-only, non-destructive, open-world mutation, the description adds meaningful behavioral details: creating a Text DAT, wiring into a slot, optional promotion, and reinitialization. It discloses the main side effects without contradicting 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 concise (two sentences) and front-loaded with the core action. Every phrase earns its place: the action list is specific, and the pairing guidance is valuable without bloating the text.

  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?

  The description covers the main workflow steps (create, wire, promote, reinit) for a mutation tool, and the schema fully documents parameters. It is sufficiently complete for an agent to understand when and how to invoke the tool, though it omits potential edge cases like overwriting an existing extension in the slot.

  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 all parameters, so the baseline is 3. The tool description restates the meaning of `methods` and `promote` but does not add new syntax or constraints beyond what the schema already provides, making its contribution marginal.

  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 and resource: 'Give a COMP a Python extension class', and enumerates the concrete steps (create Text DAT, wire into slot, promote, reinitialize). It also distinguishes itself from related tools by naming companion tools (`add_custom_parameters`, `manage_component`), making its role clear.

  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: it is 'the other half of making a generated network reusable' and explicitly recommends pairing with `add_custom_parameters` and `manage_component`. However, it does not state when NOT to use this tool versus other scaffold tools, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scaffold_tool_generatorA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only provide readOnlyHint=false and destructiveHint=false, which are minimal. The description adds valuable behavioral context: it is a local filesystem generator with no TD bridge call, and it returns an integration-hint. It does not fully explain overwrite conflict behavior, but the schema's 'overwrite' parameter covers that.

  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 only three sentences, front-loaded with the core purpose, and each clause adds essential detail (artifacts, unit test, return hint, no bridge call, local filesystem). No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 6-parameter tool with 100% schema coverage and no output schema, the description explains the most important missing piece—the return value (integration-hint with import line, array entry, layer index). It is complete for the tool's complexity, though it could mention behavior when overwrite=false and a file exists.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive per-parameter text, so the baseline is 3. The description's 'one-line idea' aligns with the required 'description' parameter but adds no new parameter-level meaning 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 identifies this as a 'Meta DX tool' with a specific verb ('scaffolds') and resource ('a new tdmcp tool file (xSchema + xImpl + registerX) and a matching offline msw unit test'). It also states the unique return value (integration-hint), distinguishing it from other scaffolding sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context: use it to generate a new tdmcp tool from a one-line idea, and explicitly notes what it does not do ('No TouchDesigner bridge call — pure local filesystem generator'). It does not name alternative scaffolding tools, but the behavior is specific enough to avoid confusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scaffold_vj_deckA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the full set of components created (A/B deck mixer, control surface, midiinCHOP surface) and how bindings are wired, along with default behavior for omitted sources and midi_map. Annotations already indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true; the description aligns and adds useful context about the composed side effects without contradicting 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 three sentences with no wasted words. The first sentence front-loads the main purpose and component breakdown; the second efficiently covers the key parameters and defaults; the third clarifies the tool's relationship to the primitive. Every sentence earns its place and the structure is easy to scan.

  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 an 8-parameter tool with no output schema and no required parameters, the description covers the essential context: what is created, how parameters affect the result, default behaviors, and the relationship to sibling primitives. It does not describe return values, but given the absence of an output schema, that is not necessary. Minor gaps include a lack of explicit mention of side effects on the parent container or existing nodes, though the openWorldHint annotation covers this partially.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds a small amount of contextual meaning by explaining that deck_a/deck_b are source TOP paths and that omitting them creates test sources, and it summarizes the midi_map default behavior. However, most parameter semantics (defaults, ranges, descriptions) are already fully covered by the input schema, and the description does not significantly extend beyond that.

  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 a specific verb and resource: 'Compose a complete, playable VJ deck UI in one call.' It further distinguishes itself from siblings by explicitly naming the primitives it wraps (create_decks, create_control_surface, create_external_io) and positioning itself as the 'deck-scaffold layer on top of the create_decks primitive,' making its unique role 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?

  The description explains the intended use case ('Compose a complete, playable VJ deck UI in one call') and contrasts with the primitive by stating it 'wires the existing deck, surface, and I/O tools into one UI container.' It also provides parameter usage guidance (pass source TOP paths or omit for test sources, optional midi_map). However, it does not explicitly state when NOT to use this tool in favor of an alternative, such as 'if you only need a deck, use create_decks.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_parameters_batchA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses a key behavioral trait: per-update success reporting and lack of rollback. This is valuable context for an agent evaluating side effects and error handling. It adds meaningful information without contradicting 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 two sentences long, front-loads the core purpose, and includes the most important behavioral caveat. Every word earns its place with no redundancy or filler.

  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 a fully documented schema, annotations, and a description covering both purpose and non-transactional behavior, the tool description is largely complete for an agent. The only minor gap is lack of explicit guidance on response format or alternatives, but the description sufficiently covers the essential usage context.

  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 full descriptions for all parameters (100% coverage), including the path, parameters map, and the array semantics. The description adds little beyond restating the batch behavior, so it does not significantly enhance parameter understanding 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 the tool's function: 'Update parameters on multiple nodes in a single batch request.' This specifies a precise verb (update), resource (parameters on nodes), and scope (multiple nodes in a batch), distinguishing it from single-node tools like update_td_node_parameters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for batch updates across multiple nodes, which guides when to use it. It also includes a critical caveat about non-transactional behavior ('a failure does not roll back the others'), which helps the agent decide if this tool is appropriate. However, it doesn't explicitly mention alternatives or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• setup_hand_trackingA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are minimal (readOnly=false, openWorld=true, destructive=false), but the description adds substantial behavioral context: it installs/loads an engine, starts the timeline, creates a Script CHOP, and specifies the output path. This matches the annotations and gives agents a clear model of side effects without contradiction.

  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?

  Four sentences cover the full pipeline, output format, usage recommendation, and sibling relationship without fluff. It is denser than a two-sentence ideal, but every sentence earns its place and the primary action is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a setup tool with 5 parameters and no output schema, the description fully explains what is built, where the output lives, what channels it provides, and how it can be consumed downstream. It also covers installation and shared-engine compatibility, making it self-sufficient for an agent.

  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 describes all 5 parameters at 100% coverage, including defaults and coordinate_space guidance. The description reinforces key points like the output path and world-coordinate suitability but does not add significant new parameter-level detail 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 specifies a concrete pipeline: loads the MediaPipe engine, starts the timeline, locates the hand JSON DAT, and builds an adapter Script CHOP with a canonical channel layout. It also explicitly contrasts with setup_body_tracking by noting they share the same engine, distinguishing it from siblings.

  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?

  It gives clear usage context: one-shot webcam hand tracking setup, recommends coordinate_space='world' for gesture detection, and notes compatibility with setup_body_tracking. It does not explicitly state when to prefer alternatives like create_hand_gesture_bus or Leap Motion bridges, but the guidance is strong enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• show_preflight_reportA
  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 destructiveHint=false. The description reinforces this with 'without mutating the project' and adds context on what the report includes and how results are categorized. It does not discuss latency, network calls, or environmental dependencies, but given strong annotation coverage, the added context is valuable enough for a 4.

  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 key qualifier 'Read-only pre-show check'. It lists all major capabilities in a compact enumeration and ends with a direct usage statement. Every word earns its place with no redundancy or filler.

  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?

  The description provides a clear purpose, scope, usage timing, and safety guarantee. An output schema exists, so return details are handled elsewhere. It does not mention prerequisites or failure modes of the preflight itself, but for a read-only aggregate tool with strong annotations and complete schema, this is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so each parameter is already documented with name, type, default, and description. The tool description adds no additional parameter-level detail, but it doesn't need to; the schema carries the full burden. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb+resource: 'Read-only pre-show check' and enumerates the exact set of checks (bridge reachability, node errors, topology, cook-time budget, GPU/display, perform-mode status). It distinguishes itself from sibling tools by presenting itself as a consolidated report generating PASS/UNVERIFIED/WARN/FAIL results.

  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 explicitly says 'Use before rehearsals or venue handoff', giving clear when-to-use context. It does not name alternative tools or provide explicit when-not-to-use guidance, but the aggregation nature and the 'in one PASS/UNVERIFIED/WARN/FAIL report' phrasing imply it should be preferred for a comprehensive pre-show overview.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• version_library_assetA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the exact side effects: writing to a sidecar `<asset>.versions.json`, updating frontmatter `version` field, and the read_only mode. It also mentions the environment requirement (TDMCP_VAULT_PATH). Annotations already indicate mutability, but the description adds specific file-level behavior that annotations do not provide.

  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 three sentences long, front-loaded with the core action, and every sentence earns its place. It packs essential information (operation, file effects, read_only mode, environment requirement) without redundancy or fluff.

  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 tool with six parameters and no output schema, the description covers purpose, side effects, read_only mode, and environment prerequisites. It does not describe error cases or return format, but the provided information is sufficient for an agent to invoke the tool correctly in most scenarios.

  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 detailed descriptions for all six parameters (100% coverage), so the baseline is 3. The description does add context about the sidecar structure and read_only behavior, but it does not significantly expand on individual parameter semantics beyond what the schema already states.

  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 a specific verb+resource: 'Apply a SemVer patch/minor/major bump to a vault recipe or component note.' It clearly distinguishes its scope from siblings by specifying the vault asset context and the sidecar/frontmatter side effects, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a concrete usage mode: 'Pass `read_only:true` to inspect the sidecar without bumping,' and states an important selection criterion: 'Pure vault I/O — no TouchDesigner bridge required.' It does not explicitly name alternative tools, but the context is clear enough for an agent to decide when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• browse_libraryA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it's a discovery step returning matching recipes/packages for selection, which is useful context beyond the annotations. No contradictions found.

  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 with the main purpose front-loaded. The second sentence packs in usage context and output without wasting words. No redundant phrases or filler.

  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?

  Has an output schema, so return values are covered. The description explains the purpose, the workflow context, and what the tool returns (matching recipes/packages). Minor gaps in parameter semantics remain, but given five optional parameters and a rich output schema, the description is mostly 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?

  Schema description coverage is 0%, and the description does not explain the tags, query, or package_dir parameters. It only loosely maps to include_recipes/include_packages via the terms 'recipes' and 'packages'. The word 'matching' implies filtering but gives no specifics, so the description fails to compensate for the missing schema descriptions.

  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 'Browse built-in/vault recipes and optional local component packages' with a specific verb and resource. It also distinguishes this tool from apply_recipe and install_library_package by describing it as a discovery step, making its unique role obvious.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says 'Read-only discovery step before instantiating a recipe (apply_recipe) or installing a package (install_library_package)', which clearly tells when to use this tool versus the named alternatives. It also explains the expected outcome ('returns the matching recipes and packages'), giving solid guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• browse_vault_libraryA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with "Read-only". It adds valuable context: "No TouchDesigner connection required — reads the local vault on disk" and "Requires a configured TDMCP_VAULT_PATH". It also describes the return format (flat items array and per-category counts), going beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the primary purpose. Every sentence adds value: purpose, filtering options, and important constraints/returns. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 two optional parameters and an existing output schema, the description is complete. It covers what the tool does, how to filter, what it returns, and the required environment variable, making it fully self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description says "Filter by category (kinds) and/or a substring query", which paraphrases the schema's parameter descriptions. It adds no new syntax or format details beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb "list" and the resource "the vault's recipes, shaders, presets, components, and setlists" with specific fields (title, tags, description). It distinguishes from siblings by emphasizing the local vault on disk and no TouchDesigner connection needed.

  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 says "so the agent can pick from the library without opening individual notes", which clarifies when to use this tool. It also notes "No TouchDesigner connection required", helping choose this over TD-connected tools. It does not explicitly name alternatives, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• capture_to_vaultA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read-only, open-world operation. Description adds crucial side effects: writes PNG to <gallery>/images/ and appends to <gallery>/<note>.md, plus default date behavior and prerequisite TDMCP_VAULT_PATH. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each adds value: purpose, mechanics, and use cases/prerequisite. Well-structured and front-loaded with the main action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a write tool with 6 params and no output schema, description covers purpose, side effects, location details, and required environment variable. It is sufficiently complete for an agent to know when to call it and what to expect.

  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 covers 100% of parameters with descriptions, so baseline is 3. The description adds workflow context (defaults to today's date, daily accumulation) but does not elaborate on individual parameters beyond the schema. It is acceptable but not exceptional.

  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?

  Description clearly states 'Captures a preview still from a TOP and appends it to a dated gallery note in the Obsidian vault', identifying both the action and target. This differentiates it from sibling vault tools like save_component_to_vault or export_network_to_vault, which target different resources.

  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 explicit use cases: 'Use this to document looks, reference frames, or build a browsable gallery of your session's visuals.' It does not mention alternatives or exclusions, but the context is sufficient for when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_control_surfaceA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description adds meaningful behavioral context: it builds a specific composite, describes fader-to-parameter binding, and notes that cue buttons fire scenes 'instantly or with a crossfade.' This provides transparency about runtime effects without contradicting 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two well-structured sentences, front-loaded with the core purpose. It has minor redundancy (repeats faders/buttons behavior), but remains efficient and scannable. Every sentence earns its place, though the second sentence could be tightened.

  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 moderate-complexity tool with no output schema, the description covers the constructed result and usage mode. It lacks explicit prerequisites (e.g., that cues must already exist via manage_cue, or that comp_path must be a valid control COMP), leaving minor gaps for an agent invoking the 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 coverage is 100%, so baseline is 3. The description enriches the parameter understanding by tying `faders` and `cue_buttons` to their live behavior ('faders move their parameters, cue buttons fire scenes') and explains the role of `morph_seconds` via crossfade, adding high-level meaning beyond the schema field descriptions.

  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: 'Build a playable performance panel (a Container COMP of visual widgets)' with specific sub-features (vertical faders, cue buttons). It distinguishes itself from siblings by emphasizing 'beyond the parameter dialog' and referencing `manage_cue` for cue recall, making the scope distinct from generic panel creation tools.

  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 gives practical guidance on use: 'Open the container in Perform/Panel mode for a touchable surface' and explains how faders and buttons behave. It implies when to use this tool (live performance panel with cue control) but does not explicitly name alternatives or exclusions, so it falls short of a perfect score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_depth_from_2dA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses creation of a new container, wiring, and a depth Null TOP, consistent with readOnlyHint=false. It adds performance context (30–60s compile) and dependencies, going beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a dense but well-organized paragraph that covers purpose, dependencies, constraints, performance, and returns without wasted words. It's slightly long but every sentence contributes.

  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?

  The description covers purpose, requirements, OS limits, output fields, and downstream usage, making it quite complete for a tool with no output schema. It omits error scenarios but provides sufficient operational context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description adds context about source_top_path and output_resolution/model_variant in the return list but doesn't significantly enhance param understanding 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 the tool converts any 2D image/video TOP into a depth map TOP using Depth Anything v2, with a specific verb and resource. It also distinguishes from siblings by mentioning downstream tools (create_depth_displacement, etc.) that consume its output.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly specifies prerequisites (installed TOX, NVIDIA GPU with CUDA/TensorRT), platform exclusion (macOS), and first-cook timing. It positions the tool as an alternative to hardware depth sensors ('no Kinect or RealSense required') and indicates typical integration by naming downstream consumer tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_histogram_scopeA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly=false, destructive=false), the description reveals the internal node chain (GLSL TOP, CHOP sampling, normalisation, choptoSOP → renderTOP) and the output as a Null TOP. It also notes the GPU computation and suitability for previews/bind_to_channel. Minor gap: no mention of failure modes or state changes to input TOPs, but enough operational behavior is disclosed.

  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 compact and information-dense: purpose, pipeline, output, and sibling differentiation are packed into four sentences. Each clause contributes value, though the final sentence repeats 'single-scope, working histogram' and 'standalone focused tool' slightly redundantly. Still, overall structure is efficient and 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 complex tool with 12 parameters, no output schema, and only modest annotations, the description provides a high-level architecture, output type, usage context, and explicit alternative. It omits per-parameter edge cases (e.g., informational flags) but those are already in the schema descriptions. The return value (Null TOP) is stated, making the tool understandable in context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with detailed descriptions for all 12 parameters, so the baseline is 3. The description adds some context (e.g., 'any TOP', output for previews) but does not elaborate on parameter usage beyond what the schema already provides. It does not compensate for or contradict the schema, so a mid-score is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb-resource pairing: 'Build a luminance (and optional per-channel RGB) histogram video scope for any TOP.' It then outlines the full GPU-to-CHOP-to-SOP pipeline and output format. It explicitly distinguishes this tool from create_video_scopes by stating it is the single-scope working histogram that create_video_scopes can't render, making it unique among siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear when-to-use guidance: it is for a single histogram scope, while 'for a combined waveform/parade/vectorscope monitor use create_video_scopes.' It also explains the limitation of the alternative (can't render in TD 099), which helps the agent choose correctly. The context is explicit and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_kaleidoscopeA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description discloses what gets created under parent_path (baseCOMP, source, GLSL fold pass, Null output), the optional noise-source behavior, and the return payload including paths, controls, errors, and preview. It does not cover every edge case such as overwrites or invalid parent paths, but the added detail is substantial.

  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 dense but efficient, with every sentence contributing value: effect definition, folding mechanics, node construction, input modes, and return format. It is front-loaded with the core action and contains no filler or tautological phrases.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 thoroughly explains the returned JSON structure (container path, created node paths, output path, exposed controls, errors, warnings, preview image). It also covers both input scenarios and the parent_path placement, making it complete enough for a complex network-creation 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 100%, so all eight parameters already have precise descriptions, defaults, and units in the schema. The tool description references the parameter groups (Segments/Rotation/Zoom/Center) and input_path, but adds no new parameter-level meaning beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific action ('Wrap a source in a kaleidoscope / radial-mirror symmetry effect') and clearly identifies the resource being created. It distinguishes the tool from sibling creation tools by detailing the wedge-folding behavior, controls, and node structure it produces.

  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?

  It provides clear context for when to use the tool and gives two explicit usage modes: pass input_path to process an existing visual, or omit it to generate a self-contained noise source. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_led_mapperA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false, openWorldHint=true, destructiveHint=false. Description adds meaningful behavior: chain resizes, samples texels, preserves RGB, returns node paths/channel count/warnings, defaults to a moving Ramp test source, and warns that real output requires verification. Would benefit from more on potential overwriting of existing nodes, but strong beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences each earn their place: function, behavior/return values, default/caveat/alternative. Slightly dense but well-structured and front-loaded with the primary purpose.

  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?

  No output schema, but description compensates by enumerating return values (node paths, channel count, warnings, live controls) and the test source default. Covers prerequisites implicitly with the reachable fixture warning. Complete for a complex tool, though no mention of name collision behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all 11 parameters are documented in the schema. The description adds context about width×height resizing and source default, but these are largely already in the schema descriptions. Baseline 3 is warranted.

  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?

  Specific verb 'Build' + resource 'pixel-mapping chain from source TOP to LED fixture grid and DMX Out CHOP over Art-Net or sACN'. Distinctive from sibling create_dmx_fixture_pipeline, which is explicitly named as an alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states 'Use create_dmx_fixture_pipeline for fixture patching and this tool when you specifically need image-to-pixel mapping.' Provides clear when-to-use and alternative tool guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_macroA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate a non-read-only, non-destructive, open-world operation. The description adds meaningful behavioral detail: it creates expression-bound targets that track the macro live, and it clarifies the remapping and curve mechanics. This goes beyond the annotations by explaining the underlying mechanism and side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core action ('Add one macro knob'), then elaborates on the mechanism and use case. Every clause contributes useful information, with no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a creation tool with full schema coverage and no output schema, the description covers the purpose, the behavior, and the use case. The only minor omission is explicit prerequisites (e.g., that the target COMP must exist), but the comp_path default and schema make this relatively clear. Overall, it is complete enough for an agent to select and invoke correctly.

  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 descriptions already cover all parameters (100% coverage), including min, max, curve, and comp_path. The description's mention of '[min,max] range' and 'optional response curve' merely echoes the schema fields without adding a new semantic layer. Therefore, the description adds little beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description begins with a specific verb ('Add') and identifies the resource ('one macro knob to a COMP') and its distinctive behavior ('drives many parameters at once, each remapped into its own [min,max] range with an optional response curve'). This clearly differentiates it from sibling tools like create_control_panel or add_custom_parameters by emphasizing the one-to-many mapping.

  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: it is for sweeping a whole look from a single fader via one-to-many control. It does not explicitly mention alternatives or exclusion cases, but the intended use case is unambiguous and sufficient for an agent to decide when to select it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_midi_mapA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds key behavioral details: CC/note numbers are 'best-effort' and 'MUST be validated with real hardware', and the tool is 'HELD FROM RELEASE until hardware validation is complete'. These disclosures about reliability and external dependence are valuable context that annotations alone do not provide.

  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 compact but information-dense. It front-loads the core action and follows with the key caveats and alternative tool. Every sentence contributes meaning, though the density might push the boundary of conciseness. Still, it is well-structured and free of fluff.

  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?

  Considering the tool's complexity (5 parameters, nested bindings, no output schema), the description covers essential context: what gets created, device presets, auto-binding behavior, hardware validation, and the alternative. It doesn't exhaustively describe every TouchDesigner-specific output detail, but the schema covers parameters well and the description is sufficient for a capable agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% and the property descriptions are already detailed (e.g., bindings explains 'Explicit control→param/cue overrides'). The description adds context for how parameters fit together (auto-binding to target COMP, preset override), but doesn't add syntactic meaning beyond the schema. Baseline 3 is appropriate given the 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 function: 'Build a MIDI controller preset for a supported device (apc_mini / launchpad / midi_mix / nanokontrol / generic)'. It specifies the concrete output: 'creates a midiinCHOP + a labeled bind Table DAT'. This distinguishes it from sibling tools like learn_control via explicit contrast.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance: 'For one-at-a-time MIDI learn of a single control, use learn_control instead.' It also clarifies the scope and override mechanism ('Explicit bindings can override or supplement the preset'), giving the agent clear context for when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_npr_filterA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description discloses significant behavior: it creates a Select→GLSL→Null chain, exposes live-tweakable params, and explicitly warns that `glsl_compile_verified` is always false offline and to verify with `get_td_node_errors`. It also notes the cost model in the schema but the description adds the offline-compile caveat and return-value structure.

  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?

  Three dense sentences front-load the core purpose and then systematically cover algorithm, node chain, exposed params, and return values. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 9 params and no output schema, the description covers the algorithm, chain creation, exposed controls, and exact return values including the compile-verification caveat. This is complete for an agent to invoke and interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions (modes, defaults, ranges, cost hints). The description adds no new parameter-level info beyond mentioning Radius/Smoothness/Strength as exposed parent controls, which is a behavioral detail rather than input semantics. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening sentence uses a specific verb+resource ('Apply a non-photorealistic painterly filter to an existing TOP'), and the description elaborates with three distinct modes (oil, pencil, watercolor), clearly distinguishing it from sibling tools like create_glsl_shader or create_raytk_op.

  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 focuses entirely on mechanics and does not explicitly state when to choose this over alternatives. Usage is implied (painterly NPR effect on a TOP), but there is no 'when-not' or comparison to sibling create_* tools, so guidance remains implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_paletteA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description states what it builds (Ramp TOP gradient, Constant CHOP with swatch{i}r/g/b channels), that live controls are exposed on the parent, and that it builds standalone. This goes beyond the readOnlyHint/destructiveHint annotations and provides useful behavioral context, though it does not discuss permissions or edge cases like fallback behavior from the schema.

  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 dense paragraph but every sentence adds value: modes, outputs, downstream usage, live controls, standalone nature. No fluff, appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 11-parameter tool with no output schema, the description covers the core concept, modes, generated artifacts, and integration targets. It leverages the schema for parameter details and the annotations for safety flags, so it is complete enough for an agent to decide when and how to use it.

  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% parameter descriptions, so the description adds little beyond what the schema states. It does clarify the conceptual relationship between modes and parameters (e.g., base_hue, rule, count) and mentions the exposed controls, but no new parameter syntax or semantics beyond 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 'Generate a reusable colour palette + gradient other tools can bind to,' which is a specific verb+resource. It distinguishes two modes ('harmony' vs 'from_source') and names downstream consumers (create_color_grade, generate_from_moodboard, bind_to_channel), making it distinct from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explains when to use each mode (harmony for computed swatches, from_source for sampling a TOP) and notes that a harmony palette is standalone. However, it does not explicitly name alternative tools or exclusion cases, so it is clear but not maximally explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pop_lines_pointcloudA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and destructiveHint=false, which aligns with creating a new visual. The description adds valuable behavioral context: POPs are Experimental, par names and Nebr attribute survival are unverified, count is hard-capped at 8192 with O(N·k) CPU cost, and result carries extra.unverified. This goes 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 dense yet well-structured: it front-loads the core purpose, then walks through the pipeline, enumerates options, and ends with critical caveats. Every clause provides useful information without redundancy, appropriate for a tool with 15 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?

  Given the tool's complexity and lack of output schema, the description covers purpose, pipeline, parameter semantics, and caveats comprehensively. It does not explicitly state what the tool returns (e.g., the created container's path), which is a minor gap for an agent expecting an output. Overall, it is highly complete for selection and invocation.

  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 coverage is 100%, yet the description adds substantial meaning: auto_pattern options are paired with specific POP nodes, color_mode is explained semantically, and inter-parameter relationships are clarified (e.g., auto_pattern only used when source_path undefined, max_distance drives density). This exceeds the baseline of 3.

  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 this tool creates a Plexus-style line-web visual built on the POP family, with a specific pipeline (POP point cloud → Neighbor POP → Script SOP → Geometry COMP → Render TOP → Null TOP). It is a specific verb+resource+style, distinguishing it from other create_* siblings like create_pop_field or create_point_cloud.

  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 explaining the Plexus effect, auto_pattern options, and the caveat about POPs being experimental. However, it does not explicitly state when to use this tool versus alternatives (e.g., create_pop_particle_system, create_vector_lines) or when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pose_trackingA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only state readOnly=false and destructive=false. The description adds value by revealing it creates two CHOPs, includes smoothing and mirror features, and that the synthetic source requires no camera or plugin. It also notes the free MediaPipe plugin dependency for real tracking. Does not mention potential overwriting, but annotations already cover destructiveness.

  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?

  Four sentences, densely packed with purpose, outputs, source options, features, and downstream integration. Every sentence earns its place, and the description is front-loaded with the primary purpose. No filler or tautology.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 8 parameters and no output schema, the description is remarkably complete: it explains core function, data structure (33 landmarks, tx/ty/tz/confidence, keypoints examples), source variants, default behavior, and downstream use. It gives an agent everything needed to invoke the tool and set expectations.

  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 provides detailed, 100% coverage for all 8 parameters. The description adds no new parameter-level semantics beyond echoing the synthetic default and source enum. Baseline 3 is appropriate since the schema handles the heavy lifting.

  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?

  Clearly states it sets up full-body pose tracking and describes the produced outputs (canonical pose CHOP and keypoints CHOP). It distinguishes itself as the foundation for body-reactive visuals, explicitly naming downstream tools (create_pose_skeleton, create_body_reactive) and contrasting with extract_audio_features.

  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 strong usage context: it is the foundation for body-reactive visuals, and the output feeds into create_pose_skeleton or create_body_reactive. Also explains when to use the synthetic default (no camera/plugin) versus mediapipe, osc, or existing_chop. Lacks explicit exclusions, but the guidance is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_raytk_opA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, so the agent knows this is a mutation. The description adds valuable behavioral context: it uses COMP.copy, resolves the install-dependent master path live (never hardcoded), and discloses that the toolkit must be loaded first. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences and dense with useful information. It front-loads the core action ('Copy a RayTK ROP master...') and then adds prerequisites and differentiation. It is slightly lengthier than the simplest examples but each clause serves a purpose—no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 9 parameters and no output schema, the description covers essential context: the copy mechanism, path resolution strategy, required setup, and relationship to a sibling tool. It does not explain return values, but with no output schema and a simple creation action, the main missing piece would be what the tool returns—yet this is likely inferable. Overall it is complete enough 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description reinforces op_type semantics with examples ('sphereSdf', 'raymarchRender3D') and explains input_index for raymarchRender3D, but these details are already present in the schema. The description adds marginal value beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: copying a RayTK ROP master into a network and optionally wiring an existing op into a typed input. It names the specific master categories (SDF / camera / light / combine / material / render) and explicitly contrasts itself with the sibling tool create_raymarch_scene, making its unique role unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: it requires the RayTK toolkit to be staged and loaded, points to manage_packages and the tdmcp://raytk/operators catalog for prerequisites, and clearly distinguishes when to use this tool versus create_raymarch_scene ('this instances RayTK's own operators instead of authoring a shader'). This gives the agent clear decision criteria for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_schedulerA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a mutating, non-destructive, open-world tool, and the description adds specific side effects: it creates a scheduler COMP with a shared Callbacks DAT, fires callbacks on onDone/onSegmentEnter, and reuses manage_cue's tdmcp_cues storage. This gives the agent awareness of dependencies and created artifacts without contradicting 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?

  Three dense sentences front-load the core purpose and then add dependency and usage context. Every sentence contributes distinct value: what is built, how it fits in the automation stack, and its storage dependency. No filler or repetition of the input schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex constructor tool, the description covers the essential conceptual model (timers, segments, callbacks), the dependency on manage_cue, and the distinction from create_scene_timeline. The schema provides complete parameter-level detail, and the description adds the missing architectural context. The tool's output is a built COMP, which is implicitly clear, so no return-value explanation is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 8 parameters with detailed descriptions (100% coverage), so the description doesn't need to restate parameter syntax. It adds high-level context about timer/segment structure and the manage_cue dependency for 'cue' actions, but this doesn't materially exceed what the schema already communicates. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Build a Timer-CHOP scheduler COMP' and details its core components (named timers, optional segments, shared Callbacks DAT, cue/param/script actions). It clearly distinguishes itself as 'atomic timer primitive that create_scene_timeline and other automation rides on', separating it from higher-level timeline/sequencer siblings.

  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 frames this as a foundational primitive for automation, implying use when building lower-level timer logic rather than higher-level scenes/timelines. It also gives a concrete prerequisite: 'store target cues first with manage_cue' for the default cue action. It doesn't explicitly name alternative tools or state when not to use it, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_stage_dashboardA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnly=false, openWorld=true), the description discloses the server's network exposure and lack of auth, the POST-back mechanism, and that the panic button toggles the target COMP's safety pars. This adds meaningful behavioral context such as security risk and how the page communicates with the server.

  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 moderately long but every sentence earns its place: purpose, feature list, architecture preview, security warning, and prerequisites. It is well-structured and front-loaded with the core function, avoiding fluff while covering essential context.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (9 parameters, two layouts, external dependencies), the description covers the purpose, components, security, dependencies, and behavior of the created server. It is sufficiently complete for an agent to decide when and how to use it, especially since the schema fully documents parameters and the annotations cover safety profile.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description mentions parameters at a high level (cues, faders, panic, layout) but does not add new semantic details beyond what the schema already provides. It does clarify how the pieces fit together, but the schema carries the bulk of parameter meaning.

  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 defines the tool as creating a unified live-performance web dashboard from a Web Server DAT, enumerating specific features (cue-launch buttons, faders, panic, readout). It distinguishes itself from siblings by referencing dependencies (manage_cue, create_panic) and the security similarity to bridge/create_phone_remote, so 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states a security condition ('use it only on a trusted network'), implying when not to use it. It also provides clear prerequisites: 'Store cues with manage_cue, expose params with create_control_panel, and run create_panic first'. This gives strong when-to-use guidance and sets up dependencies, though it does not directly contrast with create_phone_remote beyond security.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_terrainA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only signal readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description carries the behavioral burden and delivers—stating it 'Creates a new baseCOMP under parent_path,' exposes Height/Drift/WaterLevel/Zoom controls, and details the JSON return payload (container path, node paths, output path, errors, warnings, inline preview). No contradiction with annotations exists.

  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 longer than average (about eight sentences) but front-loads the core purpose and every clause adds information: pipeline components, optional water/fog, sibling distinction, creation path, exposed controls, and return format. It is on the verbose side but contains no filler.

  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 13-parameter creation tool with no output schema, the description covers the full build pipeline, optional behaviors (water, fog), create location, live controls, and exactly what the return payload contains. Prerequisites and failure modes are not spelled out, but node errors/warnings are part of the declared return, keeping this sufficiently 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?

  With 100% schema-description coverage, the schema already documents all 13 parameters, so the baseline is 3. The description adds only marginal value—mapping exposed controls (Height, Drift, WaterLevel, Zoom) to the UI—and references water_level in context, but does not clarify anything the schema descriptions leave ambiguous.

  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 a specific action—'Build a procedural heightmap landscape'—and enumerates the exact pipeline (Noise TOP, Grid SOP, GLSL vertex-displacement MAT, light, camera, render). It explicitly differentiates itself from create_visual_system's 'terrain' keyword, which is the closest sibling. The verb+resource+technical scope fully anchors the tool's purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names the main alternative: 'Distinct from create_visual_system's "terrain" keyword… this is a dedicated, fully parameterized terrain pipeline with its own displacement material, water, and fog.' This communicates when the more complete pipeline is needed versus the simpler recipe mapping. It does not enumerate every terrain-adjacent sibling, but the primary confusion point is directly addressed with a clear when-not distinction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_video_synthA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate non-read-only, non-destructive. The description adds context about creating a new container, output as Null TOP, and returning parameters/preview. It does not address potential side effects like overwriting existing containers, but given the annotation coverage, this is sufficient.

  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 appropriately sized, front-loaded with the core action, and every sentence serves a purpose (action, distinction, alternative, return value). The first sentence is long but packs necessary detail without waste.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex 9-parameter generator with no output schema, the description covers creation, output container, live controls, and return value. It lacks explicit mention of preconditions like parent_path existence, but is otherwise complete enough for selection and basic use.

  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 covers all 9 parameters with descriptions (100% coverage). The description mentions live Speed/FreqX/FreqY/Scale/Color controls but does not add meaning beyond the schema's own parameter docs, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Instantiate an analog video-synthesizer pattern... into a GLSL TOP') and defines the output ('output as a Null TOP inside a new container'). It distinguishes itself from siblings by naming create_shader_lib and create_video_player as alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: 'distinct from create_shader_lib's tunnel/raymarch/fractal/metaball looks' and 'Use create_video_player instead when you want to play a real movie file.' This tells the agent when to pick this tool vs others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_voxel_stackA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Exceeds annotation signals by detailing internal construction (boxSOP, N=256x256 instances), color modes, camera defaults, exposed controls, and fallback to animated noiseTOP. This is rich context beyond the readOnly/destructive flags.

  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?

  Four sentences, information-dense, front-loaded with the core purpose. No fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers the tool's behavior thoroughly: build method, limits, color modes, camera, controls, and default source. For a creation tool without output schema, this is sufficient.

  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 covers 100% of parameters with descriptions. The description does not add new parameter meaning; it summarizes color modes and controls already enumerated in the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb+resource: 'Isometric voxel-stack renderer driven by any TOP' and describes construction details (instanced Geometry COMP, CHOP chain). Clearly distinguishes from sibling create_3d_scene or create_geo_visualization by focusing on voxel-stack rendering.

  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?

  Implied usage from the description but no explicit when-to-use vs alternatives. It notes TOP-driven input and default noise TOP, which gives context, but doesn't name alternative tools or exclusion criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• diagnose_hardware_environmentA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only' and 'without mutating the TD project.' It adds behavioral details about the check types, return statuses (PASS/WARNING/FAIL/UNVERIFIED), and dependency on generated DATs, which goes beyond the annotation values.

  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 'Read-only' and then the specific checks. Every phrase adds value: scope, return type, and context. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having three optional parameters and an output schema, the description is complete enough for an agent to decide when and how to invoke it. It covers the purpose, safety profile, return statuses, and example DATs. The existence of an output schema means return-value details need not be spelled out.

  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?

  Input schema description coverage is 100%, so the schema already documents all three parameters. The description mentions example DAT paths (source_status, bridge_status) and the overall purpose, but does not add significant new meaning beyond the schema fields. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('check') and clearly lists the resources checked (TD reachability, display/projector topology, status DATs), distinguishing it from general info tools like get_td_info or get_td_topology. The phrase 'room/hardware preflight' reinforces its specific purpose.

  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?

  It provides a clear usage context: 'a room/hardware preflight for physical installations.' While it does not explicitly name alternative tools, the context is enough to guide an agent on when to select this over a general topology or info tool. No exclusions are stated, but the preflight framing is a strong signal.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_previewA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While annotations already declare readOnlyHint=true, the description adds behavioral specifics: 'it creates and modifies nothing', and details the return format (image with caption, RGBA samples with per-channel stats). This goes well beyond the simple safety hints and sets expectations for output.

  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 three sentences with each serving a purpose: main action, output format/limitation, and cheaper alternative. It is front-loaded with the core purpose and avoids fluff.

  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 thoroughly explains the direct image mode and sample_grid mode, but omits key usage paths such as delay_frames/job_id and pre_pulses, which are documented only in the schema. Since there is no output schema, the return values for these modes are not described in the 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?

  The input schema provides exhaustive descriptions for all 7 parameters (100% coverage), so the description offers little additional parameter semantics; it mainly restates the sample_grid trade-off ('cheaper check') already captured 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 clearly states a specific action: 'Capture a TOP node's current output as an inline PNG image'. It also distinguishes from other tools by noting 'only TOPs can be previewed' and by contrasting with the sample_grid variant.

  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?

  It explicitly gives a cheaper alternative ('For a much cheaper check... pass sample_grid=N') and an exclusion ('only TOPs can be previewed (CHOP/SOP/etc. have no image)'). However, it does not mention the deferred capture workflow via delay_frames/job_id, nor does it differentiate from the sibling get_inline_preview.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_node_flagsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavior beyond this: it enumerates the specific flag and wiring data returned, explains the recursive subtree scanning, and notes the conservative filtering behavior of only_problems. It also mentions structuredContent for code processing. This goes beyond merely repeating 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 three sentences, front-loaded with the core purpose and read-only guarantee. It packs details about flags, wiring, position, color, comment, recursive scanning, and the only_problems filter without any filler or redundancies.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the presence of an output schema and 100% parameter coverage, the description fully covers the tool's purpose, usage patterns, and behavioral nuances. It explains what the tool returns (flags, wiring, position, color, comment), how to scan subtrees, and how to focus on problem nodes, making it complete for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description mentions recursive and only_problems but essentially paraphrases the schema's own descriptions, adding no net-new parameter meaning. It does not add syntax or formatting details beyond what the schema already provides. Therefore, the description adds marginal value over 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 verb ('report') and resource ('each node's operator flags... plus index-aware input wiring, network position, color and comment'). The title adds a clear diagnostic purpose ('why-is-it-black inspector'), and the content distinguishes it from sibling tools like get_td_node_parameters or get_td_topology by focusing on output-suppression signals.

  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 clarifies when this tool is valuable: 'the signals that explain a black/blank output that a parameter dump hides.' It also explains the recursive scan mode and the only_problems filter. However, it does not explicitly name alternatives or state when not to use it, stopping short of a full when/when-not comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• inspect_gpu_and_displaysA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond the annotations: it explicitly states 'Read-only' (reinforcing the readOnlyHint), and crucially discloses the offline behavior with a fallback return of '{ connected: false, reason }'. It also lists the types of data returned, exceeding what the annotations provide.

  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 with no wasted words. It front-loads the key safety property ('Read-only'), then lists the return contents, the use case, and the offline fallback. Every sentence earns its place, 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.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple read-only tool with one optional parameter and good annotations, the description is complete. It covers what data is returned, when to use it, and how it behaves offline. The lack of an output schema is compensated by the explicit enumeration of returned data categories, making this a fully specified tool 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?

  The input schema already provides full coverage (100%) for the 'include' parameter, including an enum and description. The description does not add any additional parameter-specific semantics beyond what the schema states, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: it returns GPU info, monitor topology, and Perform Mode status. The verb 'returns' and specific resource scope make it distinct from siblings like get_td_info or get_td_performance, and the use-case mention ('plan output mapping, dome rigs, and multi-display shows') further differentiates it.

  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 gives a clear context for when to use the tool: 'Use to plan output mapping, dome rigs, and multi-display shows without leaving the chat.' It implies usage without explicitly stating when not to use it or naming alternatives, but the context is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_recipesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare this as read-only and non-destructive. The description adds useful behavioral context: it works 'Offline' and lists 'built-in' recipes, implying a static, pre-populated set. It does not contradict annotations and adds extra value beyond the structured safety hints.

  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 main purpose and key output fields. Every word is useful; no redundancy or filler. It efficiently communicates scope, content, and the related apply_recipe action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 no output schema, the description is complete. It states the source (built-in library), the fields returned, the offline nature, and the next step. It does not need to explain return structure further since it lists the exact output fields.

  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 fully documents the optional 'tag' parameter with a clear description ('matches tags or name'), giving 100% schema coverage. The tool description itself doesn't mention the filter, but this is acceptable since the schema carries the semantic weight; the description adds no extra parameter context.

  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 ('List'), the resource ('built-in recipe library'), and the output contents ('id, name, tags and difficulty'). It also distinguishes from siblings by emphasizing 'built-in' and explicitly names the follow-up tool 'apply_recipe', making the tool's role 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?

  The description implies when to use the tool ('Offline', to browse ready-made templates) and points to the next action ('Apply one with apply_recipe'). It provides clear context but doesn't explicitly discuss alternatives or exclusion cases, though the word 'built-in' differentiates it from library-management siblings like browse_library.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_componentA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint, destructiveHint), the description discloses critical behavioral details: save uses a deferred, verified same-directory temporary export, refuses overwrite by default, and supports an 'ask' policy for native consent. It also explains the load legacy behavior and notes that paths are on the machine running TouchDesigner. This goes far beyond the basic annotations and provides agent-critical safety and execution context.

  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 three sentences long and front-loaded with the core purpose. Each sentence adds essential information: the overall function, save-specific safety and overwrite behavior, and load/path notes. No redundant or filler content exists, making it efficient and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 11 parameters, complete schema coverage, and presence of annotations, the description sufficiently covers the tool's complexity. It explains the key behavioral nuances (deferred save, overwrite policy, legacy load, path location) without needing to reiterate parameter details already in the schema. The absence of an output schema is acceptable as the primary return value is implied (the file operation), and the description delivers a complete operational picture.

  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 already provides 100% description coverage for all parameters, with detailed comments for each. The description itself adds only a small amount of parameter-related context, such as the behavior of overwrite_policy and the relationship between file_path and parent_path. This aligns with the baseline score of 3 for high schema coverage, as the description does not substantially add semantic value beyond the structured data.

  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 purpose as moving COMPs to/from .tox files on disk to build a reusable component library, which is a specific verb+resource combination. It also distinguishes between the 'save' and 'load' actions. However, it does not explicitly mention or differentiate from sibling tools like manage_component_storage or make_portable_tox, so it misses the full sibling differentiation criterion.

  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 on when to use the tool: for building a component library by moving COMPs to/from .tox files. It also gives detailed behavior for each action (save/load) and mentions the overwrite policy context, which helps the agent decide. It does not explicitly list alternatives or when-not-to-use cases, but the context is unambiguous and free of exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• plan_td_version_migrationA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only' and 'without touching TouchDesigner', adding context that it operates purely offline. It also discloses return content (upgrade boundaries, deltas, checklist) beyond what annotations convey.

  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 key safety property (read-only) and the main action. Every phrase adds value, and there is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the presence of an output schema and full parameter descriptions, the description fully covers the tool's purpose, scope, and safety profile. It even names the three types of returned information, which, combined with the output schema, makes the tool's behavior clear for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with each parameter having its own description, so the description does not need to explain parameter syntax. It adds no extra parameter-level meaning beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'plan' with a clear resource (TouchDesigner stable-version migration), and distinguishes itself from siblings by focusing on planning migration using offline release highlights and compatibility records. It states the outcome (upgrade boundaries, compatibility deltas, operator checklist) unambiguously.

  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 gives clear context: it is for planning a TouchDesigner version migration and is read-only, implying use before an actual migration. However, it does not explicitly name alternative tools or exclude other use cases, so it stops short of a full when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• score_buildA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds beyond that: 'Composes existing bridge endpoints — creates nothing' and mentions optional LLM critique behavior when configured. It also states deterministic suggestions, all consistent with annotations, with no contradiction.

  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 three sentences with no filler. It front-loads the core purpose, then adds efficient behavioral notes. Every sentence contributes value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With full schema descriptions, rich annotations, and an output schema present, the description covers purpose, safety, and key behaviors. It does not need to explain return values because an output schema exists. It is sufficiently complete for a read-only scoring 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 100%, so the baseline of 3 applies. The description adds some context (e.g., the fixed rubric and LLM critique condition), but it does not elaborate on individual parameters such as scopePath or targetFps, which are already well-documented 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 clearly states a specific verb and resource: 'score a built network 0–100 on a fixed rubric (palette/motion/complexity/errors/perf)' and lists the outputs ('per-criterion sub-scores plus deterministic improvement suggestions'). This distinguishes it from sibling tools that mutate or optimize, emphasizing a read-only assessment role.

  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 context is clear: this is for read-only scoring of a built network, which implies assessment use cases. However, it does not explicitly name alternatives or state when not to use it (e.g., vs get_td_performance or optimize_performance). The 'creates nothing' note gives implicit exclusions but not explicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_touchdesigner_knowledgeA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description confirms read-only behavior (matching readOnlyHint=true) and adds value beyond annotations by disclosing the return structure: normalized results with resource URIs and tool hints for deeper lookups. This gives the agent useful expectations about output and next steps without contradicting 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 two sentences: the first leads with 'Read-only' and states the broad scope, the second explains the return format and follow-up tool hints. Every word earns its place, with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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, a fully documented schema, and the presence of an output schema, the description sufficiently covers scope and return behavior. It does not need to explain the output schema's details, and the tool hints reference deeper lookups without overexplaining.

  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 provides 100% parameter description coverage, including the surface enum and descriptions for query and limit. The description's list of knowledge surfaces essentially repeats the surface enum values, adding no new semantic meaning beyond what the schema already documents. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('search') and resource ('embedded TouchDesigner knowledge router'), and enumerates the knowledge surfaces covered (operators, workflows, examples, versions, compatibility, techniques, classes, experimentals). This distinguishes it from sibling tools like search_operators by being a broad cross-domain search rather than a domain-specific one.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you need to search across multiple TouchDesigner knowledge surfaces simultaneously. It lists the covered domains, giving clear context, but does not explicitly contrast with alternatives such as search_operators or search_python_api, nor does it state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• swap_operatorA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the destructiveHint annotation by detailing the internal procedure: snapshots wires+params, deletes old node, creates new node, re-applies params, rewires connectors. It also discloses fail-forward behavior and return fields, providing a rich behavioral model not covered by 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 dense but well-structured: core action, procedure, failure handling, and return value are each given a sentence. Every sentence contributes essential information for a complex destructive operation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is complex and has no output schema, but the description explains the full lifecycle and return structure including failed_inputs/outputs and warnings. This is sufficient for an agent to understand what will happen and interpret results.

  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?

  All 3 parameters have schema descriptions (100% coverage), so the baseline is 3. The description reinforces preserve_parameters behavior but adds no new syntactic details beyond the schema; it mentions parameter preservation and dropped_parameters in the return context.

  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 a specific verb+resource: 'Change an operator's TYPE while preserving its name, position, incoming + outgoing wires, and any parameters that exist on the new type.' This clearly distinguishes it from sibling create/delete/update tools by emphasizing in-place type swap with preservation.

  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 use case—when you need to change an operator's type without losing connections—but does not explicitly name alternatives or state when not to use it. It lacks comparative guidance like 'use this instead of delete+create'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apply_lutA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare non-read-only, open-world, non-destructive. Description adds rich behavior: creates a self-contained baseCOMP, prefers OCIO, falls back to Movie File In + Lookup TOP, parses .cube in Python, exposes Strength/Bypass controls, and handles missing source_path with a grey Constant TOP. This goes well beyond the annotations without contradiction.

  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 dense but well-structured: main action first, then format preferences, fallback, controls, and usage variants. Slightly long, but every sentence adds useful information; not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 9 params and no output schema, the description covers the key workflow: input formats, branch selection, fallback logic, source handling, and exposed controls. It gives an agent enough context to decide and invoke correctly.

  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 covers 100% of parameters with detailed descriptions, so the description doesn't need to add parameter semantics. It does mention source_path and Strength/Bypass, but these already appear in the schema. No significant added meaning.

  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 a specific verb+resource: 'Apply a colour Look-Up Table (LUT) to an existing TOP inside a self-contained baseCOMP.' It clearly distinguishes from siblings like create_color_grade by targeting LUT application with specific file-format handling.

  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 clear context: applies LUT to an existing TOP, with fallback behavior for OCIO vs image LUTs. However, it doesn't explicitly name alternative tools or state when not to use it, so not a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• audio_fingerprint_to_visualA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description reveals important behavioral traits beyond annotations: it samples audio (potential latency), uses a deterministic heuristic, can hang on macOS if 'device' is used (mitigated by default), and supports dry_run to avoid building. It also explains the composite behavior of apply_top_op. These details exceed the sparse readOnlyHint/destructiveHint annotations.

  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 three sentences and effectively packs the entire workflow, key defaults, and important caveats. The first sentence is long but densely informative; while it could be split for readability, it contains no fluff. It earns a 4 for appropriate brevity despite the complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 9-parameter orchestrator with no output schema, the description gives a complete high-level story: sample audio → analyze → map → dispatch. It also clarifies the most critical behaviors (dry_run, apply_top_op, default audio_source). Schema covers the remaining parameter details, so the combination is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The tool description adds minimal parameter semantics beyond what's already in the schema; it mentions audio_source default, dry_run, and apply_top_op, but the schema already documents all parameters with similar or greater detail. No significant new meaning is added.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verbs and a clear workflow: samples audio, computes a 4-feature fingerprint, runs deterministic heuristic mapping, and dispatches a generator. It explicitly lists the candidate generators, distinguishing it from siblings like create_glitch or create_audio_reactive by being an automatic dispatcher.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies its primary use case: automatically select a generator based on audio fingerprint. It gives practical context (default synthetic source to avoid mic-permission hangs, dry_run for testing, apply_top_op for compositing) but doesn't explicitly state exclusions vs alternatives. The list of possible generators hints at when it's appropriate, though it stops short of saying 'use this instead of manual selection.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• build_pop_chainA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description reveals that unknown parameter names are tolerated with warnings (fail-forward), that results carry an 'unverified' experimental marker, and that nodes are wired under a specified `parent`. These are useful behavioral details not encoded in 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 roughly 100 words, front-loaded with the core purpose, and every sentence earns its place: structure, defaults, multi-input handling, experimental status, and a practical tip. There is no redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 77 POP types and multi-input wiring, the description covers the essential behavioral model, wiring semantics, failure mode (warnings), and result marker. It does not describe the return value structure or re-run/overwrite behavior, but the annotations and schema mitigate those gaps. Overall it is a solid, near-complete description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3, but the description adds meaning by stating that per-kind safe defaults are applied before user params and that unknown names become warnings. This goes beyond the schema's generic 'Par overlay' explanation and helps the agent understand how to handle arbitrary params.

  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 a specific verb+resource: 'Declarative Layer-2 builder for an ordered POP (Point OPerator) chain.' It clearly distinguishes itself from sibling tools like build_chop_chain by explicitly targeting POPs, and the chain-building mechanism is precisely described.

  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?

  It provides concrete usage instructions: pass a `chain` list, each entry wired output 0 → input 0 of the next, with `extra_inputs` for multi-input POPs, and a tip to end with `null_pop`. However, it does not explicitly contrast with alternative tools or state when not to use it, so it lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• build_sop_geometryA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read-only, non-destructive operation. The description adds valuable behavioral disclosure: per-op failures become warnings (fail-forward), partial chains still return useful info, and wiring occurs under a configurable parent. It does not detail what the returned 'useful info' contains, but this is a minor gap given the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, a concise explanation of the wiring pattern, a note on failure behavior, a useful tip, and an explicit alternative. Every sentence adds value without redundancy or fluff.

  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 schema covers all parameters and the description explains the wiring, failure handling, and best-practice tip, the tool is well contextualized. The only notable omission is a precise description of the return value (especially since there is no output schema), though 'returns useful info' partially addresses this.

  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% parameter description coverage, so the description does not need to explain each parameter in depth. It reinforces that `ops` contains type/name/params and mentions the parent default, but adds little beyond the schema. The special string-resolution behavior for params is already documented 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 clearly identifies the tool as a 'Declarative Layer-2 builder for an ordered SOP geometry chain' with a specific verb ('builds') and resource ('SOP geometry chain'). It explains the linear wiring model (op[i] output 0 → op[i+1] input 0) and explicitly contrasts with `connect_nodes` for multi-input fan-in, distinguishing it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states when to use this tool (for ordered, linear SOP chains) and explicitly directs users to `connect_nodes` for multi-input scenarios, serving as a clear when-not/alternative. The tip about ending with `nullSOP` for stable handoff adds practical usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• collect_project_assetsA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes well beyond annotations by clarifying that the scan is read-only but writing out_manifest may overwrite an existing file, which explains the readOnlyHint=false and destructiveHint=true annotations. Also discloses that file-par detection heuristics are UNVERIFIED across TD builds and that style_supported records reliability. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The first sentence front-loads the core purpose, and the rest provides necessary safety and reliability caveats. Longer than average but every sentence carries information essential for correct invocation and expectation-setting. Could be tightened slightly but not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 and the existence of an output schema, the description covers purpose, safety, parameter behavior, and reliability of heuristics. It fully explains what will be reported and the side effects, making it complete for an agent to select and 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?

  Schema already covers all three parameters with descriptions (100% coverage), baseline is 3. Description adds meaningful context by warning that out_manifest may overwrite and by explaining the heuristic fallback behavior related to par.style, which enriches understanding of parent_path and output behavior.

  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?

  Clearly states a specific action: scan a COMP subtree for external file dependencies and report each referenced file, the referencing node+parameter, and file existence. Distinguishes from siblings like make_portable_tox or bundle_dependencies by emphasizing it only reports and does not copy/rewrite the network.

  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?

  Implies usage by describing the read-only scan and optional manifest write, and hints at a contrast with tools that copy dependencies, but does not explicitly state when to use this tool over alternatives or provide exclusions. The guidance is context, not direct instruction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• connect_nodesA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read-only, non-destructive operation. The description adds valuable behavioral context by disclosing the fallback mechanism ('Uses the bridge's batch endpoint when available and falls back to a Python connect otherwise') and what is returned, without contradicting 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?

  Three sentences, front-loaded with the core action, followed by fallback behavior, alternative usage, and return info. Every sentence earns its place with no redundancy.

  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?

  Covers the operation, fallback behavior, return values, and an explicit alternative. With full parameter schema coverage and annotations, this is sufficient for a simple 4-parameter tool, though it could mention edge cases like occupied connectors but that is not essential.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already described. The description does not add extra parameter semantics beyond the schema, though it does mention connector indices in the return context, which slightly reinforces their purpose. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action: 'Wire one node's output connector into another node's input connector inside TouchDesigner, creating a single link between two existing nodes.' It names the verb, resource, and scope, and distinguishes from siblings like create_node_chain and disconnect_nodes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says when to use an alternative: 'Use create_node_chain instead when you are creating several new nodes and want them auto-wired in sequence.' Also implies it's for connecting existing nodes, giving clear context and an exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_ascii_renderA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, and the description adds meaningful detail by specifying that it creates a new baseCOMP containing resolutionTOP, textTOP, glslTOP, and nullTOP, plus exposed controls. This goes beyond the structured annotations while remaining consistent with them.

  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 three sentences, front-loaded with the core purpose, and each sentence contributes unique information: algorithm, modes/aesthetic, and output structure/controls. No redundant or filler content.

  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 (11 params, no output schema), the description offers a solid overview: what it does, how it works, what it creates, and key controls. The schema covers all parameters with descriptions. It doesn't mention limitations or prerequisites, but the source-optional fallback is captured in the schema, so the description is sufficiently complete for selection and 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?

  With 100% schema coverage, the baseline is 3. The description enhances parameter understanding by explaining the luminance quantization grid (connecting resolution and cell_size), the color modes (aligning with color_mode), and the glyph atlas (relating to charset/font). This adds conceptual clarity beyond the schema descriptions.

  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 ('Turn any TOP') and resource ('into a character-grid ASCII render'), clearly distinguishing it from other create_* siblings like create_halftone. It also details the algorithmic process and outputs, leaving no ambiguity about the tool's function.

  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 the tool: whenever an ASCII/character-grid render of a TOP is needed. It provides context about supported modes and default aesthetic, but does not explicitly name alternatives or exclusion criteria, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_body_bubblesA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the minimal annotations (readOnly=false, openWorld=true, destructive=false), the description discloses specific behavioral traits: it 'Builds a self-contained Base COMP with a Script CHOP physics solver, Script SOP bubble outlines...' and details runtime behaviors like 'bubbles stay inside the screen box, settle on the lower floor, and pop/fade after a configurable lifetime.' It also notes default configurations and dependency on tracking CHOPs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but information-dense, front-loading the main purpose, then behavioral details, technical internals, and dependencies in a logical order. Each sentence contributes valuable context. It could be slightly trimmed, but the complexity justifies the length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 27 parameters, no output schema, and the complexity of the generated network, the description is thorough: it explains what is built (Base COMP with specific components), the required setup inputs, default behaviors, and the visual output. It provides enough context for an agent to invoke it correctly without needing an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 100% description coverage for all 27 parameters, so the description is not required to explain each one. It adds only a high-level grouping ('live controls for emission rate, gravity, drag, buoyancy...') and mentions the default lifetime, which provides context but no significant new syntax or format details 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 opens with a specific verb+resource: 'Create a MediaPipe-ready interactive bubble installation over the live camera.' It further details the unique interaction (open palm emits bubbles, landmarks act as colliders, body contour rendered), clearly distinguishing it from sibling creation tools like create_body_reactive or create_particle_system.

  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 gives clear context by stating dependencies: 'Provide hand_chop_path from setup_hand_tracking and body_chop_path from setup_body_tracking/create_pose_tracking for full interaction.' It also explains the default behavior (low bubble count, no pose-wrist emission), which helps decide when to use it. However, it does not explicitly compare to alternatives or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_chop_recorderA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses important behaviors: re-entrant updates without rebuilding, persistence of the last take in comp.store, disk storage for large takes, and the timeline-paused playback returning 0. These are valuable details not present in the structured metadata, and there is no contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is five sentences and technically dense, but every sentence provides necessary detail: the operational pipeline, re-entrancy, persistence, disk offloading, and timeline behavior. It is appropriately sized for a tool of this complexity, though slightly long for a succinct overview.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of the tool (building a multi-node network) and the absence of an output schema, the description is remarkably complete. It covers the internal architecture, the binding endpoint (Null CHOP), persistence, scale limits, and an expected edge-case behavior, which is sufficient for an agent to understand the full scope.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the parameters are already well-documented. The description adds contextual information about the recording flow (e.g., 'fixed window', 'on Stop') and persistence behavior, which briefly relates to takeName and lengthSeconds, but it does not add significant meaning beyond the schema's own descriptions.

  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 builds a CHOP recorder/player container with a specific technical pipeline (Trail CHOP → Table DAT → Datto CHOP → Null CHOP). It distinguishes itself from sibling tools like create_capture_loop by specifying the exact mechanism and the intended use for capturing and playing back CHOP channels.

  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 makes the tool's purpose evident: to record a source CHOP's channels over a fixed window and play it back. It mentions being ready for bind_to_channel, indicating a downstream use case, but it does not explicitly state when not to use this tool or compare it to alternatives like build_chop_chain. Context is clear, but exclusions are absent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_engine_compA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses several non-obvious behaviors beyond annotations: sub-process spin-up forks a TD process, first cook may take multiple seconds on slow disks and is not a hang, and par names (reload/usecolormap/performmode) are guarded with hasattr so unverified names degrade to warnings. This is rich contextual information that annotations (readOnlyHint, openWorldHint, destructiveHint) do not provide.

  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 dense and structured, front-loading the core purpose before adding usage context, a note about output connectors, a sibling comparison, and a performance warning. It is somewhat longer than strictly necessary, but every sentence contributes meaningful information. The 'Note:' at the end is a valuable caveat that prevents false hang detection.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (external subprocess, Engine COMP behavior, guarded parameters) and the absence of an output schema, the description is remarkably complete. It explains side effects (separate TD process, crash domain), output behavior (outTOP/outCHOP/outSOP/outDAT connectors), a critical performance characteristic (first-cook latency), parameter safety, and its relationship to make_portable_tox. There are no major gaps.

  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 provides 100% description coverage for all six parameters, including defaults and enum details. The description adds some context about how parameters map to Engine COMP behavior (e.g., reload pulse, perform-mode override, color-map toggle) and notes the output connectors that result from tox_path, but these are largely redundant with existing schema descriptions. No additional syntax or format guidance 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 opens with a specific verb and resource: 'Drop a TouchDesigner Engine COMP that loads an external .tox in a separate TD subprocess.' It clearly defines the tool's scope (independent crash domain) and distinguishes it from siblings like make_portable_tox by focusing on runtime isolation and hosting heavy/unstable graphs.

  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 states when to use the tool: 'ideal for hosting heavy or unstable subgraphs.' It also names a complementary sibling (make_portable_tox), which helps orient the agent. However, it does not explicitly state when not to use it or name direct alternatives (e.g., simple COMP creation), so it stops short of full usage exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_facade_mappingA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false, so 'Build' is expected. The description adds valuable context beyond annotations: it creates a calibration skeleton, fans one source into N branches, and leaves alignment work for later—important behavioral expectations for the agent and user.

  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 sentences deliver a dense, front-loaded description with no filler. The first sentence explains the composition; the second sets expectations for what is left incomplete. Every phrase earns its place.

  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 tool with 13 parameters and no output schema, the description gives a solid high-level overview, names the main branches and operators, and clarifies the calibration-skeleton scope. It does not detail return values (not needed for a build tool) or explicitly list operator names, but it is sufficient for tool selection and 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 100%, so baseline is 3. The description adds meaning by mapping phrases like 'one source TOP' to source_top_path, 'N per-projector' to projector_count, and 'edge-blend Ramp/Composite' to blend_curve/blend_width. It frames these as initial values within a calibration skeleton, which the bare schema does not convey.

  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 the specific verb 'Build' and the resource 'multi-projector architectural facade rig', and enumerates concrete components (Crop, Corner Pin, Ramp/Composite, Level, Nulls, preview). This clearly distinguishes it from sibling create_* tools like create_projection_mapping or create_led_mapper.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool by stating it 'Ships as a calibration skeleton' and that 'per-projector corners, color match, and (when 3D) camera transforms are left to live install alignment.' This tells the agent the tool is for initial scaffolding, not final calibration, but does not explicitly name alternative tools or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_fluid_simA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses that it creates a new baseCOMP, builds a stack of GLSL TOPs, exposes controls, optionally binds a CHOP, and returns a JSON summary with errors and preview. It also notes resolution safety ('512 is safe on integrated GPUs'), adding 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 a single dense paragraph, but every sentence adds value. It front-loads the core purpose and algorithm, then lists features and return value. It is longer than average but proportionate to the tool's complexity, with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 11 parameters, no output schema, and the complexity of creating a networked simulation, the description is complete. It explains what is built, how it is built (algorithm, TOPs, feedback loops), how controls and audio binding work, and what the return value includes (paths, errors, warnings, preview). The absence of output schema is compensated by describing the JSON block contents.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are well-documented. The description adds meaning by grouping parameters into artist-facing controls and mentioning behavior like 'injection_mode='auto'', where an LFO drives the splat point, and the audio_path channel multiplier. This enriches understanding beyond the raw 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 the tool's purpose with a specific verb ('Build') and resource ('real-time 2D fluid/ink/dye simulation... as a stack of GLSL TOPs in feedback loops inside a new baseCOMP under parent_path'). It differentiates from siblings like create_particle_system or create_reaction_diffusion by naming the stable-fluids algorithm and specific output structure.

  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 gives strong context for when to use it: when a real-time 2D fluid simulation is needed, including artist-facing controls, optional audio reactivity, and auto mode for no input. It does not explicitly name alternative tools or exclusions, but the use case is clearly scoped so an agent can infer appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_generative_audioA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses extensive behavioral traits beyond annotations: it creates a new baseCOMP, playback is opt-in to avoid audio hardware prompts, the signal is silent when the timeline is paused, and it returns a structured JSON with warnings. This far exceeds the bare readOnly/destructive/openWorld hints.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long (~250 words) but well-structured, front-loading the core verb and method. Each sentence adds useful context: synthesis types, playback opt-in, timeline dependency, return structure, and warnings. Minimal redundancy, though it could be slightly tightened.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description enumerates the exact fields returned in the JSON block (container path, node paths, null path, settings, device-out, errors, warnings). It also covers creation, downstream usage, and safety behavior, making it 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.

  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 all 9 parameters, so the description's parameter-level detail is minimal. It does explain the overall chain structure (e.g., Null CHOP, Audio Device Out) but adds little beyond the schema. With full schema coverage, baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it 'SYNTHESIZE audio — generate sound rather than react to it' and details the three synthesis methods. It distinguishes from reactive/analysis tools by emphasizing generation and noting the output feeds create_spectrum/create_waveform, making the purpose specific and distinct from siblings.

  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?

  It explains when to use the tool (to generate sound) and mentions that the output can feed visualization tools like create_spectrum/create_waveform, implying alternatives. It also warns about timeline dependency and opt-in playback. However, it does not explicitly name sibling tools for when not to use it or list exclusion scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_glitchA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Even with annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description adds substantial behavioral context: it creates a new baseCOMP, details the internal node structure, explains the Select TOP usage due to wire-crossing constraints, clarifies no device permissions in the self-contained mode, and lists the return value (summary, JSON block, paths, knobs, errors, preview). This goes well 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is moderately long but every sentence earns its place, covering the visual effect, node construction, input modes, exposed controls, and return format. It is front-loaded with the core purpose. A bulleted list could improve scannability, but the current prose structure is acceptable and not bloated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (8 params, no output schema), the description is exceptionally complete. It explains what nodes are created, how the input is handled, what knobs are exposed, the return payload (including error handling), and the self-contained source behavior. There is no significant missing context for an agent to select and invoke this tool correctly.

  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% parameter coverage with rich descriptions for each of the 8 parameters (e.g., amount, speed, block_size). The description adds minimal extra semantic value beyond re-mentioning exposed knobs and audio-binding advice, but this is not necessary given the schema's thoroughness. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Build') and clearly defines the resource: a glitch/corrupted-signal visual with RGB channel split, blocky displacement, and band tearing. It lists the exact node chain (noise driver, Displace TOP, GLSL RGB-shift pass, Null), distinguishing it from sibling create_* tools like create_datamosh or create_kaleidoscope. The phrase 'signature live VJ look' further clarifies its niche.

  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 two usage modes: with input_path it glitches an existing TOP, and without it uses a self-contained noise source requiring no device permissions. It also advises binding the Amount knob to audio/beat. However, it does not explicitly contrast with alternative tools or state when NOT to use this tool, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_gpu_particle_fieldA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds valuable behavioral context: the created baseCOMP structure, the optional device-permission dialog for audio/motion reactivity, the scaling limits (512²≈262k), and the return JSON with created paths, errors, warnings, and preview. No contradiction with annotations, though it could mention side effects on existing nodes under parent_path or cooking behavior.

  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 dense but well-structured: it front-loads the core purpose, then covers architecture, scalability, sibling alternatives, reactivity, and return format. Each sentence adds distinct value, though the length is above average. It earns its place given the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex creation tool with no output schema, the description is comprehensive. It details what is created (baseCOMP with specific components), where (under parent_path), performance envelope (side², up to 512²), optional device-permission side effects, and the exact return payload (container path, created nodes, count, output, knobs, errors, warnings, preview). This fully equips the agent to select and invoke the tool correctly.

  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% parameter coverage with detailed descriptions, defaults, ranges, and enums, so the baseline is 3. The description supplements with context about how parameters map to runtime behavior (e.g., reactivity bound to uReact uniform, PointSize/Zoom knobs) but does not need to compensate for missing schema info. It adds marginal value 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 a specific verb and resource: 'Build a high-count GPU particle / point field' and details the architecture (GPU feedback-TOP loops, instanced Geometry COMP). It explicitly distinguishes itself from siblings like create_particle_system (CPU, simpler), create_particle_flock (boids), image_to_particles (image spring), and create_pop_particle_system (native POP). This is a model of 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit when-to-use guidance: for high-count GPU drift fields beyond CPU capabilities, with a direct recommendation to use create_particle_system for simpler low-count emitters. It also names sibling tools for alternative motion behaviors and explains the audio/motion reactivity options. This is explicit guidance with exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_hand_gesture_busA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false and openWorldHint=true. The description adds behavior beyond that: it 'creates helper nodes under parent_path, returns the component/output paths and created-node report', exposes specific debounced channels, and can build/use setup_hand_tracking. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each earning its place: purpose, outputs/behavior, and source guidance. Front-loaded with the core action and use cases. No repetition of schema content.

  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 20 params and no output schema, the description covers what is created, what is returned (paths and created-node report), and names the output channels. It does not detail the report structure or error behaviors, but schema covers parameters and annotations cover side effects, making it sufficiently complete for a complex 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 coverage is 100%, so baseline is 3. The description adds cross-parameter meaning by linking source='existing_chop' with hand_chop_path and noting nodes are created under parent_path. This supplements the individual parameter descriptions.

  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 and resource: 'Create a TouchDesigner Base COMP that converts hand landmarks into a stable gesture-control Null CHOP' and names concrete use cases (palm holograms, lasers, audio controls). It distinguishes from siblings by detailing output channels and source modes, making it clear this is the hand-gesture-bus creator.

  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 explicit guidance for each source value: 'Use source='synthetic' for camera-free previews, source='mediapipe' to build/use setup_hand_tracking, or source='existing_chop' with hand_chop_path when a hand landmark CHOP already exists.' This is clear when-to-use context, but it does not name sibling alternatives (e.g., create_leap_motion_hand_bus), so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_jfa_voronoiA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate non-read-only and non-destructive; the description adds meaningful behavioral detail: the exact node chain, self-contained nature, auto-derived pass count with override, and exposure of live controls. It doesn't dwell on side-effect specifics like exact container creation, but it conveys the main behavioral traits beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, zero wasted words. The first sentence front-loads purpose and architecture, the second covers the exposed controls and preview, and the third clarifies a key algorithmic behavior. Every sentence earns its place.

  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 create-oriented tool with 13 params and no output schema, the description gives a solid mental model: the GLSL TOP chain, live controls, preview behavior, and pass-count logic. It could mention the container path explicitly, but the parent_path schema covers that; overall it is sufficiently complete for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by grouping the exposed live controls (PaletteMode/SeedCount/Speed/Jitter/EdgeThickness/EdgeColor/ColorA/ColorB) and by explaining how resolution auto-derives the pass count with step_count as an override, which is extra semantic context 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 opens with a specific verb ('Instantiate') and names a distinct resource (a self-contained JFA Voronoi generator as GLSL TOPs). It differentiates itself from generic shader/TOP creator siblings by describing the concrete chain and output, so an agent can confidently identify what this tool creates.

  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 gives clear context: it creates a stained-glass/cell pattern generator with live controls and previews, implying use when such a Voronoi effect is needed. It doesn't explicitly mention when not to use it or name alternatives among the many sibling tools, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_kinect_wall_harpA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate openWorldHint=true and destructiveHint=false, but the description adds valuable behavioral context: it creates a FreenectTOP only when explicitly enabled, returns warnings instead of throwing when hardware is missing, and exposes diagnostics. It does not mention deactivation of existing Freenect nodes, but that is covered in schema parameter descriptions; no contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, each carrying substantial information: purpose, network modes, system behavior, and error handling. It is front-loaded with the primary action and resource, with no wasted words. For a tool with 47 parameters, this is appropriately 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?

  Given the complexity (47 params, no output schema), the description summarizes the system well, covering modes, fallback, and diagnostics. However, it does not explicitly state the return value or output format (e.g., the created Base COMP path), which could be inferred but is not spelled out. Minor gap for an otherwise complete description.

  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 91%, so the baseline is 3. The description adds contextual meaning by explaining how parameters work together (e.g., dividing projection into musical zones, rendering a vibrating curtain, exposing diagnostics), which helps an agent understand the role of params like string_count, visual_line_count, and show_debug beyond their individual schema descriptions.

  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 builds a Kinect v2/FreenectTD projected wall harp in an isolated Base COMP, a specific and concrete deliverable. It lists distinct operating modes (Freenect, OSC bridge, synthetic) and describes the system's function (hand tracking, zones, plucks, visuals), distinguishing it from sibling tools like create_hand_gesture_bus or setup_hand_tracking.

  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 the tool, such as building a wall harp, and explains the three source modes and the synthetic fallback when hardware is unavailable. It does not explicitly name alternative tools or state when not to use it, but the purpose is specific enough to imply usage without needing exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_optical_flowA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnly=false, openWorld=true, destructive=false), the description discloses detailed behavior: output is a single-channel TOP with bright=motion, mid-grey=still, the exact formula `gain × (current − previous luminance) + 0.5`, and the Sobel edge interaction in 'edges' mode. It also clarifies edge-case behavior (reads 0 when paused/static) and the return payload (summary + JSON with node paths, controls, warnings, inline preview).

  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 dense but not bloated; every sentence provides useful information, from the algorithm and implementation details to behavior under specific conditions. It is front-loaded with the core purpose, then expands into output format, internals, and fallback behavior. Slightly long but justified by the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 8 parameters and no output schema, the description fills important gaps: it explains the output format (single-channel TOP, nullTOP), the return value (summary plus JSON with nodes/controls/warnings/preview), performance characteristics (CPU, no CUDA), and the default test clip to avoid permission prompts. It also addresses a potential gotcha (reads 0 when paused) which users would otherwise misinterpret.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents each parameter thoroughly. The description adds algorithmic context (e.g., frame differencing, gain, blur purpose) but doesn't materially extend parameter-level semantics beyond what the schema descriptions already provide. The description mostly reinforces schema details such as the default test clip and direction_from modes.

  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: 'Build a CPU motion-energy field from a video source', and further differentiates it as a 'cheap drop-in for displacement / particle chains' and explicitly NOT a real dense optical-flow solver. This clearly distinguishes it from sibling tools like create_displacement_warp or create_motion_reactive.

  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 on when to use this tool: as a lightweight, CPU-only alternative to real optical flow, and notes the trade-offs of the 'edges' mode. It also explains the default Mosaic.mp4 clip avoids permission prompts, which guides usage in headless or non-interactive contexts. It doesn't name a specific sibling alternative but gives clear when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_phone_remoteA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that the server listens on all interfaces and accepts unauthenticated writes, which adds security context beyond the annotations. It also describes the live touch-slider interaction, showing behavior not captured by readOnlyHint openWorldHint.

  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, starting with the main purpose, then behavior, security, and related tools. No redundant phrases or fluff; every sentence contributes.

  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?

  The description covers the tool's function, security, and workflow pairing. It does not explicitly mention the return value (e.g., a URL), but given the tool's simple nature and lack of output schema, the gap is minor; overall the context is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers both parameters with descriptions (port and comp_path) at 100% coverage, so the baseline is 3. The description does not add additional parameter-specific semantics beyond what the schema already states.

  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 'Serve' and a resource 'Web Server DAT' plus the goal of controlling a COMP's numeric parameters from a phone. It distinguishes itself from siblings by mentioning 'no app to install' and pairing with create_control_panel.

  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 states when to use it ('control a COMP's numeric custom parameters from a phone') and includes a security constraint ('use it only on a trusted network'). It also suggests companion tools (create_control_panel, manage_cue), but does not explicitly name alternative tools for exclusion, so not a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pixel_sortA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral details beyond annotations: it discloses the multi-pass odd-even transposition sort over a glslTOP feedback chain, the live-tweakable parameters, and the default noiseTOP source. This gives the agent insight into the internal mechanics and side effects (creating a component) without contradicting the readOnlyHint=false and destructiveHint=false 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 three sentences long, front-loaded with the core purpose, then implementation details, parameter exposure, and default behavior. Every sentence earns its place with no redundancy or fluff, making it perfectly 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 10-parameter tool with no output schema, the description covers the main aspects: what it does, how it works, key parameters, and default source. It lacks an explicit statement about the return value (the created baseCOMP), but the schema's 'name' parameter implies it. 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 input schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by identifying which parameters are live-tweakable (Mix, Threshold, Iterations, Direction). However, it also mentions 'Reset' which does not appear in the schema, creating a minor inconsistency that could confuse the agent.

  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 'Build a glitch-art pixel-sort effect', using a specific verb and resource. It clearly distinguishes itself from sibling tools like create_glitch by naming the pixel-sort algorithm and the signature Asendorf aesthetic, so the agent knows exactly what this tool produces.

  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 on when to use the tool: for glitch-art pixel sorting. It explains the fallback behavior when no input TOP is provided, implying the tool is self-sufficient. However, it does not explicitly exclude alternatives like create_glitch or create_datamosh, missing a 'use this instead of X' statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pointer_reactiveA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description fully discloses side effects beyond the annotations: it 'Creates a new baseCOMP under parent_path', builds a demo by default, and reports node errors and warnings. It also states the return format ('a summary plus a JSON block with the container path, created node paths...'). This goes well beyond the basic readOnly/destructive hints and describes exactly what the agent can expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence carries meaningful info: purpose, node structure, channel names, demo behavior, multitouch limitation, creation path, and return value. It front-loads the core purpose and organizes details logically. A slight structural improvement would be splitting into paragraphs, but it's dense and not wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and 5 parameters, the description is remarkably complete: it explains what is built, how to access channels (including exact paths), the demo variant, the multitouch caveat, and the return value (summary + JSON with paths, channels, controls, errors, warnings). This covers all the information an agent needs to invoke and understand the result, and even includes edge-case warnings.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter (demo, multitouch, resolution, parent_path, sensitivity) has a clear description with defaults. The tool description adds only marginal references (e.g., 'Sensitivity knob gains every channel'), which is already in the schema. With full schema coverage, a baseline of 3 is appropriate; the description doesn't need to compensate.

  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 a clear, specific verb+resource statement ('Turn mouse/pointer position and click into a first-class creative seed') and then details exactly what is built: a Mouse In CHOP → normalized u/v + velocity + button on a 'pointer' Null CHOP. This distinguishes it from sibling tools like create_motion_reactive or create_audio_reactive by focusing on pointer input.

  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 makes clear when to use the tool (for pointer/mouse reactive builds) and gives practical guidance on the demo flag ('set demo=false to build only the CHOP chain'). It also notes the multitouch limitation and that the build always uses Mouse In, effectively telling the agent that this tool is for single-pointer/mouse scenarios. However, it does not explicitly name alternatives or say 'use this instead of X', so it doesn't fully meet the 'when-not-to' bar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pop_fieldA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes beyond annotations by disclosing that POPs are Experimental, the render path is uncertain, the tool fails forward (failures become warnings), the output Null is always created, extra.unverified tracks POP types and render path, and returns detailed error/warning info. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but front-loaded with the main purpose and includes essential caveats and return info. Every sentence adds value, though the density may be high; no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description explicitly lists return contents including paths, controls, errors, warnings, unverified probe record, and preview image. It also covers creation behavior, experimental risks, and parameter effects, making it fully sufficient for invoking the 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 covers all 7 parameters with detailed descriptions (100% coverage). The description reinforces parameter meanings (e.g., pattern values) but adds no new semantic info beyond the schema, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Build a GPU point field using TouchDesigner's POP family' and details the generator, transform, render path, and Null TOP output, clearly distinguishing it from sibling tools like create_gpu_particle_field or create_pop_geometry.

  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 rich context about what the tool does (patterns, transform, render path, knobs) but does not explicitly state when to prefer it over alternatives or when not to use it. The experimental POP note implies caution but is not an explicit usage guideline.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_scene_timelineA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnly=false, openWorld=true, destructive=false. The description adds valuable context beyond those flags: it lists exposed custom pars (Play/Pause/Stop/Seek/Rate/Loop/Active_Scene) and the playhead Null CHOP outputs, explains setlist schema integration, and discloses the BPM 120 + 4 beats-per-bar conversion with no auto-rescale on tempo change. This provides meaningful behavioral expectations without repeating annotation data.

  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 paragraph that front-loads the core purpose ('Build a scrubbable show timeline'), then covers hierarchy, exposed outputs, setlist integration, and a key conversion limitation. Every sentence contributes essential context with no redundancy or filler.

  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 high complexity (show timeline with scenes, morphs, setlist integration) and lack of output schema, the description is quite complete: it discloses main behavior, sibling positioning, output pars/CHOP, and conversion behavior. It doesn't mention prerequisites like requiring `manage_cue` to store cues on target, though the schema references that dependency. Overall, the description covers the critical context needed for safe invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed descriptions for all 9 parameters, so the baseline is 3. The description adds integrated context (e.g., bars→seconds conversion, setlist mirroring into tdmcp_scenes) but doesn't substantially augment per-parameter semantics beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource ('Build a scrubbable show timeline') and immediately distinguishes itself from sibling tools ('Sits above create_cue_sequencer... and create_scheduler... as the show's master clock'). This clearly identifies what the tool does and sets it apart from related alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names sibling tools and places this tool in a hierarchy ('master clock'), indicating when it should be used instead of beat-quantized or event-firing sequencers. The phrase 'sits above' provides clear alternative guidance, though it doesn't include an explicit 'when not to use' statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_sdf_textA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnly=false and destructive=false; the description adds that it 'Creates a new baseCOMP under parent_path' (a non-destructive side effect), explains the mask-to-SDF approximation and smoothing easing, and lists exposed controls plus return JSON. This aligns with annotations while contributing meaningful implementation 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 dense but every sentence provides value. However, the opening sentence is overloaded with semicolon-separated implementation details and the overall structure could be tightened into clearer chunks.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 17-parameter generator with no output schema, the description covers the rendering pipeline, creation behavior, quality tradeoffs, exposed live controls, and return format ('summary plus a JSON block with node paths, exposed controls, node errors, warnings, and an inline preview image'). This is effectively complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so every parameter already has explanatory documentation. The tool description adds a little context by naming exposed controls and mentioning smoothing, but it does not materially improve on the schema's parameter semantics, so a baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Raymarch a text string as a signed-distance-field 3D slab.' It explicitly distinguishes itself from create_sdf_field and create_text_3d, making its unique output unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It names alternatives and differentiators: 'Distinct from create_sdf_field (primitive CSG only, no text) and create_text_3d (mesh-extruded text SOP) — this is the raymarched distance-field text look.' It also notes the approximate mask-to-SDF nature, helping the agent judge when this technique is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_shader_libA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a mutating, non-destructive operation, and the description adds behavioral context: it creates a GLSL TOP with live controls and self-contained built-in shaders. It doesn't contradict the annotations and provides useful operational detail beyond the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core action and scope. Every clause earns its place: the shader list, the GLSL TOP target, the live controls, and the differentiation from create_glsl_shader. No wasted 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 7 fully documented parameters, no output schema, and the tool's creation-oriented nature, the description adequately covers what the tool does and how it differs from a close sibling. It could mention potential side effects or broader alternative tools, but the core context is sufficiently 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 description coverage is 100%, so the parameter descriptions already carry full semantic weight. The main description references speed/scale/color controls and shader names, but does not add meaning beyond the schema's parameter-level descriptions. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Instantiate') and a concrete resource ('curated, ready-to-run full-screen GLSL shader') and names the exact shader options. It also explicitly distinguishes itself from create_glsl_shader, making its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description directly contrasts with create_glsl_shader ('unlike create_glsl_shader it ships robust built-in shaders rather than taking arbitrary code'), giving clear when-to-use guidance. The 'ready-to-run' and 'VJ eye-candy' phrasing further implies the intended usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_shader_parkA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate the tool is not read-only and not destructive. The description adds context that the tool creates a self-contained scene with live controls, clarifying the side effect of creating nodes. It does not explain details like overwriting behavior, but given the annotations, the disclosure is adequate.

  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 sentences, front-loaded with the primary action, and the second sentence provides a clear alternative. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 11 parameters and no output schema, the description covers the high-level purpose and primary alternative. It could mention the return value or how to access the created scene, but given the rich schema, it is sufficiently 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 has 100% coverage with detailed descriptions for all 11 parameters, so the description does not need to add parameter details. It provides general context about compiling code and instantiation, but no parameter-specific meaning 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 a specific action: compiling Shader Park JavaScript code and instantiating it as a self-contained TouchDesigner GLSL MAT scene. It distinguishes this tool from the companion shader-park:tox script and other shader tools by specifying the self-contained scene and live controls.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly notes to use the companion shader-park:tox script when the official plugin workflow is desired, providing a clear exclusion. The description implies this tool is for the alternative self-contained approach, giving context for when to choose it over the sibling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_stipple_pointcloudA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses behavioral specifics: output structure ('Outputs a Render TOP through a Geometry COMP in points render mode'), luminance-driven density ('Brighter regions yield denser clusters'), and mode-specific behaviors (random_jitter adds noisePOP for organic scatter). This provides meaningful context not present in the annotations, though it doesn't discuss potential side effects or return values.

  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 four sentences, each adding value: core purpose, density behavior, three modes, output type, and sibling differentiation. It is front-loaded with the main purpose and avoids redundant fluff.

  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 11 parameters, no output schema, and annotations providing only broad hints, the description adequately covers the tool's behavior, output, and place among siblings. It doesn't explicitly state the return value, but the creation context and parent_path/name parameters make it inferable. The description is complete enough for an agent to select and invoke the 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?

  The input schema has 100% description coverage for all 11 parameters, so the schema already documents each parameter's meaning and defaults. The description adds conceptual context (e.g., color modes, density weighting) but does not add per-parameter syntax or format details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

  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 a specific verb and resource: 'Density-weighted particle scatter rendered as discrete points — a stippled / halftone-engraving point cloud whose dot distribution follows the luminance of a source TOP.' It also names three visual modes and the output via Render TOP / Geometry COMP. It distinguishes from siblings by explicitly referencing create_pop_geometry, create_dither, and create_halftone.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear alternatives by identifying sibling tools and their differences: 'Sibling to create_pop_geometry (procedural SOP geo) and the rasterised create_dither / create_halftone tools (which stay in TOP space).' This tells the agent when this tool is appropriate: when a point cloud in geometry space with density-based stippling is needed, versus procedural SOP geometry or rasterized TOP effects.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_strobeA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already establish that this is not a read-only or destructive operation. The description adds meaningful behavioral detail beyond that: the exact node chain used to generate the effect, the behavior with and without input_path, and the limitation that the rate is free-running in v1. It does not contradict annotations, but could have mentioned side effects like container creation or failure modes, leaving room for a 4 rather than a 5.

  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 tightly written with no filler. The first sentence states the purpose, the next two explain the mechanics and input_path behavior, and the final sentence addresses the output and a known limitation. Every sentence earns its place, and the structure is logical and 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 creation tool with 7 parameters and no output schema, the description covers the essential behavior: what is built, how it is composited, the output type, and a current limitation. It does not describe error handling, idempotency, or what happens if input_path is invalid, but the full schema coverage and detailed node chain make it sufficiently complete 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?

  The input schema provides 100% parameter coverage with detailed descriptions, so the baseline is 3. The description adds value by explaining how parameters interrelate in the signal chain (e.g., Rate drives LFO frequency, Duty maps to Bias, intensity drives Level brightness) and clarifies the color default. This cross-parameter context goes beyond individual schema descriptions, warranting a 4.

  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 a specific verb ('Build') and resource ('beat-syncable strobe / flash layer'), immediately clarifying the intended effect. It goes beyond a generic statement by detailing the underlying mechanism (LFO CHOP, Level TOP, Constant TOP) and the output type (Null TOP), distinguishing it from sibling creation tools.

  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 explanation of how the strobe works and how to optionally composite it over a source provides clear context for when to use this tool. It also notes the current limitation (rate is free-running) and suggests a future approach for beat-syncing, effectively covering use cases. However, it does not explicitly name alternative tools or exclusion criteria, so it stops short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_synesthesia_unreal_oscA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate a non-read-only, non-destructive creation operation. The description adds valuable behavioral context beyond these flags: it explains the internal construction (Constant CHOP with named channels, wiring into oscoutCHOP), the channel naming convention ('<prefix>/<control>'), and the preset port mappings. This gives the agent a clear picture of what the tool does mechanically, without contradicting 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 compact yet information-dense, with no wasted words. Each sentence contributes: the core purpose, the preset details, the construction mechanism, the relationship to create_external_io, and a practical binding example. It is front-loaded with the main action and maintains focus throughout.

  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 create tool with no output schema and 8 parameters, the description covers the full workflow: what gets built, how addresses are formed, how to customize overrides, and how to bind audio/analysis. It could list the default control names, but that is a minor gap given the schema permits null defaults and the description indicates the presets fill them in.

  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 100% schema coverage, the baseline is 3. The description enriches parameter understanding by showing how preset, prefix, port, and controls interact: it details the preset-to-prefix/port mapping (synesthesia → /syn, 6448; unreal → /unreal, 8000), and explains how control names become OSC addresses and channel names. This holistic explanation goes beyond the individual schema descriptions.

  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 'Build a named OSC-out preset map for driving Synesthesia or Unreal Engine from TouchDesigner', which clearly identifies the tool's specific verb, resource, and target applications. It further distinguishes itself from siblings by explicitly positioning itself as 'the preset layer on top of create_external_io osc_out' and detailing the preset-specific behavior (prefixes, ports), making the purpose unmistakable.

  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 explicitly names create_external_io as the lower-level alternative and states this tool fills in the address templates and default control set, giving clear context for when this preset layer should be used. It lacks an explicit 'do not use when...' statement, but the positioning is strong enough to infer the appropriate usage boundary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_tempo_syncA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds significant behavioral context beyond annotations: it creates a beat-synced clock with specific output channels, and optionally broadcasts a beat event over WebSocket. This is consistent with annotations (openWorldHint=true, destructiveHint=false) and discloses side effects without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four concise sentences, each earning its place: creation, usage, optional event broadcast, and a pairing recommendation. It is front-loaded with the core purpose and avoids redundant wording.

  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?

  The description covers the tool's outputs, the WebSocket event, and how to use it, which is adequate for a creation tool with no required parameters and no output schema. It doesn't mention that a self-contained 'tempo_sync' container is created at parent_path, but that detail is in the schema. Given the tool's moderate complexity, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all four parameters are already well-documented. The description adds no new parameter-specific details; it mentions emit_events in passing but doesn't expand on parameter syntax or format. It only reinforces the general purpose of the created channels.

  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 creates a tempo clock driven by TouchDesigner's global tempo, exposing specific beat-synced channels (ramp, pulse, beat/bar counters, bpm). This distinct action and output set separates it from sibling tools like create_beat_grid_sequencer or create_audio_reactive.

  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 gives clear context: bind parameters to the exposed channels to lock visuals to the beat, and pair with extract_audio_features for musical reactivity. It doesn't explicitly state when not to use it or compare to alternatives, but the use case and pairing suggestion are clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_time_echoA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description richly discloses behavioral traits beyond annotations: it builds a container COMP, selects source by absolute path with no cross-container wire, probes live for time-machine operator, sets pars defensively, collects failures as warnings, and returns a Null TOP 'out'. This far exceeds the sparse annotation set and prepares the agent for fallbacks and unverified behavior.

  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 text is long but structured by mode, front-loading the core purpose and then detailing mode-specific behaviors and failure handling. Every sentence contributes necessary technical context, making it dense but appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with no output schema, the description covers the container build, all three modes, parameter roles, fallbacks, warning behavior, and the final Null TOP output. No critical gaps prevent an agent from understanding what the tool does and how to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how parameters interact, such as feedback opacity mapping, forced resolution for echo mode, and cache depth for slit_scan/time_displace, enriching the schema's already-detailed descriptions without redundancy.

  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 applies a per-pixel time effect to a source TOP, enumerating three specific modes: echo trails, slit-scan, and per-pixel time displacement. It distinguishes itself from sibling creation tools by specifying the exact effect family and its container-building behavior.

  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 opens with 'EXPERIMENTAL' and warns 'UNVERIFIED across TD builds; tune live,' implying cautious use but not offering explicit alternatives. It does not mention sibling tools like create_slit_scan for when this tool should be preferred, so usage guidance is implied rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_video_playerA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate mutation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds concrete behavioral detail by naming the created TOPs, the exposed controls, the Null output, and the return value (clip paths, Null path, playlist flag). It does not overclaim safety or omit major side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences, front-loaded with the core purpose, then covers input modes, alternatives, return values, and integration context. Each sentence contributes useful information; it is slightly long but appropriately dense rather than verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the medium complexity, the description covers what the tool builds, how to invoke it with different file inputs, what controls are exposed, what it returns, and how it fits into a VJ workflow. With no output schema, the explicit return description is valuable and makes the tool effectively self-contained for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the schema already explains files, parent_path, and expose_controls in detail. The description restates and slightly contextualizes the file modes ('Pass file paths, or none to get an empty player') but does not add new parameter-level semantics beyond what the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with a specific verb and resource: 'Build a movie/clip player inside a new video_player container' and explains the internal architecture (Movie File In TOP, Switch TOP, Clip selector, Null TOP). It clearly distinguishes this from create_video_synth, its most similar sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit guidance is given: 'Use create_video_synth instead when you want a procedurally generated image rather than playing a video file.' It also tells when to combine with create_layer_mixer or bind_to_channel for VJ clip playback, and explains the three file-count modes (0, 1, 2+).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_xy_padA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal a mutating build operation (readOnlyHint=false, openWorldHint=true, destructiveHint=false); the description adds non-obvious behavior: drag is read through a Panel CHOP, u/v channel names are probed at build time (varying by TD build) with warnings on mismatch, and z_target adds a slider. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two dense sentences front-load the core purpose, then add operational details (Perform mode, Panel CHOP, warning behavior, optional binding). Every clause earns its place with no filler or redundancy.

  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 an 11-parameter build tool with no output schema, the description covers invocation, optional Z axis, warning conditions, and post-build binding workflow, complemented by rich schema descriptions. An explicit example target string ('nodePath.parName') would help, but the schema already gives the format.

  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 baseline is 3; the description adds semantic relations beyond the schema—ranges remap normalized u/v values, z_target triggers a slider rather than a native axis, and empty x/y targets expose channels for later bind_to_channel. This enriches parameter understanding.

  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 a specific verb 'Build' and names the resource ('a draggable 2D (XY) gesture pad'), then details what it produces (Container COMP, x/y CHOP channels, optional Z slider). It clearly distinguishes itself from sibling create_* tools by focusing on this unique XY pad interaction.

  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 clear usage context: open in Perform/Panel mode, drag inside to scrub X/Y live, add Z via z_target, and leave targets empty to bind later with bind_to_channel. It lacks explicit exclusions or named alternative tools, but the workflow guidance is clear enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• curated_collection_packA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral detail beyond the annotations: it creates a directory tree with JSON and checksum manifests, supports pack/unpack with optional integrity verification, and is fully offline. It does not fully disclose failure modes or overwrite semantics, but annotations already cover the general safety profile.

  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 three sentences with no filler. It front-loads the purpose, then details pack/unpack behavior, and closes with a key constraint (offline). Every sentence earns its place.

  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 an 11-parameter, two-mode tool with rich schema descriptions, the overview plus action details give enough context for selection and invocation. It could mention return values or explicit alternative usage, but the schema and annotations fill most gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is high (91%), but the description adds semantics for the action parameter (pack vs unpack), explains the name parameter becomes <name>.pack/, and enumerates asset kinds (recipes, components, looks, raw assets) that map to the items[].kind enum.

  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 bundles curated vault assets (recipes, components, looks, raw assets) into a portable pack, and explains the two actions (pack/unpack). It distinguishes itself from siblings like export_recipe_bundle by focusing on multi-asset curated packs with provenance and integrity, and by being fully offline.

  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?

  It provides clear context: use when you need a portable, shareable, offline bundle of curated vault assets with provenance and integrity checks. However, it does not explicitly say when not to use it or name alternative sibling tools for single-asset exports.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• duplicate_networkA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal readOnlyHint=false and destructiveHint=false. The description adds useful behavioral details: it returns the source path and new copy's path, and copies contents. This exceeds what annotations provide, though it does not describe side effects or naming rules.

  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 action, and includes usage guidance without redundancy. Every sentence adds value, and it is 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?

  The description covers the core operation, return value, and usage context, and clarifies the distinction from a sibling tool. It does not mention error cases or naming behavior, but given the tool's modest complexity and lack of output schema, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema documents all three parameters. The description reinforces the meaning of parent_path ('placed in the source's parent or another parent_path') but does not add new semantic detail beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool copies a node or COMP and all its contents to a new location, and specifies the placement (source's parent or another parent_path). It also distinguishes itself from create_container, 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly indicates when to use this tool ('to clone a built network') and provides an alternative ('use create_container instead when you just need a fresh empty COMP'). This gives clear guidance on selecting the right tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• edit_shader_live_loopA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations flag readOnly=false and destructive=true, and the description aligns by describing write/replace actions. It adds value by disclosing that the tool immediately runs the feedback loop, inspects errors, and can produce a preview, plus mentions DAT write guardrails.

  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?

  Three sentences, each adding value: purpose, workflow, and implementation detail. No redundancy or filler.

  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 tool with 15 parameters and no output schema, the description provides a strong mental model of the workflow, including edit, inspect, and preview. It doesn't explicitly state the return structure, but the preview mention hints at output, making it reasonably 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?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning by framing parameters like mode ('write or surgically replace'), the error inspection workflow, and the compact inline preview, which helps connect parameters to the tool's purpose.

  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 edits a GLSL/Text DAT and runs a shader feedback loop including error inspection and optional preview. This distinguishes it from generic DAT editing tools like edit_dat_content and set_dat_content by emphasizing the shader-specific workflow.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for shader editing with immediate feedback and mentions the underlying set_dat_content/edit_dat_content functions, providing context on delegation. However, it doesn't explicitly state when not to use this tool or name direct alternatives for non-shader DAT editing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_setlist_to_vaultA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable context beyond the annotations: it reveals the note frontmatter structure, the COMP snapshot key, the prerequisite TDMCP_VAULT_PATH, and the round-trip workflow with import_setlist. It does not disclose behavior if the note already exists or if the COMP has no cues, but given the annotations, this is a minor gap.

  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 four sentences, information-dense, and front-loaded with the primary action. It uses some jargon (COMP, tdmcp_cues) but each sentence contributes essential context, and it is not overly verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 100% schema coverage, annotations, and no output schema, the description is complete: it explains the note format, prerequisites, and the re-import path. It fully covers the intended use case and relationships to sibling tools.

  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 parameters are already well-defined. The description enhances the target parameter by specifying the 'tdmcp_cues' key and explains the relationship with import_setlist, adding meaning beyond the schema for the target and include_tempo 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?

  Purpose is crystal clear: it serializes cues from a COMP into a setlist note in Obsidian, with specific format details and a round-trip purpose. It cites the 'tdmcp_cues' key and names import_setlist as the counterpart, distinguishing it from other export tools.

  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 explicitly states the use case: round-tripping a live-built show into the vault as a git-diffable setlist, and it names import_setlist for re-import. However, it does not explicitly contrast with alternative export tools (e.g., export_network_to_vault) or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• extract_audio_featuresA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds context beyond these: it may trigger a macOS permission dialog, the Sensitivity knob scales all channels, and it produces raw signals rather than a visual. It doesn't mention every side effect but sufficiently discloses the key behaviors for an open-world creation tool.

  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 dense but well-structured: it leads with purpose, then contrasts with alternatives, explains output usage, and lists source options. It is longer than minimal but earns its length with actionable guidance and no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a fairly complex tool with 8 parameters and no output schema, yet the description covers the output channels, how to bind them, source choices, permission caveats, and alternatives. It gives enough context for an agent to select and use the tool without needing additional resources.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed per-parameter descriptions, so the baseline is 3. The description adds a practical binding example ('op('…/audio_features/features')['bass']') and mentions the Sensitivity knob, but it does not materially extend the parameter semantics beyond what the schema already explains.

  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 and resource: 'Build an audio-analysis chain' that exposes reactive channels on a Null CHOP, and explicitly contrasts itself with create_audio_reactive ('renders a spectrum visual') and create_spectrum ('N fine per-band channels'). This clearly distinguishes its purpose from nearby siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit when-to-use guidance: use this for raw signals to drive ANY parameter, use create_spectrum for fine per-band channels, and pass this Null as source_chop to bind_audio_reactive. It also explains the four source modes and their appropriate use cases (testing, file, live device, existing CHOP).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• generate_library_indexA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false and destructiveHint=false, so it is already known as a write operation. The description adds valuable context: it reads local vault contents, writes a file, requires a configured TDMCP_VAULT_PATH, and performs no network/TD interaction. This goes beyond the annotations by clarifying side effects and prerequisites, though it does not mention the overwrite default behavior (covered by the schema).

  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 core action and output, then providing essential context (no TD connection, filters, requirement). Every clause adds useful information without redundancy. It is concise and well-structured for an agent to parse quickly.

  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 (6 optional parameters, no output schema), the description is quite complete: it explains the output note format, the data source (local vault), the thumbnail source, filtering options, and the environment requirement. It does not mention the overwrite default or edge cases, but those are specified in the input schema. The description gives enough context for correct selection and invocation, though not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the output structure (grid of cards with thumbnails and load snippets) and mapping 'kinds' to library categories (recipes, shaders, presets, components, setlists). It also ties thumbnails to the include_thumbnails parameter. This elevates it above baseline, though it does not describe every parameter individually.

  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 'Write[s] one Markdown contact-sheet note of the whole vault library' with specific content (grid of cards, thumbnails, tags, load snippets). This distinguishes it from siblings like save_recipe_to_vault or browse_vault_library, which have different outputs and purposes. The verb 'Write' and the resource are explicit 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?

  The description says 'No TouchDesigner connection required: it reads the local vault on disk and writes the index note,' which gives clear when-to-use context (when you need an index without a live TD connection). It also mentions filtering by category/query, implying use cases for targeted indexes. However, it does not explicitly name alternatives or say when not to use it, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• generate_readmeA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the description only needs to add extra behavioral context. It does so by stating the result is returned 'on the structured channel under markdown' and by mentioning max_nodes to cap large inventories. While it doesn't warn about potential cost of thumbnail generation, the read-only nature and added details make this solid.

  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 only two sentences, yet it packs in the tool's purpose, output sections, key parameters, and the return channel. It is front-loaded with the main verb and resource, and every word earns its place.

  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 an output schema present, the description needn't detail return fields. It covers the scope (any COMP/project), lists all included sections, mentions relevant parameters, and specifies the structured output key. The only minor gap is a lack of explicit performance caveats, but max_nodes partially addresses large inventories.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining include_mermaid and max_nodes in the context of document generation, and the phrase 'optional preview thumbnail' connects to include_preview. These contextual hints go beyond the bare schema descriptions.

  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 a specific verb and resource: 'Produce a Markdown project document for any COMP or project' and then enumerates the exact sections (family/type counts, custom-parameter table, inputs/outputs, child inventory, external file dependencies). This level of detail clearly distinguishes it from more generic sibling tools like document_network or project_documentation_site.

  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: it is for generating a Markdown project document for any COMP or project, with specific output components. It does not explicitly name sibling alternatives or state when not to use it, but the context is unambiguous enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• import_isf_shaderA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already convey non-read-only, non-destructive, and open-world traits. The description adds useful context: URL fetches are bounded by fetch_timeout_ms, the tool returns specific artifacts (container/GLSL/output paths, controls, provenance, warnings, conditional preview), and it creates companion DATs. This meaningfully goes beyond the structured 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?

  Three sentences, each earning its place: first states core creation and output, second covers input modes and network timeout, third lists return values and alternatives. Front-loaded with the essential action, no filler.

  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?

  No output schema exists, so the description compensates by enumerating return contents (paths, controls, provenance, warnings, inline preview). It covers creation scope, input flexibility, and alternatives. Nested parameter behavior is left to the schema, but overall it provides a solid decision-making picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so parameters are already well-documented. The description echoes source modes (raw/file/URL) and mentions fetch_timeout_ms and capture_preview, but adds little new meaning beyond the schema's own per-parameter descriptions.

  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 creates a new TouchDesigner system container with an ISF shader as a GLSL TOP plus companion DATs. It distinguishes from siblings by explicitly naming create_glsl_shader and import_shadertoy as alternatives for different source types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It specifies when to use the tool (for ISF .fs shaders from raw/text/file/URL) and provides explicit alternatives for hand-written GLSL and Shadertoy sources. It also notes runtime considerations like fetch_timeout_ms and capture_preview for headless runs, giving clear selection and usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• import_modelA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description reveals the exact network structure: File In SOP, Geometry COMP, Camera, Light, Render TOP output as a Null. It also discloses the fallback behavior when model_path is omitted and the exposed knobs. This is rich behavioral context with no contradictions.

  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, efficient sentence that front-loads the core action, then details the network, fallback, and sibling relationship. Every clause earns its place with no redundant 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?

  The description covers the main purpose, network construction, fallback behavior, exposed controls, and the sibling relationship. It does not mention parent_path or container creation, but the schema fully covers those, and there is no output schema to explain. Overall, it is complete for a creation tool with good annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has a detailed description. The tool description adds no new parameter semantics beyond referencing model_path and the knob names, which the schema already documents. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb+resource: 'Import a 3D model file (.obj/.fbx/.usd) and render it to a TOP.' It also clearly differentiates from the sibling tool create_3d_scene by calling itself 'the imported-model sibling,' so an agent can tell them apart.

  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 names the alternative create_3d_scene explicitly and distinguishes the use case (importing a model file vs. creating a scene). However, it does not explicitly state 'when not to use' or provide a direct comparison of scenarios, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• import_shadertoyA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral context beyond the annotations. It discloses that the first fetch on macOS may trigger a permission prompt, that setting TDMCP_SHADERTOY_KEY improves fetch reliability, and that pasting into raw_source keeps operations offline. These details align with the openWorldHint and give the agent actionable expectations about network behavior and side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, three sentences, with the core purpose front-loaded. Every sentence adds value: main function, feature details, and important network/offline caveats. No unnecessary words or filler.

  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 12 parameters, nested objects, and no output schema, the description covers the essential workflow: what gets built, how inputs are provided, and critical operational notes. It does not describe return values or all parameter options, but it gives enough context for an agent to invoke the tool successfully for the primary use case.

  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 schema description coverage at only 25%, the description compensates for some key parameters (url, shader_id, raw_source, channels, expose_speed_control, expose_mouse_control, capture_preview) but leaves many others undocumented, such as resolution, pixel_format, parent_path, and provenance_override. It adds meaning to the main inputs but does not fully cover the parameter space.

  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: 'Build a GLSL TOP from a Shadertoy URL, ID, or pasted source.' It identifies the resource (GLSL TOP) and the specific input formats, distinguishing it from sibling import tools like import_isf_shader. The mention of wiring iChannels, exposing Speed/Mouse controls, and capturing previews further clarifies the tool's scope.

  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 usage context: it explains the three input modes (URL, ID, pasted source) and gives guidance on offline usage via raw_source and reliability via TDMCP_SHADERTOY_KEY. It does not explicitly mention alternatives or when-not-to-use, but the context is sufficiently clear for an agent to select this tool appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• learn_controlA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only indicate non-read-only, non-destructive, open-world behavior. The description adds significant behavioral context: it's stateful (snapshot stored in parent COMP), requires two calls, binds via expression, and is experimental. It also warns to verify the matched channel, which is important for correctness. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph that front-loads the experimental nature and core purpose. Every sentence is informative, but it's somewhat run-on and could be broken into steps for easier parsing. Still, no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex, stateful tool with no output schema, the description covers the workflow, statefulness, prerequisites, and a sanity check (verify channel). It also references failure handling (min_delta warning) indirectly. The description is sufficiently complete for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The overall description does not add parameter-specific semantics beyond what the schema already provides; it merely mentions 'optional scale/offset' and references the source CHOP and target generically, which are already detailed 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 clearly states a specific two-step process ('snapshot' then 'bind') with precise verbs: record, diff, find, bind. It identifies the resource (input CHOP, target parameter) and distinguishes itself from typical MIDI learn tools by the stateful snapshot approach and experimental status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit step-by-step instructions: call with mode:'snapshot' first, wiggle a control, then call with mode:'bind'. It clarifies prerequisites (input CHOP, controls at rest) and warns to verify the matched channel. However, it doesn't mention alternatives or when not to use this tool, so it's clear context without explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• learn_from_my_corpusA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses that it writes to Memory/corpus_style.md and optionally merges into Memory/style.md, which is important since readOnlyHint=false. It also notes the env var requirement and that it is a pure filesystem operation. The phrase 'pure filesystem read' is slightly misleading given the writes, but the writes are clearly disclosed.

  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 only two sentences, front-loaded with the sibling relationship and then packing in details about inputs, outputs, and prerequisites. Every clause contributes new information without redundancy.

  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?

  Covers the core purpose, input parameters, output files, optional merge behavior, and prerequisites. However, it does not describe the return value (especially for dry_run mode) or explain that also_patch_style_memory defaults to true, which would be useful given there is no output schema.

  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 input schema has 100% coverage with detailed descriptions for all 6 params. The description adds value by mapping the observe families (palette, naming, recipe-shape, param-default) to the vault corpus folders and by explaining vault_path via TDMCP_VAULT_PATH. It does not merely duplicate schema details.

  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 'walks the Obsidian vault corpus' and 'distils palette, naming, recipe-shape, and param-default preferences' into specific output files. It distinguishes itself from sibling learn_conventions by explicitly calling itself the 'Offline companion' and noting 'No TouchDesigner required'.

  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 clear context for when to use: as an offline companion to learn_conventions, with no TouchDesigner required. It also states the prerequisite of TDMCP_VAULT_PATH or vault_path. However, it does not explicitly describe when not to use it or directly contrast with other alternatives beyond learn_conventions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• make_portable_toxA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark destructiveHint=true, but description adds specifics: 'writes/overwrites local files in out_dir' and mentions return values (paths and warnings). It also notes the requirement of a running bridge, which goes beyond schema/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?

  Three sentences pack purpose, usage guidance, side effects, and returns with no filler. Front-loaded with the action verb; 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?

  For a tool with nested object help_snapshot and 12 params, the description covers key aspects: what it does, when to use, side effects, and what is returned. However, it omits details about the overwrite_policy and help_snapshot semantics, relying on schema for those.

  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 58% (7/12 params), so description should compensate. It names out_dir and docs/README but does not explain remaining undocumented params like idempotency_key, provenance_policy, or timeout settings. Adds minimal param detail beyond 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?

  Description opens with a specific verb and resource: 'Save one live TouchDesigner COMP as a portable .tox package on disk, then write a tdmcp-component manifest beside it...' This clearly states the tool's function and scope, distinguishing it from bundle_dependencies and other packaging tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use: 'Use this for packaging a finished component'; then points to an alternative: 'use bundle_dependencies instead when external media must be collected and relinked.' It also warns about prerequisites ('Requires a running bridge') and side effects.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• moodboard_to_systemA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description adds valuable behavioral details: it discloses the use of a vision-capable local LLM when configured, a deterministic fallback grammar, and a specific quirk ('preview may read 0 on a paused timeline'). These context-rich additions exceed the bar set by 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 concise and front-loaded: the first sentence states the core action, the second explains the process and fallback, and the third gives a practical tip. No unnecessary words; the generator list is dense but informative.

  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 no output schema, the description should ideally explain the return value or result of the build, but it does not. However, it covers inputs, process, fallback, and a behavioral quirk, making it fairly complete for a complex tool. A return value mention would push it to 5.

  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 covers all 7 parameters with descriptions (100% coverage), so the description does not need to add much. It mentions 'palette hint' and the generator enum, but these are already detailed in the schema. The preview quirk is unrelated to parameters. This aligns with the baseline of 3 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 action ('Ingest 1..6 moodboard images and build a matching generative system in TouchDesigner') with a specific resource and target. It distinguishes itself from sibling creation tools by referencing moodboard input and a generator enum, making the tool's unique role clear.

  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 the tool (when building a generative system from moodboard images), but it does not explicitly name alternatives or state when not to use it. This meets the 'clear context, no exclusions' level.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• project_documentation_siteA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag this as potentially destructive (readOnlyHint=false, destructiveHint=true). The description adds the concrete behavior of writing multiple files into out_dir and conditionally generating thumbnails, but it does not clarify whether existing files in out_dir are overwritten or deleted, which is a notable gap given the destructive hint.

  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 sentences, no filler. The first sentence efficiently packs the purpose and file inventory; the second contrasts with a sibling. Every word earns its place.

  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?

  The description enumerates all generated files and their contents, the conditional thumbnails, and the output directory. It doesn't discuss overwrite behavior or prerequisites, but for a documentation writer, the key details are present. Output schema absence is mitigated by the detailed package structure description.

  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?

  All 5 parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds meaning by explaining that include_thumbnails triggers PNG generation linked from gallery.md, and that all files are written into out_dir, going slightly beyond the schema's property descriptions.

  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 it 'compose[s] a one-folder handoff/portfolio documentation PACKAGE for a network' and enumerates the outputs (README.md, topology.md, thumbnails). It also explicitly contrasts with sibling generate_readme, making the tool's scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Names generate_readme as the alternative and explains the difference ('a single file' vs 'a small multi-file site folder'), with an explicit use case: 'for sharing or archiving a project.' This gives the agent a clear selection criterion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pulse_td_parameterA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses validation-before-invocation, typed error behavior for missing/non-Pulse cases, and the absence of raw Python fallback. This adds meaningful behavioral context about what happens on failure and what the tool intentionally does not do.

  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 core action, and each sentence earns its place: the first explains the process, the second covers error semantics and the no-fallback trait. No redundancy or fluff.

  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 pulse tool, the description covers validation, invocation, error behavior, and the no-fallback policy. The only minor gap is the vague 'confirm the result' without specifying return format, but since no output schema exists and the tool is simple, this is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive parameter entries ('Full path of the operator that owns the Pulse', 'Exact name of the Pulse parameter'). The description does not add extra meaning beyond what the schema provides, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action: 'Validate that an existing operator parameter is Pulse style, invoke its structured .pulse() operation, and confirm the result.' It names the resource (operator parameter), the exact operation (.pulse()), and differentiates from siblings like execute_python_script by noting it does not use raw Python fallback.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use: for Pulse-style parameters needing a structured pulse call. It clarifies limitations ('Does not use raw Python fallback') and error conditions (missing operators/parameters/non-Pulse styles return typed errors). However, it does not explicitly name alternatives or state 'use this instead of X', leaving some room for inference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• randomize_controlsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses behavior beyond the annotations: it specifies that non-numeric controls are left untouched, explains the blending behavior of the 'amount' parameter, and explicitly states safety ('always safe to fire'). The annotations already indicate it is not read-only and not destructive, and the description adds valuable detail about what exactly changes and what does not.

  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 core purpose. Each sentence adds distinct value: main action, parameter behavior, safety, and a workflow tip. There is no fluff, and the structure flows logically from what it does to how to use it.

  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?

  The description is complete enough for a tool with 4 optional parameters and no output schema. It covers the effect on numeric vs non-numeric parameters, the blending behavior, and a use case. It does not explicitly mention whether it works on the current selection or only the specified comp_path, but the schema's comp_path parameter covers this. Minor gap: no mention of return value, but that is not necessary without an output schema.

  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% and the schema already describes parameters well. The description adds a higher-level interpretation, such as 'amount blends toward random (1 = fully random, low values nudge the current look)' and clarifies that only numeric custom parameters are affected, reinforcing the meaning of the 'params' array. This adds value beyond the schema without redundancy.

  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: 'Randomize a COMP's numeric custom parameters within their slider ranges' with a specific resource and scope. It also adds the use case 'instant new variation for live improvisation,' making it unmistakable what the tool does and distinguishing it from any other tool.

  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 gives clear context for use ('live improvisation') and explicitly says it is 'always safe to fire' with no prerequisites. It suggests pairing with manage_presets/manage_cue to snapshot results, but does not explicitly state when not to use it or name an alternative tool. This is clear guidance but lacks explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• reload_bridgeA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=false and destructiveHint=false, but the description adds valuable behavioral detail: it performs an in-place reimport, returns the reloaded list, and avoids reopening the project. It discloses that it mutates the running environment, which goes beyond the annotations and gives the agent a clear expectation of side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the main purpose, and each sentence adds value (action, mechanism, return value, usage). There is no fluff or redundancy.

  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 zero-parameter tool with no output schema, the description is complete: it explains what happens, why, and what the agent will receive. It could mention potential risks of reimporting modules (e.g., state reset), but that is beyond the necessary scope given the annotations indicate non-destructive behavior. Overall, it is well-rounded.

  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 schema coverage is effectively 100%. The description adds no parameter info needed, and the baseline for no-param tools is 4. It appropriately focuses on the tool's action and return value.

  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 ('hot-reload') and resource ('bridge's Python inside the running TouchDesigner'), explaining what it does and how it achieves it (reimports mcp.*/utils.* modules). It distinguishes this from sibling tools like get_bridge_logs by focusing on code reload rather than 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 explicitly states when to use the tool: 'Use after editing bridge code.' This gives clear context. It does not mention alternatives or exclusions, but the instruction is sufficient for a typical dev workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• resolume_vdmx_output_chainA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses concrete behavioral details beyond annotations: it 'builds target-specific OSC Out lanes' and lists the specific channels (layer opacity, crossfader, speed, clip trigger, blackout). Annotations only indicate non-read-only, non-destructive, open-world behavior; the description adds meaningful context about what is created, though it omits potential side effects like overwriting existing lanes or prerequisites.

  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 core purpose, and every clause adds value. The first sentence states the action and scope; the second details the built channels and the usage context. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 7 parameters and no output schema, the description covers the tool's essence, creation scope, and usage context. It could be more complete by noting that the target VJ software must be configured to receive OSC on the specified ports, and it does not explain what the return value is (e.g., the created COMP), but overall it is sufficient for an agent to select and invoke the 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 100%, so baseline is 3. The description adds meaning by explaining that the tool creates 'target-specific OSC Out lanes' with specific channel types, which gives context to the 'target' parameter and ports. This goes beyond the individual parameter descriptions by clarifying how the parameters fit together.

  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 action ('Create an OSC control chain') with a defined resource ('for driving Resolume, VDMX, or both from TouchDesigner'), and it distinguishes itself from siblings by detailing the scope (layer opacity, crossfader, speed, clip trigger, blackout channels) and its place 'beside video/NDI/Syphon output tools' for external VJ composition.

  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 use case ('use it beside video/NDI/Syphon output tools when an external VJ app handles playback or final compositing') and implies alternatives exist by contrasting with output tools. However, it does not explicitly name exclusion criteria or alternative sibling tools such as connect_resolume_arena, so it falls short of exhaustive guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_python_apiA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already covers safety, and the description adds useful behavioral details: the knowledge base is embedded offline and version filtering is conservative, only applying where compatibility metadata exists. It doesn't contradict annotations and adds meaningful context beyond them.

  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 sentences, front-loaded with 'Read-only' and a clear action. No redundant content; every clause adds 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 output schema and full parameter descriptions, this is sufficiently complete: it states the search source, scope, and filtering capabilities. The only missing context is explicit comparison to sibling tools, but that's covered under usage guidelines.

  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 input schema provides 100% parameter coverage, so the baseline is 3, but the description adds nuance: version filtering is 'conservative' and only applied 'where compatibility metadata exists', clarifying the version parameter's behavior. It also explicitly mentions class category filtering, reinforcing the category parameter's purpose.

  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 searches TouchDesigner Python API classes, methods, and members from an embedded offline knowledge base, using specific verbs and a defined resource scope. It distinguishes itself from sibling search tools like search_operators and search_touchdesigner_knowledge by targeting the Python API specifically.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context: querying the offline Python API knowledge base, with optional filters for category and version. It does not explicitly name alternative tools or state when not to use it, but the context is clear enough for an agent to differentiate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• setup_face_trackingA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behavioral traits: it loads a specific engine, starts the timeline, and builds an adapter Script CHOP, which is consistent with the annotations (readOnlyHint=false, openWorldHint=true). It also explains the output format (468/478 landmarks, tx/ty/tz/confidence, nose tip centering) beyond what annotations provide. No contradiction found.

  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 dense but well-structured sentences. It front-loads the primary action ('One-shot face-landmark tracking from a webcam'), includes a practical installation note, lists the build steps, and ends with downstream integration. Every sentence earns its place with no redundancy.

  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 (setup with engine load, node creation, data output) and the absence of an output schema, the description covers the essential aspects: what it does, prerequisites, output format, and downstream tools. It could mention naming or access to the created CHOP, but it is sufficiently complete for an agent to invoke successfully.

  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 input schema already documents all three parameters with 100% coverage. The description adds semantic value by explaining how num_landmarks relates to the output (468 base vs 478 with iris), and clarifies the tox_path default behavior via the install command. This goes beyond schema descriptions to enhance understanding.

  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+resource: 'One-shot face-landmark tracking from a webcam' and details the operational steps (loads MediaPipe engine, starts timeline, builds adapter Script CHOP). It also distinguishes from sibling tracking tools by explicitly focusing on face landmarks and noting downstream usage with bind_to_channel and create_data_visualization.

  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 usage context: tracking face landmarks from a webcam, including the prerequisite installation command and the intended downstream tools. It does not explicitly contrast with alternatives like setup_hand_tracking, but the scope is unambiguous enough that an agent can decide when to invoke it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• setup_segmentationA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description reveals behavioral details beyond annotations: it loads an engine, creates a COMP with Null TOPs, is idempotent, and requires the timeline playing and camera permission. These specifics about side effects and runtime conditions are not present in 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 concise paragraph that front-loads the purpose, immediately states the install prerequisite, and details the workflow in four sentences. Every sentence adds operational value without redundancy.

  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?

  The description explains the setup workflow, outputs (mask and RGBA Null TOPs), integration with other tools, idempotency, and runtime requirements. However, it does not explicitly state what the function returns (e.g., the COMP path), which would be valuable since there is no output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema descriptions cover 100% of the 8 parameters, providing thorough explanations such as feather_px's blur radius and invert_mask's Level TOP application. The tool description adds no additional parameter-level semantics beyond these, so it does not exceed the baseline score.

  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 'One-shot selfie segmentation via the MediaPipe TouchDesigner engine' and details the build steps, distinguishing it from sibling tracking setup tools. It specifies the resource (selfie segmentation) and the output (adapter COMP with alpha-mask Null TOP), making its 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description advises 'Wire the mask into create_keyer, create_depth_silhouette, or any matte-consuming tool', establishing a clear usage context. However, it does not explicitly exclude alternatives like setup_hand_tracking or setup_face_tracking, relying on the name and sibling list for differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• suggest_operator_chainA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses valuable behavioral traits: it operates offline, returns connection hints and next tool hints, and explicitly does not create nodes. This adds meaningful context about data source and side-effect-free behavior, complementing the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise, delivered in two short sentences. It front-loads the critical 'Read-only' signal, then efficiently conveys the tool's function, data source, return type, and non-destructive nature. Every phrase serves a purpose, with no redundancy or extraneous 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?

  Given the presence of an output schema and complete parameter descriptions, the description covers the essential context: purpose, read-only nature, offline operation, and return value summarization. It is well-rounded but could improve by explicitly guiding selection against sibling tools like search_operators or validate_operator_chain, though 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 provides descriptions for all four parameters (goal, family, max_steps, seed_operator) with 100% coverage. The tool description does not add any additional parameter-specific meaning or constraints, so the baseline score of 3 is appropriate since the schema already carries the semantic weight.

  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: suggesting a small ordered TouchDesigner operator chain for a creative or technical goal, using offline docs and workflow patterns. It distinguishes itself from mutation tools by explicitly noting it returns hints and does not create nodes, setting it apart from siblings like create_node_chain and validate_operator_chain.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies appropriate usage for planning and suggestion scenarios, emphasizing read-only behavior and the absence of node creation. However, it does not explicitly name alternative tools for validation or creation, and doesn't state when one should prefer this over search_operators or get_operator_workflow_guide, leaving exclusions implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• summarize_td_errorsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is known. The description adds meaningful behavior: clustering by message/type/parent, returning a summary with groups and suggestions, and indicating a severity-based investigation order. This goes beyond the annotation coverage and clarifies the tool's output 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 compact and front-loaded: it states the core function, the return shape, and the usage distinction in three sentences. Every sentence adds value, and the formatting is easy to parse.

  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?

  The tool has an output schema that presumably documents {total, groups[], suggestions[]}, so the description need not elaborate on return fields. It includes usage guidance and alternatives, which suffices for network-wide triage. However, it does not mention potential performance implications or whether the traversal is recursive, which could matter for large networks. Still, the provided context is strong overall.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and both parameters ('path' and 'group_by') have clear descriptions in the schema. The description references the grouping options by enumerating 'message, type, or parent container,' but this simply mirrors the schema's enum rather than adding new meaning. It does not provide extra parameter context such as path syntax or behavior with missing paths.

  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 errors across a network and cluster them') and names the resource (network errors) with clear output features (worst-offending nodes, suggested investigation order). It also explicitly distinguishes itself from the sibling tool get_td_node_errors, making its 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance: 'Use this for network-wide triage' versus 'use get_td_node_errors when you just want the raw error list for one node or sub-tree.' This directly addresses alternatives and exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sync_external_clockA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses specific side effects: 'All modes write the global tempo (op('/').time.tempo)' and explains the hardware-gated nature of Link/MIDI modes with fallback to the manual Bpm knob. This adds significant behavioral context not present in 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?

  Four sentences, front-loaded with the core purpose, and every sentence contributes: purpose, mode details, side-effect, and hardware gating. No redundant or filler content.

  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?

  The description covers the tool's purpose, modes, side effects, hardware dependencies, and relationship to downstream tools. It does not state return values, but no output schema exists and the tool's function is a side-effecting action (creating a container and setting tempo), so this gap is minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter (bpm, mode, parent_path) already having detailed descriptions. The tool description largely restates the mode semantics and adds no new parameter-specific meaning. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 a specific verb+resource: 'Lock the project tempo to a live source so beat-synced visuals follow the music.' It clearly distinguishes the tool by explaining the three modes and explicitly positions it as the source that create_tempo_sync and create_autopilot follow, differentiating it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage 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 sync project tempo to a live source (tap, Ableton Link, MIDI clock). It names downstream consumers (create_tempo_sync, create_autopilot), but does not explicitly state when NOT to use it or enumerate alternative tools. This matches 'clear context, no exclusions'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tag_and_search_libraryA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations (all false) by specifying that the 'tag' operation can edit frontmatter, supports union or replace, and always preserves '*'-pinned tags. It also clarifies that the tool is pure vault I/O and requires an environment variable. This adds useful behavioral context beyond what annotations convey, though it does not detail return formats or error behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph that front-loads the primary purpose, then uses semicolons to enumerate operations efficiently. Every sentence contributes meaningful information, and the structure makes it easy to scan.

  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 (11 parameters, 4 operations, no output schema), the description covers all operations and key constraints. It lacks details on return values or edge cases, but the functional coverage is strong enough for an agent to select and invoke the tool correctly in most scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by grouping parameters under their relevant operations (e.g., tags, replace for 'tag'; query, tags_any, tags_all for 'search') and clarifies the set logic and pinned-tag behavior, enriching the raw schema definitions.

  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 a specific verb+resource pair ('Faceted browse + tag editing over a vault library') and immediately enumerates four distinct operations (list, search, tag, filter) with clear scoping to Recipes/ and Components/ markdown notes. This makes the tool's purpose instantly clear and differentiates it from sibling tools like browse_library or generate_library_index.

  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 defines the exact condition for use: it operates on the vault library and mentions 'no TouchDesigner bridge required', contrasting with many siblings. It also states the prerequisite 'Requires TDMCP_VAULT_PATH'. However, it does not explicitly name alternatives or say when not to use this tool, so it lacks explicit exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• validate_library_assetA
  4.4/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only and non-destructive behavior, but the description adds rich detail: deep_roundtrip runs in an 'authenticated disposable quarantine bridge on a non-9980 port', uses a 'structured loadTox-only job with bounded polling and verified scratch cleanup', and clarifies 'offline evidence is UNVERIFIED, never PASS.' This significantly 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 exactly two sentences with no filler. The first sentence states the purpose, and the second packs the deep-mode behavior and result interpretation ('offline evidence is UNVERIFIED, never PASS') into a single dense sentence. Every word earns its place.

  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 (nested deep object, no output schema), the description gives a solid behavioral overview but omits return-value specifics beyond the UNVERIFIED note. It also does not explain the deep sub-parameters or failure modes. Still, the core purpose and mode distinction are well covered, making it reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains path (local library asset), manifest_path (optional manifest), and validation_mode (static/deep_roundtrip), and hints that deep_roundtrip requires an 'absolute .tox' and quarantine port. However, the many sub-parameters of the deep object (max_nodes, timeout_ms, expected_contract, etc.) are not described, leaving a coverage gap.

  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: 'Check that a local library asset exists and is referenced by an optional manifest.' This clearly distinguishes the tool from siblings that validate operator chains or checksums, and identifies the resource and scope.

  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 on mode selection: 'default static mode preserves the cheap filesystem check' vs 'Opt-in deep_roundtrip' for more thorough validation. However, it does not explicitly mention alternatives or when-not-to-use, so it falls short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• variant_packA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnly=false and destructive=false; description adds that it writes to the vault, requires TDMCP_VAULT_PATH, and details the clamping/rounding/perturbation algorithm. This goes beyond the annotation flags by disclosing input probing and file output behavior, though it doesn't discuss failure modes or overwrite 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?

  Three sentences, each serving a purpose: purpose, algorithm, and integration with morph_pack. No redundant phrasing; front-loaded with the core action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 13 parameters and no output schema, the description covers the key aspects: what it generates, where it writes, the environment requirement, and downstream consumer. Minor omission is return value details, but the file-based output is adequately implied.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so descriptions provide baseline. The description adds value by explaining how delta_range scales with slider span and how comp_path is used to read customPars, which clarifies parameter semantics beyond the schema. It doesn't enumerate each parameter but contextualizes the algorithm.

  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?

  Description clearly states the tool generates N perturbed variants around an anchor look and writes a morph_pack-compatible JSON to the Obsidian vault. It identifies the specific resources (anchor parameter look, COMP customPars, vault) and distinguishes itself from morph_pack by being the generation step.

  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?

  Description explains the workflow (probes customPars, perturbs, writes for morph_pack unpack), implying when to use it. However, it does not explicitly exclude alternatives like create_preset_morph or state when not to use it, so it gets a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• analyze_projectA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already indicate readOnlyHint=true and openWorldHint=true, but the description adds valuable behavioral context: 'Read-only and conservative — every flagged item carries a human-readable reason.' This goes beyond the structured hints by explaining the conservative nature (likely under-reporting) and the presence of human-readable justifications, which helps an agent calibrate expectations. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: two sentences containing all essential information without redundancy. It front-loads the primary action ('Diagnose a network for cleanup') and lists outputs efficiently. Every clause earns its place, making it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description thoroughly enumerates what the tool reports (dead operators, broken dependencies, orphan COMPs, dependency map) and provides context about safety ('read-only and conservative') and relationship to sibling tools. Since an output schema is present, the description doesn't need to detail return values, and the existing coverage is sufficient for a complex analysis 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?

  Both parameters are fully described in the input schema (100% coverage), so the schema carries the load. The description does not add any additional semantic details about the parameters themselves, such as how path and recursive affect the analysis output. It meets the baseline for high schema coverage but doesn't exceed it.

  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 ('Diagnose') and resource ('a network for cleanup') and enumerates concrete report types: likely-dead operators, broken external-file dependencies, orphan COMPs, and a dependency map. It clearly distinguishes itself from siblings by naming plan_visual and snapshot_td_graph, so an agent can tell this tool's purpose apart from related ones.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says it 'Complements plan_visual (which plans a build) and snapshot_td_graph (which dumps structure),' providing direct comparison and alternatives. It also states 'Read-only and conservative,' giving an additional usage context that signals safety and caution. This gives an agent a clear sense of when to choose 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.

• animate_parameterA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnly=false, openWorldHint=true), the description reveals side effects: it creates an LFO CHOP, binds targets, and switches each parameter to expression mode. This provides significant behavioral context not captured by annotations alone.

  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 sentences, front-loaded with the main action, then the mechanism and benefit. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and lack of output schema, the description covers the process, the target format, and the result. It is self-contained and sufficient for an agent to know what happens upon invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description references min, max, and period but does not add additional detail beyond the schema's own parameter descriptions.

  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?

  Description clearly states the verb 'Drive' and resource 'node parameters over time with an LFO', specifies the mechanism (creates an LFO CHOP and binds each target) and lists waveform types. This distinguishes it from sibling animation/parameter tools such as pulse_td_parameter or set_parameter_expression.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for LFO-based animation without manual keyframing, and contrasts with keyframing. It does not explicitly name alternative tools or state when not to use, but the intended context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• batch_operationsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses critical behavioral traits beyond annotations: 'fail-forward, per-operation warnings; not transactional' and 'Names created earlier can be referenced by later connect/setParam operations.' These are not derivable from the readOnlyHint/destructiveHint annotations and are essential for the agent to predict partial failure behavior and cross-referencing 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 core purpose, followed immediately by the key behavioral caveat and a sibling distinction. Every sentence earns its place with no filler or redundant repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with a complex nested schema and multiple operation types, the description covers all essential aspects: what it does, the non-transactional behavior, name referencing, and relationship to a similar tool. Since an output schema exists, not explaining return values is acceptable. The description fully equips an agent to select and invoke the tool correctly.

  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 comprehensive descriptions for all parameters (100% coverage), including the operations array's ordering and fail-forward behavior. The description reinforces these points but adds no new parameter-level details. The baseline of 3 is appropriate given the schema's completeness; the description does not need to compensate.

  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 exactly what the tool does: 'Run an ordered list of create / connect / setParam operations in one call.' It clearly identifies the resource (network builder) and the scope of operations. It also distinguishes itself from a sibling tool ('distinct from set_parameters_batch'), leaving no ambiguity about its purpose.

  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 explicitly names an alternative tool (set_parameters_batch) and explains the difference, which helps with selection. It implies use for multi-step network construction via 'Exposes the network builder as a general primitive,' but doesn't explicitly state when not to use it (e.g., for single operations). This is clear context but lacks formal exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bind_to_channelA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly=false, destructive=false), the description discloses the key mutation: 'Each is switched to expression mode so it tracks the channel live.' It also details the smoothing mechanism ('insert a Lag CHOP between the channel and the parameter'). This adds important behavioral context that annotations do not provide.

  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 two sentences but is somewhat long. However, each clause contributes meaningful information: purpose, typical sources, smoothing options, and a concrete example. The structure front-loads the core action ('Drive one or more node parameters...') then elaborates, making it easy to scan.

  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 tool with 9 parameters and no output schema, the description covers purpose, usage context, parameter semantics, and side effects. It doesn't discuss potential failure modes or prerequisites beyond pointing at a source CHOP, but for this complexity it is quite 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?

  Schema coverage is 100%, so baseline is 3. The description adds extra meaning by explaining how smoothing parameters work together ('fast attack + slow release for a punchy hit that decays smoothly') and explains the 'smooth' convenience parameter as symmetric attack/release. This adds value beyond the schema's individual parameter descriptions.

  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: 'Drive one or more node parameters from a CHOP channel by expression' and its purpose ('the link that makes a visual react'). It also distinguishes from sibling tools by explicitly naming the upstream tools it connects: 'This is how you wire extract_audio_features / create_tempo_sync into a visual system.'

  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 when-to-use context by pointing at specific channel types ('audio_features channel (bass/mid/treble/level) or a tempo_sync channel') and referencing upstream tools. It does not explicitly state when not to use or name alternative tools, so it stops short of full explicit exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bind_vault_textA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations, the description details side effects (node creation + file read), explicitly states it does not write to the vault, explains sync behavior, and lists return values. This adds significant context over the readOnlyHint/destructiveHint/openWorldHint 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?

  Concise at 4 sentences, action-first opening, includes side effects, usage, returns, and requirement without extraneous detail. Every sentence contributes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool without an output schema, the description adequately explains return values, side effects, and prerequisites. It covers the full workflow and boundaries, making it sufficient 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.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers 100% of parameters with descriptions, so baseline is 3. The description does not add much parameter-level meaning; it mentions sync's live-editing effect, but the schema already states that. No new parameter insights are 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 opens with 'CREATE a Text DAT in TouchDesigner whose file parameter points at a vault note', specifying the exact action and resource. It clearly differentiates from sibling tools like create_td_node or edit_dat_content by focusing on vault-note-binding behavior.

  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 clear context: use this to turn the vault into text/lyrics source for visuals, and mentions a workflow step (wire into Text TOP). It notes prerequisites (TDMCP_VAULT_PATH) and boundaries (does not write to vault), but does not explicitly name alternative tools or when-not-to-use conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• caption_topA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly, openWorld, non-destructive), the description discloses crucial behaviors: the deterministic luma/color-histogram fallback that 'always works, no model needed', the current inert vision path, and the return structure including 'source: vision|histogram' and warnings. This provides rich context about reliability, fallback logic, and potential warnings, going well beyond the structured 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 front-loaded with the core action ('Read-only: render a TOP's preview and return a plain-text description'), then efficiently explains the two paths, the outputs, the use case, and a caveat about the vision path. Every sentence contributes value without redundancy, and the structure flows logically.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description explicitly enumerates the return fields ('{node_path, width, height, source:... caption, stats{...}, warnings}'). It explains both execution modes, the deterministic fallback, the intended usage scenario, and a current limitation. For a tool with 4 parameters and no output schema, this description is exceptionally complete and self-contained.

  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 thorough descriptions for all four parameters (width, height, node_path, use_vision), including defaults and the 'smaller is faster' note. The description adds context about the two paths (vision vs histogram) and the inert vision path, but most parameter-specific information is already in the schema. Since coverage is 100%, a baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: 'render a TOP's preview and return a plain-text description of it'. It also labels it as the 'headless is the output alive? primitive', and specifies the exact outputs (dominant colors, mean luma, near-black fraction, classification, caption). This is a specific verb+resource and distinguishes it from sibling tools like get_inline_preview or render_output.

  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 gives an explicit use case: 'Use it after a build to confirm the network is actually rendering instead of a black frame.' It also clarifies the two execution paths and warns that the vision path is currently inert. However, it doesn't explicitly state when not to use this tool or compare it to alternative tools, so it lacks exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• compact_graph_digestA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable context beyond that: it reveals the tool uses getNetworkTopology and getNetworkErrors, performs 'no new bridge work,' and returns an approxTokens count. This gives the agent a clear mental model of cost and side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the read-only flag, and every sentence carries unique information: what it does, what it returns, and how it compares to alternatives. There is no wasted text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  An output schema exists, so the return shape is already documented, and the description covers the tool's purpose, underlying mechanism, and relative cost vs. siblings. For a read-only planning digest, this is complete enough for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all six parameters already have robust descriptions. The tool description mentions max_tokens as a default budget but does not add new per-parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb-resource pairing: 'compress a TD subtree into a structured digest,' which clearly states the tool's function. It further differentiates from siblings by explicitly naming get_td_topology and snapshot_td_graph as costlier alternatives, so purpose and differentiation are both strong.

  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 gives a clear use case ('for planning turns') and explicitly names alternatives ('Cheaper than get_td_topology / snapshot_td_graph'), which tells the agent when this is preferable. However, it does not explicitly state when not to use it, so it falls just short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• compare_operator_docsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and destructiveHint, so the 'Read-only' prefix aligns with them rather than adding new safety info. However, the description adds useful context about the embedded offline knowledge base and the exact comparison scope (overview metadata, shared/unique parameters), which goes beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the key action and safety qualifier. Every clause adds value: read-only indicator, comparison target, offline KB, parameter types, and explicit distinction from live-node comparison.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With a rich output schema, clear annotations, and a precise description of purpose and scope, the tool is fully contextualized. The distinction from compare_td_nodes and mention of the offline KB cover the main potential confusions. No material gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the schema already documents all four parameters in detail. The description adds contextual value by explaining the comparison nature and what "documented parameters" means, but it doesn't describe the parameters themselves beyond what the schema provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb ('compare') and resource ('two TouchDesigner operator types from the embedded offline knowledge base'), and explicitly distinguishes from sibling tool compare_td_nodes by clarifying it compares documentation, not live node settings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use this tool (for comparing offline documentation) and when not to (for live node parameter diffs), naming the alternative tool compare_td_nodes. This provides clear usage boundaries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• compare_td_nodesA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Description says 'Read-only' which complements readOnlyHint: true and adds the default behavior of returning only differing values. The return object structure is disclosed. No contradiction with annotations, and no hidden side effects beyond what is implied.

  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?

  Three sentences with a clear flow: operation + default behavior, return structure, and usage guidance. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the presence of an output schema and annotations covering safety, the description fully covers purpose, usage, and the distinction from the key sibling. It is complete enough for an agent to select and invoke the tool correctly.

  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?

  Input schema has 100% coverage with descriptions for all three parameters (path_a, path_b, only_diff with default). Description adds no extra parameter-level information beyond referring to 'by default', so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states the tool diffs parameters of two nodes and returns differing values by default. Includes the exact return structure and explicitly mentions it operates on live nodes, distinguishing it from diff_snapshots.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives a concrete use case (aligning settings across similar operators) and explicitly contrasts with diff_snapshots (whole-network snapshots over time). This provides clear when-to-use guidance and naming of an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• component_changelog_trailA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds behavioral context beyond annotations: append-only nature, offline operation, and file output behavior (rendering markdown into vault). The annotations already indicate readOnly=false and destructive=false, and the description aligns without contradiction.

  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 appropriately sized for the tool's complexity, front-loads the core purpose, then systematically covers the three actions, location, offline capability, and related tools. Every sentence contributes meaningful information without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 5 parameters (one nested object), no output schema, and multiple actions, the description covers all key aspects: file format, storage location, action semantics, and relationships. It's sufficient for an agent to understand and invoke the tool correctly without needing additional clues.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining the meaning of actions ('read' returns JSON, 'export' renders markdown), clarifies the trail file naming convention, and mentions the optional sha256 hash and changed-param list, which enriches understanding 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 specifies a clear verb ('Maintains') and resource (append-only per-component revision history as JSONL trail), with three distinct actions. It distinguishes itself from siblings by noting it pairs with save_component_to_vault and provenance_stamp, and explicitly states it operates offline.

  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 clear context: it's for maintaining revision history offline, and mentions complementary sibling tools. However, it doesn't explicitly state when NOT to use it or compare against alternatives like version_library_asset or manage_component_storage, so it lacks exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• controlled_disorder_gridA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description transparently discloses side effects: 'Creates a new baseCOMP under parent_path', determinism via 'each hashed from the cell index in a single GLSL TOP', and the shape of the return value including node errors and warnings. This goes well beyond the annotations (readOnlyHint: false, openWorldHint: true) by explaining what will be created and what the response contains. No contradiction.

  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?

  Four sentences with no wasted words. The first sentence specifies the core function and the disorder range, and subsequent sentences cover customization, creation side effects, and return value in a compact, front-loaded structure.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 14 parameters, no output schema, and only basic annotations, the description covers all essential context: what it generates, how it achieves stability, what side effects occur, what live controls are exposed, and exactly what the response includes (summary, node paths, errors, warnings, preview image). The return-value detail compensates for the missing output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds cross-parameter meaning by explaining that the disorder knob 'scales per-cell position, rotation, and scale jitter together', connecting the individual jitter parameters (pos_jitter, rot_jitter, scale_jitter) into a single mental model. It also clarifies parent_path as the creation location. These are meaningful additions 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 leads with a specific verb and resource: 'Generate a rows×cols grid of quads (or outlined cells)' and uniquely identifies the disorder knob. This clearly distinguishes it from generic siblings like create_generative_art or create_glsl_shader.

  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 context through 'classic generative-design controlled randomness / Schotter study' and explains the single-knob mechanism, but it never explicitly states when to choose this tool over alternatives or names any exclusion cases. Usage is largely implied rather than directed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_body_reactiveA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and openWorldHint=true, and the description adds that it creates a new baseCOMP under parent_path, lists the node hierarchy, and details the return payload with node errors, warnings, and preview. It also explains that the default synthetic source needs no camera or plugin, going beyond the basic mutation flags.

  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?

  Although it is a single dense paragraph, every sentence earns its place: pipeline, node list, styles, source defaults, sibling relationship, and return value. It is front-loaded with the main action and avoids repeating schema details verbatim.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 11-parameter creator with no output schema, the description covers the full invocation reality: what is built, how the visual styles differ, which source to choose for which scenario, and what the tool returns (paths, controls, errors, warnings, preview). This is more than enough for an agent to select and invoke the tool 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?

  Schema coverage is 100%, so the baseline is met. The description adds extra meaning by connecting visual_style to dot_size/glow_amount/trail_decay and explaining source enum options with concrete CHOP paths, which helps the agent wire parameters to behavior.

  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 a specific verb and resource — 'Build a body-reactive visual driven by full-body pose tracking' — and then details the concrete components created (Null TOP, baseCOMP, Geometry COMP, Camera, Render TOP). It also distinguishes itself from siblings by explicitly calling itself the visual counterpart of create_audio_reactive.

  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?

  It provides clear context for source selection — synthetic for instant preview, mediapipe/osc/existing_chop for a real performer — and references create_audio_reactive. It does not name or exclude deeper pose-specific siblings like create_pose_reactive, so it lacks an explicit 'when not to use' statement, but the guidance is otherwise clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_color_wheelsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate mutating (readOnly=false), non-destructive, open-world behavior. The description goes further by explaining a new baseCOMP is created under parent_path, how source_path is wired, and that output is a Null TOP. It doesn't address conflicts/idempotency but the 'new baseCOMP' and destructiveHint=false provide a reasonable safety profile.

  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 dense but well-structured: chain architecture, wheel math, build behavior, exposure, output, and alternatives each take one sentence. No filler; every sentence carries operational value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 9-parameter creation tool with no output schema, the description covers the generated network, source handling, exposed controls, output identity (Null TOP), and fallback when no source_path is provided. This is sufficient for an agent to predict the tool's effect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with detailed parameter descriptions, so the description need not enumerate them. It adds architectural context (series of Level TOPs, live-bound knobs) but doesn't add syntax or default information beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Classic colour-grading wheels' and clearly states the tool 'Builds a new baseCOMP' containing the chain, with specific components (three Level TOPs, HSV Adjust). It distinguishes from siblings by naming create_color_grade and apply_post_processing as alternatives. The verb-resource pair (create + colour wheels) 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly advises when to use alternatives: 'Use create_color_grade for a simpler single-Level + HSV chain, or apply_post_processing to chain several distinct effects.' It also clarifies the optional source_path behavior (Select TOP vs Ramp gradient) so the agent knows when an external source is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_datamoshA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description adds rich behavioral context: it details the internals of each mode (Feedback TOP loop, Level TOP opacity, Time Machine TOP), notes the UNVERIFIED fallback for time_echo, mentions that resolution is forced to prevent flickering, and specifies the return value (container with Null TOP, exposed controls, live preview). This goes well beyond what annotations convey.

  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: first sentence states the core purpose, second details modes, third covers shared controls, fourth describes output. No redundant phrasing; every sentence adds necessary information. It is well-structured and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description appropriately explains the return value (container with Null TOP output, exposed controls, live preview). It also covers mode-specific internals, fallback behavior, source options, and resolution constraints. For a 7-parameter creation tool with no output schema, this is complete and self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds cross-parameter context by stating 'All modes expose a Decay knob', tying the decay parameter to all modes, and explaining the source parameter's fallback to a built-in animated Noise TOP. It does not repeat every parameter detail but provides cohesive semantics 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 uses a specific verb ('Build') and resource ('datamosh visual effect network'), enumerates three distinct modes with clear explanations, and distinguishes itself from generic creation tools by describing what it produces (container with Null TOP, controls, preview). It is precise 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 Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use the tool (create a datamosh effect in one call) and explains parameter choices (source omitted for built-in test source), but it does not explicitly compare to sibling tools like create_time_echo or create_feedback_network. The mode list implicitly covers these, but explicit when/when-not guidance is missing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_data_visualizationA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Given annotations only indicate non-read-only and non-destructive, the description adds substantial behavioral context: it details the node creation process, the placeholder data seeding, the return payload (summary, JSON block with paths, errors, warnings, preview image), and behavior differences among chart_style values. This goes well beyond what annotations provide.

  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 four sentences that efficiently cover the tool's behavior, creation steps, wiring instruction, and return value. It is front-loaded with the primary action and avoids unnecessary filler, earning a high score.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 compensates by fully describing the return value (summary, JSON block with paths, errors, warnings, preview image). It also covers the full build process, the need to wire real data, and potential warnings. For a tool with this complexity, the context is rich and 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 input schema already has 100% parameter description coverage, with detailed explanations for each enum and parameter. The tool description adds little new parameter-specific meaning—only the 'Scale level' mention aligns with expose_controls. Baseline 3 is appropriate since the schema already carries the descriptive weight.

  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: it builds a data-driven visualization with a specific node chain (data source to CHOP to chart TOP). It lists the exact components created (baseCOMP, 'data' source, conversions, Scale, chart, Null) and names the output structure, making it distinct from sibling creation tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use (when you need a data-driven visualization chart) and includes a critical workflow instruction ('Wire your real data into the created 'data' node'). However, it doesn't explicitly contrast with alternatives like create_waveform or create_histogram_scope, so the guidance is clear but not fully exclusions-focused.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_ditherA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses the full side-effect profile: it creates a new baseCOMP containing a source, GLSL TOP with inline shader, and Null output; exposes live knobs; returns summary/paths/controls/preview; and explains the optional self-contained noise source with no device permissions. This exceeds the baseline for mutation tools.

  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?

  Four dense sentences, each carrying essential information: effect type, palette modes, node structure, dynamic controls, and return payload. No redundant phrasing or filler; front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex 12-parameter creation tool with no output schema, the description effectively covers what gets created, how it behaves, and what is returned. It also notes the self-contained noise source fallback. This gives an agent a complete mental model for invocation.

  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?

  Input schema has 100% coverage with detailed descriptions for all 12 parameters, so the description need not restate them. It adds high-level context (e.g., '2/4/16-colour palette' maps to bits, 'Mix, Threshold, and Scale knobs' map to parameters) without introducing new meaning per parameter. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Build a retro dither effect' using a specific verb and resource, enumerates supported patterns (Bayer, checker, noise, error-diffusion) and palette modes, and lists concrete node outputs. This clearly distinguishes it from visual-effect siblings like create_halftone or create_glitch.

  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 clear context that this tool is for creating a dither effect and describes the resulting node structure and interactive knobs, implying when to use it. However, it does not explicitly name alternatives or exclusions, though the specificity of 'retro dither effect' is enough to differentiate from sibling creation tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_envelope_followerA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes well beyond the annotations: explains the internal chain (Select/Lag/Logic+Math/Null CHOPs), optional expression binding to target parameters, and warns about UNVERIFIED Logic CHOP par names and gate reading near 0 at default threshold. This is valuable practical 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 dense and information-rich, with a clear front-loaded purpose. The first sentence is long and contains multiple clauses, but every piece of information (modes, components, binding, limitations, alternative) earns its place.

  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?

  Covers purpose, internal build, modes, optional binding, experimental caveats, and a simpler alternative. Does not explicitly mention the return value or container path output, but for a creation tool this is reasonably inferable from the parent_path and name parameters.

  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 covers 100% of parameters, but the description adds extra meaning by explaining gate vs duck mode behavior and highlighting the threshold's real-world tuning pitfalls ('gate reads near 0 at the 0.2 default... tune threshold live'), which is not fully captured 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?

  Description uses the specific verb 'Build' with a clear resource ('reactive signal-shaping chain from a CHOP channel') and explicitly names the use case ('pump the whole layer on every kick'). It also distinguishes from the sibling bind_to_channel tool by pointing to a simpler alternative.

  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 states when to use this tool (sidechain pumping/ducking) and explicitly recommends an alternative ('Use bind_to_channel with attack/release for a simpler Lag-only envelope without a gate'). It lacks exhaustive when-not-to-use guidance but provides strong contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_feedback_tunnelA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly=false, openWorld=true, destructive=false), the description discloses the precise node topology, the built-in seed fallback, and the return payload including node errors. It also notes that fixed resolution prevents feedback runaway, which is useful behavioral context. The description does not explicitly mention any side effects or permissions, but given annotations already set the safety profile, the additional detail is valuable.

  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 front-loaded with the essential purpose and uses each subsequent sentence to add substantive detail: controls, seed fallback, topology, return value, and sibling differentiation. It is detailed but not redundant, and every sentence contributes to understanding the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description explicitly lists the return payload (summary, paths, controls, errors, preview image), which is critical for usage. It also covers the input handling, network topology, and the relationship to a sibling tool. Together with the detailed parameter schema and annotations, this is a complete and self-sufficient 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?

  With 88% schema coverage, the input schema already documents parameter meanings in detail. The description adds only marginal semantic value by mentioning that Zoom, Rotate, HueShift, and Decay are audio-bind-ready and mapping them to the topology (e.g., transformTOP for zoom, levelTOP for decay/hue shift), but it does not explain individual parameter syntax beyond what the schema provides. The baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Build a parameterized infinite-zoom/rotate feedback tunnel,' which clearly states the action (build) and resource (feedback tunnel). It also distinguishes itself from the sibling tool by ending with 'This is the fixed zoom-and-rotate spiral preset; ... use create_feedback_network instead,' explicitly naming the alternative for a different use case.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance by stating this is for the fixed zoom-and-rotate spiral preset and directing users to create_feedback_network for general feedback loops with arbitrary chains of effects. It also implies a use case for live performance with audio-bind-ready controls and a quick-start scenario via the built-in noise seed when no source is provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_generative_artA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses rich behavior beyond annotations: technique-specific implementation paths, fallback warnings, Speed knob exposure (except for recipe-built techniques), and the exact return structure including JSON block, errors, and inline preview. This far exceeds the annotation hints (readOnly=false, openWorld=true, destructive=false).

  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?

  Three sentences, front-loaded with the core action, each sentence earning its place: what it creates, technique variations, and return value. No filler, appropriately sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 9 techniques, fallbacks, exposed controls, and a detailed return payload, the description fully covers creation behavior, technique limitations, knob behavior, and output structure. No output schema exists, but the description adequately compensates.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, with detailed descriptions for all six parameters. The tool description largely repeats schema content (e.g., technique behavior and evolution_speed as the 'Speed' knob) without adding new parameter-level meaning, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Opens with a specific verb and resource: 'Create an evolving generative visual.' Clearly states it creates a baseCOMP under parent_path with specific generator structures and technique behaviors, distinguishing it from sibling create_* tools by covering multiple generative methods in one container.

  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 context on when to use it by describing which techniques produce real GLSL vs fallback to animated noise (with warning). However, it does not explicitly name alternative tools for specialized techniques like create_reaction_diffusion, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_halftoneA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses side effects far beyond the minimal annotations: it creates a new baseCOMP under `parent_path`, pulls in sources via a Select TOP, uses inline GLSL, exposes knobs, and returns a summary plus JSON block with paths, errors, warnings, and a preview image. It also explicitly notes 'no device permissions' for the standalone source.

  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 front-loaded with purpose and then flows logically through node creation, source handling, exposed knobs, and return value. Every sentence contributes information without redundancy, and length is justified by the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of an output schema, the description fully compensates by explaining the return payload: summary plus JSON with container path, created node paths, output path, exposed controls, errors, warnings, and inline preview. It also covers both input modes and side effects, leaving no major gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 8 parameters with detailed descriptions, including enum semantics for `style`. The description adds minimal new parameter meaning—mostly recapping that Mix, DotSize, and Angle are exposed as knobs. With 100% schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('Build a print/comic print-look effect') and clearly states the tool's scope: halftone dots, CMYK separation, ordered dithering, or posterized stepped colour in one GLSL pass. It distinguishes itself from siblings by naming the exact node structure (baseCOMP, GLSL TOP, Null output) and the optional source input.

  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 explicitly explains when to use a `source` (to stylise an existing TOP) versus omitting it (self-contained animated noise source with no device permissions). It implies usage for retro print looks, but does not name alternative tools directly. This is clear context without formal exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_llm_chainA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond annotations by disclosing side effects (creates baseCOMP, writes API keys into headers tableDAT), network behavior (POSTs JSON to endpoints), security properties ('MCP server never sees them'), and prerequisites. It even includes verification status ('verified live TD 099') and explicitly flags unverified aspects ('dotsimulate TOX par names are UNVERIFIED'). This is exemplary transparency.

  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 appropriately lengthy for a 14-parameter tool but every sentence serves a purpose: mode explanation, defaults, security, return values, and technical caveats. It is front-loaded with the main action and then logically organized. No filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity, no output schema, and rich annotations, the description is remarkably complete. It lists return values (container_path, prompt_dat_path, response_dat_path, status_chan, etc.), explains both modes, covers provider-specific behaviors, and flags unverified parts. The agent has enough context to invoke the tool correctly and set expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds some context not in the schema, such as the offline nature of the default provider and that custom provider requires endpoint_url and model, but these are also partially in the schema descriptions. It adds implementation details like 'webclientDAT uses reqmethod/url/includeheader' but those are not parameter semantics. The added value over the schema is marginal, so a 3 is warranted.

  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: 'Stand up a prompt → response LLM chain inside TouchDesigner as a self-contained baseCOMP.' It distinguishes two modes (webclient and tox_drop) with specific implementation details, making it unique from siblings like create_voice_prompt_pipeline or connect_huggingface_inference_bridge. The verb 'stand up' is specific and the resource (LLM chain) is well-defined.

  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 when-to-use guidance by outlining two modes with their prerequisites: webclient for any OpenAI-compatible endpoint, tox_drop requiring the dotsimulate TOX installed locally. It also notes the default provider (ollama) is fully offline with no key, and mentions requirements like 'Ollama requires ollama serve running on 127.0.0.1:11434.' However, it does not explicitly compare against alternative tools or state when not to use this tool, so a 4 is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_look_bankA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the sparse annotations (readOnly=false, openWorld=true, destructive=false), the description adds crucial behavioral details: 'Pulses and strings are always skipped at capture', recall 'behaves exactly like a cue morph', and slots are mirrored into the COMP's cues. It also mentions the visible/editable Table DAT and the momentary recall button behavior, providing substantial transparency beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a dense single paragraph but front-loaded with the core concept ('A playable snapshot row') and every clause adds useful information. It is concise relative to the tool's complexity, though it could be restructured with bullets for even easier parsing. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 10 parameters and no output schema, the description covers the main capabilities: building, storing, recalling, morphing, interop with manage_cue/create_control_surface, and the prerequisite of building with create_control_panel. It does not explicitly mention the list/delete actions, but those are self-explanatory from the schema's action enum. Overall, it provides enough context for correct usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful context on top: it clarifies that pulses/strings are always skipped (impacting the `include` parameter), that recall behaves like a cue morph with optional beat/bar quantize (for `quantize` and `morph_seconds`), and that `comp_path` should point to a control-panel container built with create_control_panel. This goes beyond the schema descriptions, though it doesn't independently explain every parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's purpose: it creates a playable snapshot row (look bank) that stores named looks of a control COMP's parameters, with recall buttons and an A/B morph knob. It is specific about the resource (control COMP) and distinguishes from siblings by explicitly referencing reuse of manage_cue's morph engine and interoperability with manage_cue/create_control_surface.

  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 on usage: it tells users to build cues/params with create_control_panel first, and explains how this tool relates to manage_cue and create_control_surface. However, it lacks explicit exclusions or direct comparisons with alternative tools like manage_presets or create_preset_morph, so it doesn't fully earn a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_modulatorsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  It discloses destructive re-run behavior ('rebuilds it in place, clearing that container's children'), timeline dependency ('only move while the timeline is playing'), tempo-lock expression behavior, and output structure (one Null CHOP with named channels). This goes well beyond the annotations, which only declare destructive=true and readOnly=false.

  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 dense paragraph that front-loads the core purpose and then efficiently covers output, tempo behavior, timeline constraint, and destructive re-run. No sentence is filler; each adds critical information for correct invocation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (6 params, no output schema), the description covers return shape (Null CHOP 'mod_out'), integration with bind_to_channel, destructive consequences, and runtime constraints. It is complete enough for an agent to select and invoke correctly.

  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% coverage for all 6 parameters, so the baseline is 3. The description adds some narrative context around rate_beats and phase ('stays phase-continuous'), but it mostly restates what the schema already documents for each parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Build a bank of N BPM-synced LFOs in one self-contained container.' It clearly distinguishes this from sibling tools like create_tempo_sync by describing the LFO bank, per-modulator outputs, and the single Null CHOP it produces.

  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 frames the tool as the 'everything breathes' lever and mentions readiness for bind_to_channel, implying a use case for animation/modulation needs. It does not explicitly name alternatives or say when not to use it, but it gives clear context about timeline-driven behavior and tempo locking.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_panicA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the destructiveHint annotation by explaining exactly how Blackout (Level TOP brightness1 = 0) and Freeze (Cache TOP active = 0) are implemented, why it's destructive, and the return value. It also discloses internal construction details (Select TOP, Ramp TOP, Null TOP) that are not in annotations or schema.

  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 paragraph that front-loads the purpose, then systematically explains the mechanics, modes, output, and return values. Every sentence earns its place without redundancy, making it concise despite its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity and lack of an output schema, the description is fully complete: it explains the internal node graph, the two input modes, the destructive consequences, the exposed controls, and explicitly lists the returned node paths and toggle states. No important behavior is left unexplained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers all 5 parameters with detailed descriptions (100% coverage). The tool description adds context about how input_path works and the test source, but does not add per-parameter meaning 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 builds a live-performance safety control ('oh no' button) with Blackout and Freeze switches, distinguishing it from generic control creation tools like create_control_surface or create_safety_blackout_chain. The specific verb 'Build' and the detailed COMP structure make 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies a clear use case (live-performance safety) and explains the input_path vs. standalone test source mode. However, it does not explicitly contrast with alternative tools like create_safety_blackout_chain or state when not to use it, so it falls short of full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_phone_gestureA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are minimal (readOnlyHint false, openWorldHint true), but the description adds crucial behavioral context: it builds a Web Server DAT, exposes specific channels, listens on all interfaces with no auth, and requires HTTPS for iOS motion permission with a fallback to touch-only. This fully discloses side effects, security implications, and platform limitations.

  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?

  Four sentences are efficiently packed: action, result, composability, security, and platform note. No waste, front-loaded with the core function, and all additional details earn their place. Perfectly sized for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description sufficiently covers what the tool creates (Web Server DAT, Null CHOP), the channels produced, security posture, and platform-specific behavior. It is complete enough for an agent to understand the tool's full impact and prerequisites. No ambiguity about return values since the tool builds visible operators.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with descriptive parameter explanations, so the baseline is 3. The description adds the channel names (tilt_x/y/z, etc.) which helps understand the enableImu parameter, but this is a minor addition since the schema already explains each parameter's role. The description's value here is supplemental, not essential.

  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 purpose: stream phone IMU and multitouch into TouchDesigner as CHOP channels. It explicitly names the output channels and distinguishes itself from create_phone_remote by noting composability on the same COMP with a different port.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage context ('bind to anything', any browser, no app) and mentions composability with create_phone_remote, but it does not explicitly state when to choose this tool over alternatives or provide exclusionary guidance. The composability note helps but lacks direct 'use this when...' language.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_phrase_locked_cue_engineA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only declare readOnlyHint=false and openWorldHint=true, so the description carries the burden of explaining behavior. It does so richly: FIFO queueing, firing on phrase boundaries, live controls (Active, PhraseLength, Flush, QueueDepth), mode semantics, and the exact output path (0/1 trigger Null CHOP at <container>/out). No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only four sentences but packs a comprehensive overview: what it does, input sources, queue behavior, live controls, mode options, integration points, and output. Every sentence earns its place, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (7 params, no output schema, rich integration context), the description is highly complete. It explains the input trigger types, the queue and firing mechanism, the live controls, mode differences, upstream/downstream pairs, and the output path. Combined with the detailed schema, this is sufficient for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already having detailed descriptions. The tool description adds context by explaining how parameters relate to the overall behavior (e.g., queue_capacity with FIFO, expose_controls with live controls), but this is complementary rather than essential. Baseline 3 is appropriate given the schema does the heavy lifting.

  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 it 'Build a DJ/VJ phrase-quantized cue-lock engine' with a specific verb and resource. It distinguishes itself from siblings by detailing the FIFO queueing and phrase-boundary firing behavior, and even names upstream/downstream companion tools (create_tempo_sync, bind_to_channel, manage_cue), leaving no ambiguity about its specialized role.

  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 it: for phrase-quantized cue locking in DJ/VJ workflows. It explains the two modes ('next' vs 'aligned') to help users choose. It names integration points but does not explicitly state exclusions or alternatives (e.g., 'use this instead of create_beat_grid_sequencer'), so it falls short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_preset_morphA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly=false, destructive=false), the description discloses a rich set of behavioral traits: snapshotting into slots, internal normalization of weights, use of Lag CHOP + Lookup curve, exposure on a Null CHOP for bind_to_channel consumers, and the paused-timeline limitation. This goes far beyond what annotations provide and helps the agent anticipate side effects and constraints.

  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 front-loaded with the core concept and uses four dense sentences that each carry substantive information. It is appropriately sized for the tool's complexity, though it packs many technical terms into a compact space. No filler or 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?

  Given the tool's complexity (10 params, nested objects, no output schema), the description gives a strong conceptual and architectural overview, including key limitations. However, it does not explicitly state what the tool returns (e.g., path/status), which is a minor completeness gap for an agent expecting to consume the result. Still, the volume of contextual detail is high.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers 100% of parameters with detailed inline descriptions, so the baseline is 3. The description adds contextual architecture (Lag CHOP, Lookup curve, Null CHOP) but does not add new per-parameter meanings beyond what the schema already states. It reinforces the overall workflow but doesn't elevate parameter understanding further.

  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 'Target-agnostic preset morph engine' and immediately specifies the resource (any OP's animatable parameters), the action (snapshot into N named slots, blend with weight vector or A↔B recall), and the output (exposed on a Null CHOP). It distinctly differentiates from create_look_bank by contrasting scope and weight-count support, making the tool's purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names create_look_bank as an alternative and clarifies when this tool is appropriate ('Unlike create_look_bank … this drives any OP and supports >2 simultaneous weights'). It also points to reuse of manage_cue's MORPH_HOOK for quantized recall, and adds a critical caveat about Lag CHOP not advancing while the timeline is paused, effectively giving both when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_raytk_sceneA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds practical behavioral context: it copies masters at runtime, requires RayTK to be loaded, and 'fails forward' with guidance when the library is absent. This is useful and non-contradictory. It doesn't cover every side effect, but annotations already handle the safety profile.

  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?

  Three tightly packed sentences with no filler. Each sentence carries distinct value: what is built, how it relates to a sibling, and prerequisites/failure behavior. Front-loaded with the primary action and chain.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description covers prerequisites (RayTK staged + loaded), version compatibility (RayTK 0.46 requires TD 2025.30770+), failure behavior ('fails forward' guidance), and the alternative tool. For a creation tool with rich schema coverage, this is 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?

  Schema coverage is 100% and every parameter has a description. The description additionally maps 'optional flags union a second SDF, insert an inline basicMat, and add an explicit lookAtCamera / pointLight' to the union_with, material, add_camera, and add_light parameters, enriching the node-graph context beyond the raw 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 provides a specific verb ('Build') and resource ('minimal renderable RayTK node graph') with an explicit node chain (sphereSdf → raymarchRender3D → Null TOP). It also differentiates from the sibling create_raymarch_scene by calling itself the 'node-graph-native complement' to that lightweight GLSL path.

  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?

  It clearly situates when this tool is appropriate (node-graph-native RayTK approach, in contrast to create_raymarch_scene's lightweight GLSL path) and gives a concrete prerequisite ('Requires the RayTK toolkit staged + loaded'). However, it does not explicitly state exclusions (e.g., 'don't use if you don't need RayTK masters') beyond the complement framing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_show_failoverA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) are minimal, but the description adds substantial behavioral detail: the exact chain of operators (Switch TOP, Filter CHOP, Info CHOP), how stall detection works (total_cooks delta), sticky-recover logic, and what happens when no primary or fallback is provided (noiseTOP/constantTOP). It also discloses the controls exposed and return values, going far beyond the annotation booleans.

  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 dense but purposeful. The first sentence establishes the core purpose, and subsequent sentences explain the mechanism, controls, and return values. No sentence is wasted; each adds specific technical detail (e.g., 'blend=1 cross-dissolve', 'total_cooks delta', 'Filter CHOP smooths') that helps an agent understand the tool's behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 explicitly states what is returned ('container, output TOP, status CHOP, control names, operator paths'). It covers major behavioral aspects including defaults (noiseTOP/constantTOP), sticky-recover, error watching, and exposed controls. Given the complexity of the 9-parameter system, the description provides a complete and intelligible overview.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter already having a detailed description. The tool description does not add new per-parameter semantics but does mention some parameters (fade_ms, stall_ms, sticky_recover) within the overall system context, reinforcing their role. This matches the baseline of 3 for full 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 opens with 'Build a live-show watchdog' which is a specific verb+resource, and immediately distinguishes this tool from siblings like create_safety_blackout_chain or create_panic by detailing the failover mechanism (Switch TOP, Info CHOP, watchdog CHOP-Execute). It clearly states what the tool produces: a container, output TOP, status CHOP, control names, and operator paths.

  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 the use case: creating an automatic failover system for live shows that detects cook stalls and optionally primary errors. It explains the behavior and controls, giving context on when it would be relevant. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_slit_scanA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes well beyond annotations by disclosing critical limitations: GLSL compile is unverified offline, cacheTOP binding must be validated live, memory cost scaling (depth × 32 MB at 1080p), and output freezes when timeline pauses. This is exactly the kind of behavioral nuance an agent needs and adds substantial value over the annotations, which only state it is not read-only and not destructive.

  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 dense yet efficiently structured. Every sentence delivers specific, non-redundant information: mechanism, components, headless behavior, exposed knob, verification warnings, memory costs, pause behavior, and return value. It is front-loaded with the core purpose and maintains clarity throughout.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 7 parameters and no output schema, the description is exceptionally complete. It explains the internal architecture, return value shape, runtime pitfalls, and resource requirements. No significant gaps remain for an agent to safely invoke and interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so parameters are already well-documented. The description adds a bit of extra context (e.g., 'Depth' knob binding to cache.cachesize, memory formula for cache_depth) but mostly repeats or paraphrases schema descriptions. It does not significantly deepen understanding beyond the schema, hence baseline 3.

  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 a clear, specific verb ('Build a slit-scan visual system') and explains the mechanics (row/column samples past frames from a Cache TOP ring buffer). It distinguishes itself from sibling creation tools by naming the exact technique and visual style (Floris Kaayk / Adam Magyar), making its 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is clearly described: it is the tool for creating slit-scan looks, and it explicitly notes it works headless/CI when no source_top_path is given. However, it does not name alternative tools for similar effects (e.g., create_time_echo), so it lacks explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_spectrumA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already state readOnlyHint=false and openWorldHint=true, so creation is expected. The description adds valuable context: it may trigger a macOS microphone-permission dialog, exposes channels in a specific naming pattern, includes a Sensitivity knob (if expose_controls is true), and supports multiple audio source types. This goes beyond the annotation-derived baseline and surfaces non-obvious side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but not verbose. It packs a clear definition, a usage example, a sensitivity knob note, source options, a security caution, and sibling tool guidance into one compact paragraph. Every sentence contributes a distinct piece of information, and the opening sentence immediately answers 'what does it do?'.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Because there is no output schema, the description fully covers what the agent will get: a Null CHOP with band0..band{N-1} channels, how to bind them (via op('…/spectrum/spectrum')['band0']), what the Sensitivity knob does, the four source modes, and a macOS permission caveat. It also positions the tool relative to its siblings, making the context complete for selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a descriptive comment (e.g., bands, source, parent_path). The description reinforces the bands/channel naming and shows a binding example, but it doesn't add meaning beyond the schema's existing parameter descriptions. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb ('Build an FFT audio-spectrum analyzer') and includes the concrete deliverable: N bindable frequency-bin channels (band0..band{N-1}) on a Null CHOP. It also names sibling tools and explicitly frames itself as the per-band complement, making differentiation clear from the outset.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-to-use vs alternatives: 'Use extract_audio_features when you want coarse level/bass/mid/treble bands instead of N fine bins, create_audio_reactive for a ready-made spectrum visual, and feed this Null into bind_audio_reactive to drive a COMP.' This is textbook usage guidance—it tells the agent when to choose this tool versus its siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_strange_attractorA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds substantial behavioral context beyond this: time-dependent integration, rolling ring buffer, optional Tube SOP, deterministic CPU-geometry idiom, and exact return fields including 'errors, warnings, and an inline preview.' There is no contradiction with 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 about 100 words and densely informative. It covers the architecture, rendering pipeline, relationship to sibling tools, critical temporal behavior, and return value format without fluff. Each sentence adds value, 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.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 13 parameters with complete schema descriptions, solid annotations, and no output schema, the description compensates well. It explains the full pipeline (CHOP -> SOP -> Tube -> render), the deterministic CPU-geometry context, timeline sensitivity, and exactly what the tool returns (summary plus JSON block with container path, output path, controls, errors, warnings, inline preview). This is comprehensive for an agent to select and invoke correctly.

  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% coverage with all parameters described in detail, including defaults, bounds, and specific meanings (e.g., dt, trail_length, attractor). The description only briefly mentions 'configurable sub-steps' and 'trail_length' without adding new semantic depth beyond the schema. With full schema coverage, the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states its purpose: 'Build a strange-attractor deferred geometry generator' with specific implementation details (Script CHOP, Script SOP, optional Tube SOP). It distinguishes itself from sibling tools by explicitly naming create_growth_system and create_particle_flock as complements, making it clear what this tool does and how it relates to others.

  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 context and alternatives: 'Complements create_growth_system (L-systems) and create_particle_flock (boids) as the deterministic CPU-geometry idiom.' It also notes time-dependent behavior ('With TD timeline paused the integrator pauses too'), which helps the agent decide when this tool is appropriate. However, it does not explicitly state when not to use it, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_text_3dA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly=false, destructive=false), the description discloses the exact node chain (Text SOP, Extrude SOP, Geometry COMP, Constant MAT, Camera, Light, Render TOP, Null TOP), the spin expression on ry, and the return format including summary, JSON fields, and inline preview. This is rich behavioral context; only minor omissions (e.g., failure/overwrite behavior) keep it from a 5.

  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 efficiently packed—each sentence covers a distinct facet: pipeline construction, spin behavior, live knobs, use cases/alternative, and return value. No redundant phrases, and the primary purpose is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 params and no output schema, the description carries the responsibility of explaining return values and internal behavior. It states the JSON structure (container path, node paths, controls, errors, warnings, preview) and the use-case context, making it complete for effective tool selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: primarily that Spin and Depth are exposed as live knobs. Other parameter details (depth controls depthscale, spin drives ry) are already present in the property descriptions, so no significant compensation needed.

  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 'Build a self-contained 3D text scene' and enumerates the full node pipeline, so the verb and resource are specific. It also explicitly distinguishes itself from create_kinetic_text, making sibling differentiation unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description directly names the alternative: 'use create_kinetic_text instead for flat 2D animated text.' It also provides typical use cases ('title cards, lyric reveals, and 3D text drops'), giving agents both when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_text_crawlA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=false and destructiveHint=false, which align with the description's 'Build' action. The description adds valuable context beyond annotations: it explains internal implementation (textTOP, transformTOP, EXPRESSION parameter), the looping behavior, the 'out' nullTOP handle, and explicitly flags risks for typewriter mode ('EXPERIMENTAL — unverified') and bg_alpha par probing ('UNVERIFIED'). This transparency about potential instability is exemplary.

  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 detailed but dense, covering modes, mechanism, loop behavior, output handle, sibling differentiation, and return format. While longer than typical, every sentence contributes useful operational information. It is organized from high-level purpose to implementation to differentiation, though a slight rewrite could tighten the technical explanation.

  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 11 parameters and no output schema, the description compensates well by explaining internal topology, output handle, and return JSON structure. It covers key behavioral aspects like continuous wrapping and the experimental typewriter mode. Minor gap: no explicit example or mention of typical resolution/defaults, but overall it is complete enough 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?

  Schema coverage is 100%, providing baseline 3. The description adds meaning by explaining the role of mode (three animation styles) and loop (continuous vs one-shot), and by describing the return JSON fields. It also clarifies semantic nuances like 'speed is a fraction of output resolution per second' and 'use \n to separate lines', which go beyond individual parameter descriptions.

  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: 'Build a multi-line animated text crawl / ticker / credits roll / typewriter reveal inside a self-contained baseCOMP.' It enumerates three specific modes (crawl_horizontal, roll_vertical, typewriter) and explicitly differentiates from sibling tools create_kinetic_text and create_text_overlay. The verb 'build' plus the resource (baseCOMP) makes the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance: 'Differs from create_kinetic_text (single-string flash/pulse/slide) and create_text_overlay (a static, non-moving caption/title); this tool handles multi-line copy, continuous scrolling, and character-reveal.' It also explains how each mode is used (e.g., roll_vertical uses \n to separate lines) and notes the loop behavior for continuous scrolling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_two_way_surfaceA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the minimal annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false). It discloses the internal Script CHOP gate mechanism, epsilon delta and rate-limit throttling, the last_in cache, and the custom parameters (Bypass, Globaleps, Ratehz, Reseccache) exposed on the container. This gives the agent a detailed picture of side effects and configurability.

  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 three sentences long but information-dense. It front-loads the core purpose, then explains the guard mechanism and exposed custom parameters. Every sentence earns its place with no padding or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (9 params, no output schema), the description covers the construction purpose, bidirectional behavior, oscillation guard mechanics, and container-level custom parameters. This is sufficient for an agent to understand what the tool creates and how it behaves, especially with the rich schema descriptions for all parameters.

  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 has 100% coverage with descriptive parameter docs, so the baseline is 3. The description adds only a high-level nod to epsilon delta and rate limit, which are already defined in schema, and does not elaborate on individual parameter semantics beyond what schema provides. Thus it does not significantly augment the schema's information.

  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 a specific verb and resource: 'Build a bidirectional OSC or MIDI control surface that drives TouchDesigner params from a controller AND echoes outgoing changes back to it.' It clearly distinguishes from sibling tools like create_control_surface by emphasizing two-way communication and the feedback guard. The title reinforces the same, 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly establishes the use case: bidirectional control with echo, such as motor faders and RGB pads, and explains why the oscillation guard is necessary to prevent ping-pong. However, it does not explicitly name alternatives or state when not to use this tool, though the context strongly implies that unidirectional surfaces would be better handled by other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• diff_library_assetsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate those. It adds useful behavioral context: offline operation, no TouchDesigner interaction, and detailed output behavior (added/removed keys, old-to-new values, recipe-level diffs of nodes/params/connections). No contradiction; a slight gap is that error handling or file-access prerequisites are not mentioned.

  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?

  Three efficient sentences with no filler. The first sentence front-loads the core purpose, the second covers output behavior, and the third gives an alternative tool. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the annotations (read-only, open-world, non-destructive) and presence of an output schema, the description sufficiently covers the tool's complete behavior: what it operates on, what it reports, and when to use a sibling. It is a well-rounded, self-contained description for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the description is not required to explain parameters. It adds a bit of context by listing asset types in the description, but the mode enum descriptions already cover recipe-aware diffing, so it provides little beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it performs an offline deep diff of two saved library assets on disk, listing specific asset types (recipe JSONs, component manifests, serialize-network spec JSONs). It distinguishes itself from diff_snapshots for live TD graphs, providing a specific verb+resource and unique scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly names the alternative tool: 'Use diff_snapshots to compare two live TD graphs.' Also states 'Does not touch TouchDesigner,' making the offline/online distinction clear and telling the agent when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• document_networkA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, so the read-only nature is known, but the description adds valuable behavioral context: it reads nodes/connections and returns counts plus a Mermaid flowchart. It also clarifies scope (existing network) and that it does not plan or create. This goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each earning its place: first defines the function and output, second contrasts with a sibling tool, third gives a clear use case. No filler words, well front-loaded with the core action and deliverable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With only two parameters, no output schema, and readOnly annotations, the description fully explains what the tool returns (readable map with counts and Mermaid flowchart), what it operates on (existing network), and when to use it (explain/hand off a patch). No missing information for a tool of this complexity.

  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 both parameters (path with default and description, recursive with default and description). The description adds no parameter-specific detail, but the schema handles that burden. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it documents an existing network by reading nodes and connections and returning a readable map with counts by operator family/type plus a Mermaid flowchart. Explicitly distinguishes itself from the sibling plan_visual by focusing on the actual project state rather than a plan.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Gives explicit comparison with plan_visual: 'Unlike plan_visual (which plans from a description), this describes what's actually in the project.' Also names concrete use cases: 'Use it to explain or hand off a patch.' This tells the agent exactly when to choose this tool over the alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• execute_python_scriptA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag readOnlyHint=false and destructiveHint=true. The description adds valuable context that code runs only in TD and never on the local machine, which is a meaningful behavioral boundary. It does not restate the safety flags but adds execution-scope context, earning above 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?

  Two sentences with zero filler. The first sentence states purpose, the second provides usage guidance and execution context. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a generic escape-hatch tool, the description fully covers purpose, when-to-use, execution environment, and safety boundaries. The rich annotations and complete schema fill remaining gaps, so nothing essential is 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?

  Schema provides 100% parameter coverage with descriptions for 'script' and 'return_output', including a default. The description does not add parameter-level detail, but the schema already carries that burden, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('run') and names the resource ('arbitrary Python script inside the TouchDesigner process'). It clearly distinguishes itself from siblings by labeling it an 'escape hatch' and pointing to structured tools, making its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use this tool ('reach for this only when no structured tool can express the operation') and names concrete alternative structured tools. This is exemplary guidance for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_sop_to_svgA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations by detailing the internal process: 'each primitive becomes one <polyline>', projection to x/y, viewBox auto-fit, and the guarantee to 'always return the SVG string in the report'. It also explicitly discloses the disk write side effect, aligning with the destructiveHint annotation. No contradictions.

  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 first sentence states the core action, follow-up sentences add projection, styling, output behavior, and use case. Every sentence contributes value without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description adequately explains what is returned ('SVG string in the report') and the optional side effect. It covers the transformation logic, styling options, and target applications. This is sufficient for an agent to select and invoke the tool confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a detailed description. The tool description references parameters (stroke/fill/scale/flip_y) and the output_path condition, but adds no significant new semantic meaning beyond what the schema already provides. It stays at the baseline for complete 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 opens with a specific verb and resource: 'Walk a SOP's primitives... emit an SVG document of polylines'. It clearly distinguishes this from other export tools (e.g., export_recipe_bundle, export_look_tox) by explicitly naming SVG output and SOP geometry. Details like 'Projects to x/y (drops z)' further refine the scope.

  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 by ending with 'Pen-plotter / laser / print deliverable', indicating the intended use cases. It also explains the optional disk write behavior with output_path. However, it does not explicitly exclude alternative tools or state when not to use it, so a small gap remains for a perfect 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• extract_paletteA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only; no nodes are created or modified.' It adds useful behavioral details like the deterministic nature of k-means and the sorting by dominance, which go beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise (three sentences), front-loaded with the core action, and efficiently packs method, return format, and use cases without unnecessary filler. Every sentence contributes meaningful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description fully specifies the return object structure and sorting order, making the tool's behavior and outputs clear. The read-only nature is stated, and the use cases provide sufficient context for an agent to decide when to invoke it.

  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 covers all parameters at 100%, but the description adds value by explaining the rendering process (e.g., 'smaller is faster' for width/height) and how the parameters relate to the output (k colors, dimensions). This exceeds the baseline of 3 for full 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 samples dominant colors from a TOP using a specific method (capturing preview PNG and running deterministic k-means). It distinguishes itself from siblings like create_palette and get_preview by focusing on extraction from an existing TOP.

  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 mentions concrete use cases ('Feeds AI grading prompts, create_palette, and design hand-offs'), giving clear context for when to use it. It does not explicitly contrast with alternatives or say when not to use it, but the intended usage is well implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• find_td_parametersA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint and destructiveHint annotations, the description adds critical behavioral details: values are point-in-time snapshots, likely secrets are redacted and cannot satisfy filters, and the scan_truncated/count_complete fields must be inspected for completeness. It also states the prerequisite of the current structured bridge route and that it never falls back to raw Python or a full dump. This substantially enriches the agent's understanding.

  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, front-loaded with 'Read-only' and a clear purpose, and every sentence adds value—covering scope, constraints, limitations, and usage tips. No redundant or repetitive content is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (17 parameters, live system interaction, output schema present), the description covers all key aspects: what it searches for, the bounded/read-only nature, point-in-time semantics, redaction, completeness checks, prerequisites, and the guarantee of not falling back to raw Python. The output schema handles return-value details, so the description is sufficiently complete for effective use.

  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 53%, so the description is not fully responsible for parameter semantics. The description summarizes the searchable dimensions (node, type/family, parameter name, value, expression, mode, non-default state) which maps to several parameters, but it does not clarify the semantics of parameters like time_budget_ms, node_scan_limit, parameter_scan_limit, limit, or type_match. These remain only partially understood from names and defaults, so the description only partially compensates for the coverage gap.

  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 ('search') and resource ('live TouchDesigner parameters'), and enumerates the filter dimensions ('node, operator type/family, parameter name, evaluated value, expression, mode, or non-default state'). It clearly differentiates from siblings like get_td_node_parameters by framing it as a bounded search rather than a full listing, and explicitly states it never falls back to raw Python or a full parameter dump.

  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: it is a read-only, bounded search for live parameters, and advises to inspect scan_truncated and count_complete before claiming project-wide completeness. It implicitly discourages using raw Python or full parameter dumps, but it does not explicitly name alternative tools like get_td_node_parameters or specify 'use this when you need to search by criteria rather than list all.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_bridge_logsA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds meaningful behavior beyond the readOnlyHint annotation: guaranteed walking of the operator tree, best-effort probe of textport/log DATs, and probe reporting which log sources are reachable. Consistent with annotations and no contradiction.

  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?

  Four dense sentences front-load purpose, then give behavior, use case, and return shape. Every sentence earns its place with no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Complete for a project-scope debugging read with good schema, annotations, and output schema. Explains guarantee vs best-effort, walk scope, and the probe return field; no significant gaps.

  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 covers all three parameters with full descriptions, so the schema already does the heavy lifting. Description adds no additional parameter-level meaning beyond the baseline 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?

  Specific verb+resource+scope: collects cook errors/warnings across the operator tree under `scope`, plus best-effort log DAT probe. Clearly distinguishes from narrower per-node error tools by project-wide scope and its guaranteed vs best-effort split.

  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?

  Explicitly states when to use: 'when a script or cook fails and you need more context than the immediate error string.' It also contrasts with needing a new REST endpoint, but it does not name sibling alternatives or give explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_module_helpA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate read-only, but the description adds context: offline knowledge base, return format with formatted text or {found:false, suggestions[]}. This goes beyond the structured fields. No contradictions.

  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 'Read-only', and contains no fluff. It efficiently conveys purpose, output, and alternative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema, the description adequately explains return values (formatted text or found:false with suggestions). It covers source (offline), scope (class/module), and alternative, making it complete for a single-param read-only 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?

  The only parameter 'name' is fully described in the schema with examples. The description adds no extra parameter semantics beyond what the schema provides, so the baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool provides human-readable Markdown help for TouchDesigner Python classes/modules from an offline knowledge base. It distinguishes from get_td_class_details by specifying the output format (Markdown vs structured JSON).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names get_td_class_details as the alternative when structured JSON is needed, and implies use for human-readable output. It also mentions the fallback behavior with suggestions for unknown names.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_parameter_menuA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description discloses valuable behavioral traits: values come live from the running build and are authoritative, dynamic menus are included, empty menuNames means not-populated-yet (not absence), requires TDMCP_BRIDGE_ALLOW_EXEC=1, and falls back to a bundled catalog with a stale-catalog warning. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with 'Read-only' and the primary function, then provides dense but necessary context: usage scenario, authoritative source, empty-menu interpretation, and environment requirement. Every sentence earns its place; no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for a read-only menu inspection tool. It explains what is returned, how to interpret results, environment prerequisites, fallback behavior, and dynamic menu nuances. With an output schema and annotations present, nothing essential is 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?

  Schema description coverage is 100%, so the input parameters (path, keys, menu_only) are already well documented. The description focuses on output semantics (menuNames, menuLabels, current) and behavior rather than adding new meaning to the input parameters. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's function: live-fetch menu option values, labels, and current selection for each menu parameter of a node. It uses specific verbs and identifies the resource ('menu parameter of a node'), distinguishing it from sibling tools like get_td_node_parameters which cover all parameters generically.

  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 explicitly instructs when to use the tool: 'Use this before setting a Menu / StrMenu parameter so you pick a valid option instead of guessing.' This is clear context, though it does not name alternative tools or state when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_class_detailsA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare read-only and non-destructive. The description adds valuable context: offline mode, return shape for unknown classes with {found:false, suggestions[]}, and the structured nature of the documentation. This 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?

  Three concise sentences, front-loaded with the read-only designation and core purpose. Each sentence adds distinct value: what it returns, behavior for unknown names, and guidance on the alternative tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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, the description fully covers purpose, return format, error behavior, offline operation, and the relevant alternative. No output schema exists, so the description adequately fills that gap by describing the return object.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with a clear description and examples for class_name. The tool description adds no extra parameter semantics beyond the schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('provides'), resource ('one TouchDesigner Python class'), and scope ('members + methods from embedded knowledge base'), clearly distinguishing it from the sibling get_module_help by contrasting structured JSON versus Markdown.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly names get_module_help as the alternative when Markdown is preferred, and implies this tool is for structured JSON output. This gives the agent a clear choice criterion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_classesA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and destructiveHint, and the description adds valuable context beyond that: it says the tool works offline and never touches TD, which is more specific than a generic read-only hint. It also discloses the return shape ({classes[]}), enhancing behavioral transparency.

  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 three sentences with no wasted words. It front-loads 'Read-only' and each sentence provides distinct value: purpose, behavior/return format, and alternative tool guidance.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 clear annotations, this description is complete. It covers what it does, safety profile (offline/read-only), return format, and how to proceed for more detail, without needing an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the single 'filter' parameter, which already includes a description ('case-insensitive substring'). The description's 'Optionally filter by name' adds minimal extra meaning, so the baseline of 3 is appropriate—schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists TouchDesigner Python API class names from the embedded knowledge base, with a specific verb ('list') and resource ('class names'). It also explicitly distinguishes from siblings by pointing to get_td_class_details and get_module_help for expansion, making its purpose unique.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance: use this tool for listing class names, and use get_td_class_details or get_module_help to expand a class into members/methods. It also notes that it works offline and never touches TD, giving clear context for when it's appropriate to invoke.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_tutorialA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly declares read-only behavior, matching the annotations, and adds valuable behavioral details: content cap (~30K chars), sections_available list, and section-based drilling. This goes beyond the annotation to set expectations for return content.

  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 sentences with no filler. The first sentence covers primary operations concisely; the second efficiently explains the include_content behavior and section guidance. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read-only retrieval tool with a rich output schema, the description covers the main usage modes and the special content-handling behavior. The only minor gap is explicit differentiation from similar sibling tools, but the description is otherwise 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?

  While the schema already documents all 5 parameters, the description adds the relationship between include_content and section, explaining the content cap and sections_available list. This enhances understanding beyond the schema's individual parameter descriptions.

  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 three concrete actions (list, search, retrieve) with a specific resource (embedded TouchDesigner tutorials) and notes retrieval by id/name. This distinguishes it from generic doc retrieval tools like get_td_docs.

  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?

  It explains when to use list, search, or retrieve modes and gives guidance on using include_content with section to avoid pulling full documents. However, it does not explicitly compare against sibling tools like get_td_docs or search_touchdesigner_knowledge.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• insert_operator_at_selectionA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description richly discloses behaviors beyond annotations: atomicity, compare-and-swap semantics, idempotency replay, bounded before/after connector receipts, rollback state, preservation of fan-out siblings, and the use of an authenticated bridge with ALLOW_EXEC=0. This far exceeds the minimal readOnly/destructive hints and accurately characterizes the tool's side effects and safety guarantees.

  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 three sentences, front-loaded with the core action in the first sentence, followed by essential constraints and safety details. Each sentence adds distinct value with no redundancy or filler, making it dense yet concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (atomic mutation with compare-and-swap, idempotency, rollback) and the presence of an output schema, the description is complete. It covers operation, prerequisites, return receipts, side effects, and execution model. No critical behavioral aspect is left unexplained.

  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 detailed descriptions for all 5 parameters (100% coverage), including type patterns, idempotency semantics, and expected_context requirements. The tool description reinforces the importance of idempotency_key and compare-and-swap but does not add substantial new parameter-level meaning beyond what the schema already documents, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Atomically insert one same-family operator on one deterministic downstream edge of the exactly selected/current TouchDesigner operator.' It specifies the verb, resource, and precise location, and distinguishes it from sibling tools like create_td_node or connect_nodes by emphasizing the atomic, context-compare, single-edge insertion.

  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?

  It provides clear context for use: requires an 'exact editor-context compare-and-swap' and an 'idempotency key', and explicitly contrasts with unsafe alternatives by stating 'it never invokes raw Python, mouse-interactive placeOPs, or implicit pane selection.' It does not name specific sibling alternatives, but the context is sufficient for an agent to infer when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• inspect_op_extensions_storageA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds valuable context beyond these: it notes return data is 'structured data for agent code-path consumption,' explains that 'API names vary by TD build,' and introduces the 'probe' field as a record of reachable attributes. This openly addresses the open-world variability hinted at by openWorldHint.

  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?

  Four sentences, front-loaded with the key safety qualifier 'Read-only', then listing the three inspection targets. Every sentence earns its place: usage guidance, return format, and API-variability caveat. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given four parameters, rich annotations, and an output schema, the description covers the essential context: what the tool does, when to use it (in the component-creation loop), what it returns, and the 'probe' fallback for varying API names. The output schema handles detailed return fields, so no further elaboration is needed.

  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% coverage with descriptive parameter comments, so the baseline is 3. The description restates some content (e.g., 'custom-parameter definitions (page/name/style/default)') but does not add new semantics about the path parameter or boolean flags beyond what the schema already provides. The mention of the 'probe' field concerns output, not 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 a specific verb ('inspect') and resource ('a COMP'), then specifies exactly what is inspected: Python storage dict, extension class descriptors, and custom-parameter definitions. This clearly distinguishes it from sibling tools like inspect_component_manifest or get_td_node_parameters by enumerating unique inspection targets.

  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 gives explicit when-to-use guidance: 'use after scaffold_extension + add_custom_parameters to verify what was built, or call standalone to examine any COMP without resorting to raw Python.' It does not name specific alternative sibling tools for exclusion, but the usage context and the 'without raw Python' note clarify positioning.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• install_library_packageA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behaviorbeyond annotations: it copies/extracts, refuses replacement unless overwrite=true, rejects symlinked directory trees, and returns scope plus resolved paths. Since destructiveHint=true, the overwrite refusal is consistent and enhances the safety profile. It doesn't contradict 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 three tightly packed sentences: target formats and modes, project scope prerequisite, and core behavioral constraints and return value. No fluff—each sentence earns its place and the key purpose is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 6 parameters, no output schema, and a destructive hint, the description covers installation modes, prerequisites, behavioral safety (overwrite, symlink rejection), and return value. Given 100% schema coverage, this 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?

  Schema coverage is 100%, so baseline is 3. The description adds meaning beyond schema by explaining the project scope requirement (project_dir and the <project_dir>/.tdmcp/packages path) and the legacy dest_dir/<packageName> form, enriching the context for scope and dest_dir 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 a specific verb ('Install') and clearly identifies the resource types (folder, .zip, .tox, manifest) and the two installation scopes (project/user explicit scope, legacy dest_dir form). This distinguishes it from siblings like manage_packages and manage_component.

  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 gives an explicit alternative and prerequisite: 'Use inspect_component_manifest first for unknown packages.' It also clarifies when project scope is needed by noting project_dir is required. However, it doesn't explicitly state when not to use the tool or contrast it with other install-related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_packagesA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Even though destructiveHint and openWorldHint are provided, the description goes well beyond by detailing the reconciliation flow: 'dry-run-first, proves marker ownership, and uses Delete/Bypass/Keep consent before pruning a live package.' It also notes that legacy uninstall now returns a safe plan instead of deleting. This gives critical safety context that annotations do not convey.

  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?

  Three sentences, front-loaded with the action list, then safety specifics, then hard exclusions. Every sentence earns its place without redundancy or fluff. The structure is efficient for an agent to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a high-complexity tool with 17 parameters and multiple actions, yet the description covers the full action set, scope semantics, safety-critical reconciliation behavior, and strict exclusions. Even without an output schema, the description is sufficient to guide invocation and avoid dangerous mistakes.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for all 17 parameters, so the baseline of 3 applies. The description adds some high-level context about scope and dry-run behavior, but does not add detailed parameter-level meaning beyond what the schema already provides. It is neither misleading nor incomplete, but the schema carries the semantic burden.

  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 enumerates the actions: 'Search, list, inspect, doctor, install, reconcile, and uninstall' manifest-driven TouchDesigner community packages. This provides a specific verb+resource combination and unmistakably distinguishes it from sibling tools focused on node creation, rendering, or external integrations.

  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 gives clear context via 'at explicit user or project scope' and explicitly excludes what it never does ('never runs third-party scripts, pip installs, model downloads, or external app setup'). However, it does not name alternative tools or explicitly state 'use this when...' versus other package-related tools, so it slightly misses the full 'when-not' guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• plan_visualA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by detailing exactly what happens: 'every suggested tool, recipe and operator is validated,' and 'any unavailable or invalid LLM path falls back deterministically without mutating TouchDesigner.' This discloses fallback behavior and safety guarantees, adding substantial value beyond the readOnlyHint/destructiveHint 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?

  Three sentences pack all necessary information: purpose, default behavior, and LLM option details. There is no redundancy or filler; each sentence adds a distinct piece of information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the output schema and full parameter descriptions, the description is highly complete. It covers purpose, safety (read-only), planner behavior, and fallback mechanism, leaving no critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already covers 100% of parameters with descriptions, so baseline is 3. The description adds meaning to the 'planner' parameter by explaining the difference between deterministic and LLM modes, including the bounded completion and fallback behavior, which is not 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 clearly states the tool's function: 'Turn a visual description into a read-only build plan.' The verb 'turn' plus the resource 'visual description' make the action explicit, and 'read-only build plan' distinguishes it from execution-oriented sibling tools that create or modify TouchDesigner nodes.

  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 context that this is a planning tool that 'creates nothing,' which implies it should be used before actual node creation. However, it does not explicitly name alternative tools or state when not to use it, leaving the comparison to siblings implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• profile_cook_costA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context about the sampling methodology (N samples × intervalMs) and output composition (hotspots, warnings), which goes beyond the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the key action ('Read-only') and purpose. Includes a compact return signature. No redundant or placeholder content; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With output schema present and annotations covering safety, the description still adds purpose, use case, and return structure. It is sufficient for an agent to understand when and how to invoke the tool, and the inclusion of the alternative tool makes the context complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter already described in detail. The description reinforces the relationship between samples and intervalMs (window) and mentions targetFps forwarding, but does not add significant new meaning beyond what the schema provides. Baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool samples cook times over a window and ranks hotspot nodes by p95 cook time. It uses specific verbs ('sample', 'rank') and identifies the resource (cook times, hotspot nodes). It also distinguishes itself from get_td_performance by targeting intermittent stalls a single snapshot misses.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use this tool: 'Use this to diagnose intermittent stalls that a single get_td_performance snapshot misses.' It names the alternative tool and the specific scenario where this tool is superior, providing clear guidance for agent selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• rebuild_networkA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the destructive clear_existing option and explains the fail-forward behavior (unknown operator, missing parameter, or unresolved wire become warnings). These specifics go beyond the annotations, which only broadly indicate non-read-only and destructive behavior, adding valuable context about failure handling and side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but efficient, with each sentence covering a distinct aspect: purpose, process, failure mode, option effects, and return values. There is no redundancy, and the structure is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with a nested spec and no output schema, the description is remarkably complete. It specifies the return values (node names, wire count, parameters set, warnings), explains error handling, and describes the behavior of both optional flags. This makes it self-sufficient for 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?

  Although the schema covers all parameters, the description adds meaning by explaining how the spec's nested structure (nodes, params, wires) is used during the rebuild process (one-pass creation, wiring by name). This helps the agent understand the relationship between parameters and the tool's operation, going beyond raw schema definitions.

  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 reconstructs a live network from a serialize_network spec, identifying it as the 'REBUILD half of a git-diffable round-trip.' It distinguishes itself from sibling tools like serialize_network and create_td_node by explicitly focusing on whole-network reconstruction from a spec.

  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?

  It provides clear context for when to use the tool: as a counterpart to serialize_network for round-trip workflows. It also mentions fail-forward behavior, implying usefulness with partial specs. However, it does not explicitly exclude alternatives like repair_network or create_td_node, though the round-trip framing is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• recall_similar_workA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint, the description adds valuable behavioral details: it is offline, requires TDMCP_VAULT_PATH, explains the scoring mechanism (query-token overlap with title/intent/prompt/tags/body, optional boosts), and describes return content (ranked hits, paths, score, matched terms, body snippet). No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the tool's purpose, then explaining scoring and outputs/constraints. Every sentence adds distinct value with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a search tool with an output schema, the description covers purpose, behavior, scoring, output, and constraints (offline, path requirement). It is sufficiently complete to guide an agent without needing to reference sibling tools or external docs.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% with each parameter already well-described (e.g., tags 'should boost matching notes', ops 'boosts notes whose ops overlap'). The description's mention of 'optional tag and op boosts' is largely redundant with the schema, adding only slight contextualization within the scoring algorithm.

  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 'rank' and resource 'past memory notes', clearly stating the tool's purpose: to find similar past work for reuse. It distinguishes from siblings by focusing on similarity-based recall over memory notes, not generic search or library browsing.

  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 gives clear context: use when starting a new visual goal to reuse prior recipes/params/prompts instead of rebuilding. It implies the primary use case but does not name explicit alternatives or when-not-to-use, though the 'read-only vault search' framing helps.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• run_macro_scriptA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds rich behavioral context beyond annotations, such as dispatching entries through tool handlers, dryRun avoiding invocation, stopOnError halting on first failure, and the warning about redacted args failing at the tool boundary. This complements the annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two concise sentences, front-loaded with the core action and followed by parameter details and a warning. Every sentence adds value without redundancy.

  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 complexity of a tool that dispatches to other tool handlers, the description covers the essential behavior, parameters, and a security caveat. No output schema exists, but for a side-effect-driven replay tool, the description adequately guides usage, though it does not mention return values or the overall expected outcome.

  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?

  With 0% schema coverage, the description carries full responsibility for parameter semantics. It explains each parameter's purpose: dryRun for planning, stopOnError for failure handling, argsOverrides for shallow-merging replacements, and allowRawPython for opting into raw-Python entries, plus the macroPath is implicitly the file to replay.

  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: replay a MacroRecord JSON file by dispatching entries through in-process tool handlers. This specific verb (replay) and resource (MacroRecord JSON file) distinguishes it from siblings like macro_recorder, which records rather than replays.

  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 detailed parameter usage guidance (dryRun, stopOnError, argsOverrides, allowRawPython) but does not explicitly state when to use this tool versus alternatives or when not to use it. The usage context is implied by the purpose, but no exclusions or sibling comparisons are provided.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• save_td_projectA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it as destructive and non-read-only, but the description adds substantial behavioral detail: bounded overwrite consent, fail-closed to Keep on timeout/error, no native file dialog, no project load/quit, no raw Python fallback, and the exact return payload. This far exceeds what annotations alone convey.

  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?

  Three focused sentences, front-loaded with the core purpose. Every sentence adds operational value—purpose, consent behavior, and constraints/returns. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 no output schema, the description provides all necessary context: when a path is required, timeout bounds, overwrite consent semantics, fail-closed behavior, what it never does, and what it returns. It is complete and self-contained.

  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 with clear descriptions for both parameters, so the description doesn't need to add much. It reinforces the 'Save As' path concept but adds no new meaning beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Save') and names the precise resource (current TouchDesigner project) plus the Save As variant. It clearly distinguishes from sibling tools like save_component_to_vault or export_network_to_vault, which target different artifacts.

  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 indicates the tool is for saving the current project or a Save As, which implies the primary use case. It does not explicitly name alternatives or exclusions, but the context is unambiguous given the tool name and the niche purpose. Slight deduction for no explicit 'when not to use' guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scaffold_showA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses exactly what gets created (new container, master and tempo nodes), what is intentionally omitted (scenes/look), and what is returned (container path plus node paths). It goes beyond the basic readOnlyHint=false and destructiveHint=false annotations by describing the structural side effects and the blank-canvas nature, while avoiding any contradiction.

  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 three sentences with clear front-loading: what the tool does, how it differs from a sibling, and what it returns plus next steps. Every sentence adds value without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the absence of an output schema, the description explicitly names the return values (container path, 'master' and 'tempo' node paths) and the absence of scenes/look. It covers all essential context for a simple creation tool with 2 parameters, and the workflow guidance completes the picture.

  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 with clear descriptions for both parameters ('Name of the show container to create' and 'Parent COMP path the show container is created inside'). The description adds no additional parameter-level detail beyond what the schema states, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create a starting skeleton for a live show') and clearly enumerates what is included ('master' output Null, 'tempo' beat clock) and excluded ('NO scenes or look'). It explicitly names scaffold_genre as a distinct sibling tool, making the tool's 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit alternative with a condition: 'Use scaffold_genre instead when you want a genre-flavored start.' It also implies the use case for scaffold_show (blank-canvas start) and outlines a recommended workflow ('then add scenes, audio features, a layer mixer into master, cues and a control surface').

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• serialize_networkA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds 'Read-only' plus detailed behavioral context: best-effort custom parameters, truncation behavior, and the exact return shape {root, nodes[], truncated?, warnings[]}. This goes well beyond the annotations and fully discloses the tool's operational characteristics.

  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 information-dense yet well-structured: it front-loads the read-only nature, defines the exact serialization behavior, explains the round-trip pairing, and gives concrete use cases. Every sentence contributes meaning without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich input schema, output schema, and annotations, the description covers all necessary aspects: what the tool does, what it returns, when to use it, and edge cases like truncation and best-effort parsing. No significant gaps remain.

  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?

  All three parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds some context like 'immediate children' and 'best-effort' for include_custom_params, but it does not materially extend the schema's parameter semantics.

  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 serializes a COMP's immediate children into a git-diffable JSON spec and enumerates exactly what is captured (node name, op type, parameters, wires, position). It distinguishes itself by positioning as the serialize half of a round-trip pair with rebuild_network, setting it apart from other network/snapshot tools.

  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 explicit use cases: snapshot a network for diffing or version control, and pair with rebuild_network for reconstruction. It does not explicitly name alternative tools or state when not to use it, but the context is strong enough to guide selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• setup_body_trackingA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint false, openWorldHint true, destructiveHint false), the description reveals important behavioral traits: the engine only captures the webcam while playing, it reads pose JSON DAT through an adapter, and macOS shows a camera permission prompt. These are useful disclosures not present in the structured metadata.

  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 yet information-dense, with a clear logical flow: one-shot setup, installation prerequisite, engine behavior, adapter pipeline, skeleton output, and permission warning. Every sentence contributes new information, and the structure is front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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, no output schema, and rich annotations, the description covers the complete workflow, prerequisites, runtime behavior, and expected user actions. It even addresses the failure case (engine not installed) and platform-specific permission prompts, making it fully self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description adds contextual meaning by explaining the engine (.tox) referenced in tox_path and the live skeleton built by build_skeleton, but it does not directly map each parameter. The schema already provides clear descriptions, so no significant additional parameter semantics are added.

  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 verb and resource: 'One-shot body tracking from a webcam.' It details the full workflow (loads mediapipe engine, starts timeline, reads pose JSON, builds skeleton), which distinguishes it from sibling tools like setup_face_tracking and setup_hand_tracking.

  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 on when to use this tool (for one-shot body tracking) and includes a prerequisite instruction ('install it first with tdmcp install mediapipe-touchdesigner'). It does not explicitly mention alternatives or exclusions, but the unique webcam body-tracking workflow makes its usage scope evident.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sync_timecodeA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description exposes substantial behavior beyond annotations: it creates a full node chain ('input op + Math CHOP normaliser + Null CHOP tc_out'), optionally writes project.frame via Execute DAT, and warns about LTC's missing native decoder and MTC's build-dependent availability. This goes well beyond the sparse 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 front-loaded with the core purpose, then compactly covers node creation, optional timeline driving, and important caveats. Every sentence earns its place; it is detailed but not bloated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 9-parameter tool with no output schema, the description adequately explains what will be created (tc_out, channels, Execute DAT), how it behaves, and what limitations exist. It is complete enough for an agent to understand the tool's effects and prerequisites.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a detailed description. The tool description adds some global behavioral context (e.g., MTC availability) but doesn't materially enhance per-parameter meaning 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 opens with a specific verb and resource: 'Wire an external SMPTE/MTC/LTC/OSC timecode source into the TouchDesigner timeline.' It clearly distinguishes itself from related siblings like create_ltc_timecode_bridge by covering multiple timecode standards and the timeline-driving behavior.

  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?

  It provides clear context and a key prerequisite: 'Requires the project to be playing — paused TD will not advance.' It also flags LTC and MTC caveats. However, it doesn't explicitly name when alternatives like create_ltc_timecode_bridge or sync_external_clock should be preferred.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• tutorial_companion_packA
  4.5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds substantial behavioral detail beyond annotations: it discloses exact file writes, the read-only nature of bridge calls (no mutation of TD), and the requirement of environment variables and bridge connection. This goes well beyond the readOnlyHint=false and openWorldHint=true annotations, providing no contradictions.

  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 four sentences, densely packed with useful information: purpose, outputs, file layout, constraints, and non-recipe status. There is no fluff or repetition; every sentence contributes value, and the most critical details are front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with eight parameters and multiple output artifacts, the description covers inputs, outputs, exact file paths, environmental requirements, and the read-only nature of its underlying calls. No output schema exists, but the description's explicit list of files and the 'for reference only' caveat fully compensate, making the tool's behavior predictable.

  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 75% (6/8 parameters), so the schema already documents most parameters. The description adds meaning for lesson_count ('N-step'), folder ('vault subfolder'), and name ('slug'), but does not clarify preview_width or preview_height, which are undocumented in the schema. This is acceptable but not exceptional.

  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 verb ('Build') and resource ('teaching/selling companion for a network'), and enumerates concrete outputs (tutorial.md, topology.json, network_snapshot.json, previews/*.png). It also distinguishes itself from siblings by explicitly stating it is not a RecipeSchema-compatible installable recipe, making its purpose unmistakable.

  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 on when to use: to scaffold a tutorial pack via read-only bridge calls, and it notes prerequisites (TDMCP_VAULT_PATH, running bridge). It also gives an when-not by clarifying the snapshot is for reference only and not an installable recipe, though it does not explicitly name alternative sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• arrange_networkA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds substantial behavioral detail beyond the annotations: it discloses that explicit mode is atomic, bounded, has stale-context checks, readback, and rollback. It also clarifies the tool is non-destructive (never adds/deletes/rewires nodes), which complements the destructiveHint=false annotation. This significantly helps an agent predict side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exceptionally concise: two sentences that front-load the primary purpose, then cover the explicit mode's key traits, legacy behavior, and safety guarantee. Every sentence provides essential information without any redundant filler.

  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 tool with 10 parameters and complex behavior, the description covers the core behavioral aspects (modes, atomicity, non-destructive guarantee) and references the legacy response. The schema handles individual parameter details, so the description does not need to echo them. While it does not spell out the return format, no output schema exists and the description gives enough context for selection and safe 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 description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantics of layout_mode (explicit atomic mutation vs automatic) and mentions annotation-aware layout, which maps to the annotation_aware parameter. While it doesn't describe every parameter, it enriches understanding of the key mode-switching parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool tidies an existing network into a readable left→right data-flow layout, and also explains the alternative explicit coordinate mode. It distinguishes itself from sibling tools by explicitly stating it never adds, deletes, or rewires nodes, which differentiates it from connect/disconnect/rebuild tools.

  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 automatic vs explicit layout modes, and notes that omitting layout_mode preserves the legacy response. It implies when not to use the tool (for rewiring actions) by stating it never rewires nodes, but does not explicitly name alternative tools for those cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• copilot_visionA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful behavioral context beyond the readOnlyHint annotation: it explains egress requirements for remote backends, states that returns are redacted, and notes `calibration: not_checked`. It also discloses implementation via ctx.llm.complete(). No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences with no fluff. The main purpose is front-loaded, followed by key constraints and a sibling differentiation.

  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?

  The description covers the core operation and key edge-case constraints (egress, calibration). However, since there is no output schema, it would be helpful to explicitly state that the response contains the LLM's answer; it is implied but not stated. Overall, it is fairly complete for the tool's complexity.

  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?

  All parameters are already described in the schema (100% coverage), so baseline is 3. The description adds value by clarifying when `allow_remote_image_egress` is needed and by explaining the role of `source_top` in the capture process, enhancing the schema descriptions.

  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 captures a TOP as a preview image and asks a multimodal LLM a question about it. It distinguishes itself from sibling `caption_top` by noting the different behavior (deterministic vs open-ended).

  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 context on when to use the tool by contrasting with `caption_top` (deterministic vs open-ended) and states it is not the calibrated visual-mutation authority. It also gives configuration guidance for when `allow_remote_image_egress` is required, but does not explicitly enumerate all alternative tools or exclusion cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_ai_mirrorA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations only saying non-read-only, non-destructive, and open-world, the description adds substantial behavioral detail: camera permission dialog on macOS, fallback_to_synthetic behavior, and the warning-not-error handling of missing pars. It also explains the delegation to drive_streamdiffusion and how the panel binds pars via .expr expressions, which is far beyond what annotations reveal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a dense single paragraph with every sentence carrying useful operational detail. The first sentence is long and packed, but it front-loads the purpose and pipeline, so it remains effective without being wasteful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 16 parameters and no output schema, the description covers the full pipeline, output modes, delegation, parameter binding behavior, error handling, OS permission side effects, and fallback semantics. This is more than enough context for an agent to decide and 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?

  Schema coverage is 100%, giving a baseline of 3. The description adds integration-level semantics by explaining how cfg, strength, and prompt feed the control panel and drive StreamDiffusion pars, and how fallback_to_synthetic keeps the rig alive. It does not restate every parameter but meaningfully enriches 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 it wires a complete AI-mirror installation in one MCP call, detailing the exact pipeline: camera/synthetic/existing TOP -> StreamDiffusion -> output -> control panel. It distinguishes itself from sibling tools like drive_streamdiffusion by framing itself as the 'Layer 1 COMBO' that delegates to that tool.

  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?

  It provides strong context for when to use the tool ('canonical 2026 AI-mirror installation in one MCP call') and references drive_streamdiffusion as the delegated sub-tool. However, it does not explicitly state when NOT to use this tool or name alternative tools for simpler/composable setups, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_audio_reactiveA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate this is a mutating, non-destructive, open-world tool. The description adds valuable detail about the concrete side effects (creating a baseCOMP with a specific node chain) and what the return payload includes (summary, node paths, preview image). It does not mention any potential edge-case behaviors like overwriting existing nodes, but this is minor given the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence delivers critical information: the build steps, style options, return format, and alternatives. It is well-organized and does not waste words on repetition or filler.

  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 (14 parameters, creation of multiple nodes) and absence of an output schema, the description covers the essential output structure and alternatives. It could be more explicit about prerequisites (e.g., requiring existing audio files or CHOP paths) but the schema already documents those parameter conditions and the description returns node errors to diagnose issues.

  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 100% schema description coverage, the baseline is 3. The description adds extra meaning by explicitly mapping each visual_style enum value to a rendering description ('glsl=horizontal bars, geometric=radial bars' etc.) and by referencing the Sensitivity gain and optional Beat CHOP, which clarifies how parameters like expose_controls and beat_detection fit into the built chain.

  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 a specific verb+resource ('Build an audio analysis chain... and a spectrum visual driven by it') and enumerates the exact node components created. It unambiguously distinguishes this tool from siblings by stating 'This is the only audio tool that produces a built-in visual' and names the alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit when-to-use and when-not-to-use guidance: the tool is for creating a complete audio-reactive visual, whereas extract_audio_features and create_spectrum are for channel extraction without visuals, and bind_audio_reactive is for wiring channels onto existing COMPs. This directly addresses alternative selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_band_routerA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses internal composition (Select CHOP, audiofilterCHOP, Analyze CHOP, Merge, Lag, Null) and explicitly flags unverified details across TD builds with fallbacks and warning behavior ('UNVERIFIED across TD builds — they are set in guarded tries...'). This goes well beyond the annotations' limited hints.

  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 substantial but well-organized, front-loaded with the core purpose and using a list format for internals. It repeats some schema content (e.g., the expression format) but each section earns its place; a minor trim of redundancy would be possible.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a build tool with no output schema, it thoroughly explains what is built, the naming conventions, the routing expression, and fallback behavior, plus how to use the result via bind_to_channel. It even notes failure modes.

  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 descriptions cover 100% of parameters and already explain bands, smooth, targets, etc. The description adds little new parameter-specific meaning beyond restating the expression format and band naming already present 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 first sentence clearly states the tool's function: 'Split an audio signal into EQ bands and route each band to its own target parameter(s)'. It also explicitly distinguishes from sibling extract_audio_features, naming the alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly names extract_audio_features as an EXTENSION sibling and contrasts their purposes ('that one extracts named features; this one is the band-split + multi-target router'). Also states the option to omit targets for later binding via bind_to_channel.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_cubemap_domeA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Even with annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) already signaling that this tool creates and modifies the scene graph, the description adds substantial behavioral detail: it names the exact node chain (Render TOP in cubemap mode or Select TOP, GLSL TOP sampling sTDCubeInputs[0], Null), explains the source-fallback logic, exposes that the tool creates controls (Fov and Rotation knobs), and states the structured return info (JSON with paths, errors, warnings, preview). This fully discloses side effects and matches 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense and information-rich: each sentence contributes to purpose, pipeline, side effects, or output. While it is long, it remains front-loaded with the core intent and tradeoff. A slight restructuring into separate sections could improve scannability, but the content is efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 7 parameters and no output schema, the description covers all essential aspects: the render process, source handling, projection modes, created components, exposed controls, and the return value (summary plus JSON with paths, errors, warnings, preview). This gives an agent everything needed to correctly select and invoke the 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 100%, with all 7 parameters already provided rich details (e.g., fov gives an angular range, projection enums have explicit definitions, source has a fallback explanation). The description adds only marginal conceptual value beyond the schema, such as the note that real cube-map sampling avoids the equirect pole-pinch/seam, but does not meaningfully extend parameter understanding.

  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 a specific, action-oriented phrase ('Render a true cube-map dome master') and immediately distinguishes the tool from the sibling create_dome_output, calling it 'the higher-fidelity follow-up' that only warps a flat equirectangular source. It clearly enumerates the output resource (a baseCOMP containing a cube-map source, GLSL remap, and Null output) and the two projection modes (fisheye and equirectangular).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names an alternative tool (create_dome_output) and explains the fidelity tradeoff, making it clear when this tool is the better choice. It also describes what happens if no source is provided (a self-contained test scene) and notes the output ends 'on a Null ready for setup_output', providing downstream pipeline context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_data_source_http_wsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnly=false, destructive=false, and openWorld=true. The description adds valuable behavioral context beyond these hints: it explains the underlying mechanisms (webclientDAT, timerCHOP, websocketDAT with auto-reconnect), the JSONPath-lite selector limits, fallback behavior for non-numeric values, and the self-signed certificate silent failure noted in the URL parameter. It does not explicitly mention the side effect of creating nodes in the project or continuous network activity, but the 'create' verb and openWorld hint imply this. Overall, it's rich detail without contradiction.

  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 about six sentences, longer than the ideal two-sentence example, but every sentence carries essential information: mode differences, selector syntax, output handling, and usage guidance. It is structured with clear labels (http_poll, websocket, Both) and front-loaded purpose. It is dense but not wasteful, so a 4 is appropriate.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 12 parameters, nested objects, no output schema, and external I/O, this description is exceptionally complete. It covers both modes, the selector language, the generated artifacts (Null CHOP, Null DAT), the fallback semantics, and the differentiation from the simpler sibling. Combined with 100% schema description coverage and annotations, the agent has all the context needed to select and invoke the tool 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?

  Schema description coverage is 100%, so the baseline is 3. The description adds architectural context beyond the schema by explaining how polling cadence is tied to a timerCHOP and how websocketDAT manages reconnects, which deepens understanding of parameters like poll_seconds and reconnect_seconds. It also clarifies the selectors' mapping to output channels. This goes beyond what the schema already provides, justifying a 4.

  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 a specific verb and resource: 'Advanced live-data ingest for HTTP polling and WebSocket streams' and immediately distinguishes itself as 'the richer-transport sibling of create_data_source.' This clearly states what the tool does and differentiates it from its sibling, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The final sentence provides explicit usage guidance: 'Use create_data_source for simple one-knob JSON/CSV polling; use this tool when you need real POST/headers, fine-cadence timer sync, or a WebSocket stream.' This names the alternative, states when to use this tool, and when not to, which is exactly what the dimension requires.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_depth_silhouetteA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate no destructive behavior, but the description adds valuable context: it creates a baseCOMP under parent_path, may prompt for macOS permissions when using sensors, defaults to a synthetic source requiring zero permissions, and returns a summary plus a JSON block with node paths and errors. This enriches the behavioral profile 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence contributes meaningful information—purpose, pipeline, defaults, permissions, return value. It could benefit from line breaks to improve scannability, but it avoids redundancy and keeps each clause purposeful. Slightly verbose but appropriate for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers functionality, node chain, source options, permission side effects, exposed controls, return format, and distinguishes from a related sibling. With no output schema, it fully explains what is returned, including the JSON block and preview image. For a tool with 8 parameters and network creation, this is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and descriptions for params like threshold, smooth, and source are already detailed. The tool description adds marginal value by filling in the intended use context (e.g., binding threshold to audio) but does not substantially extend beyond what the schema already provides. Baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool extracts a silhouette/body mask from depth or video, names the specific action (creates a new baseCOMP), and explicitly distinguishes it from the sibling create_depth_displacement tool. The verb+resource combination and the explicit alternative make the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context (reactive visuals, interactive installations), explains when to choose synthetic vs file vs sensor sources, and explicitly directs to create_depth_displacement when 3D relief is needed. This goes beyond simple context to provide actionable when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_external_ioA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations only stating readOnlyHint=false, openWorldHint=true, destructiveHint=false, the description adds substantial behavioral context: platform constraints (RTMP requires NVIDIA GPU on Windows; Spout needs NVIDIA/AMD but not Intel), default safety behaviors (active defaults off so the artist can confirm destination), error tolerance for bind_to (missing channels fall back to 0), and validation limitations. This goes well beyond the annotations and gives the agent critical operational expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph with lengthy parenthetical asides and repetitive enumerations. It is front-loaded with the core purpose, but the structure makes it harder to scan. While every part is informative, it could be organized with bullets or separate sections for input vs output categories to improve readability without losing content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers all major categories, platform-specific requirements, default behaviors, validation caveats, and an alternative tool usage (get_td_nodes). There is no output schema, so return-value documentation is not required. For a tool with 17 parameters and 15 kind variants, this description is remarkably complete, leaving few ambiguities about how and when to invoke it.

  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?

  While the schema already describes all 17 parameters (100% coverage), the description enriches their semantics significantly. It explains workflows like passing source_path for outputs, using bind_to with learned channels from get_td_nodes, and the distinction between dmx_out and artnet_out via the net/interface parameters. The prose adds conceptual meaning and practical usage guidance that the schema's per-parameter descriptions do not fully convey.

  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 'Bridge TouchDesigner to the outside world' and enumerates the full spectrum of supported I/O kinds (OSC/MIDI input/output, DMX/Art-Net, RTMP, NDI/Syphon-Spout). This clearly distinguishes it from sibling tools like create_control_surface or create_ndi_router_matrix by framing it as a generic external I/O bridge. The verb 'bridge' and the detailed resource list make the purpose unmistakable.

  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 when-to-use context, covering all the I/O bridging scenarios. It explicitly names an alternative workflow for discovering MIDI channels ('use get_td_nodes, then bind_to'), and warns about validation limits ('real signal needs the hardware/sender present'). However, it doesn't explicitly contrast with sibling tools beyond that one example, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_gaussian_splat_sceneA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses substantial behavioral detail beyond annotations: it drops a community .tox, loads assets, optionally binds cameras, exposes a renderTOP, returns specific paths/artifacts, and warns about OOM crashes with no friendly error. It also clarifies unsupported platforms and the friendly error behavior, which is highly valuable.

  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 dense and well-structured, covering creation, asset sources, camera integration, requirements, VRAM guidance, and return values. It is lengthy but every sentence carries operational weight; nothing is fluff. The front-loading of the core action is effective.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (7 parameters, no output schema), the description covers the full lifecycle: what it creates, what it requires, what it returns, and failure modes (OOM, unsupported platforms). The explicit return list partially compensates for the missing output schema and leaves no major gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds meaning by linking parameters to real-world domains: asset sources (Polycam, Postshot, Luma, Nerfstudio), VRAM/resolution tradeoffs for output_res, and how camera_path integrates with create_camera_orbit rigs. This goes beyond the schema's field descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses specific verbs ("Drops", "loads", "binds", "exposes") and names precise resources (TDGS .tox, baseCOMP, .ply/.splat asset, cameraCOMP, renderTOP). It clearly distinguishes this tool from generic container or 3D scene creators by focusing on Gaussian splat scenes.

  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 (creating Gaussian splat scenes from specific asset sources) and includes hard requirements (Windows, NVIDIA, TouchDesigner version). It does not explicitly state when not to use alternatives, but the niche nature of the tool makes the intended use obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_glsl_shaderA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description fully discloses side effects and nontrivial behaviors: it creates companion Text DATs (`<name>_frag`, `<name>_vert`), wires them to the GLSL TOP's parameters, performs best-effort uniform binding on the Vectors page, sets output resolution, and returns warnings for sampler2D or manual-wiring cases. This is far beyond the basic annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) and provides essential operational context.

  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 yet complete: three sentences cover the core action, the operational details (DAT creation, wiring, uniform binding, resolution), and the return value plus warnings. Every sentence contributes new information; there is no redundancy or fluff. The structure is front-loaded with the primary purpose and flows logically to side effects and outcomes.

  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?

  The description covers the creation process, side effects, and return values, which is especially important given there is no output schema. It mentions potential warnings for sampler2D and manual wiring. However, it omits a few possible edge cases like parent_path validation or behavior if the shader fails to compile, but given the richness of the schema and the level of detail, the description is mostly complete. A 4 reflects the minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds meaningful workflow semantics not in the schema, such as the companion DAT naming convention (`<name>_frag`/`<name>_vert`), the behavior of best-effort uniform binding, and the resolution setting. It also clarifies return values including warnings. This enriches the parameter context without replacing the schema, so a 4 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Create a GLSL TOP under parent_path' – a specific verb + resource + target location – and explains it renders a custom fragment shader with optional vertex shader. This clearly distinguishes it from siblings like create_glsl_material (which creates a material, not a TOP). The description goes beyond a generic statement by detailing the companion DATs, wiring, and return values.

  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 indicates the tool is for creating a GLSL TOP with shader source, but it does not explicitly name alternatives or state when not to use it. The mention of 'under parent_path' and the specific TOP/component context provides strong situational guidance, yet no exclusionary or comparative language is present. This earns a 4 for clear context without exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_interaction_zonesA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only indicate readOnly=false, openWorld=true, destructive=false. The description goes far beyond this by disclosing exactly what gets built (motion-energy TOP, cropTOPs, scriptCHOP, Null CHOP), that output is a CHOP not a TOP, that no preview image exists, and that the synthetic source cooks clean without external assets. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph, but every sentence carries essential information about the node chain, coordinate conventions, output format, and offline safety. It is front-loaded with the core purpose, but could be slightly better structured with separation between behavior, parameters, and return value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description fully covers return value (summary plus JSON with container path, node paths, channel names, warnings), behavioral constraints (camera-only, no preview), and binding instructions. For a tool this complex, the description leaves little ambiguous.

  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 covers 100% of parameters, so baseline is 3. The description adds meaningful semantics: zone coordinates are normalized rects with top-left convention mapped to TD bottom-left origin, threshold is a live tuning knob, resolution is described as cheap/bandwidth-bound, and omitting source_path yields a synthetic Noise TOP. This is valuable 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 a specific verb+resource: 'Define N rectangular zones over a camera / motion input' and details the resulting CHOP-based interaction system. It distinguishes itself from siblings by emphasizing camera-only motion detection, a stock-TOP chain, and CHOP output rather than a TOP preview.

  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 gives strong context: it is camera-only (excludes depth cams), can use a selectTOP source or a synthetic offline-safe source, and explains the bind point for cues. It does not explicitly name alternative tools, but the exclusions and output nature give clear guidance on when it is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_layer_stackA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the exact node structure ('Each layer is a Select TOP... → a Level TOP... layers above the base each get their own 2-input Composite TOP'), exposed controls (Opacity, Blend, Mute, Solo), and the terminal Null node, going well beyond the minimal annotation cues. It also specifies the return payload (summary + JSON block with paths, errors, preview image).

  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 detailed but each sentence adds operational value, covering purpose, architecture, parameter modes, controls, and return value. It is appropriately sized for a tool that builds a multi-node network, though slightly long compared to minimal tools.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers all relevant aspects: input modes (explicit vs count), node generation logic, exposed UI controls, output chain, and return format with error/warning reporting. No output schema exists, but the description thoroughly fills that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema description coverage, the baseline is 3. The description adds extra meaning by explaining the relationship between layers and count, the behavior when source is omitted, and how parameters map to the node chain (e.g., opacity becomes a Level TOP parameter). This elevates it above baseline.

  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 'Build a VJ-style N-layer compositor' which immediately identifies the verb, resource, and style. It further details the node chain (Select TOP → Level TOP → Composite TOP) and control strip, clearly distinguishing it from sibling tools like create_layer_mixer.

  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?

  It provides clear context for parameter selection: 'Pass layers (bottom-first) for an explicit stack, or omit it to build count empty test layers.' However, it does not explicitly state when to prefer this tool over alternative compositors or mixers, so it earns a 4 rather than 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_mesh_warpA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses exactly what the tool creates: 'a Geometry COMP holding a grid...' 'Creates a new baseCOMP under `parent_path`', 'output is a Null ready for setup_output; exposes a Zoom knob.' It also explains the internal node structure and the return payload (summary + JSON block with paths, errors, warnings, preview). This goes far beyond the annotations, giving a complete picture of side effects and results.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph but is front-loaded with the purpose. Every sentence adds value, covering the workflow, node structure, output, and return values. It is appropriately sized for a complex tool, though it could be broken into bullets for quicker scanning. Still, it's efficient without fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex creation tool with no output schema, so the description must cover return values and side effects thoroughly. It does: it mentions the created baseCOMP, specific node types, output Null, exposed Zoom knob, and a detailed JSON return block including container path, node paths, output path, controls, errors, warnings, and preview image. This is comprehensive for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description does not add much new parameter-level meaning beyond the schema; it mentions parent_path and Zoom knob, which are already described in the schema. It provides some context (e.g., warp types map to shapes) but doesn't compensate beyond baseline given the schema already documents parameters thoroughly.

  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 a specific verb and resource: 'Map a source TOP onto a curved or irregular surface via a deformable textured grid.' It clearly differentiates from sibling create_projection_mapping by calling itself the 'curved-surface upgrade' for domes, columns, and sculptures. This makes the tool's purpose unambiguous and distinguishes it from flat projection mapping.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states when to use this tool: 'the curved-surface upgrade to create_projection_mapping's flat corner-pin, for domes, columns, and sculptures.' This names an alternative tool and the condition for choosing this one (curved/irregular surfaces vs. flat). It also implies the alternative by contrast, giving clear usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_multi_outputA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond the annotations, such as the creation of a new baseCOMP under parent_path, the node structure (Select TOP, per-tile Crop, optional GLSL feather, Null outputs), and the as_windows behavior with borderless Window COMPs left closed. While it doesn't discuss failure modes or collision behavior, the destructiveHint=false annotation covers non-destructive intent, and the description is consistent with readOnlyHint=false.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every sentence contributes. It is front-loaded with the core purpose, then elaborates on edge blending, node creation, window behavior, alternatives, and return value. The structure is logical and not wasteful, though it is dense enough that a 5 would require a more concise presentation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 7 parameters and no output schema, the description is complete. It explains the created node structure, the behavior of as_windows, the overlap feature, the alternatives, and explicitly describes the return value (summary plus JSON block with all relevant paths and an inline preview). There is no obvious missing context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the overlap parameter in depth (tiles widen into neighbors, GLSL feather fades seams), the as_windows parameter (borderless Window COMP offset, left closed for Perform mode), and the overall layout behavior. This elevates it above the baseline.

  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 a specific verb+resource: 'Fan a master TOP across N projectors/displays' and explains exactly what each output is (cropped slice resized to projector resolution, ended on a Null). It also distinguishes itself from sibling tools by explicitly naming setup_output for single-window output and create_dome_output/create_cubemap_dome for curved/fulldome applications.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance on when to use this tool vs alternatives: 'Use setup_output instead for a single-window output; create_dome_output/create_cubemap_dome for curved/fulldome instead of flat tiling.' It also notes the intended follow-up (ready for setup_output) and the as_windows usage pattern (open in Perform mode).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pbr_sceneA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only state readOnlyHint=false and destructiveHint=false, so no contradiction exists. The description goes beyond by detailing exactly what is created ('a new baseCOMP under parent_path' with a full list of nodes), how env_color works without an HDRI file, what controls are exposed, and what the return payload contains (summary, JSON block, preview image). This is rich behavioral context not present in annotations.

  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 relatively long but densely packed with essential information: main action, node list, alternative tool, controls, rotate behavior, and return format. It is front-loaded with the primary purpose and uses clear structural progression. While lengthy, every sentence earns its place for a complex scene-creation tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 8 parameters and no output schema, the description carries the full burden of explaining return values and component creation. It comprehensively covers the entire scene graph, fallback behavior (no HDRI), exposed controls, and return payload (paths, errors, preview). It also provides an explicit fork to create_3d_scene, making it contextually complete for an agent to decide and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds minimal parameter context beyond the schema: it mentions the exposed controls (Metallic, Roughness, BaseColor, Spin) and actions (rotate to show reflections), but these are already in the schema. It does not significantly deepen parameter understanding, so a 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Build a physically-based 3D scene' and enumerates exact components (Geometry COMP, PBR MAT, Environment Light, etc.). It clearly distinguishes itself from sibling 'create_3d_scene' by stating 'Use create_3d_scene instead for basic (non-PBR) shading or GPU instancing.' The verb 'Build' and 'Creates' precisely convey the action and outcome.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names the alternative tool ('create_3d_scene') and specifies when to use it ('for basic (non-PBR) shading or GPU instancing'). It also provides practical usage tips like 'set rotate to turn the object so its reflections move' and explains the env_color Constant TOP fallback, giving clear context for when this PBR-specific tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pop_growthA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  It goes far beyond the annotations by disclosing that POPs are Experimental, par writes are fail-forward, the result reports unverified op/par sets, and warning conditions for divergence (feedback_gain × (1 − decay) ≥ 1.0). These are critical behavioral traits that help an agent anticipate side effects and failure modes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph, but every sentence contributes useful information and it is appropriately sized for a complex build tool. Minor structural improvements (e.g., separating the output chain from warnings) would elevate it, but it remains focused and front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite 13 parameters and no output schema, the description is exceptionally complete. It explains the internal node chain (particle_pop, noise_pop, force_pop, feedback_pop), the output path (poptoSOP → geometryCOMP → renderTOP), delegation to buildPopChainScript, and risk warnings. This gives an agent everything needed to understand what the tool does, how it works, and what could go wrong.

  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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds meaningful system-level context (e.g., how feedback_gain and decay interact to cause divergence, max_points passed defensively, overrides on presets). This enhances understanding of parameter relationships beyond the isolated field descriptions.

  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 a specific verb+resource: 'Build a POP-native reaction-diffusion / growth system inside a fresh baseCOMP.' It clearly distinguishes itself from sibling tools like create_reaction_diffusion or create_pop_field by emphasizing the POP chain, presets, and output chain. The three mode presets further clarify the tool's specific niche.

  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 on when to use this tool (for organic POP-based growth systems) and even sets expectations about experimental behavior and divergence risks. However, it does not explicitly mention alternatives or exclusions, so it stops short of a perfect score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pose_skeletonA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only convey readOnly=false and destructive=false, so the description carries the burden, and it delivers: it reveals the created node hierarchy, the Script SOP that rebuilds points each cook, the default synthetic source, exposed knobs, and the JSON return payload including preview. This goes beyond the annotations to explain how the tool behaves at runtime.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but well-structured, front-loading the core purpose and then flowing into sources, created nodes, alternatives, exposed controls, and return value. Every sentence adds relevant detail for a complex tool; only minor trimming would be possible.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 fully explains return values (summary, paths, bone count, errors, preview). It covers all major behaviors, source options, and the network built, making it complete for a 9-parameter tool with no required parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds a little grouping context (e.g., 'Exposes LineColor / LineWidth / CamDistance') but doesn't provide significant meaning beyond the already-detailed property descriptions.

  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 starts with a specific verb+resource: 'Render a live stick-figure skeleton from full-body pose tracking' and then enumerates the exact component network created. It explicitly distinguishes itself from the sibling tool create_body_reactive ('Use create_body_reactive instead for glowing dots/trails...').

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear context: the synthetic source works with no camera/plugin, while 'mediapipe', 'osc', or an existing pose CHOP are for real performers. It also names an explicit alternative (create_body_reactive) and a prerequisite source tool (create_pose_tracking), giving the agent concrete decision criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_shared_memory_bridgeA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal it is a non-read-only, non-destructive create operation. The description adds critical behavioral details: zero-copy IPC semantics, exact shmName matching, raw headerless buffer risks when format.header=false, and platform-dependent fatal errors.

  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?

  Four dense sentences with no fluff. The key decisions (direction, kind, shmName) are front-loaded, and every sentence adds operational value without repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (6 params, nested format object, absent output schema), the description covers the core workflow, wiring step, and a failure mode. It does not state the success return value (e.g., the created operator path), which would be useful, but otherwise it is highly 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?

  Schema covers 100% of parameters, so the baseline is 3. The description adds extra meaning by tying direction/kind to the IPC scenario, emphasizing the exact-match requirement for shmName, and explaining the format.header=false garble risk, going beyond schema descriptions.

  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 as creating a Shared Memory In/Out TOP/CHOP for zero-copy IPC with other apps, naming specific examples (Notch, Unity, Unreal). It distinguishes itself from generic node creation siblings by referencing shared memory and IPC specifically.

  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?

  It conveys the target use case (same-host IPC with external apps) and provides a follow-up step (connect_nodes after Out creation), but it does not explicitly contrast with alternative IO tools or state when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_text_overlayA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description discloses that the tool produces a 'finished visual layer ready for setup_output', that the text is static, and that it can composite over a source TOP or output on transparent background. It mentions creating a self-contained container at parent_path, which implies node creation. It does not detail every side effect (e.g., naming collisions), but it covers the expected behavior well.

  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 information-dense yet efficient. Each sentence serves a distinct purpose: function, use cases, and differentiation. No filler or repetition; it front-loads the primary action and then provides contextual guidance, 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 8 parameters, no output schema, and sparse annotations, the description covers the essential context: what the tool does, when to use it, and how it differs from similar tools. It omits potential error conditions or prerequisites, but given the clear semantics of the schema and the explicit 'static text' note, it is sufficiently complete for an agent to select and invoke the 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 coverage is 100%, so the baseline is 3. The description adds meaning by explaining the optional source_path behavior ('Omit to get the text alone on a transparent background, ready to composite later') and clarifies the output as a Null TOP container. It also frames parameters like font size, color, and alignment within the compositing pipeline, which the schema alone doesn't fully capture.

  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 a specific action: 'Composite styled STATIC text over a visual (or on its own transparent background)', clearly identifying the tool as a text overlayer. It names the involved nodes (Text TOP, Composite TOP, Null) and explicitly differentiates from siblings like create_kinetic_text and create_text_crawl, leaving no ambiguity about its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit use cases are provided: 'For lyrics, titles, song names, or credits in a set.' It also gives explicit exclusions: 'The text does not move: for a single word that flashes/pulses/slides use create_kinetic_text, and for multi-line scrolling tickers/credits rolls/typewriter reveals use create_text_crawl.' This is textbook when-to-use vs alternatives guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_transitionA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Even though annotations are present (readOnlyHint=false), the description adds significant behavioral detail: creates a new baseCOMP under parent_path, brings in sources via Select TOPs, exposes live Progress and Duration knobs, and returns summary plus JSON block with node paths, errors, warnings, and preview image. It fully explains the creation side effects without contradicting annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph, but every sentence contributes useful information without fluff. It is front-loaded with the core purpose. It could benefit from bullet points or section breaks for readability, but overall it is well-structured for the complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (8 params, 5 styles, output specification), the description covers all essentials: what it builds, the styles, progress semantics, exposed knobs, how to drive it externally, the output Null, and the return format. No output schema exists, so the description rightly explains the return value in 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 100% with descriptive parameter docs, so baseline is 3. The description adds value by explaining each style's implementation details (e.g., luma_wipe uses Ramp-gradient-driven moving edge via GLSL) and clarifies that omitted sources default to built-in test looks. This goes beyond the schema's basic field descriptions.

  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 the tool builds a parameterized A→B transition over a Progress knob, the executable core of VJ cutting. It enumerates five distinct transition styles with concrete implementations (Cross TOP, GLSL ramp, etc.), clearly distinguishing it from siblings like create_glitch or create_layer_mixer.

  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 strong context: it is the core transition builder for VJ cutting and explains how to drive it via manage_cue/bind_to_channel. However, it does not explicitly mention when not to use it or point to alternative tools, so it stops one step short of full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_visual_systemA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description discloses the full behavioral pipeline: classifies intent, delegates to a builder/tag-matched recipe, creates a self-contained COMP under parent_path, verifies, previews, and returns a note plus the builder's result. This is rich context well beyond the basic readOnly/destructive hints and does not contradict 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 well-structured and front-loaded with the core action, followed by process details and a clear alternative reference. Every sentence earns its place, and the classification list adds useful specificity without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex orchestration tool with a rich schema and no output schema, the description adequately covers input interpretation, side effects, verification, preview, return values, and the main alternative. It could mention failure behavior or more details on the preview, but overall it is sufficiently complete for selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds only minimal parameter context beyond the schema, such as mentioning parent_path in the creation flow; it does not add new semantic details for resolution, frame rate, or description beyond what the schema already explains.

  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 creates a complete visual system from a natural-language description, with specific verbs and a defined resource. It distinguishes itself from siblings by naming classifier categories (audio-reactive, particle, etc.) and by delegating to Layer-1 builders or recipes, and from plan_visual by explicitly marking the difference.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit guidance is given: use this tool to actually build a visual system, and 'Use plan_visual instead for a dry run that reports which tool/recipe would be chosen without building anything.' This clearly communicates when to use this tool versus a key alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_waveformA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behavioral traits beyond the annotations: it mentions the macOS microphone-permission prompt, the creation of a self-contained container, and that the output is a Null TOP. It describes the internal operator chain (Trail CHOP, CHOP-to-SOP, Geometry COMP, etc.), giving the agent a clear picture of side effects and results. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with purpose, but the final sentence about scale and time_window is redundant with the schema parameter descriptions. It could be trimmed slightly without losing needed content, though it remains logically organized and free of fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers all essential aspects for such a complex tool: what it does, how it works (operator chain), output type, source choices and their implications (permission, testing), and differentiation from close siblings. With no output schema, the 'Output is a Null TOP' statement fills that gap. It is complete for the tool's complexity.

  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?

  All 8 parameters have rich descriptions in the input schema (100% coverage) that already explain their meanings, defaults, and underlying CHOP mappings. The description largely repeats this information (e.g., 'Scale is the vertical amplitude zoom; TimeWindow is the horizontal time span') without adding new parameter-level insight. Baseline 3 is appropriate since the schema does the heavy lifting.

  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 a specific verb+resource: 'Build a time-domain audio waveform / oscilloscope' and immediately clarifies the exact nature (actual audio signal scrolling as a moving trace). It also distinguishes itself from sibling tools by naming create_spectrum, detect_onsets, and create_audio_reactive, making the tool's unique purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit guidance on when to use this tool and names alternatives: 'the time-domain companion to create_spectrum's frequency bins and detect_onsets' transients' and 'Unlike create_audio_reactive (which renders a spectrum), this shows the raw waveform.' It also gives practical advice on choosing the source (e.g., oscillator for testing without permission).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_td_nodeA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations. It details the confirmation workflow, fallback behavior on UI unavailability, reversibility of 'bypass', the explicit TDMCP_YOLO skip policy, the wrapping in a TouchDesigner undo block, and the limitation that whole-tool undo across multiple requests is unverified. It also states the return fields (decision, action applied, final path, confirmation policy/request id, undo label). This is exemplary transparency.

  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 dense but well-structured; it front-loads the core purpose and then expands on safety, modes, undo behavior, and return values. Each sentence adds useful information. The only slight issue is its length and the somewhat niche reference to 'TDMCP_YOLO', which may require external knowledge, but it is still concise for the complexity it covers.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that this is a destructive operation with two modes, a confirmation step, and no output schema, the description covers all essential aspects: what it does, how each mode behaves, failure fallbacks, undo handling, and what will be returned. It is complete enough for an agent to select and invoke the tool correctly without needing additional documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the behavioral implications of 'mode' and the timeout parameter (e.g., 'asks the artist', 'immediate and reversible', 'bounded wait'). It does not repeat schema descriptions verbatim, and it adds context about how parameters affect the operation. This pushes it above the baseline.

  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: 'Safely remove or bypass one TouchDesigner node.' It distinguishes between two modes ('delete' and 'bypass'), and the 'Safely' prefix sets expectations around destructive behavior. It is specific enough to stand apart from sibling mutation tools like swap_operator or disconnect_nodes.

  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 explains when to use each mode: 'delete' asks the artist for confirmation and falls back to 'Keep' on close/timeout/error, while 'bypass' is immediate and reversible. It also mentions the TDMCP_YOLO skip policy and the undo caveat. However, it does not explicitly compare with alternative tools (e.g., swap_operator), so it slightly loses points on explicit when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• detect_pitchA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses significant behavioral details beyond the annotations: it is implemented with stock CHOPs because the Pitch CHOP isn't createable, it may trigger a macOS permission prompt, it creates a Null CHOP, and it has Threshold/Sensitivity knobs. It also clearly lists caveats (~1 Hz resolution, no harmonic correction, monophonic only). This far exceeds what the sparse annotations (readOnly:false, openWorld:true, destructive:false) provide.

  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 front-loaded with a clear purpose statement and then provides implementation details, usage, and caveats in a logical flow. It is slightly long but every sentence contributes information (how it works, how to use, source options, limitations). It earns a 4 rather than 5 because the internal CHOP chain explanation could be trimmed for ultimate conciseness, though it is valuable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 fully explains what the tool produces (pitch_hz, note, confidence) and how to access it via a Null CHOP path. It covers all source types, parameter effects, limitations, and a concrete example of driving visuals. This is a complete and self-sufficient description for an agent to select and invoke the tool 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 input schema covers all 7 parameters with detailed descriptions (100% coverage), so the baseline is 3. The tool description adds extra value by explaining the min_hz/max_hz search band in context and describing the behavior of Threshold and Sensitivity knobs (which are exposed via expose_controls), giving operational meaning to the 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 opens with 'EXPERIMENTAL monophonic pitch tracker' and states it 'Estimates the dominant musical pitch of live audio', clearly identifying the action (detect/estimate) and resource (pitch). It distinguishes itself from siblings like detect_tempo or detect_onsets by specifying it outputs pitch_hz, note, and confidence on a Null CHOP.

  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 usage context: bind a color/parameter to the CHOP channel to drive visuals, source options (device, file, oscillator, existing CHOP), and a 'monophonic only' caveat implying when not to use it. It does not explicitly name alternative tools but gives practical guidance and limitations. A minor gap is the lack of explicit 'use this when...' versus 'use other tools when...'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• edit_dat_contentA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation nature is known. The description adds valuable behavioral context: the error condition when 0 or >1 matches occur without `replace_all`, and the requirement to add context. This goes beyond annotations but doesn't mention potential side effects on Table DAT structure or whether the edit triggers a cook, so it's not a 5.

  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 sentences deliver a clear purpose, error semantics, and an alternative tool without any filler. The main verb and target appear up front, and every clause earns its place. This is a model of concise, high-signal description.

  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 mutation tool with no output schema, the description covers the target, the matching rules, the `replace_all` switch, and the alternative tool. It's missing details about what happens on error (beyond saying it's an error) and the return value, but the core selection and invocation guidance is complete for the agent's needs.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning to `replace_all` by explaining the exact-match error behavior and that setting it true replaces every occurrence. This is a genuine semantic addition beyond the schema's 'Replace every occurrence' intent, pushing the score above baseline.

  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+resource construct: 'Surgically replace a substring inside a Text or Table DAT's `.text`.' This precisely defines the operation and scope. It also distinguishes from the sibling set_dat_content by explicitly contrasting targeted replacement with full overwrite, making the tool's 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit guidance: use this tool for targeted edits, and use set_dat_content to overwrite an entire DAT's text. It also explains the critical `replace_all` behavior and the exact-match requirement, giving the caller clear usage context and an alternative tool for the other use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_node_parametersA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true. The description goes beyond by warning that a full parameter dump is large, explaining the token economy rationale, and disclosing that inputs/outputs are included unless omitted. This adds practical behavioral context not captured in annotations.

  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?

  Three sentences, front-loaded with the core purpose. The token economy point is repeated twice (keys and omit_io), which is slightly redundant, but the description remains efficient and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple scope (3 params, full schema coverage, output schema exists, annotations present), the description fully covers purpose, usage, alternatives, and performance considerations. No critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  All parameters have schema descriptions (100% coverage), so baseline is 3. The description adds meaning beyond the schema by explaining why to use keys and omit_io (token economy) and that a full dump is large, which ties parameter choices to usage context.

  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 ('read') and resource ('current parameters of one node'), and distinguishes it from siblings by explicitly naming compare_td_nodes for diffing. It also lists the exact return fields, 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names compare_td_nodes as the alternative for diffing two nodes, and explains when to use keys and omit_io for token economy. This gives clear context on when to use this tool vs. alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• image_to_particlesA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses that it builds a new baseCOMP with a specific node structure, may pop the macOS mic-permission dialog when using audio device, resolves sentinel paths, and returns a JSON block with container path, particle count, output path, etc. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph that is front-loaded with the purpose and includes only relevant details. It is appropriately sized for the tool's complexity, though it could be better structured with separations for defaults, return value, and alternatives. Still, every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 12-parameter tool with no output schema, the description is exceptionally complete: it explains the pipeline, default behaviors, return format, permission caveats, and even path resolution quirks ('bare 'Banana.tif' does NOT resolve'). The agent has everything needed to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds high-level context for some parameters (e.g., default source is Banana.tif, audio_source options) but mostly relies on the schema. It does not introduce meaning beyond the schema, which is acceptable given full 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 states a specific verb+resource: 'Turn any image (a file path or an existing TOP) into a GPU particle field'. It details the mechanism (rest position per pixel, colour sampling, spring force) and explicitly distinguishes itself from siblings: 'This is the only particle tool seeded by image/video pixels... pick a sibling instead when particles are NOT driven by an image'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit when-to-use and when-not-to-use guidance is given, naming four alternative tools with their use cases: 'create_gpu_particle_field for a free noise/curl/gravity drift field, create_particle_flock for boids/flocking, create_pop_particle_system for TouchDesigner's native POP particle network, create_particle_system for a simple CPU emitter'. It also clarifies default behavior and opt-in audio sources, including a permission caveat.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• load_session_profileA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds important behavior: it creates a default skeleton if no file exists, overwrites when reset=true, and always returns the resolved path. This clarifies that the tool mutates the filesystem only in controlled ways and adds context about the file path behavior beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is four sentences long, front-loaded with the main action, then adds purpose, edge-case behavior, and a return-field note. Every sentence earns its place without redundant or vague wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has an output schema and only two optional parameters, the description is quite complete: it covers default path, custom path, default creation, reset behavior, and the resolved path in the return. Minor gaps such as error handling for corrupted files are not critical for this simple tool, so a 4 is appropriate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description's mention of 'custom path' and reset=true essentially repeats what the schema parameters already document. It does not add substantive new meaning for the parameters beyond the schema definitions.

  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 ~/.tdmcp/session-profile.json and returns a unified JSON snapshot, with specifics about creating a default if absent. It also distinguishes itself from sibling tools by explaining it caches outputs of four other tools, so the agent can load a session profile without running them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs the agent to load it 'at the start of every session' and frames it as a substitute for running style_memory, recall_similar_work, learn_conventions, and learn_from_my_corpus every time. This provides clear when-to-use guidance and a direct comparison to alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• marketplace_index_seedA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark it as not read-only and destructive, and the description adds critical behavioral context: it writes a file, has a guard, and defaults to not overwriting (overwrite=false protects existing files). This goes beyond the annotation flags and helps the agent predict side effects. However, it does not disclose what happens on conflict beyond failing, which is implicit.

  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 action, and each sentence provides distinct valuable information (purpose/features, then usage/guard). No redundant phrases.

  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 output schema exists, the description doesn't need to detail return values. It covers the tool's purpose, timing relative to a sibling, and the file-safety guard. The remaining parameter details are available in the schema, so the description is sufficient for an agent to understand the tool's role and safe invocation, though it could explicitly mention the failure behavior on existing files for absolute completeness.

  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 only 60% schema description coverage, the description compensates partially by referencing three key parameters: 'built-in seed entries' maps to include_builtin_starters, 'custom package entries' to entries, and it explicitly explains overwrite=false protects existing files. It does not mention the `name` parameter, but the schema covers that with a default. Overall, it clarifies the main functional parameters beyond schema alone.

  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 a specific verb and resource ('Write a guarded starter marketplace index JSON') and immediately distinguishes from the sibling tool (`local_marketplace_index`) by specifying this is the preparatory step. It clearly identifies the tool's output and its role in marketplace setup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The second sentence gives explicit timing ('before local_marketplace_index') and scenario ('when planning a local package marketplace'), naming the alternative sibling tool. This tells the agent exactly when to choose 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.

• merge_vaultsA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark the tool as destructive (destructiveHint=true), but the description adds significant behavioral detail beyond that: it lists the folders walked, the hashing mechanism, conflict resolution strategies with meanings, dryRun behavior, and LF/CRLF conflict caveat. This is exactly the kind of operational context that helps an agent predict side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-organized: one main sentence followed by conflict-resolution details and a note about line endings. Every sentence adds value, though a slightly more compact phrasing could be achieved without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no output schema, 5 parameters, and a destructive action, the description covers all critical aspects: source/target resolution, folder scope, conflict handling, dry-run capability, and even edge-case behavior (LF/CRLF). This is a complete picture for an agent to decide and 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?

  Schema coverage is only 40%, so the description carries important parameter meaning. It explains 'strategy' values ('theirs', 'ours', 'rename', 'skip'), clarifies dryRun as planning without writing, and specifies that targetVaultPath defaults to TDMCP_VAULT_PATH. It does not detail the 'kinds' parameter beyond listing folders, but the schema's enum and default cover that partially.

  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 starts with a specific verb and resource: 'Merge the contents of a source Obsidian vault into a target vault'. It clearly states what the tool does and distinguishes it from vault-related siblings like sync_presets_vault or export_network_to_vault by focusing on full-vault merging with conflict resolution.

  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: it is for merging a source vault into a target vault, with an explicit default target path. It does not explicitly name alternatives or when-not-to-use, but the operation is specific enough that the intended use is obvious.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• repair_networkA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal readOnlyHint=false, destructiveHint=true, openWorldHint=true. The description goes beyond by detailing what destructive actions occur (resetting parameter expressions, re-enabling bypassed ops), the dry_run default that prevents changes, the hard bound max_steps, and the re-check/stop behavior. It also discloses the return object including rolled_back, providing a clear behavioral contract.

  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 somewhat dense but well-structured: it front-loads the core purpose, then explains safety bounds, fix types, return values, and usage. Every sentence contributes value; however, it could be slightly tightened without losing critical details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (autonomous repair, potentially destructive, multiple failure modes), the description covers all essential aspects: operation, bounding, dry_run behavior, safe vs risky fixes, error re-checking, return structure, and usage context. No output schema exists, so the return object explanation adds necessary completeness.

  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 covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds context about how dry_run and max_steps relate to the repair behavior, but it largely reinforces schema information without introducing new parameter semantics.

  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+resource: 'Bounded, autonomous repair' that scans cook errors under a subtree, classifies, and plans a safe fix. It distinguishes from siblings by explicitly naming summarize_td_errors / get_td_node_errors for raw triage, making the tool's unique role clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: 'Use it as the diagnostic "try the obvious safe fixes" loop after a build' and directs to alternatives for raw triage. It also explains the exclusion of risky cases (DAT syntax errors, missing inputs, unclassified errors) which are always PLAN-only, further clarifying appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• vault_repo_syncA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds non-obvious behaviors: 'Never auto-resolves conflicts', 'Never uses --force', 'Never invokes a shell', and 'Conflicts are surfaced as structured data'. It also discloses the environment requirement via TDMCP_VAULT_PATH.

  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 four sentences, front-loaded with the core purpose ('Read-mostly git wrapper'), and every phrase earns its place. No redundancy or filler.

  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 no output schema, the description conveys essential outcomes: status shows changes, pull reports conflicts without auto-resolution, push reports rejections. It does not detail return structures, but the comprehensive schema action descriptions and the description's high-level guarantees suffice for a tool of this complexity.

  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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful context by emphasizing the vault_path argument and explaining that pull is fetch/fast-forward-only, which complements the schema's action details. This surpasses the baseline.

  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 it is a 'Read-mostly git wrapper for the configured Obsidian vault directory' and enumerates specific actions: status, pull, push, log. This distinguishes it from sibling vault tools (e.g., merge_vaults, sync_presets_vault) which are not git wrappers.

  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 defines when to use the tool (for git operations on the vault) and provides explicit constraints: never auto-resolves conflicts, never uses --force, never invokes a shell. It does not explicitly name alternatives or exclusions, but the unique scope is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• add_timecode_overlayA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds substantial behavioral detail beyond the annotations: the timecode is live and re-evaluates every frame, count_down clamps at zero, FPS is probed live with a fallback, and the chain ends in a Null TOP 'out'. It does not contradict the annotations and clearly indicates the tool builds a node chain (consistent with readOnlyHint=false).

  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 dense but every sentence earns its place: implementation approach, mode semantics, formatter location, live FPS probing, sibling distinction, and output terminal. No wasted words. The structure flows from general action to mode details to implementation specifics.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (8 parameters, no output schema, open-world behavior), the description covers everything needed: what it builds, how timecode computation behaves, what the output is ('Null TOP out'), and how it differs from sync_timecode. The schema handles parameter syntax, and the description fills in behavioral context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3, but the description enriches several parameters: it clarifies that 'clock' shows time since project start and is 'NOT the OS wall clock,' that count_up starts from zero when the overlay is built, and that count_down clamps at 00:00:00:00. These are semantic clarifications not present 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 opens with a specific verb and resource: 'Overlay a running HH:MM:SS:FF timecode (or a countdown) onto an input TOP as VISUAL pixels.' It immediately distinguishes itself from sync_timecode, which is a sibling tool for syncing clock signals rather than rendering pixels. This leaves no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly names the closest alternative (sync_timecode) and explains the difference: 'Distinct from sync_timecode, which syncs a CLOCK SIGNAL (no pixels) — this tool draws the timecode into the image.' The mode breakdown (clock/count_up/count_down) also clarifies when each mode should be used.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apply_post_processingA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description details exactly what will be created (a new baseCOMP, Select TOP, effect chain, Null TOP), how it works (pulls source in via Select TOP, wires effects in series), and what is returned (summary, JSON with paths, errors, warnings, preview). This adds substantial behavioral context beyond the annotations, which only indicate non-read-only, non-destructive, open-world 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?

  Three concise sentences: first states purpose, second explains behavior and output, third gives alternative usage. No filler; every sentence contributes value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for a complex tool: it explains the node graph construction, the output structure, and alternatives, and the schema covers parameters and effect enums. The absence of an output schema is compensated by the explicit description of the JSON return block.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already fully describes source_path, parent_path, and effects. The description adds no new parameter-specific semantics beyond restating that effects are applied in order, which the schema also says. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action: 'Chain post-processing effects ... onto an existing TOP, applied in the order given.' It names the resource (existing TOP), the result (new baseCOMP with effects wired in series), and explicitly differentiates from sibling tools like create_color_grade and create_glitch.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: 'Use create_color_grade or create_glitch instead when you want a single dedicated effect with its own exposed controls.' It also notes in the schema that 3D-aware effects are redirected to post_passes_3d, offering clear alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apply_recipeA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description reveals detailed behavioral steps: creating a baseCOMP, wiring nodes, exposing controls, auto-layouting, verifying, and previewing. It also describes the exact return structure (summary plus JSON block) and error handling for unknown ids. This goes well beyond the annotations, providing rich context without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact yet comprehensive: three sentences cover the purpose, the creation process, and the return/error behavior. Each sentence provides distinct value with no redundancy, and key details are front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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, two parameters, and absence of an output schema, the description is exceptionally complete. It explains what the tool does, what it returns, how errors are handled, and even implies the prerequisite of listing recipes. There are no critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already documents both parameters (id, parent_path) with descriptions. The tool description adds extra meaning by referencing list_recipes for the id, clarifying parent_path as the destination COMP, and noting the friendly error for unknown ids. This supplements the schema coverage rather than merely repeating it.

  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 ('Instantiate') and resource ('built-in recipe by id'), clearly distinguishing it from sibling tools like list_recipes (which merely lists) and apply_lut (which applies LUTs). It also specifies the context ('inside a COMP') and the outcome ('creates a new baseCOMP').

  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?

  It explicitly mentions 'from list_recipes', implying the prerequisite workflow, and states that the result is a ready-made network to tweak. However, it does not name explicit alternatives or 'when not to use' scenarios, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• apply_shader_from_vaultA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint: false, destructiveHint: false), the description clarifies that the side effect is node creation in TD, not file writes, and that it returns the created GLSL TOP. It also notes the vault path requirement, adding useful 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loaded with the primary action, and each sentence adds value—covering source, side effect, alternative, return value, and prerequisite. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With annotations, full schema coverage, and a description that includes the side effect, return value, and alternative tool, the description is complete for an agent to select and invoke the tool correctly. No output schema exists, but the description states what is returned.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description adds context about the shader note format but does not add significant new meaning to the individual parameters beyond what the schema already provides (e.g., note as path or name).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool's action: read a shader note from the Obsidian vault and create a GLSL TOP in TouchDesigner. It specifically names the vault as the source and distinguishes itself from create_glsl_shader, which supplies inline code.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit guidance is provided: 'Use this to apply a shader you keep in the vault; to supply shader code inline instead, use create_glsl_shader.' Also mentions the side effect (node creation) and the prerequisite (configured TDMCP_VAULT_PATH).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• auto_tag_library_assetA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Building on annotations (readOnlyHint=false, destructiveHint=false), the description adds meaningful behavioral specifics: write mode merges only when write:true, preserves '*'-pinned user tags, and uses a deterministic heuristic. It also discloses conditional requirements for target types, going well beyond the structured 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?

  Two sentences, front-loaded with the core purpose, then the use case and prerequisites. No wasted words; every clause contributes to understanding. Excellent density without becoming a wall of text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 10-parameter tool with no output schema, the description covers the essential behavior (what it emits), the primary use case, and environmental prerequisites. The detailed parameter descriptions in the schema fill in the rest, so the description is complete enough for an agent to select and invoke the tool confidently.

  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 the schema already explains each parameter. The description adds marginal value by clarifying the write flag's effect and target-specific bridge requirements. This is a slight bump above baseline without duplicating 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 the tool 'inspects a captured library asset' and emits a 'suggested tag set, difficulty, and one-line description', with an optional write mode that merges into frontmatter. It differentiates itself by naming the downstream consumer 'browse_vault_library' and by the 'auto-' prefix in the name, distinguishing it from sibling tagging/search tools.

  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 explicitly says 'Use this to backfill consistent tags across a library so browse_vault_library can find by category', giving a clear when-to-use directive. It also states prerequisites (TDMCP_VAULT_PATH, bridge for td_comp). It does not provide when-not-to-use or explicit alternative tools, but the directive is strong enough for a 4.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_blob_traceA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are minimal (readOnlyHint=false, openWorldHint=true, destructiveHint=false), and the description adds valuable context: it creates a new baseCOMP under parent_path, may prompt for macOS camera permission, follows a specific node pipeline, and returns a detailed JSON result. It does not mention potential overwrites or cleanup behavior, but 'new baseCOMP' implies non-destructive creation consistent with destructiveHint=false.

  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 dense but efficient: four sentences cover pipeline, sibling relationships, source options, node creation, exposed controls, and return value. Every sentence carries substantive information with no filler or redundant restatement of the tool name.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description fully specifies what the tool returns (summary plus JSON block with container path, node paths, output path, controls, errors, warnings, and inline preview). It also explains creation location, source options, and exposed controls, making it complete for a complex 13-parameter 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 coverage is 100%, so baseline is 3, but the description adds pipeline-level meaning (source → monochrome → blur → threshold → Edge → Trace SOP), clarifying how parameters like pre_blur, threshold, edge_only, and invert fit together. It also ties expose_controls to the named Threshold, Blur, and LineWidth controls.

  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 a specific verb and resource: 'Trace the contour/outline of a blob or silhouette into vector line art' followed by a clear pipeline. It explicitly distinguishes itself from siblings: 'complement to create_vector_lines (full image vectoriser) and export_sop_to_svg, and is distinct from create_blob_reactive (which tracks blob position/reactivity — it does not draw the outline).'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is explicitly scoped via sibling differentiation, including when to prefer alternatives (full image vectoriser vs contour trace) and what create_blob_reactive does differently. It also gives practical guidance on source selection: camera, file, synthetic (testable without a camera), or existing TOP.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_color_gradeA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations by detailing the exact node chain created (Level, HSV Adjust, Movie File In, Lookup, Select, Ramp, Null), how the controls are exposed, and precisely what the return value includes (summary, JSON block with paths, exposed controls, errors, warnings, inline preview). It also explains the LUT loading mechanism and the standalone-build behavior, giving full visibility into side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is densely informative yet efficiently structured: it front-loads purpose, then explains mechanism, then input/output behavior, then alternatives. Every sentence contributes either a technical detail, a usage condition, or a critical distinction, with no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, the description fully specifies what the tool returns, covering container path, node paths, exposed controls, errors, warnings, and preview image. The tool's complexity (10 optional params, branching behavior) is fully addressed through the chain explanation, mode behavior, and LUT loading details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%: every parameter already has a detailed description, including exact TOP parameter mappings (e.g., brightness1 not gain). The tool description adds only a high-level chain context (e.g., 'Level TOP applies lift/gamma/gain'), but this does not materially increase semantic understanding 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 opens with a vivid, specific verb-object pairing: 'Build a colour-grading / LUT finishing stage over a source,' and clarifies its niche as 'the make the final output look graded' tool for VJ sets. It also explicitly differentiates itself from the sibling tool apply_post_processing, removing ambiguity about its role.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly states when to choose this tool over an alternative: 'Use apply_post_processing instead to chain several distinct effects in series.' It also explains the two operational modes (with or without input_path), so the agent knows when to supply a source and when the tool will fall back to a test gradient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_data_sourceA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds substantial behavioral context beyond the annotations: it explains the output artifacts (Null CHOP, Null DAT), offline cooking behavior when no url is given, and that live OSC/serial values only appear when a sender/device is present. There is no contradiction with annotations (readOnlyHint=false, openWorldHint=true).

  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 dense but well-structured: it front-loads the core purpose, then breaks down each mode and the resulting data structures. Every sentence adds distinct information, and there is no wasted verbiage.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (10 parameters, 4 modes, no output schema), the description covers the essential behavioral outcomes: the creation of binding-ready channels and a raw text table, offline mode, and the condition that live values require a sender/device. Remaining parameters are self-explanatory via the schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds semantic value by explaining that numeric fields become channels on the output Null CHOP, how omitting `url` triggers static sample cooking, and how `kind` selects the data source mode. This extra context goes beyond the schema's per-parameter descriptions.

  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 ('Ingest') and resource ('live external data onto a binding-ready channel/table'). It explicitly distinguishes itself as the 'input counterpart to create_data_visualization and bind_to_channel', which clarifies its role relative to sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use this tool—when you need to bring external data in for binding—and explains mode-specific usage (json/csv polling, osc listening, serial reading). However, it does not explicitly mention alternative input tools or state when not to use this tool, so it falls short of full alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_displacement_warpA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly=false, destructive=false), the description discloses substantial behavioral details: how the Displace TOP maps to parameters, that Amount and Speed become live knobs, that output is a Null TOP, and that audio mode requires an active audio device/file. It also details the JSON return payload including container path, created nodes, errors, warnings, and preview. This far exceeds annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact yet information-dense, leading with the core purpose and then layering implementation details, modulator explanations, fallback behavior, and return format. Each sentence earns its place, and the structure is logical (what→how→modes→fallback→mapping→returns→pairings).

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (8 parameters, no output schema), the description covers all critical aspects: the node graph built, each modulator's behavior and prerequisites, the standalone source fallback, parameter mappings, exposed controls, return payload, and recommended companion tools. Nothing essential is left unspecified.

  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 100% schema description coverage, the baseline is 3. The tool description adds valuable semantic context by explaining the parameter mappings (amount → displaceweight1, speed → Noise translate speed), the meaning of the three modulator modes, and that the source is pulled via a Select TOP. This enriches the schema descriptions without duplicating them, justifying a 4.

  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 'Build a displacement-warp stage over a source' and specifies it as the 'heat-haze, liquid, audio-pushed pixels' tool for VJ sets. It clearly differentiates this from siblings by naming the three modulator modes (noise, second_top, audio) and the source fallback, making its purpose unmistakable.

  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 clear context for when to use each modulator: 'noise' for smooth continuous warp, 'second_top' for a custom displacement map, and 'audio' for music-reactive effects. It also notes that omitting a source builds a standalone preview over a Ramp TOP. However, it does not explicitly contrast with alternative warp tools or state when not to use this tool, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_dmx_fixture_pipelineA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations state readOnlyHint=false, so the description's 'creates', 'inserts', 'merges', and 'drives' are consistent. The description goes far beyond annotations by disclosing the internal CHOP construction (Constant CHOPs with named channels, pad CHOPs for alignment), the output container and JSON report contents, and the fact that per-fixture sliders are not auto-exposed. This is substantial behavioral transparency.

  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 paragraph that front-loads the core purpose, then details the construction steps, return value, and a critical caveat about slider exposure. Every sentence adds value—no filler. It is appropriately sized given the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description fully covers the return value (container + JSON report with listed contents), the build process, naming conventions, and post-build binding instructions. The annotations and schema handle safety and parameter details, so the description covers all remaining context needed to invoke the tool 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 input schema already has 100% description coverage for all 7 parameters, each with a clear description. The tool description adds meaning by explaining how the 'fixtures' parameter maps to CHOP creation (using the fixture id as a channel prefix) and how 'startChannel' drives pad-CHOP alignment for DMX slots. It also links 'net', 'universe', 'host', and 'fps' to the dmxoutCHOP par names. This justifies a 4.

  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 a specific verb+resource: 'Build a DMX/Art-Net (or sACN) output chain from a fixture list.' It enumerates the supported fixture profiles and the exact CHOP structure built, plus the return value. This clearly distinguishes it from sibling tools such as create_fixture_control, which likely has a narrower scope.

  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 states what the tool does and what it returns, giving an agent clear context for when to use it. It also tells the agent that per-fixture sliders are NOT auto-exposed and directs to bind_to_channel/animate_parameter afterward, which provides follow-up guidance. However, it doesn't explicitly state when not to use it or compare it to alternative pipeline-creation tools, so it earns a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_dome_outputA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only state readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds substantial behavioral detail: it creates a new baseCOMP under parent_path holding Select/GLSL/Null nodes, explains the shader differences for fisheye vs equirectangular, exposes the Rotation knob, and notes the return payload includes node errors, warnings, and a preview image. This fully discloses side effects and expected results 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 dense but well-structured and front-loaded. The first sentence states the core purpose; subsequent sentences cover node architecture, controls, alternatives, caveats, and return values. Every sentence contributes new information, and the length is justified by the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 compensates by clearly enumerating the return payload (container path, node paths, output path, exposed controls, node errors, warnings, inline preview). It also explains the two projection modes, the created network structure, and the cubemap alternative. This is complete for a create-and-wire tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, and all six parameters already have descriptive text. The description reinforces semantics (e.g., fov used by the fisheye shader, projection mode meanings) but does not meaningfully add beyond the structured schema. Baseline 3 is appropriate when the schema carries the parameter detail.

  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 a specific action: 'Remap a source TOP ... into a square single-output dome master for planetarium fulldomes / 360'. It also explicitly distinguishes itself from sibling tools by calling itself 'the curved complement to create_multi_output's flat tiling' and referencing create_cubemap_dome as a different alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage context is explicit and comparative. It names create_multi_output as the flat-tiling alternative and instructs 'use create_cubemap_dome instead for a true cube-map render'. It also clarifies the input expectation ('another source' / 'an existing flat source'), giving the agent clear guidance on when to choose this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_fixture_controlA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the annotations by detailing the internal structure created: a Constant CHOP, dmxoutCHOP, Geometry COMP with a tube-cone beam, and a Render TOP. It explains the expression-driven rotation mapping (pan→ry, tilt→rx) and how DMX values map to degrees. These specifics align with readOnlyHint=false (write operation) and openWorldHint=true (creates multiple nodes) without any contradiction.

  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 dense but well-structured: it is front-loaded with the main purpose, then details the per-fixture construction, then closes with a comparison to the sibling and a usage example. Every sentence adds operational detail, though it is a single long paragraph that could benefit from light segmentation for readability.

  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 an 11-parameter tool with nested fixture objects, the description provides a comprehensive mental model of the resulting network, including the dmxoutCHOP and previz components. It gives a concrete usage example (op('rig_out')['fix1/pan']) that helps agents understand how to interact with the outputs. The main gap is not explicitly stating what the function returns (e.g., the path to the created rig), but given the openWorldHint and detailed creation steps, this is a minor omission.

  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 100% schema description coverage, the baseline is 3. The description adds value by showing how parameters connect to implementation, e.g., 'padded and merged into a dmxoutCHOP (interface, universe, netaddress, rate)' corresponds to net/universe/host/fps, and '0-255 mapped across pan_range/tilt_range degrees' directly references pan_range and tilt_range. It also references the 'id' field via '<id>/…', adding relational context beyond individual parameter descriptions.

  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 'Build a moving-head lighting rig with BOTH a DMX/Art-Net output chain AND a 3D visual previsualization,' clearly stating the verb and resource. It also explicitly differentiates from the sibling create_dmx_fixture_pipeline by noting it adds 'the live 3D preview on top of what create_dmx_fixture_pipeline (DMX-out only) does,' making the tool's unique role unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly references create_dmx_fixture_pipeline as the DMX-only alternative, telling users when to choose this tool (when 3D previz is needed). It also provides post-creation guidance: 'Bind individual channels later with bind_to_channel / animate_parameter on op('rig_out')['fix1/pan']', showing how to use the created rig. This combines an explicit alternative with concrete usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_glsl_materialA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond annotations by disclosing side effects: shader sources placed in companion Text DATs with specific naming conventions, wiring to GLSL MAT parameters, best-effort uniform binding, and known TouchDesigner GLSL footguns. It also states the return value (MAT paths, DAT paths, warnings) and that the artist must assign the MAT to a Geometry COMP. This is rich behavioral transparency.

  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 dense yet well-structured, starting with the core action and then covering side effects, requirements, return values, and footguns. Every sentence adds necessary information; there is no filler or repetition of obvious schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (9 parameters, no output schema, multiple shader stages, uniform binding, and known pitfalls), the description is exceptionally complete. It covers what is created, how it is wired, what the return value contains, what prerequisites exist (fragColor declaration), and what the caller must do afterward (assign the MAT). This leaves little ambiguity for an agent.

  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?

  Although the input schema already documents every parameter (100% coverage), the description adds meaningful cross-parameter semantics: how shader sources map to DAT names (`<name>_pix`/`_vert`/`_geo`), how the uniforms array maps numeric types to the Vectors page and sampler types to the Samplers page, and the requirement that pixel shader declares `out vec4 fragColor;`. This elevates the parameter understanding beyond individual field descriptions.

  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 'Create a GLSL MAT under parent_path for custom-shaded geometry,' which is a specific verb+resource+scope. It clearly differentiates from sibling tools like create_glsl_shader by framing the output as a material (MAT) with companion Text DATs wired to it, not just a shader object.

  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 gives clear context on when to use the tool: when you need a GLSL material for custom-shaded geometry, with shader sources and uniforms. It does not explicitly name alternatives or exclusion conditions (e.g., 'if you only need a shader, use create_glsl_shader'), so it falls short of a 5, but the usage context is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_keyerA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses the full chain creation ('source (Select TOP or test card) → key stage → composite → Null TOP output'), the exposed controls on the container, and the return summary with 'node errors, warnings, and an inline preview image'. This is rich behavioral context beyond what annotations provide.

  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?

  Every sentence contributes distinct information: purpose, chain structure, mode comparisons, parameter roles, and return behavior. It is dense but not bloated, and it is front-loaded with the main verb and resource.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 compensates by explicitly detailing return values (container path, created node paths, exposed controls, errors, warnings, inline preview). It also covers optional inputs and the built output topology, making it complete for a complex creation 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 coverage is 100%, so the parameters are already described. The description adds workflow-level meaning, such as 'key_color sets the target colour to remove (chroma/rgb modes)' and the fallback test card when no source is given, which helps the agent understand parameter relationships and optional behaviors.

  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 'Composite a keyed performer, logo, or any source over a background visual' and explicitly labels it as 'the green-screen / chroma-key / matte tool'. This is a specific verb+resource that distinguishes it from generic create_* tools, and it further details the three key_type modes to eliminate ambiguity.

  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 context ('for installations and live camera work') and explains conditional behavior (with/without a source or background). However, it does not explicitly name alternatives or state when not to use this tool, though the context makes the intended use clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_keyframe_animationA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses creation of a baseCOMP under parent_path, an Execute DAT that interpolates each frame, writing to target parameters, loop/hold behavior, return summary/JSON block, and error handling for non-positive duration. This goes well beyond the annotation hints (readOnly=false, destructive=false) and provides rich 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise yet complete, front-loading the core purpose, then mechanics, use case, return format, and error condition. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 explicitly details the return value (summary plus JSON block with container path, hook path, loop duration, targets, warnings) and error behavior. Combined with a fully documented schema and annotations, this is a complete and self-sufficient definition for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 5 parameters with descriptions (100% coverage), so the baseline is 3. The description reinforces relationships (keyframes are time/value, targets are nodePath.parName) but does not add new meaning 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 the tool animates parameters along a keyframed curve synced to the timeline, explicitly distinguishing it from animate_parameter's LFO behavior. It names the resource (keyframed animation, baseCOMP 'keyframe_anim') and the action (animate parameters).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly advises using animate_parameter for continuous LFO oscillation and this tool for choreographed moves (build-up, drop, sweep). This gives clear when-to-use and when-not-to-use guidance relative to a sibling tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_layer_mixerA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing specific behaviors: it creates a baseCOMP, uses Select TOPs, auto-creates demo sources when fewer than two inputs, outputs a Null, and returns a detailed JSON summary including errors, warnings, and a preview image. This gives the agent a clear mental model of what happens.

  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 four sentences, each packed with essential information: what it does, how blend modes work, the Select TOPs and demo behavior, and the return format. There is no fluff or redundancy; it is well-structured and front-loaded with the primary purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even without an output schema, the description fully explains the return value (summary plus JSON block with paths, controls, errors, warnings, and preview). It also covers edge cases (fewer than two inputs) and the downstream use (Null ready for post-processing). Given the tool's moderate complexity, this is 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 already documents all four parameters with 100% description coverage, so the baseline is 3. The description adds extra meaning by explaining the effect of the 'blend' parameter ('crossfade makes an A/B Cross TOP with a Crossfade knob; any other blend mode composites the inputs') and the demo-source fallback for the 'inputs' parameter. This adds value beyond the schema, but not dramatically so, hence a 4.

  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 a specific verb and resource: 'Build a VJ-style layer mixer: combine source TOPs into one output. Creates a new baseCOMP under parent_path.' It clearly distinguishes this tool as a mixer for visual layers, with the key output being a baseCOMP. This is distinct from sibling tools like create_layer_stack or create_visual_system, and the scope 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 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 the tool: for VJ-style mixing of TOPs, with specific blend modes (crossfade vs. composite). It also explains the output readiness ('Output is a Null ready for post-processing or setup_output'). However, it doesn't explicitly state when not to use it or name alternative tools, so it stops short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_live_sourceA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses critical runtime behaviors: camera can hang TouchDesigner on a macOS permission modal, NDI requires runtime, Syphon/Spout are OS-specific, and par names are probed defensively turning build differences into warnings. This is substantial behavioral context that annotations alone do not provide.

  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?

  Three sentences, each earning its place: the first states the core build action and output, the second covers safety/permission/platform caveats, and the third explains defensive probing. Dense but not bloated, and front-loaded with the most important information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description states the output clearly ('exposes a named Null TOP output'). It accounts for all 5 parameters, platform quirks, permission risks, and defensive behavior. For a creation tool with zero required parameters, this is exceptionally 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?

  Input schema covers 100% of parameters, so the baseline is 3. The description adds extra meaning by linking `source_name` to all source kinds and explaining defensive probing of par names, which clarifies how the parameter behaves in different TD builds. It also frames `resolution` as part of a Fit/Resolution stage, adding context 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 opens with a specific verb+resource: 'Build a self-contained source COMP that ingests an external feed...' and enumerates exact source kinds (screen grab, NDI, Syphon/Spout, camera, video stream). It clearly distinguishes this tool from generic create_* tools by emphasizing the input-layer role and the Null TOP output.

  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?

  It provides explicit guidance on when to use each `kind` value (e.g., screen_grab is safe for testing, camera can hang on macOS, NDI/Syphon/Spout are platform-gated). However, it does not name alternative sibling tools or state conditions where this tool should not be used, so it stops short of full exclusions/alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_motion_reactiveA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite annotations already flagging write/open-world behavior, the description adds substantial context beyond them: macOS camera-permission side effects, creation of a baseCOMP and child nodes under parent_path, the macOS optical-flow restriction, and the exact return shape (summary + JSON block). It also discloses that 'no preview image' is returned because the output is a CHOP, not a TOP. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but every clause earns its place — purpose is front-loaded, then usage, then creation/behavior details, then return format. It is well-structured with no filler or repetition of schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex creation tool with no output schema, yet the description fully covers return values (summary + JSON block with container path, node paths, channel names, controls, errors, warnings), side-effect behavior, platform caveats, and all source variants. The high complexity and absent output schema demand exactly this level of detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, and each parameter already has rich schema descriptions (source enum values, resolution tradeoff, conditional file paths). The description reinforces the Sensitivity knob context and the downsized analysis chain but does not add meaning beyond what the schema already provides, so the baseline of 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Build a video-analysis chain that exposes ready-to-bind reactive channels — overall brightness plus frame-to-frame motion energy — on a Null CHOP.' It clearly differentiates from siblings by explicitly positioning itself as 'The camera counterpart to extract_audio_features' and by noting that optical flow is unavailable on macOS (distinguishing it from create_optical_flow).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly names the sibling alternative (extract_audio_features), explains the exact binding pattern to the output channels, and gives source-selection guidance — 'synthetic' is 'handy for testing without any device permission,' 'existing_top' analyzes an existing TOP, and camera may prompt for macOS permission. The macOS optical-flow limitation also clarifies when the tool should not be used.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_particle_flockA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite annotations being minimal, the description reveals extensive behavioral detail: it creates a baseCOMP under parent_path with specific components, uses GPU feedback loops, exposes live knobs, and returns a detailed JSON with node paths and errors. There is no contradiction with readOnlyHint=false, openWorldHint=true, or destructiveHint=false; the creation is consistent with these hints.

  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 long but every sentence delivers value: it front-loads the main purpose, describes the internal GPU mechanism, gives sibling comparisons, states the timeline requirement, and enumerates the return payload. The structure is logical and repetitive content is absent, making it appropriately concise for the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (GPU simulation, multiple components) and absence of an output schema, the description covers all necessary context: what is built, how it works, when to use it, runtime caveats, and exactly what the response contains. This allows an agent to invoke the tool correctly without additional information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the baseline is 3. The description adds no significant parameter-level semantics beyond what the schema already provides; it only references exposed controls (Separation, Alignment, Cohesion, Speed), echoing the expose_controls parameter. Thus it stays at baseline.

  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 a specific verb and resource: 'Build a boids-style GPU particle flock', clearly defining the tool's core function. It also distinguishes from siblings by naming create_gpu_particle_field, image_to_particles, create_pop_particle_system, and create_particle_system, so an agent can easily tell this tool apart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly provides usage guidance: it names alternatives and when to prefer them (e.g., 'use create_gpu_particle_field for curl-noise/gravity drift rather than flocking'). It also adds a critical runtime condition: the flock only evolves while the TD timeline plays, which is essential for correct use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_particle_systemA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false, but the description goes far beyond by detailing side effects: it creates a baseCOMP with specific contents, exposes live knobs, returns warnings for approximated forces and fallback render styles, and describes the return block structure. No contradictions with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Though long, every sentence delivers value: pipeline explanation, output structure, usage guidance, alternatives, and return format. It is front-loaded with the core purpose and clearly structured, avoiding redundancy with the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 properly explains the return value (summary plus JSON block with paths, controls, errors, warnings, preview image). It covers creation details, limitations (approximations, fallbacks), alternatives, and exposed knobs, making it fully self-sufficient for an agent to decide and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100% for all 7 parameters, so the baseline is 3. The description adds high-level context (e.g., 'Forces and render style are scaffolded for further tuning', 'Exposes live Drag / Turbulence / Gravity / Lifetime knobs') but these details are already present in the schema descriptions. It does not add significant new meaning 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 uses a specific verb ('Build') and resource ('CPU particle system'), details the exact node pipeline (emitter SOP → Particle SOP in Geometry COMP), and clearly differentiates from sibling tools by naming them with their specific use cases (GPU field, flock, image-to-particles, POP system).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use this tool ('simplest CPU emitter') and provides clear alternatives with rationale: 'pick a sibling instead when you need scale or specific motion', listing create_gpu_particle_field, create_particle_flock, image_to_particles, and create_pop_particle_system. Also notes behavior for forces and render styles.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pop_geometryA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations present (readOnlyHint=false, destructiveHint=false), the description adds rich behavioral context: it creates a baseCOMP under parent_path, exposes a RotateY control, and conditionally exposes Noise knobs only when noise_amount>0, explaining the Noise SOP is otherwise omitted. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is densely informative but well-structured: chain diagram, creation details, exposure logic, and alternatives. Every sentence adds value with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 11 parameters and no output schema, the description fully explains the generated result (new baseCOMP, rendered to Null TOP), the conditional behavior, and alternatives. It is complete for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and all parameters have detailed descriptions. The tool description repeats some schema info (e.g., conditional knob exposure) but adds no meaning beyond what the schema already provides, so baseline 3 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it's a 'Procedural Op Pattern (POP) geometry generator' that builds a SOP chain and renders through a Camera+Light+Render TOP, creating a new baseCOMP. It distinguishes from siblings by explicitly naming alternatives like build_sop_geometry and create_3d_scene.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage guidance: 'Use build_sop_geometry for a fully declarative SOP chain without a render rig; use create_3d_scene for instanced primitives, create_pbr_scene for PBR shading.' This clearly states when to prefer alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pose_reactiveA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses side effects: it creates a fresh baseCOMP with a Select→Math→Hold→Filter→Limit→Rename chain merged into null_out, exposes a Reactive custom page, writes expression-mode binds with failures as warnings, and emits a warning for constant tz. This exceeds what annotations alone convey and adds valuable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but every sentence earns its place, covering purpose, pipeline, metrics, bindings, controls, and a data-quality warning. It is front-loaded with the main purpose and flows logically. For a tool with 8 parameters and complex behavior, this length is appropriate and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is highly complete given the tool's complexity: it explains the whole workflow, the output structure, the supported metrics, the bindings behavior, the exposed controls, and the critical MediaPipe 2D-landmark caveat. Even without an output schema, the agent knows what to expect (a Null CHOP with channels and a Reactive page). No gaps are evident.

  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% and individual parameter descriptions are already detailed, so the baseline is 3. The tool description adds extra meaning by explaining the internal processing chain (Select→Math→Hold→Filter→Limit→Rename), the exact behavior of bindings (expression-mode, same shape as bind_to_channel, warning instead of throw), and the reliability caveat for z/angle/velocity metrics. This supplements the schema rather than merely repeating it.

  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: it takes a 33-sample MediaPipe pose CHOP and derives scalar reactive channels (right-hand height, distance, angle, velocity, etc.) into a Null CHOP. It explicitly distinguishes itself from bind_audio_reactive and references setup_body_tracking, providing a specific verb+resource+output structure.

  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 gives clear context when to use the tool (body-pose reactivity) and prerequisites (run setup_body_tracking first). It implies alternatives by naming bind_audio_reactive and warns about unreliable metrics, but does not explicitly list when not to use it versus other body-reactive tools. This is strong but not fully explicit about exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_safety_blackout_chainA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=true. The description adds valuable behavioral context beyond these flags: the chain is deterministic, Python-free at cook time, ALLOW_EXEC=0-safe, and built at the end of the master output chain (which implies it modifies the output path). It does not contradict annotations, and while it does not elaborate on the destructive implications, it sufficiently discloses the tool's construction and safety characteristics.

  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?

  Though the description is a long sentence, every clause provides essential information: purpose, placement, capabilities, technical mechanism, complementary tool, and return value. It is front-loaded with the core action and avoids redundant filler. The structure is efficient given the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool is complex (11 params, 0 required, no output schema). The description covers what the tool creates, where it fits in the signal chain, how it is triggered (hotkey, watchdog, emergency), the recovery behavior, the Python-free safety aspect, and explicitly enumerates the returned node paths. This fully compensates for the lack of an output schema and gives the agent a complete mental model.

  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?

  All 11 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds a cohesive semantic layer by describing how parameters interact: 'configurable time', 'optional emergency single-frame hard-cut', 'optional hotkey + external watchdog trigger', and 'symmetric fade-in recovery'. It reinforces that 'All reactivity is parameter-driven... no Python runs at cook time', which helps the agent understand the overall parameter architecture beyond individual parameter descriptions.

  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 exactly what the tool does: 'Build a live-show safety primitive at the very end of the master output chain' with specific capabilities (fade-to-black, emergency cut, hotkey, watchdog, fade-in recovery). It is a specific verb+resource, and it distinguishes from sibling create_panic by explicitly positioning itself as the 'master-output dimmer' complement.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context: it is for live-show safety at the end of the master output chain, and it explicitly names the alternative `create_panic` and differentiates: 'Complements create_panic (per-source kill+freeze) by being the master-output dimmer with grace, recovery, and a watchdog hook.' This is an explicit when-to-use vs. alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_setlist_runnerA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the full construction behavior: builds a baseCOMP with N Select TOPs, Switch/Cross TOPs for crossfades, optional HUD, Timer CHOP + CHOP Execute auto-advance engine, and live custom params. It also states the output path (Null TOP at `<parent>/<name>/out`). This is far beyond what annotations (readOnlyHint false, openWorldHint true, destructiveHint false) communicate, and there is no contradiction.

  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 dense, front-loaded sentences capture the tool's purpose, construction details, output, and positioning relative to siblings. Every clause earns its place, and the description is structured logically from what it does, to how it does it, to where the output lands, to when to use it.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (8 parameters, nested rows, no output schema), the description is remarkably complete. It explains the generated node graph, the auto-advance timeline behavior, the HUD option, the custom stage override params, and the exact output path. It also situates the tool among related siblings, leaving little ambiguity about its capabilities or intended use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a clear description, so the baseline is 3. The tool description adds contextual meaning by explaining that rows drive the construction ("Pass rows[]... builds a baseCOMP") and mentions the custom params for stage overrides, but it does not add syntax or relationship details beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description leads with a specific verb+resource: "Layer-1 wall-clock setlist player for rehearsed VJ shows," and then details the exact components built (Select TOPs, Switch TOP, Cross TOP, HUD, Timer CHOP engine). It explicitly distinguishes itself from sibling tools, create_clip_launcher and create_cue_sequencer, by positioning itself as the wall-clock gap-filler.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use context: "For rehearsed VJ shows" and "Fills the gap between create_clip_launcher (manual grid) and create_cue_sequencer (musical bars)." This clearly names the alternatives and explains the specific niche, giving the agent direct guidance on tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_vector_linesA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behavioral traits beyond annotations: the non-realtime pulse-driven nature, intentional cook cost bounding, default source behavior to avoid camera permissions, and that camera is opt-in. It also states it returns warnings for unverified details. This adds significant context over the basic readOnly/destructive hints.

  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 paragraph with four sentences, each adding essential context: pipeline, non-realtime constraint, source defaults, exposed controls, and return values. It is long but proportionate to the tool's 22 parameters, and every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 22 parameters and no output schema, the description is remarkably complete: it explains the full workflow, the phase boundaries, default source rationale, control exposure, and return values (container, paths, warnings, preview). The schema covers individual parameters, and the description ties them together effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% so baseline is 3, but the description adds value by naming exposed controls (Vectorize, Threshold, PreBlur, StepSize, Smooth/Fit/Border, line color/width, opacity, overlay mode) and explaining source defaults and camera opt-in, which enriches the meaning of the source and control 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 opens with 'Build a pulse-driven image-to-vector-lines system' which is a specific verb+resource that clearly differentiates it from sibling tools. It details the full pipeline (source capture, mask, snapshot, Trace SOP, overlay, composite), leaving no ambiguity about what the tool creates.

  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 gives clear usage context: it is intentionally non-realtime, uses a default synthetic source for safe preview, and camera is opt-in. It implicitly warns against realtime use by noting the Vectorize pulse bounds cook cost, but it does not name explicit alternative tools or state when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_vertex_displacement_matA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already signal readOnly=false and destructive=false; the description adds behavioral detail by explaining it creates a new baseCOMP under parent_path, may build a demo scene, and returns a JSON summary with node paths and preview. This goes beyond annotations without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense yet efficiently organized: it opens with the core purpose, then sibling distinction, then param-mode behavior, and ends with the return summary. Every sentence contributes and there is no repetition or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite lacking an output schema, it thoroughly describes the return payload (summary, JSON block with paths, exposed controls, errors, warnings, preview). It also covers creation side effects and the demo mode, providing a complete picture for a tool with 9 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds value by clarifying relationships, e.g., 'frequency is ignored when texture_path is set,' explaining that target_geo is for existing geometry vs demo mode, and confirming expose_controls binds Amount/Frequency/Speed. These details enrich the schema's field descriptions.

  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 builds a 'true vertex-shader displacement material' and explicitly distinguishes it from the sibling tools create_depth_displacement and create_displacement_warp by noting those 'push 2D pixels' while this 'pushes mesh vertices.' This is a specific verb+resource+scope with clear differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives explicit when-to-use guidance: assign to a Geometry COMP via target_geo, or omit to build a standalone demo. It also states when not to use it (for TOP-space image warps use the siblings), making the decision criteria unmistakable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_video_scopesA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses meaningful behavior: the histogram panel is silently skipped in TD 099, the default source requires no device permission, and the rendering pipeline is detailed. This adds value beyond structured 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?

  Four sentences, each earning its place: purpose, technical pipeline, companion distinction, and unsupported feature caveat. No filler, logically front-loaded with the core purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Although the tool has 14 parameters and no output schema, the description covers the essential context: what it builds, how it renders, default behavior, companion tools, and a known limitation. The rich schema handles parameter specifics.

  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?

  All 14 parameters have full descriptions in the input schema (100% coverage), so the description does not need to explain parameters. It adds only minimal extra context about source and histogram, which is already largely present in schema descriptions.

  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 ('Build a broadcast-style video engineering monitor') with clear scope details (waveform, RGB parade, vectorscope) and distinguishes itself from sibling tools by explicitly naming create_waveform (audio) and create_spectrum (audio frequency) as companions, and directing to create_histogram_scope for histograms.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: names companion tools for audio-focused needs, points to create_histogram_scope for working histograms, explains the default test pattern source avoids permissions, and flags device as opt-in with potential macOS permission modal issues.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_vintage_lensA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations, the description discloses that it creates a new baseCOMP with four ordered GLSL passes, how era presets interact with per-parameter overrides, and the exact return envelope including paths, preview, warnings, and resolved strengths. This gives the agent a solid behavioral model of side effects and outputs.

  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?

  Four front-loaded sentences with no filler: the first states the purpose, the second details the pipeline, the third explains presets/overrides, and the fourth lists return values. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 8 parameters and no output schema, the description covers purpose, pipeline, preset behavior, and the full return envelope. The schema already documents each parameter, so together they provide enough information to invoke the tool 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?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the chain order (distortion → chromatic aberration → vignette → grain) that ties the strength parameters together, and clarifies that era presets are overridden by individual parameters. It doesn't re-describe each parameter but enriches the overall semantics.

  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 'Drape a vintage analog-film aesthetic over any TOP in one call,' naming a specific verb, resource, and scope. It further distinguishes itself from siblings by detailing the exact four-pass GLSL chain and era presets, making its function unmistakable.

  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?

  It gives clear context: use this when you want a vintage analog-film look applied to any TOP, with era presets and per-parameter overrides. It does not explicitly name alternatives or when-not-to-use cases, but the intended use case is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_volumetric_fieldA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the sparse annotations by disclosing the full toolchain architecture (noiseTOP → cacheTOP → viewer glslTOP), the approximation nature ('stacked-2D-slice approximation'), performance scaling ('cook cost scales roughly linearly with slice_count × resolution'), and the return format (summary JSON with node errors, warnings, inline preview). These are important behavioral traits that annotations do not cover.

  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 dense but every sentence adds value: it covers purpose, architecture, limitation, performance, and return format in a structured flow. It is front-loaded with the core concept and uses no filler. The length is justified by the technical complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 7 parameters fully documented in the schema, the description focuses on what the schema cannot convey: architecture, performance, limitations, and output. It clearly states the return JSON fields, addresses the main limitation (2D-slice approximation), and gives actionable performance advice. This is comprehensive for a creation 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 coverage is 100%, providing a solid baseline of 3. The description adds extra context beyond the schema, such as recommending lower slice counts on integrated GPUs ('drop to 4–8') and explaining the impact of slice_count on rewiring the cache. It also clarifies the turbulence parameter's effect on displacement and noise period, adding practical meaning.

  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 starts with a specific verb and resource: 'Build a stacked-slice fake-volumetric noise field'. It lists palettes and explicitly distinguishes itself from a raymarched volume ('NOT a raymarched volume'), which differentiates it from sibling tools like create_volumetric_raymarch. The architecture summary and mention of optional displace+blur further clarify the scope.

  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 explicitly says when not to use this tool: 'For a true raymarcher see the planned create_volumetric_raymarch'. It also gives performance guidance ('drop to 4–8 on integrated GPUs'), which helps in choosing appropriate parameters. However, it does not compare against other volume-related siblings like create_sdf_field or create_raymarch_scene, so it lacks a broader when-to-use context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• detect_onsetsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only state readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds substantial behavioral detail beyond that: it walks through the signal chain (band filter -> RMS -> baseline compare -> threshold), explains the macOS permission prompt, describes the output pulse channel, and mentions the optional WebSocket event broadcast. This gives the agent a clear mental model of what the tool does at runtime.

  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 dense but well-structured, covering purpose, differentiation, internals, sources, events, and relationship to a sibling. It is somewhat long and repeats the 'Unlike create_tempo_sync' idea twice (once at the start and once at the end), which is slightly redundant. Still, every paragraph contributes meaningful 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?

  For a complex creation tool with 10 parameters and no output schema, the description covers the essential aspects: what is built, how it behaves, what sources are supported, and a notable side effect (macOS permission prompt). It could have mentioned how the generated container integrates with the existing network or how to access the per-band channels, but the provided details are sufficient for an agent to invoke it 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?

  Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how the Threshold and Sensitivity knobs relate to the detection chain, and it mentions the source options (live device, file, oscillator, existing CHOP) in context. This goes beyond per-parameter schema descriptions, though not every parameter is elaborated in the description itself.

  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 a specific verb and resource: 'Build a transient/onset detector that flags kick/snare/hi-hat hits in live audio and exposes a per-band pulse channel... on a Null CHOP.' It explicitly distinguishes itself from the sibling create_tempo_sync by stating it follows actual audio rather than a fixed internal clock, making the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly contrasts with create_tempo_sync ('Unlike create_tempo_sync') and even calls itself 'the audio-following complement to create_tempo_sync.' It provides concrete use cases (e.g., bind a parameter to flash or cut on kick), making it clear when to choose this tool over the tempo-sync alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• detect_tempoA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (which only indicate non-read-only and open-world), the description discloses concrete behaviors: it creates a Null CHOP with a 'bpm' channel, can write to global tempo when drive_tempo is on, may hang on macOS permission modal with device source, reads 0 on a paused timeline, can lock to half/double time, and requires live tuning. This is rich, honest context.

  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 dense but every sentence earns its place: purpose, algorithm, output, integration, source options, and caveats are all covered. It is front-loaded with the key experimental label and core function, and the structure flows logically from what → how → when → caution.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (10 parameters, no output schema, and nontrivial behavioral caveats), the description covers all essential angles: detection method, output channel path, global tempo integration, source selection, and failure modes. It is sufficiently complete for an agent to invoke and interpret the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and each parameter already has a detailed description (e.g., source rationale, min/max clamps, sensitivity mapping). The tool description adds overall algorithmic context but does not significantly augment individual parameter semantics beyond what the schema already states, so the baseline of 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'automatic tempo (BPM) detection WITHOUT manual tapping,' and clearly distinguishes itself from sibling tools by noting it 'Complements sync_external_clock (which is tap-tempo) and detect_onsets (which flags hits but derives no tempo).' This makes both purpose and differentiation explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear when-to-use guidance by contrasting with tap-tempo and onset-only tools, and provides practical source-selection advice (defaults to synthetic to avoid macOS permission hang, also accepts file/existing/device). The drive_tempo option's downstream effect on Beat CHOPs is also explained, helping the agent decide when this tool fits.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• disconnect_nodesA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations, the description discloses important runtime behaviors: returns a list of removed wires, a probe of Connector API attributes, and per-wire warnings. It also explains failure semantics ('Fatal only when to_path is not found — partial removals with per-wire warnings still succeed') and implies mutation consistent with readOnlyHint=false.

  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?

  Four sentences, front-loaded with the core action. Every sentence adds distinct value: scope, return values, error behavior, and relationship to connect_nodes. No redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 fully explains return values and error conditions. It covers the default behavior, scoping options, partial failure handling, and the inverse relationship. This is complete for a 3-parameter tool with high schema coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds meaningful context on how parameters interact: 'narrow the scope with from_path (only wires from that upstream node) and/or to_input (only that input slot index).' This clarifies the combined filtering behavior beyond individual schema descriptions.

  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 a specific verb and resource: 'Remove one or more input wires from a node in TouchDesigner.' It clearly distinguishes itself from the inverse operation by stating 'The inverse of connect_nodes.' This is explicit 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?

  The description provides clear usage context: default behavior (removes every incoming wire), how to narrow scope via from_path and to_input, and partial success behavior. It mentions 'The inverse of connect_nodes' as an alternative, though it doesn't explicitly say when not to use this tool versus other wire-related operations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_externalized_treeA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by detailing that files are written under out_dir (destructive), that the live COMP's externaltox parameter is mutated, and that out_dir must be writable by the TouchDesigner process. These specifics disclose side effects and prerequisites not covered by structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, dense but well-organized. It starts with the core action, then explains the mechanism, side effects, and a key constraint without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the output schema exists, the description provides sufficient context about what the tool does, its side effects, recurse semantics, and filesystem requirements. It is complete for an agent to decide when and how to invoke it.

  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?

  While the schema already covers all parameters, the description adds meaningful context: out_dir must be reachable by the TD process, recurse=true externalizes descendants, and name defaults to the last path segment of comp_path. This enriches the schema information.

  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 saves a COMP as a git-diffable externalized .tox tree, naming the underlying mechanism (COMP.saveExternalTox). It distinguishes this from an opaque binary save and contrasts with related tools like make_portable_tox by emphasizing per-node diffs for version control.

  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 explains why you would use this over saving a single binary (git-diffability, per-node diffs) and describes the recurse option's behavior. It does not explicitly name alternatives or state when not to use the tool, but the use case is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_network_to_vaultA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses that the note is 'fully rewritten on each call,' which is important behavioral context beyond the annotations. Also describes the side effect (vault graph becomes a clickable map) and return value (note path, node/connection counts, truncation flag). No contradiction with readOnlyHint=false or destructiveHint=false.

  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 every sentence carries essential information: what it does, output format, default behavior, alternative usage, return values, and prerequisite. No filler or redundant repetition of schema/annotations.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a three-parameter tool with no output schema, the description adequately covers what is returned, the file behavior, the environment requirement, and the distinction from a sibling. This gives an agent enough context to invoke it correctly and interpret the result.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the schema already documents all three parameters (note, path, recursive). The description adds little additional parameter-level meaning beyond what is in the input schema, so baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action: READ an existing TD network's topology and WRITE it as an Obsidian note, including Mermaid flowchart and wikilinks. It also distinguishes itself from the sibling document_network by clarifying that this tool persists to the vault while the alternative returns documentation without touching the vault.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says 'Use this to persist a browsable map in the vault; use document_network to get the same documentation back as a tool result without touching the vault.' This gives clear when-to-use guidance and names the alternative tool. It also notes the TDMCP_VAULT_PATH requirement, which is a prerequisite for use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_recipe_bundleA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already flag destructiveHint=true and readOnlyHint=false. The description adds useful behavior beyond that: unknown IDs appear in 'missing' rather than being silently substituted, and it discloses the return payload (bundle kind, version, timestamp, exported recipes, missing IDs). It does not explicitly discuss file overwrite semantics, but the destructive hint covers that risk.

  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?

  Three tight sentences, front-loaded with the primary action, no fluff, and every sentence earns its place: purpose, conditional logic, sibling guidance, and return value summary. Ideal density.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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, the presence of a full output schema, and rich annotations, this description is fully sufficient. It covers all decision points, error handling (missing IDs), and output essentials without needing to restate schema details. The agent can select and invoke this tool correctly with no gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description enriches the parameter semantics by explaining the conditional interaction: when include_all=true, recipe_ids is ignored; unknown IDs are surfaced in 'missing'. This goes beyond the schema's per-parameter descriptions and clarifies the actual runtime behavior.

  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 a specific verb+resource+output: 'Write a portable JSON recipe bundle to out_file.' It clearly differentiates from siblings by naming import_recipe_bundle (restore) and publish_recipe_bundle (checksums/versioned artifacts), making its 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly explains when to use this tool vs alternatives: 'Use import_recipe_bundle to restore the bundle on another machine or publish_recipe_bundle when you need checksums/versioned handoff artifacts.' Also clarifies the include_all/recipe_ids selection logic, so the agent knows exactly how to invoke the right option.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• find_td_nodesA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses behavior beyond annotations: it's 'Read-only' (consistent with readOnlyHint), notes it returns '{count, truncated, matches/paths, search_metadata} without transferring topology' (efficient/compact), and states 'older bridges fall back only to structured list/topology reads' (fallback behavior). This adds significant context without contradicting 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?

  Three concise sentences cover purpose, return format/fallback, and usage guidance. Front-loaded with the main function, and every sentence adds value. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite 13 parameters, the description covers purpose, return fields, fallback behavior, and sibling differentiation. With a full output schema and 100% parameter descriptions, nothing critical is missing. The guidance about older bridges addresses edge cases in tool availability.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the description doesn't need to explain individual parameters. The description does synthesize key concepts ('name/path glob', 'exact or partial operator type', 'family', 'bounded depth') which map to schema params, but adds no new meaning beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it's a node search tool with specific filter capabilities: 'compact bridge-side node search by name/path glob, exact or partial operator type, family and bounded depth.' It also distinguishes from siblings by explicitly naming get_td_nodes and get_td_topology and when to use each.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage guidance: 'Prefer this over get_td_nodes when looking through a sub-tree; use get_td_topology only when you need wiring.' Also notes fallback behavior for older bridges, so the agent knows when this tool's advanced features may not be available.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_dat_contentA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds significant context: return structure (total counts, header, sliced page, preview, row_range), the lossy split caveat for cells with embedded tabs/newlines, and the advisory to probe live data. This goes well beyond the annotation baseline, though it doesn't cover error handling or invalid 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?

  Two sentences, densely packed with essential information. The first sentence front-loads the purpose and return values; the second provides a critical caveat and points to write tools. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 fully explains the return values (total row/col counts, header, sliced page, preview, row_range) and covers the lossy split limitation. It also addresses pagination intent and the presence of sibling write tools, making it complete for a read tool of this complexity.

  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 rich descriptions. The description adds extra meaning by explaining how offset/limit interact with the header, how preview_rows provides a stable head preview, and when row_range appears. This clarifies parameter behavior beyond the schema's individual definitions.

  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 this tool reads a Text or Table DAT with pagination, distinguishing it from sibling tools like edit_dat_content and set_dat_content. The verb 'Read' and resource 'DAT' are specific, and the pagination purpose is explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly names edit_dat_content/set_dat_content as the tools to use for writing, providing a clear alternative. It also explains when pagination is useful (to avoid flooding context) and warns about probing live data before relying on the table split.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_editor_contextA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable behavioral context beyond the annotations. It discloses that only available fields are returned, unavailable UI fields are omitted with warnings instead of inferred, and that it does not mutate TouchDesigner. This informs the agent about the tool's non-inferring behavior and its side-effect-free nature, which is not fully captured by the readOnlyHint and destructiveHint annotations alone.

  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 exceptionally concise, consisting of three sentences that front-load the purpose, then detail the return behavior, and end with exclusions. Every sentence adds value with no redundancy or filler. It is well-structured for quick comprehension.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, read-only tool with no output schema, the description is complete. It specifies the exact fields returned (project/build, perform mode, pane, active Network Editor, current/selected, rollover, viewport), how missing fields are handled (omitted with warnings), and what it does not do (dump topology or mutate). This fully equips an agent to understand the tool's behavior and limitations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty (100% coverage). Per the rubric, a baseline of 4 is appropriate when there are no parameters to describe. The description does not need to detail parameters, and it doesn't, so it fully meets the baseline.

  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: 'Read compact project and editor state for references such as 'this node', 'the selected node', and 'place it here'.' It specifies the exact verb (read), resource (project and editor state), and the use case (resolving references). It also distinguishes itself from topology-focused tools by explicitly saying it does not dump project topology, making it stand out among siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: when you need compact editor context for reference resolution. It also provides an exclusion: 'Does not dump project topology,' signaling that it is not for topology queries. However, it does not explicitly name alternative tools, so the guidance is clear but not exhaustive.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_docsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, but the description adds valuable behavior beyond those: the source search order, the restriction of web fallback to a specific domain with 'latest-web' labeling, and the guarantee of never accepting filesystem paths or returning raw HTML. This enriches the agent's understanding without contradiction.

  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?

  Three dense, front-loaded sentences. Every sentence adds critical information: read-only nature and sources, return contents and provenance, web fallback policy, and hard constraints. No filler or repetition of schema fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 6-parameter tool with an output schema, the description covers all key aspects: what it does, where it looks, what it returns, constraint boundaries, and fallback behavior. The output schema handles return-value details, so no further explanation is needed. It is fully contextualized within the large sibling set.

  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 the baseline is 3. The description adds extra meaning by explaining how 'section ids' enable bounded drill-down and by tying the 'query' to operator/Python/concept resolution. It also clarifies the 'web_fallback' and 'source' semantics beyond the schema, which aids parameter selection.

  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 'Read-only: resolve compact TouchDesigner operator, Python API, or concept documentation' — a specific verb, resource, and scope. It distinguishes itself from sibling tools by naming the OfflineHelp corpus, embedded KB, and restricted web fallback, and by stating what it never does (filesystem paths, raw HTML).

  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?

  It clearly states the source resolution order (installed OfflineHelp first, then embedded KB) and when web fallback is applicable ('off by default, when explicitly enabled'), plus its restriction to docs.derivative.ca. It does not explicitly name alternative sibling tools for different doc searches, but the context implies this is the primary docs-resolution tool, so guidance is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_node_errorsA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with 'Read-only'. It adds behavioral context beyond annotations: explains recursive sub-network traversal, summary mode, and the return structure. This enriches understanding without contradicting annotations, though it doesn't detail performance implications or edge cases.

  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?

  Three sentences, each adding distinct value: the read-only nature and scope, the summary grouping behavior, and the alternative tool for large networks. Front-loaded with 'Read-only' and the primary purpose; no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With an output schema present, the description is complete for the tool's complexity: covers usage with recursive and summary, return format, and a specific alternative tool for large networks. It addresses all key aspects an agent would need to invoke it 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?

  Schema coverage is 100% and descriptions are provided for all parameters. The tool description adds value by explaining the combined effect of recursive and summary, and clarifies the return format ({total, errors[] or by_type}), which enriches the schema definitions without redundancy.

  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 node errors and warnings, with a specific verb ('check') and resource ('node or sub-network'). It distinguishes itself from the sibling summarize_td_errors by mentioning the alternative for large networks, making its purpose and scope unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says to prefer summarize_td_errors for large networks, providing an alternative and the reason (clustering by shared cause, pointing at worst-offending nodes). Also describes when to use recursive and summary parameters, giving clear context for tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_topologyA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only'. It adds valuable behavioral context: returns a structured object with nodeCount, connectionCount, issues[], and topology, and flags structural issues. The recursion advice is useful but not fully backed by the schema (no recursion parameter), preventing a perfect score.

  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 well-structured: three sentences that front-load the read-only nature and return shape, then provide usage alternatives and operational advice. Every sentence contributes value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that an output schema exists and annotations cover safety, the description is complete: it states purpose, return structure, explicit alternatives, and practical usage constraints. The only minor gap is the unbacked recursion reference, but overall the description fully equips an agent to select and invoke the tool 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?

  Schema coverage is 100% for the single root_path parameter, providing a basic description. The description adds meaningful guidance by advising users to point at a specific network root rather than the project root for token economy, which goes beyond the schema. The mention of recursion is slightly ambiguous since no recursion parameter appears 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 clearly states the tool returns nodes and connections under a network root, with the specific verb 'return' and resource 'network topology'. It also distinguishes itself from siblings by explicitly mentioning get_td_nodes/find_td_nodes and snapshot_td_graph as alternatives for different needs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance ('Use this when you need how nodes are wired together') and names alternative tools for other scenarios. It also gives practical token-economy advice: target a specific network root and avoid recursion unless needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_agent_skillsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations by disclosing concrete safety behaviors: mutations default to dry-run, exact manifest ownership, rejection of unowned conflicts and symlinks, and rollback of partial filesystem changes. This complements the destructiveHint annotation without contradicting it.

  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 sentences carry a high information density: purpose, constraints, safety model, and exclusions. It is front-loaded with the action and resource, with no filler or repetition of schema fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the rich input schema, explicit annotations, and output schema, the description is complete enough. It conveys the tool's safety model, scope limitations, and host applicability, leaving parameter syntax and return values to the schemas where they already live.

  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 the baseline is 3. The description adds meaningful semantic context by reinforcing the dry-run default, explaining manifest ownership semantics, and bounding acceptable skills to package-bundled items, which helps interpret the 'skills' and 'dry_run' parameters 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 opens with a specific verb set ('Safely inspect, install, update, or uninstall') tied to a precise resource ('the small bundled tdmcp skill catalog for Codex or Claude'). It clearly distinguishes itself from generic installers by stating 'this is not a remote or arbitrary skill installer.'

  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 establishes scope: only package-bundled skills are managed, and it explicitly says it is not a remote/arbitrary installer. However, it doesn't name a specific sibling tool as an alternative, so the 'when to use vs alternatives' guidance is strong but not fully explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_artist_workspaceA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only indicate not read-only and open world; the description adds rich behavioral detail beyond that: 'schedules every UI access on the TD main thread, keeps only JSON job state, uses compare-and-swap restoration, and fails closed in Perform/headless/conflicted states.' It also states 'authenticated structured routes work with ALLOW_EXEC=0,' disclosing a key execution restriction. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the core purpose, followed by implementation details and boundaries. Every sentence earns its place with no filler, making it dense but efficiently structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (7 params, 4 actions, output schema present), the description covers critical context: safety model (fails closed), threading (main thread), state persistence (JSON only), restoration mechanism (compare-and-swap), and execution restrictions (ALLOW_EXEC=0). It does not need to describe return values because an output schema exists.

  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 71%, so the schema already explains most parameters. The description adds semantic context by clarifying the 'right-hand' split (viewer_mode) and 'bounded'/'temporary' nature (lease_seconds). It does not duplicate all schema details but enhances understanding of the action enum and the workspace lifecycle.

  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 precisely states the tool's function: 'Open, inspect, restore, or cancel one bounded TouchDesigner editor workspace using an existing Network Editor plus one right-hand TOP Viewer or Panel split.' It names the specific resource (workspace) and actions (open/inspect/restore/cancel), and differentiates from siblings by defining its bounded scope and constraints (e.g., 'never opens arbitrary UI, creates project operators, adds graph undo').

  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 usage for creating/managing a temporary, safe workspace and provides strong exclusions: 'It never opens arbitrary UI, creates project operators, adds graph undo, or falls back to raw Python.' It also notes when it fails closed (Perform/headless/conflicted states), giving practical context, but it does not explicitly name alternative tools or provide an explicit 'use this when' statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_project_briefA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds rich behavioral context: atomic replacement, versioned file, root resolution order (cwd never used), and the important limitation that 'brief text is untrusted project evidence and cannot override current user intent, safety policy, consent, tool tier, verification, or emergency behavior.' This goes far beyond what annotations convey.

  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?

  Three information-dense sentences with no fluff. Each sentence earns its place: first describes the core operation, second details replacement requirements, third covers root resolution and safety limitations. Front-loaded and structured efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the output schema exists and annotations provide safety hints, the description covers all critical operational aspects: atomicity, versioning, root precedence, expected_revision semantics, and the untrusted nature of brief content. An agent has sufficient information to invoke both actions 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?

  Schema description coverage is 0%, but the description compensates by explaining key parameters: expected_revision ('absent' or exact sha256 revision), project_root precedence (explicit, env var, then editor context), and action (read vs replace). The brief object's nested structure is left to the schema, which is detailed enough.

  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: 'Reads or atomically replaces the versioned brief at <project_root>/.tdmcp/agent-brief.json.' This is a specific verb+resource+location, and it distinguishes itself from all sibling tools, none of which manage the agent brief.

  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 operational guidelines, such as 'Replace requires expected_revision='absent' for creation or the exact revision returned by read' and root precedence rules. It does not explicitly name alternatives because none exist among the many siblings, but the context is clear enough for an agent to know when to use read vs replace.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• narrate_setA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already set readOnlyHint=false and destructiveHint=false, and the description adds concrete behavioral detail: 'Writes a local file (not read-only)' and explains append is timestamped and recall reads the last `tail` lines. This goes beyond the annotations by specifying the side effect (local markdown file) and append-only nature, though it doesn't discuss permissions or error handling.

  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?

  Three dense sentences cover purpose, modes, usage context, and sibling distinction with zero filler. The most important information (persist narration) is front-loaded, and every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 (7 parameters, two modes, file I/O), the description covers the essential context: what it does, when to use it, how modes behave, and how it differs from log_performance. The output schema and parameter descriptions fill in remaining details, so the description is fully adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3, but the description adds meaning by explaining how mode='append' and mode='recall' use parameters like section, cue, and tail. It also clarifies the default log path behavior (date-based set_name), enriching the schema's parameter descriptions.

  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 a specific verb+resource: 'Persist the running narration of a live VJ/show set so decisions can be recalled afterwards.' It then clearly distinguishes the two modes (append and recall) and explicitly contrasts with the sibling tool log_performance, removing any ambiguity about its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: 'Pair with the auto_vj_director prompt: instead of narrating only in chat, call narrate_set on each major move.' It also provides a clear alternative: 'Delta vs log_performance, which writes a one-shot network snapshot rather than an append-only decision log,' telling the agent when to use this tool versus log_performance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• record_movieA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond the annotations: it explains the start/stop workflow, that stop cleans up the recorder node, and that the file is written by TouchDesigner on the TD machine. With annotations already indicating a non-read-only, non-destructive operation, the description provides useful extra detail without contradicting them.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences long, front-loaded with the main purpose, and every sentence delivers critical information. No redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 5 parameters and no output schema, the description covers the workflow (start/stop/auto-stop), the file location, the TD machine context, and the alternative for single frames. It is sufficiently complete for an agent to select and invoke the tool 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?

  Schema coverage is 100%, and the description enriches the parameter semantics by explaining how start uses file and fps, seconds auto-stops after a fixed length, and stop finishes recording and cleans up. This is a clear added value over the raw schema descriptions.

  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 records a TOP to a movie file via a Movie File Out TOP, with a specific verb and resource. It explicitly distinguishes itself from render_output, which only saves a single frame, making its 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says to use this tool for exporting a clip or a loop, while recommending render_output per frame for individual numbered frames. This gives clear when-to-use and when-not-to-use guidance, directly naming the alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• save_recipe_to_vaultA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses that it writes to the vault, refuses to overwrite unless overwrite:true, returns the note path/recipe id/counts, and requires a configured vault path. This adds safety and configuration context beyond the annotations (readOnlyHint=false, destructiveHint=false).

  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?

  Five sentences, each carrying essential information: action, use case, alternative, overwrite guard, return values, and prerequisite. No filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Comprehensive for a write-to-vault tool: covers purpose, usage, side effects, return values, and configuration requirements. With 100% schema coverage, there are no significant gaps in understanding how to invoke this tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so baseline is 3. The description mentions overwrite:true and Recipes/<id>.md, which slightly reinforces parameter meaning, but it does not add substantial detail beyond what the schema already provides. It does contextualize what is captured (child nodes, wiring, DAT bodies), helping infer parameter intent.

  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 it captures a COMP's network and writes it as a recipe note in the Obsidian vault at Recipes/<id>.md. It uses a specific verb+resource pairing and distinguishes from apply_recipe (instantiate a template) and references list_recipes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use this tool: 'Use this to turn a patch you already built into a template — to instantiate a template instead, use apply_recipe.' Also notes the prerequisite of a configured TDMCP_VAULT_PATH.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scaffold_recipe_from_networkA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only with respect to TD — no operators are created or modified'. It additionally discloses the file-writing side effect when write_path is set, validation against RecipeSchema, and the structuredContent return path — all 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 compact: three sentences that front-load the core relationship to apply_recipe, then pack in serialization scope, validation, output behavior, and read-only guarantee. Every sentence earns its place with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 10 parameters and no output schema, the description adequately explains the return value (RecipeSchema JSON), how it is delivered (write_path or structuredContent), and that validation occurs. The schema covers parameter details, so the description provides enough contextual glue for correct selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema covers all 10 parameters with rich descriptions, so the description does not need to repeat them. It adds high-level context like 'walk a COMP's child network' (which maps to root_path) and the serialized content categories, but it does not add format or syntax details beyond the schema. Baseline 3 is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Inverse of apply_recipe', which immediately distinguishes it from the sibling apply tool. It then specifies the exact action: walk a COMP's child network and serialize it to RecipeSchema JSON. This is a specific verb+resource with clear scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly names apply_recipe as the inverse alternative, giving an agent clear directional guidance on when to select this tool. It also explains the two distinct usage modes: write_path set (write file) vs. null (return structuredContent), providing concrete context for invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scaffold_vaultA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite annotations already indicating non-read-only behavior, the description adds valuable detail: it writes Markdown files into the root and subfolders, skips existing files unless overwrite:true, requires TDMCP_VAULT_PATH, and describes the return value. This is far beyond what annotations provide alone.

  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 efficiently structured in three sentences: purpose, behavior, and usage/prerequisites/return. Every sentence adds distinct information without redundancy, 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.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with one optional parameter and no output schema, the description covers the primary purpose, side effects, prerequisite, return value, and relationship to sibling tools. Complete enough for an agent to select and invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% and the only parameter (overwrite) is fully described in the schema. The description's mention of 'skipped unless overwrite:true' repeats the same meaning without adding new semantic detail 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 the tool's purpose with a specific verb ('Populate') and resource ('configured Obsidian vault'), and explicitly differentiates it from sibling tools by noting this runs before save_recipe_to_vault/import_setlist/etc.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage context: 'Run this once when first setting up a vault' and names the exact ordering relative to related tools. This goes beyond implied usage and offers clear alternatives for later steps.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_operatorsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes far beyond the readOnlyHint and destructiveHint annotations. It discloses that the search is 'fully offline by default', that results are 'ranked by relevance', that semantic mode 'falls back to keyword' when the LLM endpoint is unavailable, that parameter_search includes menu options, and that results include a data_version and stale_hint when the TouchDesigner major differs. This is rich behavioral detail that significantly exceeds 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 appropriately sized for the tool's complexity. It front-loads the core purpose in the first sentence, then proceeds logically through use case, return format, optional modes, data versioning, and querying guidance. Every sentence provides unique value, and there is no redundancy or tautology. The structure is well-organized despite its length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description states what the tool returns ('name, family, summary, facets and optional matching parameters') and covers edge cases such as stale_hint and semantic fallback. It also provides usage examples and trade-offs (offline vs. semantic requiring an LLM endpoint). This is a complete and self-contained explanation for a search tool with 8 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining how parameters interact, e.g., 'Pass semantic:true to re-rank fuzzy candidates by embedding similarity' and 'With parameter_search, matched Menu parameters include their menu options.' It also contextualizes the version and category filters. This added context justifies a 4, though it does not fully re-explain every parameter since the schema already does.

  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 a specific verb and resource: 'Search the embedded operator knowledge base (629 operators)' and details the search dimensions (keyword, exact name, tag, category, subcategory, parameter metadata, version compatibility). It clearly distinguishes itself from sibling search tools by focusing exclusively on the operator knowledge base, with concrete example queries like 'what sends DMX?' and 'corner pin'.

  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 explicitly states when to use the tool: 'Use it to discover the right operator before creating nodes instead of guessing a type.' This gives clear context and an implicit alternative (guessing). It also provides token economy advice ('use a specific query and a small limit'), but it does not explicitly contrast with sibling search tools such as search_touchdesigner_knowledge, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_dat_contentA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (destructiveHint, readOnlyHint), the description discloses a safety guard: it refuses empty/whitespace-only text unless `confirm_wipe:true` is passed, and explains the rationale ('preventing silent data loss'). This adds meaningful behavioral context not present in 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?

  Three concise sentences, each adding essential information: purpose, differentiation/usage, and safety behavior. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive write operation with no output schema, the description fully covers the tool's function, appropriate use cases, and safety constraints, making it self-sufficient for an agent to decide when and how to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with each parameter already well-documented. The description reiterates the `confirm_wipe` role but introduces no new parameter semantics 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 uses a specific verb ('Overwrite') and resource ('Text or Table DAT's entire .text'), and explicitly contrasts with `edit_dat_content` for surgical edits, clearly distinguishing its scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly names the alternative sibling tool `edit_dat_content` and states when this tool is preferred ('use it to deploy a full script or template'), plus explains the `confirm_wipe` condition for blank content.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_parameter_expressionA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds rich behavioral context beyond annotations: explains fail-forward batch behavior (per-item failures become warnings), partial batch returns useful results, reset restores defaults, unbind freezes current value and drops the driver, and the exec path requirement. This significantly exceeds what annotations provide.

  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?

  Four sentences, each carrying essential information: purpose, modes, batch behavior, and usage guidance. No fluff or repetition; structure is logical (purpose -> modes -> behavior -> alternative).

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description covers the key operational aspects: all five modes, batch semantics, prerequisites, and the relationship to a sibling tool. It gives the agent enough to invoke correctly and anticipate results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description restates mode behavior that is already in the schema (expression/bind/constant/reset/unbind), but adds the fail-forward and environment variable context, which is more about tool behavior than parameter semantics. Minimal additional parameter-specific value beyond 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 opens with a specific verb and resource: 'Set one or more parameters on a node to an expression, bind expression, or constant value.' It clearly distinguishes from siblings by mentioning it avoids the raw-Python escape hatch and explicitly references execute_python_script as an alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use this tool instead of execute_python_script when TDMCP_RAW_PYTHON is off. It also provides a critical prerequisite for reset/unbind modes (TDMCP_BRIDGE_ALLOW_EXEC=1), giving clear usage conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• setup_outputA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the annotations, explaining that a matching output node is created under parent_path, how window mode differs (points the Window COMP's winop), and why a Select TOP bridge is used for other types (TD wires can't cross COMP boundaries). It also discloses the return value including non-fatal warnings, which is valuable 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but highly informative. Each sentence adds distinct value: destination list, per-type wiring logic, usage as last step, and return value. It is front-loaded with purpose and ends with outcome expectations, with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description fully covers what the agent needs to know: prerequisites, input expectations, node creation behavior, special cases for window vs other types, and return value semantics including warnings. It is complete for its moderate complexity.

  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% and each parameter has a description, so the baseline is 3. The description adds meaning by explaining the purpose of the source_path ('final TOP'), how output_type affects behavior (window vs NDI/Syphon/Spout/record/Touch Out), and what happens with the created node. This adds value beyond the enum labels.

  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 a specific action ('Route a finished TOP to an output destination') and enumerates five distinct destination types. It clearly differentiates itself from sibling tools like render_output or record_movie by covering the full output-routing step, including node creation and special wiring behavior.

  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?

  It explicitly states when to use this tool: 'Typically the LAST step after building a visual' and tells the agent to feed it the output Null from a create_* tool or create_layer_mixer. It does not explicitly mention when not to use it or name alternative tools, but the contextual guidance is clear and practical.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• snapshot_td_graphA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, and the description reinforces this with 'Read-only'. It goes far beyond annotations by explaining compact-mode hoisting of per-type defaults, delta storage, per-node request behavior with caps, and that compact mode implies parameter-mode preservation. This is rich, non-obvious behavioral detail.

  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 dense but every sentence earns its place: purpose, return shape, compact-mode guidance, and downstream diffing workflow. It is front-loaded with the most important information ('Read-only: capture...') and contains no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 4 optional parameters and the existence of an output schema, the description is complete: it explains the return shape, the trade-offs of each parameter mode, caps on per-node requests, and the intended workflow with diff_snapshots. An agent has enough context to select and invoke this tool correctly without needing additional clarification.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics: why compact is useful ('without paying for repeated identical values'), the relationship between compact and include_parameter_modes, and the 'Embody-style read_tdn' analogy. These go beyond the schema's already-thorough property descriptions.

  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 a specific verb+resource: 'capture a compact, serializable snapshot of a network' and enumerates the exact contents (nodes, connections, structural issues, optionally parameters). It distinguishes itself from sibling tools like get_td_topology or serialize_network by emphasizing the serializable snapshot format and diffing use case.

  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?

  It clearly states use cases ('for review, diffing, or documentation') and gives concrete guidance to set `compact` for a token-cheap whole-COMP read and to feed two snapshots to diff_snapshots. It does not explicitly call out when not to use it or name alternative tools beyond diff_snapshots, but the context is strong enough for an agent to choose correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• style_memoryA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description far exceeds the sparse annotations (readOnlyHint: false, destructiveHint: false). It details mode-specific behaviors ('show' returns compact context string, 'read' returns full note, 'update' field-wise merges with lists union+dedup and scalars overwrite, bumps updated date). It also states the side-effect boundary ('no TouchDesigner side effects') and environment requirement, giving the agent complete operational expectations.

  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 with zero filler. It opens with the core action and resource, then succinctly packs mode behaviors, merge semantics, side-effect scope, and a prerequisite. Every clause adds value; it is a model of efficient technical writing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no output schema, the description covers most needed context: return formats for show/read, merge behavior for update, side effects, and prerequisites. The only minor gap is not explicitly stating what 'update' returns (e.g., the updated note) and no error-handling detail beyond the required env var, but this is a small omission in an otherwise thorough description.

  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 coverage is 100%, and the description adds substantial semantic enrichment. It explains the meaning of each mode in practical terms and the merge strategy for the patch (lists union+dedup, scalars overwrite), which is not present in the schema descriptions. It also clarifies that patch is ignored for show/read, and that TDMCP_VAULT_PATH is required.

  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 two specific verbs ('READ or UPDATE') and the exact resource ('Memory/style.md note in the configured Obsidian vault'), plus its scope ('artist's standing preferences across sessions'). This distinctively separates it from sibling vault and TouchDesigner tools.

  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 conveys when to use the tool: for accessing or modifying long-lived style memory, not for ephemeral operations. It notes 'Touches the vault only — no TouchDesigner side effects' and the prerequisite 'Requires TDMCP_VAULT_PATH'. However, it does not explicitly name alternative tools or state 'when not to use', so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• sync_presets_vaultA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only say readOnlyHint=false, destructiveHint=false, but the description adds substantial context: export READS TD and WRITES Markdown, import READS note and WRITES into TD merging by name, and it returns the note path plus affected preset names. This exceeds the annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Five sentences, each earning its place: purpose, action semantics, return value, usage guidance, and prerequisite. No fluff, front-loaded with the core purpose. This is concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-action sync tool with no output schema, the description fully explains the workflow, return value, relationship to sibling tool, and required configuration. It is complete enough for an agent to select and invoke correctly.

  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 covers all 3 parameters with descriptions (100% coverage), so baseline is 3. The description adds some context like merging behavior and default paths, but doesn't significantly enhance the meaning of individual parameters beyond what schema descriptions already provide.

  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 exactly what the tool does: bridges manage_presets snapshots with the Obsidian vault, with explicit export/import directions. It also distinguishes from sibling manage_presets by noting that manage_presets captures/recalls live, whereas this tool is for version-control/share.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use this to version-control or share presets across machines; use manage_presets to capture/recall them live.' This provides both when-to-use and when-not-to-use. It also states the prerequisite of a configured TDMCP_VAULT_PATH.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• watch_parameter_changesA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses several behavioral traits beyond the annotations: the opt-in nature, the event payload shape, the bridge-side coalescing to prevent flooding, and the fact that it works even when TDMCP_BRIDGE_ALLOW_EXEC=0. It also notes that events only arrive when the server's TD event stream is enabled, adding environmental context.

  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 composed of four sentences, each contributing critical information: the core subscription behavior, the action syntax, the event stream prerequisite and coalescing behavior, and the bridge allow_exec note. It is dense but not redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the annotations, output schema, and the detailed description covering opt-in semantics, actions, event conditions, and subscription scope, the description is contextually complete for this tool's complexity.

  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 documents all three parameters with descriptions, covering 100% of the schema. The description adds value by explaining the interplay between `action` and `parameters` (e.g., 'parameters' is optional and scoped for watch/unwatch, omitted for list), and provides an example path 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 clearly states the tool subscribes to `param.changed` events for an operator's parameters, with a specific event payload. It distinguishes from sibling tools like `watch_node` by focusing on parameter-level changes rather than node-level watching.

  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?

  It provides explicit context for when to use it: opt-in subscription, with three actions ('watch', 'unwatch', 'list') and prerequisites like the TD event stream being enabled. However, it does not explicitly name alternative tools or when not to use it, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_3d_sceneA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses detailed behavioral traits: what nodes are created (baseCOMP with Geometry, Camera, Light, Render TOP, Null), options like GPU instancing with scale_variation and spin, exposed controls (RotateY, Zoom), and return value details (summary plus JSON block with paths, errors, warnings, preview image). This goes well beyond the minimal annotations (readOnlyHint=false, destructiveHint=false) and adds meaningful context about side effects and output.

  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 information-dense and well-structured, starting with the core action, then optional behaviors, usage suggestion, alternatives, and return format. It is slightly longer than strictly necessary but every sentence adds value; no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description completely covers the tool's purpose, usage, parameters, side effects, alternatives, and return value in the absence of an output schema. It even informs about node errors and warnings in the return, making it self-sufficient for an AI 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?

  Schema coverage is 100% with each parameter already having descriptions. The description adds conceptual cohesion by explaining how instances, scale_variation, and spin interact in the scene, and how expose_controls relates to the knobs. While it doesn't add new syntax details, it provides helpful context that ties the parameters together.

  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 the tool 'Build a renderable 3D scene' and enumerates the exact composition: Geometry COMP, Camera, Light, Render TOP, output as Null. It also names the primitive choices and differentiates from sibling tools by explicitly mentioning create_3d_audio_reactive and create_pbr_scene as alternatives for different use cases.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear when-to-use guidance: it positions the tool as 'The starting point for 3D visuals' and recommends binding RotateY to tempo/audio. It explicitly states 'Use create_3d_audio_reactive instead when you want the geometry driven by sound, or create_pbr_scene for physically-based materials,' giving direct alternative conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_asemic_writingA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnly=false, openWorld=true, destructive=false), the description discloses deterministic seeding, creation of a new baseCOMP under parent_path, and the complete return structure (summary, JSON block, preview image). It also details the rendering pipeline, providing rich behavioral context without contradicting annotations.

  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 dense and front-loaded with the core purpose. Technical details like 'Script SOP', 'tube ink strokes', and 'orthographic camera' are all relevant. It is slightly longer than minimal, but every sentence contributes useful information, making it appropriately sized for the complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 compensates by enumerating the return payload (container path, node paths, output path, exposed controls, errors, warnings, preview image). It also covers creation location, exposed parameters, and rendering behavior, making it complete for an agent to decide when and how to invoke the 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 coverage is 100%, so the baseline is 3. The description enhances this by explaining parameter interactions (rows × glyphs layout, strokes control points, lift_chance breaking marks) and how they affect the visual result, adding value beyond the schema's isolated parameter descriptions.

  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 'Generate a page of procedural asemic writing', a specific verb and resource, and elaborates on the exact output (glyphs, baselines, randomness). It explicitly distinguishes itself from create_growth_system and create_vector_lines, making its purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names two sibling tools and explains how this tool differs ('Genuinely distinct from...'), giving the agent clear selection criteria. This satisfies the requirement for explicit alternatives, even if it does not list all when-not scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_cue_sequencerA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses the internal architecture (Beat CHOP, CHOP Execute DAT), the timing behavior (advances on bar/beat boundaries), the morphing behavior (morph_seconds), and the runtime controls (Live Active / Step / BarsPerStep). It adds significant context about side effects and dependencies without contradicting 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 two sentences, front-loaded with the main purpose, and every clause adds value: architecture, timing, morphing, comparison to autopilot, prerequisite, and live controls. It is dense but not verbose, and no fluff is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex 7-parameter tool with no output schema, the description is quite complete: it explains what is built, how it behaves, what dependencies exist, and how it is operated. However, it does not explicitly state return values or error conditions, though these are minor for a creation tool. The prerequisite and behavioral details make it sufficient for most use cases.

  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 input schema has 100% parameter description coverage, so the baseline is 3. However, the description enhances understanding by explaining the semantic model: 'ordered list of steps' clarifies the steps array, and 'bar-quantized cue timeline' gives context to quantize and bars. This extra context justifies a 4.

  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 a specific verb and resource: 'Build a bar-quantized cue timeline,' and then details the concrete implementation (Beat CHOP + CHOP Execute DAT). It explicitly differentiates itself from create_autopilot as the 'deterministic, musically-timed counterpart,' making its purpose clear and distinguishing it from a key sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states a clear usage contrast: 'The deterministic, musically-timed counterpart to create_autopilot (which is random/cyclic).' It also gives a prerequisite: 'store the target's cues with manage_cue first,' which tells the user when and how to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_energy_structureA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes far beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true). Reveals that the tool is experimental, uses adaptive thresholds, maintains a rolling buffer, emits a 5-channel Null CHOP, has built-in hysteresis, and may trigger a macOS mic-permission dialog. This is rich behavioral disclosure that helps an agent anticipate side effects and output structure.

  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?

  Although long, every sentence earns its place with technical specifics: threshold formulas, hysteresis values, output channel layout, and side effects. It is front-loaded with the purpose, then builds with operational detail. No fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with no output schema, the description completely covers what the tool creates, its internal algorithm, output channels, parameter behavior, default audio source handling, and a known side effect. It is sufficiently complete for an agent to invoke it correctly and interpret the result.

  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?

  The schema already covers 100% of parameters, but the description adds crucial meaning beyond the schema: thresholds are k-multipliers of sigma above mu (NOT absolute amplitudes), windowSec defines the rolling buffer length, and audioSource is optional. This clarifies parameter relationships and the self-calibrating behavior, making the parameters more understandable than raw schema descriptions alone.

  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 and resource: 'Build a song-structure (build / drop / breakdown) edge detector COMP with adaptive thresholds.' This clearly distinguishes it from sibling tools like create_envelope_follower or detect_onsets by specifying a unique COMP type and output behavior.

  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 concrete usage context: it can listen to an existing audio CHOP via audioSource or create an Audio Device In, explicitly telling users to pass an existing source to skip device creation. It mentions the mic-permission dialog and how to avoid it. While it doesn't explicitly name alternative tools, the instruction is clear enough for selecting and using this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_kinetic_textA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Even though annotations already declare non-read-only and non-destructive, the description adds substantial behavioral detail: node hierarchy (Text TOP, LFO CHOP, Transform/Level nodes, Composite, Null), per-mode animation mechanics (flash vanishes rather than black, pulse breathes, slide scrolls), input compositing behavior with Select TOP, and rate binding to beat CHOP. This goes well 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is lengthy but each sentence carries useful information—alternatives, mode mechanics, input handling, and return format. It is a single dense paragraph rather than structured bullets, but it is not padded or redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no output schema, the description fully explains what the tool returns (summary, JSON block with paths/controls/errors/warnings/preview). It covers node creation, source compositing, rate binding, alternative tools, and edge cases (no input_path), leaving no obvious gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3; description adds practical guidance beyond the schema, such as binding rate to a beat CHOP for tempo sync, and clarifies mode behavior in prose. This elevates it above the baseline, though much of the detail is already present 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 verb ('Build') and resource ('self-contained animated / kinetic typography layer'), and clearly distinguishes itself from siblings by naming create_text_overlay for static captions and create_text_crawl for multi-line scrolling text.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly provides when-to-use context (live-VJ lyric-flash effect) and names exact alternatives with conditions: 'for a static caption or title use create_text_overlay, and for multi-line scrolling tickers/credits rolls/typewriter reveals use create_text_crawl.' This gives clear guidance on choosing the correct tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_nodesA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces and extends this by explaining the output behavior (compact summary vs full list), return shape, and operational caveats like avoiding re-listing inspected paths. It fully discloses the tool's scope and side-effect-free nature.

  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 front-loaded with the core purpose and contains no filler, but the token economy and alternative-tool guidance spans multiple sentences and could be tightened. Every sentence still adds value, so it's above average but not maximally compact.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers purpose, output shape, default behavior, parameter choices, alternatives, and best practices, which is complete for a read-only list tool. The rich schema and annotations handle the remaining details, and no critical operational context is missing.

  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 detailed parameter descriptions, satisfying the baseline, but the description adds meaning by explaining how detail_level/path_only/pattern relate to output modes and filtering, and by noting the default parent scope. It doesn't restate everything in the schema but provides enough additional context to select and combine parameters effectively.

  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?

  Description clearly states the action ('list the DIRECT child nodes of one COMP'), defines the scope (direct children, one level), and explicitly distinguishes this from sibling tools find_td_nodes and get_td_topology. The verb+resource+scope combination 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use and when-not-to-use guidance: use for one-level browsing, use find_td_nodes for recursive search, use get_td_topology for connections. It also offers token economy recommendations about when to request full vs summary output, which is actionable context beyond the schema.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• manage_checkpointA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description details exactly what a checkpoint captures, what restore does (reapplies parameters, recreates deleted nodes, prunes created nodes), and frames it as an undo point. This is substantial behavioral disclosure that helps the agent understand destructive consequences.

  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 four sentences, each earning its place: the action summary, the content of a checkpoint, the restore behavior, and the comparison with manage_presets. It is front-loaded with the core purpose and contains no filler.

  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 multi-action tool, the description covers the purpose, content, restore semantics, and alternative, but it does not mention the return value or output format for the list action, which could matter for an agent choosing to use it. Still, with a rich schema and annotations, it is largely complete enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining how restore behavior maps to the prune_created and recreate_deleted parameters, and by clarifying that comp_path represents a full sub-network. This goes beyond the schema's field-level descriptions.

  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 a specific verb list ('Store / restore / list / delete a full snapshot of a sub-network') and clearly identifies the resource (sub-network snapshot). It distinguishes itself from manage_presets by contrasting whole-network capture with custom-parameter looks, making the tool's 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states when to use the tool ('before risky live edits', 'for safe experimentation') and explicitly names the alternative (manage_presets), explaining that this tool captures the entire network rather than just parameter looks. This gives the agent clear decision criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• auto_repair_loopA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only state readOnly=false, openWorld=true, destructive=false. The description adds substantial behavioral detail: dry-run does no writes and runs exactly one planning iteration, non-dry-run propagates to repair_network, loop stops on clean/stalled/exhausted, and it returns a structured result. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-structured: it starts with an overview, then adds dry-run behavior, a key limitation, and the return envelope. Each sentence contributes non-redundant information without bloat.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Even with no output schema, the description fully specifies the return shape {status, iterations[], errors_before, errors_after, remaining[], recommended_prompts[], warnings} and explains termination conditions and fixer hand-offs. For a complex orchestrator, this is sufficient for an agent to invoke and interpret results.

  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 already detailed parameter descriptions, so baseline is 3. The description enriches meaning by tying dry_run to one planning iteration with no writes, allowed_fixers to advisory-only behavior, and max_iterations to the 'exhausted' termination state.

  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 'Driver: scan a subtree for cook errors...' and clearly describes a bounded iterative repair loop. It explicitly specifies the fixers it calls (repair_network) and those it only hands off (fix_shader/fix_reactivity), distinguishing it from sibling fix and repair tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states when the loop is appropriate (subtree cook errors), its iteration bounds, dry-run default, and explicitly notes that shaders/dead reactivity are not fixed directly but surfaced via recommended_prompts for the agent to execute next turn. This gives clear routing guidance versus repair_network and fix_shader/fix_reactivity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bundle_dependenciesA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already flag destructiveHint=true and readOnlyHint=false, but the description goes further by disclosing exactly what is mutated (parameters in the live network), what is created (assets folder, .tox, manifest), and how missing files are handled. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence in the description carries essential, non-redundant information. It is front-loaded with the main purpose, then covers output structure, sibling distinctions, and a critical mutation warning—all without filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity of a 5-parameter tool with destructive side effects, the description is remarkably complete. It covers the full process, the delivered artifact, how it differs from alternatives, and the key caveat about live network mutation. An output schema exists, so return values are already covered.

  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 a baseline of 3 applies. The description adds contextual meaning by explaining the relationship between the workflow and parameters, especially rewrite_refs (mutation behavior) and out_dir/assets structure. It doesn't add per-parameter detail beyond schema but augments understanding of the overall flow.

  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 begins with 'Make a COMP self-contained' and details the exact workflow: scan, copy, rewrite, save with manifest. It also explicitly distinguishes itself from make_portable_tox (which leaves assets behind) and collect_project_assets (which only reports), so the agent knows exactly what this tool accomplishes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly contrasts this tool with sibling tools make_portable_tox and collect_project_assets, telling the agent when this is the right choice. It also provides a critical usage caveat: rewriting mutates the live network, and setting rewrite_refs=false enables a copy-and-report mode without mutations.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_3d_audio_reactiveA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint false, openWorldHint true, destructiveHint false), the description discloses specific behavioral traits: creates a baseCOMP under parent_path, includes Camera/Light/Render TOP and Null TOP output, exposes Sensitivity/Zoom/Spin controls, warns about a macOS microphone-permission prompt, and describes the return payload (summary + JSON block with paths, errors, warnings, preview image). No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose, then systematically explains modes, components, controls, sources, and return value. Every sentence adds information; there is no filler or repetition of schema field text. Despite its length, it remains appropriately concise for a complex build tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a complex tool with 9 parameters, no output schema, and only basic annotations. The description fully compensates by covering the generated node structure, source options, permission caveat, exposed controls, return format, and fallback behavior. It provides enough context for an agent to invoke the tool correctly and interpret the result.

  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?

  Input schema covers 100% of parameters with detailed descriptions, so baseline is 3. The description adds extra semantic value beyond schema: 'bass_pulse' is described as the guaranteed-visible fallback, 'oscillator' is 'handy for testing without any device permission', and it explains the FFT spectrum mapping context. These nuances help parameter selection beyond what the schema already provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource ('Build a 3D scene that reacts to sound') and clearly distinguishes this from the sibling create_audio_reactive (2D counterpart). It also differentiates from other 3D creation tools like create_3d_scene by focusing on audio reactivity and FFT-driven geometry.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names the alternative tool (create_audio_reactive) for 2D spectrum visuals and provides guidance on choosing between modes (instanced_bars vs bass_pulse fallback) and sources (device/file/oscillator/existing_chop), including when oscillator is handy for testing without device permission. This is clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_beat_grid_sequencerA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses the internal architecture (Table DAT, CHOP Execute, count % steps), how actions dispatch, and a critical unverified timing caveat with a suggested workaround. This is substantial behavioral context that helps the agent anticipate side effects and edge cases.

  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 dense but every sentence contributes: purpose, mechanism, differentiation, examples, live-edit tip, and a critical caveat. It is well-structured, starting with the main purpose and ending with a warning, with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 8 parameters and no output schema, the description covers the architecture, both action modes, typical use cases, and the timing limitation. It gives enough detail for an agent to decide whether this tool fits a request and what parameters matter.

  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?

  Even though schema coverage is 100%, the description adds operational meaning: it explains how 'pattern' relates to action (values vs 1/0 flags), how 'steps' is used in count % steps, and how 'param' and 'cue' actions behave. It links 'target' to the COMP being fired on beat boundaries, adding more than the bare schema fields.

  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 builds a programmable step-grid sequencer driven by a Beat CHOP, with a specific mechanism (Table DAT + CHOP Execute) and explicit differentiation from create_autopilot and create_cue_sequencer. It includes concrete examples (strobe on beats 1+3, hue shift) that make the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly positions this tool as the 'deterministic, repeating-rhythm instrument between create_autopilot (random drift) and create_cue_sequencer (linear list)', giving clear when-to-use guidance. It also notes live reprogramming via the step_table DAT and distinguishes the two action modes.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_capture_loopA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations only say readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds substantial behavior: anti-feedback wiring (two halves never wired together), platform gating, runtime probing of parameter names, and warning about unverified live behavior. It clearly explains what the tool does internally, which is well beyond annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is about 170 words, which is detailed but not overly long given complexity. It is front-loaded with purpose, then flows through mechanics, warnings, and comparison. A few technical details (like 'receiver TOP → Null') are dense and could be clearer, but overall each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 8 params, no output schema, and open-world hints, the description thoroughly covers purpose, internal wiring, platform constraints, warnings, and relationship to siblings. It leaves little ambiguity about when and how to use it, making it highly complete given the tool's complexity.

  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 coverage is 100%, but the description adds high-level meaning beyond schema: it explains how direction 'both' creates a round-trip, how resolution is applied, that publisher inherits resolution, and the anti-feedback logic. It ties parameters to the overall bridge behavior, which enriches understanding beyond the individual property descriptions.

  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 builds a bidirectional inter-app video bridge, with specific mention of receive (IN) and publish (OUT) functionality. It explicitly distinguishes itself from create_live_source and setup_output, and names the sibling tools it combines.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly explains when to use: for inter-app video bridging to programs like Resolume, OBS, etc. It contrasts with create_live_source (in) and setup_output (out), and warns about platform-specific requirements (Spout/Syphon/NDI) and unverified live behavior, helping the agent choose appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_depth_displacementA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With annotations only indicating readOnlyHint=false and destructiveHint=false, the description carries the behavioral burden and does so thoroughly. It discloses that the tool creates a new baseCOMP under parent_path, lists the exact node graph built, warns about the macOS camera-permission dialog, and states the return format including node errors and warnings. This goes well beyond the annotations and gives the agent a clear model of side effects and output.

  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?

  Although the description is long, it is dense and every sentence adds operational value: purpose, differentiation, source options, parameter behavior, node hierarchy, exposed controls, and return payload. The information is front-loaded with the core concept and then flows logically through setup, behavior, and output. No filler or redundancy is present.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (8 parameters, no output schema, network-building side effects), the description is exceptionally complete. It covers what gets created, where, which sources are allowed, permission caveats, parameter meanings, exposed controls, and the full return structure including preview image. This is more than sufficient for an agent to select and invoke the 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 schema covers 100% of parameters, so the baseline is 3, but the description adds meaningful context beyond the raw schema. It explains the conceptual role of subdivisions ('sets the relief resolution'), depth ('the push amount'), and invert ('flips bright↔near'), and adds source-specific caveats like the macOS permission and the fact that synthetic is testable without a camera. It also mentions exposed Depth and Zoom knobs, which helps the agent understand the practical effect of expose_controls.

  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 a specific verb and resource: 'Push a flat plane into real 3D relief by a depth/luminance map' and immediately clarifies this is 'true geometry — a 2.5D landscape.' It explicitly distinguishes itself from the sibling tool create_depth_silhouette, which is described as a flat 2D mask, making the tool's unique purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit when-to-use guidance by contrasting with create_depth_silhouette and enumerating valid source types with use-case context: 'live camera (may prompt for macOS permission)', 'movie file', 'animated synthetic pattern (testable without a camera)', or 'existing TOP (e.g. a real depth map)'. It also suggests an application ('bind Depth to a tempo ramp or an audio feature to make the surface heave'), which helps an agent decide if this tool fits a requested visual effect.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_euclidean_sequencerA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses far more than the annotations (readOnlyHint false, openWorldHint true, destructiveHint false). It details side effects: writes to a Table DAT, fires dispatches per active step, creates/uses a Beat CHOP, re-shapes table live when parameters sweep, and even includes a caveat about unverified timing when the TD timeline is paused. This goes well beyond what annotations convey.

  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 dense but well-structured: opening with the core function, then distinguishing from its sibling, then explaining action modes, and ending with a critical caveat. Every sentence adds value, and the front-loading makes it easy to parse quickly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 11-parameter tool with no output schema, the description covers the full scope: what it builds, how it works algorithmically, what outputs are written, how parameters relate to behavior, and a limitation. It fully equips an agent to understand the tool's operation and side effects without needing an output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema descriptions: it explains the mathematical relationship between pulses and steps, gives canonical musical patterns, and notes the live-sweep behavior for Pulses/Rotation. It doesn't detail every parameter, but the schema already does that.

  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 a specific verb and resource: 'Build a Euclidean rhythm sequencer' and details the algorithm (Bjorklund's) and output (Table DAT, dispatches). It explicitly distinguishes itself from create_beat_grid_sequencer as the deterministic, mathematically-grounded sibling, making its unique role clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use this tool: to program rhythms by musical intent (with examples like E(3,8), E(5,8), E(4,16)) rather than hand-editing cells, and names the alternative create_beat_grid_sequencer. It also clarifies the two action modes (param vs cue) and cautions about unverified beat-callback timing, giving practical usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_feedback_networkA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses the created node structure, the feedback loop mechanism ('Feedback TOP samples the Level node to close the loop'), the exposed 'Feedback' knob, and the full return payload (summary, JSON block with paths, errors, warnings, preview image). It adds substantial context about side effects and output.

  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 front-loaded with the core purpose, followed by concise implementation details, use-case context, and an explicit alternative. Every sentence provides useful information without padding, making it appropriately sized for a tool with this complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (6 params, multi-node creation, feedback loop), the description is complete: it explains what is built, how the loop works, what the user gets back, and when to choose this over the similar sibling. The output schema is not present, but the description enumerates the return block contents, filling that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema already covers all 6 parameters with rich descriptions (100% coverage), so the baseline is 3. The description adds conceptual meaning by explaining how the parameters fit into the feedback loop (e.g., 'transformations' as an ordered chain, feedback_gain as 'loop decay multiplier'), which goes beyond individual parameter 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 begins with a clear verb+resource: 'Build a feedback-based visual system' and details exactly what it creates (baseCOMP with seed, Feedback TOP, Composite, transform chain, Level decay, optional GLSL pass, Null output). It also explicitly distinguishes itself from the sibling tool create_feedback_tunnel, 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The final sentence provides explicit usage guidance: 'Use this for a general feedback look with a chosen seed type and an ordered chain of effects; for the specific infinite-zoom/rotate spiral ... use create_feedback_tunnel instead.' This clearly states when to use this tool and when to use an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_growth_systemA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses the full algorithmic behavior, the stochastic rule selection via seed, the rendering pipeline (Tube SOP, recentre), and the exact return JSON structure with paths and preview. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense yet well-structured: first sentence states purpose, second explains the algorithm, third positions it among siblings, and fourth describes the return value. Every sentence earns its place with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 11 parameters and no output schema, the description is exceptionally complete: it covers the algorithm, grammar semantics, stochastic behavior, geometry pipeline, return format, and sibling differentiation. The schema handles per-parameter details, so the description focuses on integral context.

  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%, but the description adds meaningful context beyond the schema: it explains the turtle symbols (F, f, +, -, etc.), clarifies that X/A/B are non-drawing grammar variables, and notes that multiple rules with the same `from` trigger weighted-random selection. This enriches the parameter understanding.

  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 it builds an L-system / vine-growth generator, details the construction process (Script SOP, turtle interpretation, Tube SOP), and names sibling tools (create_particle_flock, create_gpu_particle_field) to distinguish it as the deterministic CPU-geometry idiom.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly names alternatives and provides a clear usage context: 'Complements create_particle_flock (boids) and create_gpu_particle_field (curl-noise) as the deterministic CPU-geometry idiom.' This tells the agent when to choose this tool over particle-based generators.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_midi_note_reactiveA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds significant behavioral context beyond annotations. It reveals the internal chain structure (midiinCHOP → eventCHOP → Null CHOP), explains how output channels pulse, and crucially discloses that the device path is 'HARDWARE-GATED (HELD FROM RELEASE until validated with real MIDI gear).' This goes well beyond the sparse annotations and clearly communicates side effects and constraints.

  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 dense but appropriately sized—about three sentences. It front-loads the purpose, then provides a comparative alternative, usage modes, and a critical warning. Every sentence earns its place; there is no fluff or repetition of schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the full lifecycle: what the tool builds (the CHOP chain), how to interact with the result (binding to channels), the two source modes with their prerequisites, and the hardware-gating limitation. With no output schema and minimal annotations, the description carries the burden and does so completely for a creation tool of this complexity.

  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%, setting baseline at 3. The description enriches parameter meaning by explaining the practical difference between 'synthetic' and 'device' (e.g., 'procedural note pattern' vs 'real MIDI keyboard'), including the hardware gating caveat. While the schema already describes each parameter, the description adds actionable context like 'so the chain is immediately visible' and the device_name filtering example, justifying a score above baseline.

  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: 'Build a MIDI note → per-note trigger/velocity chain that exposes bindable channels on a Null CHOP (note0…noteN-1).' It uses a specific verb ('Build'), names the resource (MIDI note chain, Null CHOP), and explicitly distinguishes itself from a sibling tool ('Unlike learn_control (which binds one CC), this creates a full note-event chain'). This meets the highest bar for 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage guidance: it contrasts with learn_control, explains when to use synthetic vs device sources ('source='synthetic' (default) previews without hardware… switch to source='device' when a MIDI keyboard is connected'), and warns about the hardware-gated device path. This gives the agent clear conditional context and an alternative, fulfilling the dimension fully.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_point_cloudA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses creation details: builds a baseCOMP with specific nodes, uses GLSL TOP instancing, may prompt macOS camera permission, caps at 512² points, and returns a JSON block with paths and warnings. No contradiction found; it enriches the annotation signals with concrete actions and side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but information-dense, front-loaded with the core purpose, followed by mechanism, source options, comparison, and return value. Every sentence adds value, though some details (e.g., node list) could be tightened. Still, it's well-structured for AI consumption.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 9 parameters and no output schema, the description fully compensates by specifying the return value (summary plus JSON block with paths, point count, controls, errors, preview image), covering all source modes, performance limits, and relevant caveats. It provides sufficient context for an agent to invoke the tool correctly.

  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 coverage is 100%, but the description adds valuable semantics: it explains how depth_scale maps brightness to Z, how resolution² yields point count with a GPU-sane cap, how point_size lives on the sphere due to TOP-instancing translate-only, and clarifies source-specific parameters (file, existing). This goes beyond the schema's property descriptions and ties parameters to the rendering pipeline.

  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 starts with a clear verb and resource: 'Render a point cloud from a depth/luminance map.' It details the mechanism (scatter grid of points, XYZ from texture) and explicitly contrasts with the sibling tool create_depth_displacement. This fully distinguishes it from similar creation tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states when to use this tool vs. the alternative: 'Unlike create_depth_displacement (a continuous shaded mesh), this is a cloud of discrete dots' and 'Use create_depth_displacement instead for a continuous shaded mesh rather than discrete dots.' It also explains each source mode (synthetic, file, camera, existing) and the camera permission caveat, giving clear context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_pop_particle_systemA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond annotations by disclosing the noiseTOP fallback when force_texture_path is omitted, the three output modes, delegation to build_pop_chain, and the experimental status with an unverified marker. Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) are consistent, and the description adds valuable operational context without contradiction.

  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?

  Despite its length, the description earns its space: it front-loads the core action, then covers fallback behavior, output modes, scope delegation, alternatives, and a warning. Every sentence contributes new information without redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex tool with 8 parameters and no output schema, the description fully covers the creation scope, exact operator chain, default behaviors, output options, delegated helper, and experimental status. The only omission is an explicit return value, but given the tool creates a network, this is adequately implied by the context.

  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% and each parameter already has descriptive text. The description adds extra meaning for force_texture_path (default noiseTOP creation) and clarifies output mode semantics, but most parameter details remain in the schema. This is slightly above the baseline 3 due to the added fallback behavior.

  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 and resource: 'Build a complete POP particle simulation (particle_pop → feedback_pop → lookup_texture_pop → field_pop → null_pop) inside a new baseCOMP, wire a render rig... and expose live controls.' It clearly distinguishes itself from siblings by naming the exact operator chain and output modes, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit guidance is given with alternatives: 'This is the only particle tool built on TouchDesigner's native POP operators... pick a sibling instead for non-POP paths: create_gpu_particle_field..., create_particle_flock..., image_to_particles..., create_particle_system...' It also clarifies the tool's limited scope by delegating chain creation to build_pop_chain, so the agent knows exactly when to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_td_nodeA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnly=false, destructive=false), the description discloses valuable behaviors: legacy bridge behavior when placement is omitted, idempotent reuse preserving coordinates, type validation with warnings on unknown types, and the return shape {node, warnings[]}. This goes well beyond what annotations provide.

  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 five sentences, each carrying distinct, necessary information: purpose, placement/idempotency, validation, return value, and alternatives. It is front-loaded with the core function and contains no filler, making it efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 parameters (all documented), no output schema, and a non-trivial create operation, the description covers the essential context: return shape, placement behavior, type validation, and when to prefer another tool. Nothing critical is missing for an agent to invoke this tool 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?

  Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the placement policy ('auto' picks deterministic grid cell, 'explicit' requires coordinates), the legacy bridge behavior of omitted placement, and that reused nodes keep coordinates. This supplements the schema without repeating it.

  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 a specific verb+resource: 'Create a single bare operator (node) inside a parent COMP' and further specifies placement and viewer state. It explicitly distinguishes itself from higher-level create_* tools by stating 'For a complete wired+arranged network prefer a Layer-1 create_* tool,' making its scope clear relative to siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit context for when this tool is appropriate: creating a single bare node, with placement options. It also gives a clear when-not by directing users to a Layer-1 create_* tool for complete wired networks. The idempotency note adds practical guidance on reuse, and the warning behavior informs users about unknown types.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• generate_from_moodboardA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behavioral traits beyond annotations: side effects are node creation in TD, not file writes; color is only a best-effort hint; and a configured TDMCP_VAULT_PATH is required. It also states the return value, providing clear expectations without contradicting 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 three dense sentences with no filler. It front-loads the core READ/CREATE action and then delivers necessary side-effect, alternative-use, and prerequisite details efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having no output schema, the description explains the return value, side effects, input source, alternative invocation, and prerequisite. This is sufficient for an agent to correctly select and invoke the tool for the intended moodboard-to-system workflow.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the frontmatter fields (technique/palette/colors/speed) and clarifying that the palette is only a best-effort color hint, which enriches the meaning of the 'note' 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 the verb-resource pair: READ a moodboard note and CREATE a generative system in TouchDesigner. It further differentiates from the sibling create_generative_art by explaining that this tool reads a vault moodboard instead of taking inline parameters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly tells the agent when to use this tool: 'Use this to seed a system from a vault moodboard.' It also names the alternative, 'call create_generative_art directly to specify the technique and palette inline,' and identifies the prerequisite TDMCP_VAULT_PATH.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_inline_previewA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark this as read-only and non-destructive, and the description adds meaningful behavioral context: 'one-shot', 'base64 thumbnail', 'BFS up parent_depth hops', 'intentionally tiny + lossy', and the inclusion of cook stats. It goes well beyond what annotations provide, and it does not contradict them.

  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 yet information-dense. The first sentence front-loads the core purpose and output components; the second sentence gives usage guidance and a caveat. Every clause earns its place, and it is well-structured for quick comprehension.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 (8 params, output schema present, annotations present), the description is remarkably complete. It covers what the tool does, what it returns, when to use it, when not to use it, and the intentionally lossy nature of the preview. There is no significant missing behavioral context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the baseline is 3. The description adds extra semantics by explaining the BFS error sweep in relation to parent_depth, the 'top-N changed-from-default' for max_changed_params, and that include_full_params mirrors get_td_node_parameters. It doesn't add detail for every parameter, but it enriches the most context-dependent ones.

  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 ('inspection') with a clear resource ('TOP') and enumerates exactly what the tool returns: thumbnail, error sweep, changed parameters, and cook stats. It also explicitly distinguishes itself from siblings like get_preview, get_td_node_errors, and get_td_node_parameters by framing it as a single composite call.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit when-to-use ('when you just want to know is this op alive and healthy?') and when-not-to-use guidance ('Use get_preview/render_output for delivery-grade frames'). It also names the alternative tools, making the decision clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_infoA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial context beyond that: it succeeds with connected:false when TD is offline, reports a reason, and warns about bridge version mismatches. These are behavioral traits not inferable from annotations alone, making the description highly transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the core purpose. Every sentence provides value: what it does, what it returns, when to use it, and an edge-case warning. No filler or repetition, achieving high information density without verbosity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no parameters and no output schema, the description fully covers the essential context a caller needs: return fields, offline behavior, and the stale-bridge gotcha with a pointer to the corrective tool. It is complete for its simplicity and leaves no major operational ambiguity.

  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 takes zero parameters, so the schema is trivially complete with no description needed for parameter syntax. The description implicitly confirms this by focusing entirely on output. Following the baseline for 0 params (4), this is appropriate even though no param-level detail is added.

  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 is a 'Read-only health check + TouchDesigner server info' with a specific verb and resource. It lists the exact return fields and explicitly says 'changes nothing', distinguishing it from mutation tools. It also differentiates itself by advising 'Use this first', setting it apart from diagnostic siblings like get_td_performance or get_bridge_logs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly instructs to 'Use this first to confirm the bridge is reachable', providing clear when-to-use guidance. It also explains behavior when TD is offline and warns about a stale bridge, pointing to reload_bridge as the alternative/fix. This gives the agent actionable decision logic without ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_td_performanceA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly states 'Read-only' and 'changes nothing,' reinforcing the existing annotations (readOnlyHint=true, destructiveHint=false). It goes beyond annotations by detailing the return shape and ordering behavior ('slowest node first'), adding valuable context about what the tool produces without modifying 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?

  Two tightly packed sentences deliver all critical information: read-only nature, recursive behavior, ordering, frame-budget warnings, return shape, and explicit usage alternative. No wasted words; information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for this tool: it covers purpose, usage, behavioral guarantees, and parameter implications. The output schema already documents the return structure, so the description's mention of key fields is sufficient. It also appropriately cross-references the alternative tool, making the decision context clear.

  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 the parameters are already documented. The description adds semantic context by mentioning 'recursively by default' (matching the recursive parameter) and 'warn about nodes that exceed the frame budget' (linked to target_fps). This enriches the parameter understanding without being fully redundant.

  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 action: 'report cook times under a network (recursively by default, slowest node first) and warn about nodes that exceed the frame budget.' It also distinguishes itself from the sibling tool optimize_performance by explicitly contrasting measurement-only behavior with suggestion/auto-shrink functionality.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: 'Use this to just measure; use optimize_performance when you want suggestions and the option to auto-shrink the slow TOPs.' This clearly separates the tool from its closest alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• import_setlistA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint=false and destructiveHint=false, but the description goes further by disclosing that operators are created, some scenes are skipped, dry_run can avoid side effects, and what is returned. It also notes the environment prerequisite, adding value beyond the structured annotations.

  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 front-loaded with the main action and every sentence carries operational value, but it is dense with parentheticals and long clauses. It remains appropriate for the complexity, but is slightly less crisp than the two-sentence ideal.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 explicitly mentions the return value (resolved note path and built vs skipped lists). It also covers alternative tool usage, dry_run behavior, excluded scene types, and an environment prerequisite, making it complete for a complex build 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 100%, but the description adds substantial meaning: it explains the frontmatter structure (tracks and scenes arrays), how recipe ids resolve against built-in/vault recipes, and clarifies dry_run's validation purpose. This is a clear value-add over the terse schema descriptions.

  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 compound action: READ a setlist note and build each scene's recipe by CREATING operators under parent_path, clearly establishing the tool's purpose. It distinguishes from sibling tools by explicitly mentioning preset-only/cue-only scenes are skipped and directing to setlist_runner instead.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says preset-only and cue-only scenes are skipped and names setlist_runner as the alternative for those. It also instructs to use dry_run:true to validate without touching TD and states the prerequisite of a configured TDMCP_VAULT_PATH.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• learn_conventionsA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by clarifying the dual-side effect: 'read-only on the TD side but mutates vault files', names default writes (Memory/conventions.md and possible Memory/style.md merge), and explains dry_run behavior. This is substantial behavioral context not available from annotations alone.

  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 but information-dense; every sentence adds value (purpose, side effects, dry_run, alternatives, requirements/returns). It is front-loaded with the core function and avoids redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with six parameters and no output schema, the description covers purpose, side effects, alternatives, environmental prerequisite, and a summary of returns ('sampled conventions plus write flags'). This is sufficient for correct selection and 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 100%, so the baseline is 3. The description adds meaningful context beyond the schema by mentioning the TDMCP_VAULT_PATH requirement and how dry_run affects writes, enriching parameter understanding without duplicating schema details.

  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 ('Read a TouchDesigner subtree... infer naming/colour/topology/parameter conventions, and write the result') and clearly identifies the resource and output. It distinguishes itself from sibling tools by naming alternatives (learn_from_my_corpus, load_session_profile), leaving no ambiguity about its scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit guidance is given: 'Use learn_from_my_corpus when the source is already in the vault and load_session_profile when you only need to consume cached preferences.' The dry_run flag is also presented as an inspection option, making the tool's usage contexts clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• optimize_performanceA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behavioral nuances beyond the annotations: default is read-only, apply=true triggers mutation of TOP resolutions, and it returns before/after sizes. This clarifies the destructiveHint annotation by scoping the destructive behavior to a specific flag, while adding output expectations. No contradiction with annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, tightly packed with relevant information. The first sentence front-loads the core purpose; the second covers behavior, alternatives, and usage guidance without redundancy. Every clause earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, usage alternatives, behavioral modes, and return information ('before/after sizes', 'report the bottlenecks and suggestions'). Despite no output schema, it gives enough to understand what the tool returns in both apply modes. The dual-mode complexity is well explained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining the semantic role of apply and scale in the mutation process ('mutates flagged TOP resolutions by scale') and the resulting before/after sizes, which is not fully captured in the schema. This pushes it above baseline.

  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 starts with a specific verb-resource combination: 'Scan a network for cook-time bottlenecks and report the slowest nodes with concrete suggestions.' It clearly differentiates from the sibling get_td_performance by explicitly naming that tool and contrasting its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: 'Run get_td_performance when you only need metrics; use this tool when you want the bounded resolution change, and leave apply=false for a plan-only pass.' This gives both an alternative and a clear conditional usage pattern.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• setup_mediapipe_pluginA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description reveals crucial behavioral details: the tool loads the engine once, toggles pars, requires the timeline to be playing (embedded browser webcam), and outputs DATs rather than CHOPs. It also warns that there is no stock MediaPipe and all five tools rely on the torinmb plugin.

  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 dense but every sentence serves a purpose: purpose, differentiation, prerequisite, behavioral quirks, and output format. It is front-loaded with the primary action and maintains a logical flow without repeating parameter schema details. No fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a complex setup tool with 8 parameters, no output schema, and multiple sibling tools, the description covers prerequisites, alternatives, side effects, output types, and operational constraints (timeline playing, container_name idempotency). It is thorough enough for an agent to safely invoke the 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 coverage is 100% with each parameter already well-described. The tool description adds value beyond the schema by explaining that enabling pipelines produces DAT outputs and describing the source_video_path probing order, which is not fully captured in parameter descriptions. This enriches parameter understanding, so a slight upgrade from baseline is warranted.

  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+resource ('Drop the torinmb mediapipe-touchdesigner ENGINE') and clearly states the tool's scope (enable any combination of face, hand, body, and segmentation pipelines). It also distinguishes itself from the four setup_*_tracking siblings, which is a key differentiator.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the agent to use this tool instead of running the four separate setup tools, explaining why (each reloads the engine, causing competing MediaPipe COMPs). It also names the prerequisite install step ('tdmcp install mediapipe-touchdesigner') and notes the timeline playing requirement, providing complete usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bind_audio_reactiveA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behavioral traits beyond the annotations: it switches knobs to expression mode, appends a master knob, and fails forward with warnings rather than errors. It explicitly states that only a missing/non-COMP target is fatal, and that missing CHOPs/channels/already-bound parameters are non-fatal warnings. This is rich behavioral context not present in the minimal 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 long but every sentence earns its place, covering purpose, mechanism, parameters, error behavior, and alternatives. It is front-loaded with the core value proposition and structured logically from how-to to edge cases to sibling tool distinctions.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is complete for this mutating tool with 5 params and no output schema. It covers prerequisites, exact parameter semantics, auto-mapping heuristics, master knob behavior, fail-forward error handling, and explicit alternatives to sibling tools. Nothing important appears to be missing.

  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?

  The description adds significant meaning beyond the schema's 100% coverage, detailing the auto-mapping heuristic (bright/level/opacity→level, scale/size/zoom→bass, hue/color→treble, speed/rate/rot→mid) and clarifying the interplay between intensity and add_master (master knob scales every binding). It also explains the fail-forward behavior for missing channels, which is not 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 clearly states the tool's purpose: 'Make a whole COMP react to the music in one call' and explains the mechanism (point target at a COMP, source_chop at an audio CHOP). It distinguishes itself from siblings by explicitly naming create_audio_reactive and bind_to_channel as alternatives for different needs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit usage guidance: 'This tool only WIRES an existing COMP to an existing CHOP, building no nodes' and directs users to produce the feature CHOP first, then use this tool. It clearly states when to use alternatives: create_audio_reactive for a whole new network, bind_to_channel for finer single-parameter control.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_blob_reactiveA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses important behaviors beyond the annotations: possible macOS camera-permission dialog hang, build-dependent Blob Track operator optype/naming, fail-forward warning behavior, and Script CHOP normalization. This is substantial extra context not present in 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 front-loaded with the primary purpose and every sentence carries essential information: build steps, alternatives, warnings, output format, and parameter behavior. It is dense but not bloated relative to the complexity of the tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/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 compensates by clearly stating the return payload (summary plus JSON block) and its contents. It covers container path, CHOP path, tracked TOP, tracker type, channel names, bound targets, and warnings, making it complete for operational use.

  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?

  Despite 100% schema coverage, the description adds expression syntax (value*scale+offset), concrete channel names (blob0_x), and explains threshold drives both the Threshold TOP and the tracker. It maps targets, source, max_blobs, and camera_index to actual behavior, going beyond schema descriptions.

  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 a specific verb-resource statement ('Build a blob-position-tracking chain') and immediately distinguishes it from create_motion_reactive as the per-blob counterpart. It clearly states what is created and its purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly names create_motion_reactive as the alternative for aggregate motion and explains the camera vs. TOP source choices. It also tells when to omit targets and how to bind later, giving practical usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_data_reactiveA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses important behavioral traits beyond annotations: fail-forward error handling (warnings vs fatal), the insertion of a Lag CHOP when smooth > 0, and symmetric attack+release smoothing. Annotations only state readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description adds concrete operational details without contradiction.

  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?

  Every sentence earns its place, covering purpose, setup, parameter mapping, smoothing, error behavior, and alternatives without redundancy. The structure is logical and front-loaded with the core action, making it efficient and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (4 params, nested mappings, no output schema), the description is remarkably complete: it covers prerequisites, data flow, range remapping, smoothing behavior, error handling, and relationship to sibling tools. No significant gaps remain.

  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?

  Although schema coverage is 100%, the description adds meaning beyond the schema by explaining the role of each parameter in the workflow: pointing target at a COMP with numeric custom-parameter knobs, source_chop at a live-data CHOP, and explicit mappings with input/output ranges. This goes beyond the field-level schema descriptions.

  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: wiring arbitrary external data onto a COMP's custom numeric parameters. It uses specific verbs ('wire', 'map') and identifies the resource (COMP parameters) and scope (live data channels). It distinguishes itself from siblings by calling itself 'the data counterpart to bind_audio_reactive' and referencing bind_to_channel for finer control.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage guidance: build the data CHOP first with create_data_source, use bind_to_channel for finer single-parameter control, and explains the fail-forward behavior. This clearly states when to use this tool versus alternatives, fulfilling the 'when/when-not/alternatives' criterion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_media_binA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behavioral traits beyond the annotations: it details the internal pipeline (Movie File In, Switch, Null), exposed controls (Index, Next/Prev, Crossfade), error handling for empty/missing folders, and the crossfade mechanism (ramping fractional index). It also notes that folder reading happens inside TD, a non-obvious execution detail. No contradiction with annotations present.

  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 appropriately sized for the tool's complexity. It is front-loaded with the core purpose and then delivers structured, non-redundant details: pipeline, controls, error behavior, and usage guidelines. Every sentence earns its place; there is no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 7 parameters, no output schema, and performs a complex build operation, the description is remarkably complete. It explains the resulting component structure, exposed controls, failure mode, execution context, and intended use cases. An agent would know exactly what to expect and how to decide whether to invoke this 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?

  Although schema coverage is 100%, the description adds context that connects parameters to behavior: 'filtered to the given extensions, capped at max_clips' directly explains the extensions and max_clips parameters, and the crossfade description clarifies the crossfade parameter's semantics. It also implies how 'name' and 'parent_path' are used within the 'new bin COMP' context. This goes beyond the schema's property descriptions.

  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 ('build a clip BIN inside a new bin COMP') and resource, and explains the workflow (scan folder, create Movie File In TOPs, feed through Switch, end on Null). It also explicitly distinguishes itself from the sibling tool create_video_player, eliminating ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage guidance: 'Use create_video_player for a hand-listed playlist; use create_media_bin to ingest a whole folder for clip-based VJing.' Also clarifies that the folder is read inside TD rather than the MCP server, which is a critical prerequisite. This gives clear when-to-use and when-not-to-use context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_python_scriptA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses key behavioral nuances beyond annotations: Script DAT's read-only text and the auto-created companion callbacks DAT, that it only stores code, and that it returns the created DAT's path. This is significant context not captured by the structured fields.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the core action, and each sentence provides necessary details without redundancy. It efficiently covers creation, options, a caveat, and a pointer to the alternative tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, the description adequately explains the return value (path), the behavior across all dat_type variants, and the relationship to execute_python_script. It is complete enough for an agent to select and invoke correctly.

  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?

  While schema covers 100% of parameters, the description adds meaning by explaining dat_type with concrete examples (Text, Execute, Script) and the special behavior for Script DAT. It also clarifies that name is auto-generated when omitted, and that code goes into the DAT.

  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 specifies the action (create), the resource (DAT node), and the scope (under parent_path preloaded with code). It distinguishes itself from siblings by naming execute_python_script as the alternative for immediate execution, and explains the different DAT types.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use this tool (storing code as a node) and when not to (use execute_python_script to run Python immediately). Also clarifies the use case for each dat_type (Text, Execute, Script) with examples like onFrameStart and table builder.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_sidechain_pumpA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite annotations only indicating a mutating, open-world operation, the description discloses the exact internal chain (Select, Lag, Limit, Null CHOPs), the expression applied to each target, the warning/failure behavior ('Per-target failures become warnings; fatal only if source_chop or parent COMP is missing'), and the experimental/version caveat. This goes well beyond the structured 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 dense block but is front-loaded with the core purpose and every subsequent clause adds either distinction, construction details, or failure behavior. No filler or repetition; the formula and examples are compactly integrated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 9-parameter, no-output-schema builder tool, the description is nearly complete: it explains what is created, how the internal chain works, how targets are bound, what the stable output handle is, and what conditions cause warnings vs fatal errors. The container path is inferable from parent_path and name, so no separate return-value documentation is necessary.

  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?

  Although the schema already has 100% parameter descriptions, the tool description adds essential semantics: the actual binding expression rest_value * (1 - depth * op('<pump>')[chan0]), the meaning of depth extremes (0 = no dip, 1 = full dip to zero), and typical ranges (0.7–0.9 depth, 0.001–0.02 attack, 0.1–0.6 release). This meaningfully exceeds the schema's field-level comments.

  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 begins with a specific verb+resource: 'build a sidechain ducking envelope from a trigger CHOP channel and bind multiple target parameters to dip on every hit.' It explicitly distinguishes itself from create_envelope_follower, naming the sibling and contrasting its multiple-target pump approach.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit when-to-use guidance ('ideal for classic pumping compressor feel across many targets at once') and names the alternative create_envelope_follower with its gate/duck threshold approach. It also tells the user when to omit targets ('build the chain only (bind manually with bind_to_channel later)'), covering both use and non-use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scaffold_genreA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses specific side effects (writes the project's global tempo via op('/').time.tempo), return value structure (container path, node paths, BPM, palette), and genre-specific behaviors (installation has no clock unless bpm provided). It also clarifies that the 'master' output Null and genre look are wired into it. These details go well beyond the annotations, which only state openWorldHint=true and readOnly=false.

  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 packed with relevant information but remains well-structured: main purpose, genre-specific details, side effects, return values, and usage alternatives. Every sentence adds value, and there is no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description fully covers what the tool does, when to use it (vs. scaffold_show), what it returns, its side effects, and how to continue after invocation. It also mentions edge cases like installation without a clock. No output schema exists, so the description's explicit return-value list is essential and sufficient.

  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?

  While schema coverage is 100%, the description adds concrete preset values (~130 BPM for techno, ~70 BPM for ambient, dark/warm/muted palettes) and explains the bpm override effect for installation. This enriches the parameter meaning beyond the schema's generic descriptions.

  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 'Create a genre-flavored starting network under parent_path', which is a specific verb+resource, and immediately distinguishes from the sibling scaffold_show ('beyond scaffold_show's blank skeleton'). It clearly communicates what the tool does and how it differs from alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use scaffold_show instead for an empty skeleton with no look or palette', providing a clear when-not alternative. It also gives sequential next steps ('Then add scenes, a layer mixer into master, cues, and a control surface'), which guides the user on when to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_perform_modeA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the readOnlyHint/destructiveHint annotations by explaining the internal storage location (TD root op), the advisory mechanism, and the concrete side effect (suppresses auto preview captures). It also clarifies what it does not do, adding valuable context.

  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 well-organized: a clear opening sentence, technical details in the middle, and a practical call-to-action at the end. Every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (one boolean parameter, no output schema), the description is fully complete. It covers the purpose, mechanism, side effects, exclusions, and usage lifecycle, leaving no critical questions unanswered.

  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?

  The input schema already provides 100% coverage for the single boolean parameter, and the description reinforces its meaning with real-world usage ('enabled=false after the show'). The parameter description in the schema even explains the mechanism and limitations, exceeding baseline expectations.

  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 toggles perform mode, a specific advisory flag used before live shows. It distinguishes this from sibling tools like get_td_performance or optimize_performance by focusing on the single switch artists flip before going live.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use it ('before going live', 'after the show') and provides an advisory exclusion ('does not stop the TD timeline or kill audio/video processing'). This gives clear guidance on appropriate contexts vs. alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• update_td_node_parametersA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes beyond the annotations by disclosing strict atomic behavior, error semantics (unknown names fail entirely, bad values report partial success), and the returned value. This adds critical behavioral context for an agent to predict outcomes.

  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?

  Three sentences that front-load the core purpose, then detail behavioral nuances, then offer usage alternatives. No wasted words; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description fully equips an agent to use the tool correctly: it states purpose, prerequisites for parameter discovery, preconditions for animation, strictness semantics, and return value. No output schema is present, but the description fills that gap sufficiently.

  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?

  Even though schema coverage is 100%, the description enhances parameter understanding by clarifying that parameters are set to 'constant values', that unknown parameter names cause atomic failure, and that invalid values trigger a detailed error. This significantly augments the raw 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: 'Modify an existing node by setting one or more of its parameters to constant values.' It clearly distinguishes from sibling tools like get_td_node_parameters and animate_parameter, and the title aligns with the described behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit guidance on when to use this tool vs. alternatives: 'To inspect valid parameter names/current values first use get_td_node_parameters; to make a parameter move over time use animate_parameter instead of a static value.' This directly addresses usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.