Server Quality Checklist

Tool Scores

• connect_spout_syphon_routerC
  2.6/5.0
  Behavior2/5

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

  The description adds minor behavioral context: the tool creates a scaffold including 'route maps' and 'setup notes'. It does not contradict the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), but it also doesn't disclose concrete side effects, such as whether existing operators are modified, what files/systems are touched, or if re-running is safe.

  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 sentence, which is concise, but it packs in undefined jargon ('platform-gated', 'route maps') and front-loads no newbie-friendly orientation. It earns a middle score because brevity is present but at the expense of comprehensibility.

  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 scaffold in a TouchDesigner project (inferable from parent_path param), with 7 parameters and no output schema, the description should clarify what gets created, return values, prerequisites, and side effects. It does none of this, leaving an agent underinformed for a moderately complex generative operation.

  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 covers 57% of parameters with descriptions, but the tool description mentions no parameters at all. Terms like 'platform-gated' hint at mode/source selection but don't explain how the parameters map to behavior. The description does not compensate for the schema's gaps (e.g., 'mode' and 'active' lack descriptions).

  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 names a specific resource ('Syphon/Spout texture-sharing router scaffold') with additional features ('route maps', 'setup notes'). It is clearly distinct from sibling tools focused on other routing technologies (e.g., NDI, SDI). However, 'platform-gated' is jargon that obscures the exact mechanism, preventing a perfect score.

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

  Usage Guidelines2/5

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

  No explicit guidance on when to use this tool or when to prefer an alternative. The name and domain imply usage for Syphon/Spout texture sharing, but the description itself provides no context, prerequisites, or exclusions—leaving the agent to guess.

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

• connect_max_msp_bridgeC
  2.7/5.0
  Behavior2/5

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

  Annotations already state readOnly=false and destructive=false, but the description adds little beyond that. It hints at 'feature channel maps' but doesn't explain side effects, required environment, or what the scaffold actually creates.

  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?

  A single sentence that is front-loaded and free of redundancy. However, it sacrifices valuable information; still, this is a conciseness strength rather than a flaw.

  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 domain, the description is too sparse. It omits behavioral details, prerequisites, return values, and usage context, making it insufficient for 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 coverage is only 44% and the description does not compensate. It mentions channel maps generally but avoids specifics on ports, channel_count, audio features, or any parameter syntax, leaving the agent with incomplete understanding.

  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 uses a specific verb 'Create' and names the resource 'Max/MSP OSC bridge scaffold' plus channel maps, which distinguishes it from other bridge tools. However, 'scaffold' is somewhat vague and it doesn't explicitly contrast with sibling 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 exclusions or prerequisites. Given many sibling bridge tools, the description leaves the agent without criteria for selection.

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

• connect_rfid_badge_busC
  2.7/5.0
  Behavior3/5

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

  The description adds behavioral context beyond the annotations by mentioning 'sanitized badge events', 'privacy policy', and 'access-control safety notes', which imply privacy-aware output and safety considerations. However, it doesn't detail mutation behavior, permission requirements, or what actually happens during creation. Annotations already state non-read-only and non-destructive, so the description adds some value but remains 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 communicates the core purpose efficiently. It is not overly verbose, and no words are wasted. It could be considered slightly packed with terms, but overall it is concise and front-loaded.

  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 insufficiently complete. It does not clarify what the scaffold consists of in terms of parameters, what side effects or outputs to expect, or how the 'sanitized' and 'privacy' aspects are handled. The low schema coverage makes this a significant gap.

  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% (2 of 9 parameters have descriptions), and the description does not explain any parameter semantics. The mention of 'sanitized badge events, reader maps, privacy policy, adapter source' hints at scaffold components but doesn't map them to the schema properties. The description fails to compensate for the low schema coverage, leaving most parameters 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 a specific verb+resource: 'Create an RFID badge-reader scaffold'. It lists key contents (sanitized badge events, reader maps, privacy policy, adapter source, access-control safety notes), making the tool's purpose understandable. It doesn't explicitly contrast with siblings like connect_door_access_bus, but the RFID badge-reader focus is sufficiently distinct.

  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 guidance or alternatives are provided. The description gives no context for choosing this over similar bridge/scaffold tools, such as connect_nfc_tap_bus or connect_door_access_bus. There are no exclusions or prerequisites mentioned.

  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.8/5.0
  Behavior2/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 the listed elements, but provides no additional behavioral detail about side effects, idempotency, permissions, or impact on existing resources. It does not contradict annotations but adds minimal value beyond 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 a single, well-structured sentence, front-loaded with the core action and followed by a compact list of contained elements. 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?

  Given 10 parameters, no output schema, and basic annotations, the description is too thin to guide an agent in correctly invoking the tool. It doesn't describe return values, usage examples, prerequisites, or how the scaffold fits into a broader show network. The tool is complex but the description underspecifies it.

  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% (name and parent_path). The description lists high-level components but doesn't map them to specific parameters or explain choices like severity_count, route_count, adapter_mode, or provider. 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.

  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 resource 'public-alert scaffold', listing key components (advisory alert rows, severity maps, routing policy, adapter source, safety/escalation notes). It clearly communicates the tool's function, though it doesn't explicitly contrast with sibling 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 is provided on when to use this tool versus alternatives, no prerequisites, exclusions, or scenarios. The only implication is that it creates the described scaffold, but there is no mention of trade-offs 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.

• connect_wifi_presence_busC
  2.8/5.0
  Behavior2/5

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

  The annotations already indicate the tool is not read-only and not destructive. The description adds the list of scaffold components but does not disclose side effects, whether it modifies existing components, or any prerequisites. It only restates the creation action with slightly more detail, so minimal behavioral insight.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 gets straight to the point, listing the expected components. 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?

  For a tool with 9 optional parameters and no output schema, this one-sentence description is insufficient. It doesn't explain the parameters, what the scaffold looks like, or any behavioral considerations. The component list gives a hint but leaves many important details unaddressed.

  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 (22%; only name and parent_path have descriptions). The description mentions 'dwell buckets' and 'adapter source', which weakly correspond to dwell_bucket_count and adapter_url/adapter_mode, but it does not explain any parameter's purpose, defaults, or constraints. 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 resource ('Wi-Fi presence scaffold') and enumerates key components (aggregate occupancy rows, dwell buckets, privacy policy, adapter source, device-privacy notes), making the tool's function clear. However, the tool name says 'connect' while description says 'create', and it doesn't explicitly differentiate from sibling bus-creation tools, so a slight deduction.

  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 simply states what it does without context.

  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?

  The description adds some behavior context beyond annotations by mentioning 'sanitized vessel rows' and 'receiver/privacy notes', implying data cleaning and privacy handling. It also says 'adapter source' which hints at external connectivity, consistent with openWorldHint=true. However, it does not detail side effects, permission needs, or what happens to existing data, so the score 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.

  Conciseness4/5

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

  The description is a single, well-structured sentence that immediately states the action and key deliverables. It is concise without redundant words, though the brevity limits the amount of useful information conveyed.

  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 this tool has 10 parameters, no output schema, and very low schema coverage, the description is far too thin. It does not explain return values, output structure, prerequisites, or what the resulting scaffold contains operationally. This leaves the agent with substantial ambiguity about how to invoke and interpret results.

  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 20%, the description needed to compensate by explaining key parameters. It references zone_count, route_count, adapter, and vessel-related concepts but does not map them to specific parameter names or clarify their values/meaning. The description adds vague high-level semantics, 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 tool creates an AIS vessel scaffold and lists its key components (sanitized vessel rows, zone maps, route hints, adapter source, receiver/privacy notes). This is specific enough to distinguish it from sibling connect_* tools like connect_adsb_aircraft_bus or connect_gps_fleet_tracker, though 'scaffold' could be more explicit about the resulting TouchDesigner structure.

  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_* tools or generic create_* tools. The description provides no context about prerequisites, typical use cases, or scenarios where this tool is preferred.

  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 readOnlyHint=false and destructiveHint=false, so the description's 'Create' aligns with a write operation. It adds some context by listing scaffold components and mentions 'credential/privacy safety notes,' but it does not disclose side effects, required permissions, or what happens to existing data. The safety profile is covered by annotations, so the description provides modest additional value.

  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, consisting of a single sentence that front-loads the main action ('Create a venue calendar scaffold') and then lists key components. It avoids unnecessary words and is well-organized, though the list format makes it somewhat 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?

  Given the tool has 10 parameters and no output schema, the description is too brief. It does not explain what the scaffold is for, how it should be used, what the final result looks like, or any prerequisites or side effects. It offers only a high-level component list, which is insufficient for an agent to decide when to use it and what to expect.

  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 tool description does not compensate by explaining any of the parameters. While it mentions concepts like 'adapter source' and 'reminder maps' that loosely relate to adapter_url/adapter_mode and reminder_count, it does not clarify the meaning, defaults, or relationships of the parameters. With such low schema coverage, the description fails to provide the needed parameter context.

  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 venue calendar scaffold with specific components (event rows, reminder maps, blackout windows, adapter source, safety notes). The verb 'Create' and resource are clear. However, it doesn't explicitly differentiate from sibling tools, and the tool name says 'connect' while the description says 'create,' which could cause slight confusion.

  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 no prerequisites, no mention of suitable scenarios, and no comparison to other calendar or scaffold tools. The description simply states what it does without any usage context.

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

• connect_madmapper_surfaceC
  2.9/5.0
  Behavior2/5

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

  Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the description is not required to restate that this is a write operation. However, it adds little extra beyond the literal action; 'source handoff notes' is a feature hint, not a disclosure of side effects, prerequisites, or what changes in the project. It does not contradict annotations, but it also does not meaningfully enhance 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, front-loaded sentence with no filler. Every word contributes to conveying the core purpose and the key handoff modes. It is appropriately sized for the information it carries.

  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 10 parameters, no output schema, and annotations that only cover high-level safety hints, the description gives no information about the scaffold's structure, default behavior, or what the resulting 'surface' and 'handoff notes' entail. This is inadequate 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?

  With only 40% schema description coverage, the description needed to compensate by explaining key parameters, but it does not. It mentions Syphon/Spout and NDI, which loosely align with the handoff_mode enum, but provides no meaning for the many network and count parameters (ports, host, media_count, surface_count, etc.). This leaves the agent to guess at 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 a specific action ('Create') and a specific resource ('MadMapper OSC surface/media control scaffold'), and further specifies the inclusion of source handoff notes for Syphon/Spout/NDI. This distinctly differentiates it from other connect_* tools by naming MadMapper OSC as the target.

  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, nor are any prerequisites or exclusions mentioned. The description simply restates the tool's purpose without contextualizing it among the many similar connect_* siblings.

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

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

  The description only says 'create' but does not disclose behavioral details like side effects, whether it overwrites existing nodes, connection requirements, or any limitations. Annotations indicate readOnly=false and destructive=false, but the description adds no further safety or side-effect 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 sentence that is concise and front-loaded with the core purpose. It could add more detail without becoming verbose, but it is efficient 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 7 parameters, no output schema, and a complex topic (MIDI MPE), the description is insufficient. It does not explain what the scaffold looks like, what the return value is, or what the configuration options mean. The tool requires deeper guidance for reliable 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 coverage is low (29%): only 'name' and 'parent_path' have descriptions. The description mentions zone and expression maps but does not explain key parameters like expression_count, lower_zone_channels, include_output, or device_name. It fails to compensate for the schema's lack of 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 clearly states the tool creates an expressive MIDI MPE input/output scaffold with zone and expression maps for pressure, timbre, pitch bend, and note channels. This is a specific verb+resource+features, distinct from sibling tools like create_midi_map or create_midi_note_reactive.

  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 prerequisites, exclusions, or alternatives, leaving the agent without 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_millumin_showC
  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, so the agent knows this is a mutating, non-destructive operation with open-world effects. The description adds context by specifying what is created (OSC layer, column, dashboard control) but does not disclose potential side effects, such as overwriting existing operators or creating multiple assets beyond the scaffold. It does not contradict the annotations, so a mid-range score 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.

  Conciseness4/5

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

  The description is a single sentence that starts with the action verb 'Create' and packs many relevant details. It is efficient with no filler words, but the dense list of nouns ('layer, column, and dashboard control scaffold with command maps and setup notes') could be better structured for readability. Still, it earns a solid score 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?

  Given the complexity (9 parameters, no output schema) and the existence of many sibling integration tools, the description is insufficient. It does not explain what the scaffold enables after creation, how command maps work, or what the setup notes contain. The openWorldHint suggests broader effects, but nothing in the description fills that gap, leaving the agent uncertain about the tool's full impact.

  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 params have descriptions), so the description must compensate, but it does not. It mentions 'layer, column, and dashboard control' which loosely maps to layer_count, column_count, and dashboard_page, but does not explain send_port, receive_port, active, or other parameters. The description adds only broad context, leaving most parameters semantically 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's function: 'Create a Millumin OSC layer, column, and dashboard control scaffold with command maps and setup notes.' It uses a specific verb ('Create') and names the target resource (Millumin OSC scaffold), which distinguishes it from other connect_* siblings. However, the term 'scaffold' and 'command maps' are somewhat jargon-heavy and could be clearer about the exact integration purpose.

  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_resolume_arena' or 'connect_ableton_link_session.' The description does not mention prerequisites, use cases, or exclusions. Usage is only vaguely implied by the tool's name and description, which is insufficient for an agent to decide between this and dozens of similar integration tools.

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

• connect_omniverse_usd_bridgeC
  2.9/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 a safety baseline. The description adds little about side effects (e.g., whether it overwrites existing scaffolding, touches external servers, or requires a running Nucleus session), so it doesn't significantly enrich behavioral context 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?

  A single concise sentence that front-loads the primary purpose ('Create an NVIDIA Omniverse/USD stage sync scaffold') and then lists key components. It's efficient with no filler, but the trailing list of items makes it slightly dense and could be easier to parse if 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 (9 parameters, no output schema), the description is too sparse. It doesn't explain the scaffold's functionality, what gets created, or how to use the parameters. The lack of any return-value info and minimal parameter explanations leave an agent without enough context 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 only 22% (only 'name' and 'parent_path' have descriptions). The description mentions 'Nucleus/stage metadata, layer maps, variant maps, and live-session notes,' which loosely maps to nucleus_url, stage_path, layer_count, and variant_count, but it doesn't explain critical parameters like sync_mode, server_url, or active. The description only partially compensates 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 an NVIDIA Omniverse/USD stage sync scaffold with specific components (Nucleus/stage metadata, layer maps, variant maps, live-session notes). This differentiates it from other bridge tools by focusing on scaffold creation for Omniverse, though the title says 'Connect' while the description says 'Create', which is slightly confusing.

  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 instead of alternatives like other 'connect' or 'create' bridges. The description doesn't mention prerequisites, exclusions, or intended scenarios beyond assuming the user needs an Omniverse/USD sync setup.

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

• connect_parking_occupancy_busC
  2.9/5.0
  Behavior3/5

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

  The description adds context about what the scaffold includes (zone occupancy, sensor maps, signage policy, adapter source, privacy safety notes). With readOnlyHint=false and destructiveHint=false, the write-but-non-destructive nature is consistent, but no additional behavioral details like side effects or return format are 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 a single concise sentence that front-loads the primary action and resource. The list of components is relevant and not wasted, though it is slightly jargon-heavy.

  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 required fields, no output schema, and many similar siblings, this description is too high-level. It does not explain the structure of the scaffold, what a 'bus' means, or how the parameters interrelate, leaving significant ambiguity.

  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 described). The description does not compensate by explaining how its listed components map to parameters like capacity, provider, zone_count, or adapter_mode. The parameter names are self-explanatory but the description adds little semantic meaning beyond them.

  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 resource ('parking/queue occupancy scaffold') with a clear list of components. It is reasonably differentiated from siblings like connect_queue_length_bus, though it does not 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 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 similar siblings (e.g., connect_people_counting_bus). The description only states what it does, leaving usage context entirely implied.

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

• connect_power_meter_busC
  2.9/5.0
  Behavior3/5

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

  Annotations already specify readOnlyHint=false and destructiveHint=false, and the description adds context about the scaffold's contents (read-only readings, circuit maps, adapter source, electrical-control safety notes). This goes beyond the annotations but does not reveal operational side effects (e.g., network modifications, file creation, or connection behavior). 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, packed sentence with no filler. It lists the scaffold's components efficiently. However, the term 'scaffold' is somewhat vague and could be more structured, but overall concise and front-loaded.

  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 9 parameters, no output schema, and minimal annotations. The description only provides a high-level overview and does not explain how parameters influence the scaffold, expected outcomes, or usage workflow. It is insufficient for correct invocation in an unfamiliar 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% (2 of 9 parameters have descriptions). The description's mention of 'meter readings,' 'circuit maps,' and 'adapter source' loosely maps to meter_count, circuit_count, and adapter_url, but no parameter details or formats are given. Since coverage is low, 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 power-meter telemetry scaffold and lists its key components (read-only meter readings, circuit maps, adapter source, safety notes). Specific verb 'Create' and resource 'power-meter telemetry scaffold' clearly distinguish it from sibling tools that connect other buses or create other scaffolds.

  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 usage context is provided. The description does not indicate when to use this tool over alternatives, nor does it mention any prerequisites, alternatives, or exclusions. With dozens of sibling 'connect_*' tools, the lack of guidance leaves the agent to infer selection criteria.

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

• connect_rss_feed_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, non-destructive, open-world behavior, so the description adds some context by listing the scaffold's contents (sanitized item rows, category maps, refresh policy). However, it does not disclose potential side effects, permissions, or how 'connect' differs from 'create', leaving the behavioral profile only partially complete.

  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 front-loads the primary action and lists key features. It is efficient with no filler, though the list could be more readable if broken into shorter structures.

  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 optional parameters, no output schema, and no usage guidance, the description is insufficient. It does not explain what the resulting scaffold looks like, what 'connect' means in this context, or what return values to expect, leaving the agent without a complete picture.

  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% (name and parent_path have descriptions). The description mentions concepts like adapter source, refresh policy, and category maps, which loosely map to parameters (adapter_url, refresh_interval_sec, category_count), but it does not explain each parameter's meaning or usage explicitly. Given the low schema coverage, the description fails to fully compensate.

  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 RSS/Atom/editorial feed scaffold with specific components (sanitized item rows, category maps, etc.), making the purpose specific. However, the tool name uses 'connect' while the description says 'Create', creating slight ambiguity about whether it establishes a connection or builds a 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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or references to sibling tools like other connect_* or create_* tools, leaving the agent without decision-making context.

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

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

  The description enumerates the scaffold's contents (gift tiers, moderation policy, adapter source) but does not disclose behavioral aspects like whether it creates new nodes, modifies existing components, or requires external credentials. Annotations indicate it's a non-read-only, non-destructive, open-world operation, but the description adds minimal behavioral context 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 single sentence is densely packed with relevant terms and front-loaded with the core action. It avoids filler words, though jargon like 'sanitized event rows' may be unclear to agents unfamiliar with the domain.

  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 one-sentence description is insufficient. It doesn't explain what 'scaffold' means in this context, how the result integrates with the project, or what 'sanitized event rows' and 'auth/client safety notes' entail, making it hard 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?

  With only 22% schema description coverage, the description compensates by referencing concepts like 'gift tiers' (gift_tier_count), 'moderation policy' (moderation_level), and 'adapter source' (adapter_url/adapter_mode). However, it omits several parameters such as name, active, parent_path, and creator_label, leaving them 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 action ('Create') and resource ('TikTok Live-style event scaffold'), and lists specific components such as 'sanitized event rows, gift tiers, moderation policy' that differentiate it from generic bus tools. However, it does not explicitly distinguish it from sibling event bus tools like connect_twitch_eventsub_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?

  There is no guidance on when to use this tool versus alternatives. The description only explains what it builds, leaving the agent to infer usage from the tool name and context. No exclusions or alternative recommendations are provided.

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

• connect_unity_osc_bridgeC
  2.9/5.0
  Behavior2/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 no additional behavioral details about side effects, what gets created, prerequisites, or network setup. It merely says 'Create... scaffold' without explaining consequences or environment changes.

  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. It conveys core concepts efficiently, though the phrase 'notes' is vague. Overall it 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 no further elaboration, this one-sentence description is insufficient. It does not explain what the scaffold includes, what the user should expect after invocation, or how the preview handoff and OSC network behave.

  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 should compensate. It mentions object transforms, events, and NDI/Syphon notes, which loosely map to object_count, event_count, and preview_mode, but it does not explain any parameter semantics such as ports, hosts, namespace, or parent_path.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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') and resource ('Unity OSC and preview handoff scaffold'), and clarifies scope by mentioning object transforms, events, and NDI/Syphon notes. This distinguishes it from other bridge tools in the sibling list, which target different external systems.

  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 choose this tool over alternatives, such as other connect_* bridges or the generic connect_oscquery_namespace. The context ('Unity OSC') is implicit from the name, but there is no explicit when-to-use or when-not-to-use direction.

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

• connect_weather_forecast_busC
  2.9/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false, which already establish that this is a write operation. The description adds a list of scaffold components but does not disclose additional behavioral details such as external dependencies, network calls, or side effects on existing data. It does not 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.

  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 lists components. It is concise with no redundant filler. However, it could be more informative without sacrificing conciseness, so it does not receive a 5.

  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 modest annotations, the description is too brief to provide complete context. It does not explain return values, expected behavior after creation, or how to work with the scaffold. The list of components is ambiguous (e.g., 'safety-policy notes' is unclear), leaving substantial gaps for the 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 20% (2 of 10 parameters have descriptions). The description lists high-level components ('forecast rows', 'sensor maps', 'alert maps', 'adapter source', 'safety-policy notes') that vaguely map to parameters like sensor_count, alert_count, and adapter_url, but it does not clarify default values, enum meanings, or parameter relationships. With low schema coverage, the description fails to compensate meaningfully.

  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 clear resource ('weather forecast/station scaffold') with a list of included components (forecast rows, sensor maps, alert maps, etc.). This makes the purpose understandable, but it does not explicitly compare to sibling tools, so it doesn't fully distinguish from similar 'connect_*' or '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?

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or preferred contexts. It only states what the tool does, leaving the agent to infer the usage scenario 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_websocket_control_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 need not restate those. The description adds that the scaffold includes command maps, message schema hints, status, and safety notes, which is useful context. However, it does not explain side effects like network binding, whether it overwrites existing DATs, or how 'connect' relates to 'scaffold'. With annotations present, this is a moderate disclosure.

  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, front-loaded with the core action. It contains no fluff or redundant restatement. While it is efficient, it packs in technical terms that might be ambiguous, lowering it slightly from a perfect 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 no output schema and sparse parameter descriptions, the description carries a heavy burden. It only states the scaffold's contents but does not explain the tool's purpose context, configuration semantics, or what the user should expect as output. It is insufficient for an agent to correctly invoke and validate results.

  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 have descriptions). The description itself does not explain any parameters, despite 8 parameters with defaults. It fails to compensate for the low coverage, leaving meanings of parameters like tls, path, port, active, net_address, and command_count ambiguous.

  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 a WebSocket DAT scaffold' with specific features including command maps, message schema hints, status, and safety notes. It distinguishes from siblings by focusing on WebSocket and its scaffold nature, though it does not explicitly differentiate from similar scaffold 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, no prerequisites, or exclusions. Given the large list of sibling tools with overlapping purposes (e.g., other scaffold creators), this lack of direction makes it hard for an agent to select the right tool.

  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 this is a read-write (not read-only) and non-destructive operation. The description adds context by enumerating the scaffold components, which gives some behavioral expectation. However, it does not disclose side effects, network dependencies, or reversibility, so it adds limited 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 concise sentence that front-loads the primary action ('Create'). It packs meaningful detail without waste, though the dense jargon ('segment maps', 'privacy notes') could be more accessible. It is appropriately sized for a tool overview.

  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, no output schema, and sparse annotations, this description is insufficient. It provides a high-level summary but omits critical invocation details such as what each parameter does, how the scaffold connects to Whisper, or what the resulting structure looks like. An agent would struggle to choose and set 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 description coverage is very low (25%), with most parameters (active, audio_file, server_url, source_mode, language_hint, segment_count) lacking descriptions. The description's mention of 'audio/file/chunk ingest' and 'segment maps' only vaguely maps to parameters like source_mode and segment_count, but it does not explain parameter roles or values. It fails to compensate for the schema gaps.

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

  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 specific resource ('Whisper-compatible transcription scaffold'), and lists concrete components (audio/file/chunk ingest, segment maps, status tables, privacy notes). It distinguishes itself from sibling tools by focusing on scaffolding a Whisper transcription bus, though it does not explicitly contrast with similar 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 provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusions. The description only describes what the tool does, leaving the agent to infer applicability.

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

• connect_youtube_live_chat_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 scaffold contents (sanitized rows, tiers, moderation policy, adapter source, safety notes). Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) already indicate a non-destructive write operation. However, the description does not disclose potential side effects like API authentication needs or whether it actually contacts YouTube, which openWorldHint=true might imply.

  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 that front-loads the primary action ('Create a YouTube Live Chat scaffold') and then lists the scaffold's features as a phrase series. It is efficiently sized with no wasted words, though it packs many items into one sentence.

  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 required fields, the description is too minimal. It fails to explain what the tool returns, how connection via adapter_url/adapter_mode works, or the role of parameters like channel_id and live_chat_id. The scaffold concept is partially described, but the operational context (how to use it, what the result looks like) 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% (2 of 10 parameters have descriptions), so the description must compensate. It does map some concepts ('Super Chat tiers' → super_chat_tier_count, 'moderation policy' → moderation_level, 'adapter source' → adapter_url/adapter_mode), but leaves many parameters (active, channel_id, live_chat_id, message_count, parent_path) unexplained in both schema and description. This is insufficient for an agent to correctly configure 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 'Create[s] a YouTube Live Chat scaffold' with specific components (sanitized message rows, Super Chat tiers, moderation policy, adapter source, API/quota safety notes). This distinguishes it from other chat bus tools by platform and scaffold focus, though the name 'connect' versus description 'create' introduces slight ambiguity about whether it establishes a live connection or merely generates a 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 alternatives. It doesn't mention context, prerequisites, or exclusions (e.g., when to prefer connect_twitch_eventsub_bus or other chat buses). The description only states what it does, not when or why 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_environmental_sensor_busB
  3/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false and openWorldHint=true, so the writing nature is already clear. The description adds context about the scaffold's contents (e.g., building-control safety notes) but does not disclose additional behavioral traits such as overwrite behavior or permission requirements. 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.

  Conciseness5/5

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

  The description is a single sentence with no filler. It starts with the action verb and efficiently lists the key components of the scaffold.

  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 is too brief for full completeness. It tells what the scaffold contains but omits details about required inputs, behaviors, or expected results, 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.

  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 have descriptions). The tool description does not explain any parameters directly, only vaguely referencing 'adapter source' which could map to adapter_url/adapter_mode. This does not compensate for the poor 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 an environmental sensor scaffold with normalized readings, sensor maps, adapter source, and building-control safety notes. This specific verb+resource combination distinguishes it from generic 'create' tools, though it doesn't explicitly name an alternative tool for comparison.

  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 says what it does, with no mention of preferred use cases, 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_grafana_annotation_bridgeB
  3/5.0
  Behavior3/5

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

  Annotations already declare non-read-only, open-world, and non-destructive behavior. The description adds token-safety notes, hinting at API credential handling, but does not detail side effects like modifying Grafana or creating files. It does not contradict annotations, and the extra token-safety context is useful.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 filler. It front-loads the primary action and lists key content, earning every phrase's 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?

  For an 8-parameter scaffold tool with no output schema, the description leaves critical questions unanswered: What exactly is an 'annotation bridge'? How does adapter_mode affect behavior? What does the token-safety note cover? The map terms are undefined, making the tool difficult 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?

  With only 25% schema description coverage, the description must compensate for undocumented parameters, but it does not. It mentions dashboard/panel/tag maps without mapping them to specific parameters like dashboard_uid, panel_count, tag_count, or adapter_mode. Agents cannot infer parameter meanings from the freeform text.

  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 specific resource ('Grafana annotation/event-marker scaffold') with enumerated components. It distinguishes itself from sibling bridge tools by focusing on Grafana annotations. However, 'scaffold' is somewhat ambiguous, preventing a perfect score.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool, prerequisites, or when to prefer an alternative. The description only states what it does, leaving the agent to infer applicability from the name. No exclusions or alternative references are provided.

  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/5.0
  Behavior3/5

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

  The annotations already indicate a mutating, world-open operation. The description adds that it creates a scaffold with maps and adapter notes, and highlights token-safety warnings, which is useful safety context. However, it doesn't disclose whether it overwrites existing scaffolds, modifies parent components, or makes network calls to the endpoint, so there is room for more 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?

  A single, front-loaded sentence with no unnecessary words. It conveys the main action and lists key artifacts without redundancy, 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?

  The tool has 10 parameters, no output schema, and no description of return values or expected behavior. The one-sentence description offers a high-level summary but is insufficient for an agent to correctly invoke and configure all parameters. It lacks details about defaults, ranges, and how the scaffold integrates with the rest of the 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% (name and parent_path). The description does not mention any of the other eight parameters (org, bucket, field_count, adapter_mode, endpoint_url, poll_seconds, measurement_count) or their meaning. Terms like 'measurement maps' and 'field maps' loosely relate to measurement_count and field_count but there is no explicit mapping, leaving the agent to guess.

  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 an InfluxDB telemetry scaffold and lists specific outputs (measurement maps, field maps, adapter notes, token-safety warnings). This distinguishes it from sibling connect_* tools that target other systems. However, the phrase 'telemetry scaffold' is somewhat jargon-heavy and doesn't explicitly clarify what integration step it performs.

  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 when-to-use guidance, prerequisites, or alternatives are provided. The description implies it's for setting up InfluxDB telemetry but doesn't mention the need for a parent path or how this differs from similar create_* and connect_* tools. Users are left to infer 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.

• connect_nfc_tap_busB
  3/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 (readOnly=false) and non-destructive. The description adds some context about scaffold contents but does not disclose side effects like what happens to parent_path, whether it overwrites existing components, or what 'sanitized tap events' means at runtime. It provides minimal additional 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, focused sentence that starts with the imperative verb. It packs relevant detail without wasted words, making it efficient 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?

  For a 9-parameter creation tool with no output schema and many siblings, this description is too thin. It explains what the scaffold includes but omits when to use it, how parameters affect behavior, and what result to expect. An agent would need to infer most critical context from the schema and name 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 22% (description provided for name and parent_path only). The description's terms like 'station maps' and 'adapter source' loosely hint at station_count and adapter_url but do not explain any parameter's meaning or usage. It fails to compensate for the low schema coverage across 9 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 action: 'Create an NFC tap scaffold' with a specific verb and resource. It lists distinctive components (sanitized tap events, station maps, consent policy, adapter source, tag-privacy notes), but does not explicitly differentiate it from sibling tools like create_rfid_badge_bus or create_ble_beacon_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, nor any exclusions or prerequisites. Given the large number of similar connectivity bus tools, this is a significant gap.

  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/5.0
  Behavior3/5

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

  The description discloses that it creates a scaffold, which aligns with the annotations (readOnlyHint=false, openWorldHint=true). It adds some detail about the scaffold's components. However, it does not explain side effects, integration behavior, or what 'scaffold' entails in practice. Since the annotation already signals mutation and openness, the description adds limited new 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, lean sentence that packs the essential purpose and components. There is no fluff or repetition. It is well-structured and immediately 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 9 parameters, two enums, and no output schema, this description is too sparse. It does not explain how parameters work together, the significance of defaults, or how the scaffold fits into a larger workflow. The lack of usage context and examples leaves the agent with insufficient understanding 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?

  The schema description coverage is only 22%, so the description should compensate by explaining parameter semantics. It mentions 'zone counts', 'sample windows', 'adapter source', and 'privacy policy notes', which loosely map to parameters like zone_count, sample_count, adapter_url, and privacy_level, but it does not clarify their exact meaning, ranges, or relationships. The 'active' and 'venue_label' parameters are not referenced at all.

  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 people-counting scaffold and lists its key components (aggregate zone counts, sample windows, adapter source, privacy policy notes). The verb 'create' is specific, and the resource is well-defined, distinguishing it from generic scaffold tools. However, the tool name says 'connect' while the description says 'create', introducing 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. It does not mention typical use cases, prerequisites, or exclusions. The sibling list contains many similar 'connect_' and 'create_' bus tools, and without guidance, an agent cannot easily determine when to pick this one.

  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/5.0
  Behavior3/5

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

  Annotations indicate a write operation (readOnlyHint false) that is non-destructive and open-world. The description adds context by mentioning privacy policy and PCI/PII safety notes, which suggests these are generated or considered. However, it does not explain what actual filesystem or project changes occur, whether an adapter source is live-configured, or what the scaffold looks like after creation. It lacks detail on side effects beyond the creation act.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 about 20 words, front-loaded with the action and resource. It contains no filler or redundant information, making it highly efficient.

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

  Completeness2/5

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

  The description gives a high-level summary but is insufficient for a 10-parameter tool with no output schema. It does not specify expected output, success criteria, how the scaffold integrates into the project, or what happens after creation. The term 'scaffold' is vague and could mislead an agent about the end state.

  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 10 parameters and only 20% schema description coverage, the description must compensate but does not. It loosely maps 'sales metrics' and 'revenue buckets' to metric_count and revenue_bucket_count, and 'adapter source' to adapter_url/provider, but provides no per-parameter meaning, examples, or constraints. Parameters like aggregation_window, store_label, and metric_count remain 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 'Create a POS aggregate-telemetry scaffold' and enumerates specific included components (sales metrics, revenue buckets, privacy policy, adapter source, PCI/PII safety notes). This gives a specific verb and resource. However, the title says 'Connect' while the description says 'Create', introducing a slight ambiguity about whether it actually connects a POS or merely scaffolds 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?

  No guidance is given on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, when not to use it, or how it compares to sibling tools like connect_udp_telemetry_bridge or create_data_source. The description only states what it does, not when to do it.

  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/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 listing what the scaffold includes (metrics, sample windows, adapter source, alert notes). It does not contradict annotations (readOnlyHint=false, destructiveHint=false), and the write behavior aligns with the 'Create' verb. However, it doesn't disclose side effects or 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 a single, front-loaded sentence that conveys the essential purpose without wasted words. It is well-structured for quick parsing.

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

  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 schema coverage, this sparse description leaves an agent under-informed about how to invoke the tool correctly and what to expect from it. It provides an overview but lacks the operational details needed for reliable selection and 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 22%, so the description must compensate by explaining parameters. While it mentions 'adapter source' and 'sample windows', it doesn't map these to specific parameters like adapter_url, adapter_mode, or sample_count. Most parameters remain unexplained beyond their names and types.

  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 'queue-length scaffold' and enumerates its key components, making the purpose specific and actionable. The 'queue-length' qualifier helps distinguish it from other bus-creation tools, though it doesn't explicitly contrast with 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?

  The description provides no guidance on when to use this tool versus similar ones, such as connect_people_counting_bus or connect_parking_occupancy_bus. It lacks context about prerequisites, typical scenarios, or alternatives.

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

• connect_udp_telemetry_bridgeB
  3/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, and the description aligns with 'Create'. It adds a little context about the scaffold's contents (telemetry packets, replies, status maps, diagnostics) but doesn't disclose side effects like port binding, existing-node modifications, or whether it overwrites anything. 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 a single, front-loaded sentence with no fluff. It quickly states the action and object. It could be slightly more structured (e.g., including a result or prerequisite clause), but it is appropriately 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 7 parameters, no output schema, and a large ecosystem of sibling tools, this one-sentence description is insufficient. It doesn't explain what 'scaffold' entails, whether the tool returns the created node, or what prerequisites exist (e.g., active state, port availability). The agent may not know how to configure the parameters 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?

  Only 2 of 7 parameters have schema descriptions (29% coverage), and the description doesn't compensate. Parameters like listen_port, remote_port, remote_address, packet_count, and active are unexplained in the description. An agent gets little help understanding what these parameters mean or how they relate to 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 verb ('Create') and resource ('UDP In/Out DAT scaffold') and adds the scope of the scaffold ('telemetry packets, replies, status maps, and diagnostics'). This distinguishes it from other bridge/connection tools by its UDP telemetry focus.

  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 usage context is provided. The description doesn't say when to use this tool over siblings like connect_websocket_control_bus or connect_serial_device_bus, nor does it give any exclusions or alternatives. The only hint is the tool name itself, which isn't explicit guidance.

  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 a non-read-only, non-destructive creation behavior. The description adds that the scaffold includes tile maps, status, and calibration notes, but doesn't disclose potential side-effects like whether existing components are modified or 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?

  One concise sentence, front-loaded with the action and result. No filler; the details about tile maps, status, and calibration notes are relevant and earn their 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?

  For a creation tool with 7 parameters and no output schema, this single sentence is insufficient. It fails to explain parameter roles, expected outcomes, or any setup prerequisites, making it incomplete for effective 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 43%, and the description does not compensate. It doesn't clarify the meaning of active, canvas_width, canvas_height, or display_count, leaving those parameters under-documented.

  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 verb ('Create') and resource ('Scalable Display TOP scaffold'), and adds key contents ('display tile maps, status, and calibration setup notes'). This distinguishes it from many sibling create_* tools, though it doesn't explicitly name 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 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 implies a use case (creating a Scalable Display scaffold) but lacks prerequisites, exclusions, or comparisons to similar display-related tools.

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

• create_touchosc_layoutB
  3/5.0
  Behavior3/5

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

  The annotations already indicate this is a non-read-only, non-destructive, open-world creation tool, so the description doesn't need to restate that. It adds the valuable behavioral note that it does not generate .tosc documents, which is useful context. However, it lacks detail on side effects like network binding, project structure changes, or the exact nature of the JSON manifest, so transparency is partial.

  Agents need to know what a tool does to the world before calling it. Descriptions 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, using exactly two sentences: one to state the primary purpose and one to set an important boundary. No redundant or filler content exists, making it easily scannable. The structure is front-loaded with the verb and resource, aligning well with clarity goals.

  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 tool has 8 parameters, no output schema, and low parameter description coverage, yet the description remains a minimal statement. It doesn't explain how the controls array maps to OSC, what the JSON manifest DAT contains, or how the surface integrates into a TouchDesigner project. The .tosc disclaimer is helpful but 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.

  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 carries a responsibility to clarify the undocumented parameters. Mentioning 'OSC' hints at network-related params (send_host, send_port, receive_port) but doesn't explain their specifics, defaults, or the meaning of page_name and create_manifest_dat. The description adds little value beyond the sparse schema entries.

  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 'TouchOSC-oriented OSC mapping surface and JSON manifest DAT', using a specific verb and resource. It also distinguishes itself by explicitly stating it does not generate .tosc documents, which clarifies its scope. However, it doesn't reference sibling tools (e.g., create_control_surface, create_midi_map) for direct comparison, preventing a perfect score.

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

  Usage Guidelines2/5

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

  The description provides minimal guidance on when to use this tool. The note about not generating .tosc documents implies a boundary but doesn't offer positive use cases or compare alternatives like create_control_surface or create_phone_remote. No prerequisites or workflow context are given, leaving the agent without clear direction.

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

• connect_adsb_aircraft_busB
  3.1/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the create behavior is consistent. The description adds useful context by listing the scaffold's contents (sanitized rows, altitude bands, track history, adapter source, notes), which goes beyond the raw annotations. However, it does not disclose operational details such as how the connection is established, whether it initiates network traffic, or what 'sanitized' implies in terms of data handling.

  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 leads with the verb 'Create' and front-loads the primary resource. It is efficient and contains no filler. The long list of components makes it slightly dense, but it remains scannable and avoids unnecessary 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 10 parameters, no output schema, and a likely external integration role, the description is too short to fully equip an agent. It omits what 'connecting' entails, how the scaffold is structured, the meaning of 'feed/privacy notes', and how this tool relates to sibling 'connect_*' and 'create_*' tools. The description provides only a high-level component list without operational or relational 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 only 20%, so the description must compensate for the nine undocumented parameters. It does reference several parameter concepts: 'adapter source' hints at provider/adapter_url/adapter_mode, 'altitude bands' maps to altitude_band_count, and 'track history metadata' maps to track_history_count. But the mapping is implicit, and parameters like active, airspace_label, and aircraft_count are not clearly tied to the description, leaving gaps for the agent.

  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 'ADS-B aircraft scaffold', then lists specific components (sanitized aircraft rows, altitude bands, track history metadata, adapter source, feed/privacy notes). This provides a concrete picture of what the tool produces. However, the tool name says 'connect' while the description says 'create', introducing slight ambiguity, and it doesn't explicitly contrast with similar data bus tools, though the aircraft-specific details differentiate 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?

  No explicit guidance is given for when to use this tool versus alternatives such as connect_ais_vessel_bus or other create_* scaffolding tools. The description implies it is for ADS-B aircraft data, but it does not state prerequisites, exclusions, or scenarios where another tool would be more appropriate.

  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
  Behavior3/5

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

  The description adds context by mentioning 'access-token safety notes' and the scaffold components. However, it does not disclose side effects, idempotency, or prerequisites beyond what annotations already indicate (readOnly=false, destructive=false). With annotations present, 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, well-structured sentence that front-loads the main verb and resource. It lists many components without excess verbosity or repetition, making it 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?

  With 10 optional parameters, no output schema, and minimal parameter descriptions, the description offers only a high-level overview. It does not explain what the tool returns, how parameters interrelate, or behavioral details, making it insufficient for correct invocation in varied contexts.

  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% (just name and parent_path). The description lists scaffold components like 'token rows' and 'adapter source' but does not map them to specific parameters (token_count, component_count, adapter_url, etc.). It fails to compensate for the low schema coverage, leaving parameter meanings unclear.

  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 'Figma design-token scaffold' with specific components, which is a distinct resource. However, the tool title says 'Connect' while the description says 'Create', creating minor 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 Guidelines3/5

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

  The description implies usage through its name and content, but does not explicitly state when to use this tool versus alternatives. There are many sibling 'connect_*' and 'create_*' tools, but no when/when-not guidance or exclusions are provided.

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

• connect_pangolin_beyondB
  3.1/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 the description aligns with. The description adds valuable context beyond annotations by stating it is 'safety-gated' and makes 'no live-output claim,' disclosing that no live output will be produced—essential for a laser-control 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, direct sentence that front-loads the core action and important constraints. No wasted words; every part 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 9 parameters, low schema coverage (22%), and no output schema, the description is incomplete. It explains the conceptual outcome but leaves operational details—like what the scaffold returns, how parameters affect the result, and what 'safety-gated' entails—unexplained.

  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% (2 of 9 params), and the description provides no parameter-specific details. The mention of 'zone maps, cue maps, blackout notes' maps loosely to zone, cue_count, and safety_blackout, but does not clarify their types or usage. The description does not compensate for 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 specific verb and resource: 'Create a safety-gated Pangolin Beyond laser-control scaffold' and lists key components (zone maps, cue maps, blackout notes). This distinguishes it from generic scaffold tools, though it does not explicitly differentiate from closely related siblings like create_safety_blackout_chain.

  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. The 'safety-gated' and 'no live-output claim' hints at context, but there is no explicit when-to-use or when-not-to-use instruction.

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

• connect_qlab_cue_stackB
  3.1/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 (readOnlyHint=false) and not destructive (destructiveHint=false), and the description clarifies it creates a scaffold rather than modifying existing entities. However, it does not mention side effects like immediate OSC activation (from the active parameter), external dependencies, or what happens to existing cue stacks.

  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 that directly states the action and object. It is concise with no wasted words, though terms like 'status' and 'rehearsal-focused setup notes' are slightly vague.

  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 what a 'scaffold' entails, how OSC networking is configured, whether QLab must be running, what the return value looks like, or why rehearsal-focused notes are included. This leaves significant gaps for an agent to invoke and interpret results 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 67% of parameters with descriptions, so the description does not need to repeat them. The phrase 'cue command maps, status, and rehearsal-focused setup notes' adds some sense of what the scaffold produces, but it does not clarify ambiguous parameters like cue_count, send_port, or receive_port, which the schema leaves undocumented.

  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 ('QLab OSC cue-stack scaffold') with added context about contents (cue command maps, status, setup notes). However, the tool title says 'Connect' while the description says 'Create', creating minor ambiguity and not fully distinguishing from sibling tools like qlab_osc_bridge or create_cue_sequencer.

  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 qlab_osc_bridge or create_cue_sequencer. It describes what it does but gives no context for selection, 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_reaper_transportB
  3.1/5.0
  Behavior3/5

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

  Annotations already mark this as non-read-only and non-destructive, and the description aligns with 'create' as an additive operation. It adds context about OSC transport, tracks, and markers, but doesn't disclose side effects like whether existing scaffolds are modified or whether network connectivity is required. Since annotations cover the safety profile, the minimal additional disclosure 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, reasonably concise sentence with no filler. It front-loads the key action and resource. The vague 'operator-approved recording templates' could be clarified but overall it's 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?

  For a tool with 10 parameters, no output schema, and low schema coverage, the description is too thin. It doesn't explain what the scaffold returns, what 'operator-approved' means, or what parameters are essential. An agent would need to inspect the schema for defaults and still lack behavioral context (e.g., does it overwrite, does it need REAPER listening).

  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 carries more burden but barely addresses individual parameters. It mentions 'track' and 'marker' which map to track_count and marker_count, but provides no guidance on send_port, receive_port, reaper_host, or include_record. This leaves most parameters underdocumented for a low-coverage 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 identifies the tool's function with a specific verb ('Create') and a specific resource ('REAPER OSC transport, track, and marker bridge scaffold'). It distinguishes from sibling connect_* tools by explicitly naming REAPER and its components. However, the phrase 'operator-approved recording templates' is ambiguous and could be more precise.

  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 REAPER OSC bridge but provides no explicit when-to-use guidance or alternatives. It doesn't mention prerequisites (e.g., REAPER running with OSC enabled) or contrast with other connect_* tools. This leaves the agent to infer appropriateness from the tool 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_serial_device_busB
  3.1/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 (readOnlyHint=false) and not destructive, so the description doesn't need to restate that. It adds context by specifying it creates a scaffold with DAT/CHOP and parse maps, but doesn't disclose potential side effects such as hardware access or overwriting existing nodes.

  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 concise single sentence that front-loads the main action and resource. However, the final clause 'show-control devices with parse maps' is somewhat ambiguous and could be clearer, but overall it is appropriately sized and 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 7 parameters and no output schema, the description is insufficient. It doesn't explain the scaffold's behavior, how it connects to a serial port, or what parse maps are. The low schema coverage and lack of return value documentation leave the agent under-informed about how to configure and use 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%, with descriptions for only name and parent_path. The description mentions 'parse maps' but doesn't explain any of the critical parameters like device, baud_rate, or message_count, which are essential for serial configuration. 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 Serial DAT/CHOP scaffold for microcontrollers, sensors, and show-control devices, which distinguishes it from other connectivity tools. The verb 'Create' and resource 'Serial DAT/CHOP scaffold' are specific, but the phrase 'show-control devices with parse maps' is slightly ambiguous.

  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 case is implied through 'for microcontrollers, sensors, and show-control devices,' but there is no explicit guidance on when to use this tool over alternatives like connect_webrtc_browser_input or connect_ableton_link_session. No exclusions or alternative tool mentions are provided.

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

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

  Annotations already convey mutating, non-destructive, and open-world behavior. The description adds that the scaffold includes licensing/runtime warnings and stable output/fallback modes, which is useful context, but it does not disclose deeper side effects, conditions, or failure modes. 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 that is front-loaded with the verb and object, and every clause adds distinguishing features. It is slightly dense but remains concise and 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?

  This is a complex tool with 8 parameters and no output schema, yet the description omits key context such as what 'scaffold' means in TouchDesigner, what the mode choices (touchengine, notch_top, ndi_fallback) do, or how it relates to the near-duplicate sibling. The agent is left without enough information to confidently 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 coverage is high (88%) and includes descriptions for most parameters such as name, active, output_name, and control_channels. The description adds no additional parameter-level meaning, 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.

  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 TouchEngine/Notch bridge scaffold with a specific list of features (stable output TOP, control channels, fallback modes, licensing warnings). It uses a specific verb and resource, but it does not differentiate from the nearly identical sibling tool 'notch_touchengine_bridge'.

  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 the similar 'notch_touchengine_bridge' or other bridge-creation tools. The description implies a general use case but lacks explicit when/when-not statements or alternatives.

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

• create_decklink_io_routerB
  3.1/5.0
  Behavior3/5

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

  Annotations already establish that this is a mutating, non-destructive, open-world operation. The description adds that it produces a scaffold with route maps and safety notes, but it does not clarify what 'hardware-gated' entails or what external side effects may occur given the openWorldHint annotation. It provides some additional context but not rich behavioral disclosure.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that effectively communicates the core purpose. Every word contributes to the message, with no fluff or redundancy. It is concise and appropriately 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 complexity of the tool (7 parameters, openWorldHint, many sibling alternatives), the description is severely incomplete. It leaves out parameter semantics, usage guidance, and concrete behavioral details beyond a vague mention of 'hardware-gated safety notes.' This is not enough for an agent to confidently invoke the 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?

  With schema description coverage of only 29%, 5 of 7 parameters lack meaningful descriptions, and the tool description does not mention any parameter details. The agent is left uninformed about critical parameters like route_count, signal_format, or input_device. The description completely 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 'Blackmagic DeckLink video-device input/output router scaffold' with specific features like 'route maps' and 'hardware-gated safety notes.' This is a specific verb+resource construction that distinguishes it from similar router-creation tools such as create_ndi_router_matrix or connect_blackmagic_atem.

  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, prerequisites, or alternatives. It does not mention any context in which this tool should be preferred over sibling tools, nor any exclusions or conditions.

  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_busB
  3.1/5.0
  Behavior3/5

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

  With annotations already declaring readOnlyHint=false and destructiveHint=false, the description adds some context by specifying it creates placeholders rather than a fully functional setup. However, it does not disclose side effects like whether it overwrites existing nodes or requires a Leap Motion device to be 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 a single, front-loaded sentence that directly states the tool's purpose and key components. Every word contributes value without being overly verbose.

  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 6 parameters and no output schema, the description covers the basic components (CHOP/TOP placeholders, hand maps, gesture maps, setup notes) but misses important context such as how parameters affect the output, whether the scaffold is a standalone bus, and what 'active' means. It is adequate but 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 33% (name and parent_path have descriptions). The description mentions 'hand maps' and 'gesture maps' which loosely correspond to hand_count and gesture_count, but it does not explain parameters like active, include_image_top, or how the scaffold is structured. The description adds minimal meaning beyond the parameter names.

  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 Leap Motion hand/gesture scaffold with specific components (CHOP/TOP placeholders, hand maps, gesture maps, setup notes). It uses a specific verb and resource, but does not explicitly distinguish itself from the similarly named sibling tool '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 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, use cases, or exclude any scenarios. The word 'scaffold' implies early-stage setup but it is not stated explicitly.

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

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

  Annotations already indicate a non-read-only, open-world, non-destructive operation. The description adds no behavioral context beyond the act of creation, such as side effects on the existing network graph, whether existing operators at parent_path are modified, or any prerequisites. This leaves the agent without important 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 a single sentence that is front-loaded with the primary action and object. It uses no filler words and is appropriately concise for the tool's straightforward creation 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 nine parameters, minimal schema descriptions, and no output schema, the description is too sparse to support correct invocation. It omits usage context, parameter semantics, return behavior, and any prerequisites or side effects, making it insufficient for a tool with this complexity.

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

  Parameters2/5

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

  Schema description coverage is only 22%, so the description must compensate for undocumented parameters. It does not explain any parameters explicitly; it only vaguely refers to 'joint and rigid-body mapping surfaces', which hints at skeleton_count and rigid_body_count but does not clarify their meaning or relationships. The low-coverage schema and lack of parameter explanations leave 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 identifies a precise resource: a generic OptiTrack/Rokoko/Axis Studio/VRPN-style mocap bus scaffold with joint and rigid-body mapping surfaces. This clearly differentiates it from sibling tools that target specific vendors like create_optitrack_tracking_bus or connect_xsens_mvn_mocap.

  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 vendor-specific bridges or any criteria for selecting the generic scaffold over specific ones, leaving the agent to infer usage from sibling names.

  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.1/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, which the description does not contradict. However, the description adds only that it 'creates a scaffold' with maps and notes, without disclosing additional behavioral details like whether it overwrites existing components or requires a specific Windows environment, so it adds minimal value 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 concise sentence that starts with the verb 'Create' and avoids redundancy. However, the conciseness contributes to under-specification, though the structure itself is efficient and front-loaded.

  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 6 parameters, minimal schema coverage, and no output schema, the description is far too sparse. It does not clarify the meaning of 'panel maps', 'touch-slot maps', or 'platform notes', nor how parameters affect generation, nor what the tool returns, making it incomplete for realistic agent use.

  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% (2 of 6 parameters described), and the tool description mentions no parameter semantics at all. It does not explain how parameters like max_touches, panel_count, or mouse_as_touch relate to the generated scaffold, leaving agents with almost no guidance for parameter values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 action (Create) and the specific resource (Windows Multi Touch In DAT scaffold), and lists components (panel maps, touch-slot maps, platform notes). This distinguishes it from sibling touch-related tools like create_touchosc_layout or connect_tuio_touch_surface.

  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 phrase 'Windows Multi Touch In DAT' implies it is intended for Windows touch input capture scaffolds, but no alternative tools are named or exclusions are given, leaving usage context implied.

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

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

  Annotations already indicate a write/create operation (readOnlyHint=false, openWorldHint=true), and the description aligns with that. However, it adds no behavioral context beyond the annotation, such as what the scaffold modifies, side effects, or how it interacts with the existing 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, efficient sentence that immediately communicates the tool's purpose. No wasted words, and it is appropriately front-loaded with the action verb 'Create'.

  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 tool with a large sibling set, the description is too sparse. It omits usage guidelines, parameter semantics, and deeper behavioral details, relying solely on annotations that provide limited 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 29% (2 of 7 parameters have descriptions), and the tool description does not compensate by explaining any parameters. The listed maps ('pose, lens, video-preview, calibration') are internal components, not 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 the tool creates an 'NCAM camera-tracking scaffold' with specific map types, using a specific verb and resource. It distinguishes from sibling tracking buses by explicitly naming NCAM, which is a unique tracking 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 is provided on when to use this tool versus the many sibling tracking bus creators (e.g., OptiTrack, Blacktrax). The description lacks any context about prerequisites, alternatives, or exclusionary conditions.

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

• connect_discord_interaction_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 and destructiveHint=false, so the description need not repeat the write/intent. It adds some context by specifying that the scaffold includes 'bot-token/signature safety notes' and 'adapter source', which hints at configuration behavior. However, it does not disclose side effects, required authentication, or how the scaffold interacts with external Discord systems, 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.

  Conciseness4/5

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

  The description is a single sentence, dense but not verbose. Every phrase adds meaning, listing specific scaffold components. It loses a point because the long comma-separated list makes it slightly less scannable, but overall it is efficient and front-loaded with the action 'Create'.

  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 optional parameters, no output schema, and minimal annotations, the description leaves many gaps. It does not explain the purpose of parameters like active, guild_label, or channel_label, nor does it describe what happens after creation, return values, or how the scaffold is structured. The description is too brief to fully support invocation 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 description coverage is low (20%), with only 'name' and 'parent_path' described. The description mentions concepts like 'command rows', 'message rows', 'approval policy', and 'adapter source', which map to some parameters (command_count, message_count, approval_required, adapter_url/adapter_mode), but it does not explain individual parameters or cover active, guild_label, channel_label, or numeric bounds. The description partially compensates but not sufficiently for 10 parameters.

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

  Purpose5/5

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

  The description clearly states the verb 'Create' and the resource 'Discord interaction scaffold', listing specific components (command rows, message rows, approval policy, adapter source, safety notes). This distinguishes it from sibling tools like connect_mqtt_iot_bus or connect_webrtc_browser_input, which target different platforms.

  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 explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or alternative tools. The purpose is implied by the name, but no context is given for choosing this over other connect_* tools, leaving the agent without decision support.

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

• connect_geojson_feature_busB
  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, and openWorldHint=true, so the agent knows this is a non-destructive write operation. The description adds specifics about what is created (scaffold with feature rows, property maps, style rules, adapter source, projection/privacy notes), but does not disclose any potential side effects or prerequisites beyond the parent path. 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 front-loads the action and enumerates the scaffold components. It is concise and contains no filler, though the listing is dense and could be seen as a run-on. Still, 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?

  Given the tool has 10 parameters (all optional), no output schema, and low schema coverage, the description alone is insufficient for an agent to invoke it correctly. It lacks usage context, parameter-role mapping, and any indication of what the resulting scaffold looks like or how it integrates into the project. The mention of 'projection/privacy notes' is opaque and unsupported by the schema.

  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 'adapter source', 'feature rows', 'property maps', and 'style rules', which loosely map to adapter_url/adapter_mode/source_label, feature_count, property_count, and style_rule_count, but it does not clarify the remaining parameters like active, geometry_mode, or their relationships. The compensation is partial and leaves many 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's purpose: 'Create a GeoJSON feature scaffold' with a specific list of included elements (feature rows, property maps, style rules, adapter source, and projection/privacy notes). It distinguishes itself from sibling 'connect_*' tools by naming GeoJSON feature bus explicitly.

  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 preconditions, and no examples of appropriate scenarios. It merely describes what it creates 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_huggingface_inference_bridgeB
  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, implying mutations and external interactions. The description adds context by mentioning specific scaffold artifacts (token-env hints, adapter notes) that go beyond simple creation, but it does not disclose details about external API calls, required permissions, 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.

  Conciseness4/5

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

  The description is a single sentence, appropriately concise and front-loaded with the action ('Create') and resource ('Hugging Face Inference Endpoint scaffold'). The list of scaffold components is dense but not unnecessary. It could be clearer with punctuation, but it remains 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?

  With eight parameters, low schema coverage, and no output schema, the description does not provide enough context. It lists scaffold features but does not explain what the tool returns, what side effects occur, or how the generated scaffold integrates with the project. The description is too thin to fully guide 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?

  Only 25% of parameters have schema descriptions, so the description needs to compensate. It references 'task input maps' and 'output contracts' which loosely map to 'task' and 'output_mode' parameters, but it does not clarify the meaning or relationships of the eight parameters. The coverage is too low and the description too vague to add meaningful semantic 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 tool's function: 'Create a Hugging Face Inference Endpoint scaffold' with specific deliverables (task input maps, output contracts, token-env hints, adapter notes). This distinguishes it from sibling bridge tools by focusing on the Hugging Face inference context and specific 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?

  No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. It only describes what the tool does, leaving the agent to infer 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.

• connect_isadora_patchB
  3.2/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 agent knows this is a mutating but non-destructive operation. The description adds context about what is created (actor, watcher, scene exchange scaffold) and 'stable namespace mapping', but doesn't disclose further behavior like prerequisites 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 sentence that is front-loaded with the verb and key resource. There is zero waste and every word adds meaning, making it appropriately 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 10 parameters, no output schema, and only basic annotations, the description needs to explain more about the scaffold's behavior, return values, or prerequisites. It only provides a high-level purpose, leaving significant gaps for a complex operation.

  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 doesn't explicitly define any parameter meanings; it merely hints at concepts via 'actor', 'watcher', 'scene', and 'namespace'. This doesn't sufficiently 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 resource ('Isadora OSC actor, watcher, and scene exchange scaffold') with an additional qualifier ('stable namespace mapping'). This clearly distinguishes it from other connection tools like connect_max_msp_bridge or connect_ableton_link_session, though it doesn't explicitly mention 'connect' as an action.

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

  Usage Guidelines3/5

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

  The description implies usage for Isadora OSC integration but doesn't provide explicit when-to-use or alternative guidance. It lacks exclusions or comparisons to sibling connect tools, so guidance is only inferred from the purpose.

  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?

  The description confirms a non-read-only action (create) and adds that it produces a scaffold with specific items, which is consistent with the annotations. It does not disclose side effects, permission needs, or the exact network modifications, but the annotations already convey the non-destructive, non-read-only 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 a single sentence, front-loaded with the primary action and resource, and lists components without unnecessary fluff. It is concise and readable, though slightly dense with the enumeration.

  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 minimal schema-level descriptions, the description is too brief to provide a complete understanding. It does not explain what the scaffold entails, how parameters interact, or what the result looks like.

  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 vaguely references sample windows and adapter source, which map to sample_count and adapter_url, but it does not explain the meaning or usage of most parameters. With only 20% schema description coverage, the description fails to compensate for the 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 clearly states the tool creates a noise-level telemetry scaffold and lists key components (aggregate decibel readings, sample windows, adapter source, PA/safety policy notes). This specific verb+resource combination distinguishes it from generic create/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?

  The description provides no guidance on when this tool should be used versus alternatives like connect_environmental_sensor_bus or create_data_source. There are no use cases, prerequisites, or exclusions mentioned, leaving the agent to infer applicability.

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

• connect_opcua_industrial_busB
  3.2/5.0
  Behavior3/5

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

  Annotations already convey that the tool is not read-only and not destructive. The description adds some context by indicating it creates a scaffold (rather than a live connection) and includes 'read-only safety-policy notes,' but it does not disclose side effects such as whether it makes external network calls or requires an OPC UA server. This adds value but leaves gaps.

  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, well-structured sentence that front-loads the primary action and resource, followed by a list of components. It is concise and free of redundant wording, though the dense jargon could be slightly 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?

  Given the tool's complexity (12 parameters, no output schema, sparse annotations), the description is incomplete. It does not explain how the scaffold is structured, how parameters interact, or what the agent should expect after invocation. A more thorough description is necessary for safe and 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?

  With only 17% schema description coverage, the description was expected to compensate for the 12 parameters, but it does not. It mentions high-level concepts like 'adapter ingest options' and 'node maps' without mapping them to specific parameters or explaining enum choices like adapter_mode or security_policy. The description adds minimal parameter-level 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 verb 'Create' and the resource 'OPC UA industrial telemetry scaffold', listing specific components (node maps, adapter ingest options, status tables, read-only safety-policy notes). This distinguishes it from sibling tools like connect_mqtt_iot_bus or connect_udp_telemetry_bridge, which target different protocols.

  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 explicit guidance on when to use this tool, prerequisites, or alternatives. While the name implies OPC UA connectivity, the description only states what it creates, leaving the agent to infer usage context without any 'use when' or 'instead of' cues.

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

• connect_qr_scan_busB
  3.2/5.0
  Behavior3/5

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

  The description adds context beyond annotations by listing what the scaffold creates (sanitized events, route maps, sanitization policy, adapter source, safety notes). However, it does not disclose concrete behavioral details such as how the scaffold wires into an existing project, what 'sanitized' means in practice, or whether external connections are established. Annotations already flag it as non-read-only and non-destructive, and the description 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.

  Conciseness4/5

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

  The description is a single front-loaded sentence that wastes no words and lists the main deliverables. It is concise, though the dense list of jargon-loaded terms could be clearer with slight elaboration.

  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 schema description coverage, the description is insufficient for an agent to confidently invoke the tool. It does not explain how parameters map to the resulting scaffold, what the generated output will look like, or how the tool fits into a broader workflow. The agent would likely need to ask for clarification.

  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), so the description must compensate, but it only loosely hints at parameter roles ('adapter source' likely maps to adapter_url/adapter_mode, 'sanitization policy' to sanitization_level). It does not explain the meaning, defaults, or effect of most parameters such as active, campaign_label, scan_event_count, or route_count.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 specific resource ('QR scan scaffold'), and it lists the scaffold's key components (sanitized scan events, route maps, sanitization policy, adapter source, token/URL safety notes). This clearly distinguishes it from the many similar connect_*_bus and create_* 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?

  There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites, exclusions, or appropriate use cases. The name and description imply it is for QR scan scaffolding, but no explicit 'use when...' or 'avoid if...' guidance is provided.

  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 the tool is not read-only and is open-world. The description adds 'Runtime validation against Resolume remains explicit,' which is a useful behavioral note. However, it does not disclose potential side effects like network connections, persistence, or failure modes, leaving moderate 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 two sentences: the first states the core action and deliverables, the second notes a key behavioral constraint. It is front-loaded, concise, 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?

  Despite having 11 parameters and no output schema, the description is minimal. It mentions a few artifact types but does not explain how parameters map to behavior, prerequisites, expected outcomes, or how to verify success. This is insufficient for a tool of this complexity, especially with sparse annotations.

  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%, and the description does not explain any parameters beyond the schema. It lists scaffold elements but does not map them to the 11 parameters, leaving several parameters (like send_port, clip_count, deck_count, layer_count, preview_mode) with no descriptive meaning in either schema or 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 specifies 'Create a Resolume Arena/Avenue OSC control scaffold' with command maps, status DATs, and preview handoff notes, which clearly states the action and resource. It is informative but does not explicitly distinguish from sibling tools like 'resolume_vdmx_output_chain' or 'osc_router_matrix', which are also connection/scaffolding 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 setting up Resolume OSC control but provides no explicit when-to-use or alternative guidance. Given the many sibling connection tools, mention of when not to use or alternatives would be helpful; without it, usage timing 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_rvc_voice_conversion_busB
  3.2/5.0
  Behavior2/5

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

  Annotations are sparse (readOnlyHint=false, openWorldHint=true, destructiveHint=false), so the description carries the burden of disclosing behavior. It enumerates scaffold contents but does not mention system side effects such as node creation under parent_path, network/server connections, file writes, or external service dependencies. This leaves significant behavioral ambiguity.

  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 that efficiently lists key aspects without redundancy or filler. It is front-loaded with the core action and resource, making it easy to scan. However, given the tool's 11-parameter complexity, the brevity approaches under-specification.

  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 annotations, this description is too thin to support correct invocation. It lacks prerequisites, return behavior, parameter relationships, and any guidance on how the scaffold is created or connected. For a create operation of this complexity, the description does not provide enough 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 18%, with most parameters lacking descriptions. The tool description broadly mentions 'source audio' and 'model maps' but does not map these to concrete parameters like audio_file, model_path, source_mode, server_url, or transpose_semitones. It therefore 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 names a distinct resource ('RVC-style voice conversion scaffold'), which clearly differentiates it from the many other connect_* and create_* siblings. The added components (source audio, model maps, output contracts, latency notes, consent warnings) make 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 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 RVC voice conversion scaffold through its wording, but it offers no explicit when-to-use guidance or alternatives. There is no indication of when to choose this over similar voice/AI bus tools, so usage is inferred rather than stated.

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

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

  Annotations already indicate it is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds context by naming the scaffold components, but it does not disclose side effects such as modifications to the parent COMP or network connections, leaving the openWorldHint unelaborated.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 wasted words, front-loading the action and listing components efficiently. It is appropriately concise for a high-level purpose statement.

  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 no output schema, this one-sentence description is insufficient. It leaves key terms like 'sanitized tag positions' and 'spatial policy' undefined, and does not explain what the scaffold does or what the result looks like. The complexity demands more detail.

  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 should compensate for the other 8 parameters. It vaguely references concepts like adapter source and spatial policy, but does not explain parameter meanings, defaults, or how they affect the scaffold, failing to bridge the gap.

  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 clear action ('Create') and resource ('UWB RTLS scaffold'), listing specific components like sanitized tag positions, anchor maps, and spatial policy. This distinguishes it from generic create tools, though it does not explicitly compare it 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 Guidelines3/5

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

  The description implies the tool is used to create a UWB RTLS scaffold, giving a basic use case. However, it provides no guidance on when to choose this over alternatives, no prerequisites, and no exclusions or when-not-to-use scenarios.

  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.2/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 open-world operation. The description adds that the scaffold includes receiver, trackable maps, zone maps, and calibration notes, offering some scope of what gets created. However, it does not disclose side effects like network connectivity, whether it overwrites existing components, or how the active parameter influences behavior. It adds modest value 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 concise sentence that front-loads the core action and enumerates components without redundancy. It is appropriately sized and easy to parse, though the jargon 'scaffold' and 'trackable maps' might be slightly unclear to an unfamiliar agent.

  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 six parameters and no output schema, the description does not provide enough operational detail. It omits parameter behavior, prerequisites (e.g., parent_path must exist), return values, and failure modes. The high-level overview leaves many questions unanswered for a complex scaffold-creation tool, 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 33%, and the description does not explicitly explain any of the six parameters. While 'zone maps' and 'trackable maps' hint at the roles of zone_count and trackable_count, there is no mapping for port, active, or parent_path beyond the sparse schema descriptions. 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 BlackTrax tracking scaffold and names its key components (receiver, trackable maps, zone maps, calibration notes), making the action and scope explicit. It uniquely identifies the resource (BlackTrax) which distinguishes it from sibling tracking-bus tools like 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 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 other tracking-bus or scaffold tools, nor does it mention prerequisites or exclusions. The only implied usage is the verb 'create', which is too vague for deciding between this and similar tools in the large sibling set.

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

• create_realsense_depth_busB
  3.2/5.0
  Behavior2/5

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

  The description discloses that the tool creates a 'scaffold' and includes routing notes, but provides no detail on side effects such as whether existing nodes are modified, if external dependencies are required, or what exactly a scaffold entails. With annotations indicating readOnlyHint=false and destructiveHint=false, the description adds little beyond the term 'create' to clarify the mutation behavior or network impact.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 and resource ('Create an Intel RealSense depth-camera scaffold'), then efficiently lists the modes and key routing features. No redundant or filler words; every phrase contributes to understanding the tool's scope.

  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 being a complex tool with 10 parameters and no output schema, the description does not explain what the scaffold looks like, what the routing notes contain, how the modes differ in behavior, or what the operation returns. It lacks crucial context for an agent to predict the outcome or verify success, especially when many similar create_*_bus tools exist.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description adds some meaning by mapping source_mode options (e.g., 'RealSense TOP' to realsense_top) and hinting at include_color/include_pointcloud via 'depth/color/point-cloud routing notes.' However, it does not clarify parameters like resolution, serial_number, server_url, or parent_path beyond the schema's own descriptions. Schema coverage is about 50%, so the description provides partial compensation but not full 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 explicitly states it creates an Intel RealSense depth-camera scaffold, listing the specific source modes (RealSense TOP, NDI, WebSocket adapter, sample-source) and mentions depth/color/point-cloud routing notes. This clearly distinguishes it from sibling tools like create_zed_depth_bus or create_azure_kinect_body_bus by naming the device and modes.

  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 does not mention which sibling tools are preferable for other camera types or data sources, nor does it describe prerequisite hardware/software (e.g., RealSense SDK or NDI). The intended usage is only implied by the 'RealSense' keyword.

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

• create_window_output_matrixB
  3.2/5.0
  Behavior3/5

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

  The annotations (readOnlyHint=false, openWorldHint=true) already indicate a non-read-only, world-modifying operation. The description adds that the scaffold includes window maps, source maps, status, and setup notes, but it does not explain side effects like where it creates the scaffold or whether it modifies existing network parts. This is modest added context, not rich disclosure.

  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 concise and structured well, but the extreme brevity sacrifices detail that could make it more helpful, so it doesn't earn a 5.

  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 7 parameters and no output schema, the description is incomplete. It does not explain the purpose of window maps/source maps, the meaning of setup notes, or how the parameters affect the resulting scaffold. Significant context is missing for an agent to reliably use 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%, leaving five parameters undocumented in the schema. The description does not explain parameters like window_count, resolution_width, resolution_height, active, or perform_mode, nor how they influence the scaffold. It lists output components but fails to close the schema 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 clearly states the action ('Create') and the specific resource ('Window COMP output matrix scaffold'), and it lists the key components of the scaffold ('window maps, source maps, status, setup notes'). This distinguishes it from other create_* tools like create_multi_output or create_ndi_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 such as setup_output or create_multi_output. No prerequisites, exclusions, or decision factors are provided, leaving the agent to guess 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_a1111_webui_bridgeB
  3.3/5.0
  Behavior3/5

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

  The description adds useful context by calling it a 'scaffold' rather than an actual live connection, implying it builds a structure instead of connecting to a server. However, annotations already convey create/non-read-only/non-destructive intent, and the description does not reveal side effects, file output, or network 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.

  Conciseness5/5

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

  A single sentence that is front-loaded with the verb 'Create' and packs all key features without fluff. It is efficient and well-structured, 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?

  With 8 parameters and no output schema, the description needs to set expectations for the scaffold's structure and how parameters affect it. It only lists high-level feature names and omits return values, parameter-specific behavior, or post-creation expectations, making it incomplete for moderate 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 38%, and the description partially maps to just two parameters (prompt_slot_count via 'prompt slots', include_controlnet via 'ControlNet hints'). It does not explain server_url, endpoint_kind, output_folder, active, or parent_path semantics, leaving significant gaps for 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 clearly states the tool creates an AUTOMATIC1111/Forge Stable Diffusion WebUI handoff scaffold with specific components (prompt slots, result maps, ControlNet hints, adapter notes), distinguishing it from sibling bridge tools like connect_comfyui for other image-generation backends.

  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 vs alternatives. The description only states what the tool creates; it does not compare to other bridge tools or specify prerequisites, exclusions, or preferred scenarios.

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

• connect_ableton_link_sessionB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate it's a mutating, open-world tool. The description adds that it 'creates' a scaffold, but doesn't disclose side effects like whether it modifies existing sessions, network connectivity needs, or what happens to a pre-existing link session. Given annotations cover the safety profile, a baseline 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?

  Single concise sentence, front-loaded with the action verb, 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?

  For a tool with 7 parameters, no output schema, and low schema coverage, the description is too brief. It doesn't explain the return value, prerequisites, how the scaffold integrates into an Ableton Link setup, or what 'connect' implies vs 'create'. The description leaves significant 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 coverage is only 29% (2/7 params described). The description vaguely mentions 'beat/bar maps' which relates to signature/export_bars but doesn't explicitly explain any of the 7 parameters. With such low schema coverage, the description was expected to compensate but doesn't.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Ableton Link timing scaffold') with a clear scope ('beat/bar maps for tempo-locked visual systems'). It clearly distinguishes itself from generic create tools by specifying the timing 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?

  No guidance on when to use this tool versus alternatives like create_tempo_sync or sync_external_clock. It lacks explicit contextual triggers, 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_airtable_content_busB
  3.3/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 'Create' action in the description. The description adds a few behavioral details by listing specific scaffold components, including 'token/rate-limit safety notes,' but it does not disclose side effects, auth requirements, or whether existing structures could be overwritten. Some value is added beyond annotations, but not deeply.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 lists all major scaffold components without redundancy. It is concise and every phrase 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?

  For a tool with 11 parameters, no output schema, and minimal schema descriptions, the one-line description is insufficient. It does not explain return values, parameter semantics, enum choices, or when to use the tool, leaving an agent with only vague hints about the scaffold contents.

  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 does not compensate by explaining key parameters such as base_id, table_name, sync_direction, adapter_mode, or record_count. Terms like 'record maps' and 'sync policy' hint at parameter purposes, but not enough for an agent to select or configure all 11 parameters 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 uses a specific verb ('Create') and identifies a clear resource ('Airtable content scaffold') while detailing exactly what the scaffold contains: record maps, field maps, sync policy, adapter source, and token/rate-limit safety notes. This distinguishes it from sibling tools like connect_google_sheets_cue_table or connect_ableton_link_session by focusing on Airtable content-bus scaffolding.

  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 implies the tool is for creating an Airtable content bus scaffold, but it does not state when to choose this over alternatives, nor does it provide exclusions or prerequisites. There is no explicit 'when to use' or mention of related tools such as connect_notion_show_rundown or connect_google_sheets_cue_table.

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

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

  With annotations already indicating readOnlyHint=false and destructiveHint=false, the description adds some behavioral context by listing what the scaffold creates (sanitized beacon rows, zone maps, etc.). However, it does not disclose side effects, required permissions, or integration behavior beyond the creation act. 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 that front-loads the action and lists key components. It is concise and avoids fluff, though the long list of components makes it slightly dense. It earns its place but could benefit from a short preface or examples.

  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 no usage guidance, the description is insufficiently complete. It does not explain how the scaffold integrates with the project, what 'sanitized beacon rows' means, whether existing nodes are modified, or what the expected outcome is beyond a vague scaffold. An agent would likely need to inspect parameter descriptions or ask for more 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 only 20% (name and parent_path), so the description must compensate. It mentions concepts like 'smoothing policy' and 'adapter source' that loosely map to parameters (smoothing_window_sec, adapter_url/adapter_mode), but it does not systematically explain each parameter's purpose or relationships. Partial compensation, but gaps remain for many of the 10 parameters.

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

  Purpose5/5

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

  The description states a specific verb+resource: 'Create a BLE beacon proximity scaffold' and lists concrete components (sanitized beacon rows, zone maps, smoothing policy, adapter source, device-privacy notes). This clearly distinguishes it from sibling tools like connect_serial_device_bus or create_geojson_feature_bus. The minor mismatch between 'connect' in the title and 'Create' in the description does not obscure 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 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 does not mention any conditions, prerequisites, or that other tools (e.g., connect_websocket_control_bus) might be more appropriate for different bus types. The description simply states what it does without contextualizing the decision.

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

• connect_casparcg_serverB
  3.3/5.0
  Behavior3/5

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

  Annotations indicate non-read-only, open-world, non-destructive behavior, and the description aligns by saying 'Create a scaffold.' It adds some context about the scaffold's contents, but does not disclose whether a live server connection is established or if it only creates local templates.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 with no redundant wording. It is front-loaded with the main purpose and immediately specifies key deliverables.

  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?

  There is no output schema, and the description does not explain what the tool returns or how the parameters influence the scaffold. With 8 optional parameters and no return value info, the description is incomplete for an agent to reliably invoke and use 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 25% (2 out of 8 parameters), and the description does not compensate by explaining parameters like amcp_port, caspar_host, layer_count, or channel_count. It only vaguely references channel/layer templates without connecting to specific 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 clearly states the tool creates a CasparCG AMCP/playout scaffold with specific components (channel/layer command templates, media manifest notes). This is a specific verb+resource that distinguishes it from other '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 is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only states what the tool does, leaving the 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_disguise_stageB
  3.3/5.0
  Behavior3/5

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

  Annotations already indicate mutation (readOnlyHint=false) and open-world creation (openWorldHint=true). The description adds context by specifying the scaffold includes timeline, layer, and approval maps, and uses HTTP/OSC. However, it does not disclose side effects such as establishing network connections or whether existing components are modified, leaving some behavioral ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 primary verb and resource, and contains no filler or redundant information. It is appropriately concise, though this brevity sacrifices detail that is penalized 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?

  For a tool with 8 parameters, no output schema, and sparse parameter descriptions, the description is under-specified. It does not explain the operator structure created, how API/OSC hosts are used, or what a successful scaffold looks like. The description is too thin for 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?

  With only 25% schema description coverage (only name and parent_path have descriptions), the description must compensate. It vaguely references 'timeline, layer' maps, relating to layer_count and timeline_count, but does not explain api_host, api_port, osc_port, or active. This leaves most parameters 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 clearly states a specific action ('Create'), identifies the exact resource ('disguise/d3 HTTP and OSC show-control scaffold'), and lists key components (timeline, layer, approval maps). This distinguishes it from more generic sibling tools like 'scaffold_show' or 'connect_oscquery_namespace' by naming the external system and protocols.

  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 prerequisites (e.g., requiring a disguise/d3 system), typical use cases, or situations where another tool would be more appropriate. This is a clear gap.

  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.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, so the description need not restate that. It adds some behavioral context by mentioning the scaffold includes 'sanitized' events and 'lock-control safety notes', implying data cleaning and safety considerations. However, it does not disclose side effects beyond 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?

  A single concise sentence that conveys the core purpose and components. Every phrase adds value; there is no 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?

  Despite having 9 parameters, no output schema, and very low schema description coverage, the description gives only a high-level overview. It does not explain what the scaffold looks like, how parameters affect behavior, or what 'sanitized' means in practice, making it incomplete 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 22% (name and parent_path). The description does not explicitly name any parameters, though terms like 'door events', 'door maps', and 'adapter source' loosely map to event_count, door_count, and adapter_url/adapter_mode. This is insufficient for a tool with 9 parameters, and 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.

  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 and resource: 'Create a door-access monitoring scaffold' with a list of contained elements (sanitized door events, door maps, adapter source, lock-control safety notes). This distinguishes it from sibling tools like connect_serial_device_bus or connect_kafka_event_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 about when to use this tool versus alternatives, no prerequisites, and no explicit exclusions. The description only states what it does, leaving the agent to infer usage 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_google_sheets_cue_tableB
  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. The description adds some behavioral context by mentioning sync policy, column validation, and OAuth/writeback safety notes, but it does not detail side effects or what 'scaffold' entails operationally.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 enumerates key features without redundant 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?

  With 10 parameters, no output schema, and non-trivial open-world side effects, the description is too brief. It omits what a 'scaffold' means, whether a network COMP is created, authentication requirements, and the actual return/result 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%, so the description must compensate, but it only mentions generic concepts like 'source adapter' and 'sync policy' without explaining specific parameters such as adapter_mode, sync_direction, or column_count. It adds little beyond the schema's existing sparse 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 a specific action ('Create a Google Sheets cue-table scaffold') with a distinct resource and scope, listing concrete components (source adapter, cue rows, column validation, sync policy, OAuth/writeback safety notes). This differentiates it from siblings like connect_webrtc_browser_input or create_cue_sequencer.

  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 implies a use case (building a Google Sheets cue table) but provides no explicit guidance on when to choose this tool over alternatives. It does not mention excluded scenarios, prerequisites, or sibling comparison.

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

• connect_gps_fleet_trackerB
  3.3/5.0
  Behavior3/5

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

  The description adds context about the scaffold contents (e.g., sanitized asset rows, geofence maps, privacy policy) beyond the annotations' readOnlyHint=false and openWorldHint=true. However, it does not elaborate on external side effects, configuration steps, or integration behavior, which the openWorldHint implies. The description is not contradictory but 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, dense sentence that front-loads the core action ('Create a GPS/fleet tracking scaffold') and efficiently lists deliverables in a comma-separated sequence. No filler or redundant information is present.

  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 required fields, and no output schema, this one-sentence description is inadequate. It does not address what the scaffold returns, how it integrates into the parent_path, or how the various parameter values affect the scaffold, making it incomplete 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%, yet the description does not map its listed components to the 10 parameters. It fails to explain key parameters like provider, adapter_mode, geofence_count, update_rate_hz, and tracked_asset_count. The description should compensate for the sparse schema 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 the tool creates a GPS/fleet tracking scaffold with enumerated components (sanitized asset rows, geofence maps, privacy policy, adapter source, and credential/privacy notes). This specificity distinguishes it from sibling connectivity tools that focus on integrating external systems rather than generating scaffolds.

  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 like connect_geojson_feature_bus or create_data_source. It does not mention prerequisites, alternative approaches, or exclusion criteria, leaving the agent to infer usage solely 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_homeassistant_state_busB
  3.3/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the description need not restate these. It does add that it creates a scaffold with network adapter nodes and safety notes, but it omits side effects such as whether it attempts to connect to the Home Assistant instance, modifies the existing project, or how reversible it is.

  Agents need to know what a tool does to the world before 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 17-word sentence that front-loads the action and product. Every phrase earns its place, listing the key scaffold components without filler 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 9 optional parameters and no output schema, the description should explain what the resulting scaffold looks like, how to use it, and how parameters shape the output. It names components but leaves the agent without enough context to validate the result or understand integration 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 coverage is only 22% (2 of 9 parameters described). The description hints at adapter_mode and entity/service mapping, but it does not clarify parameters like active, area_count, base_url, or parent_path. With such low schema coverage, the description should compensate more, but it only partially 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 uses a specific verb and resource: 'Create a Home Assistant state/service scaffold' and enumerates concrete components (REST/WebSocket adapter nodes, entity maps, service maps, physical-action safety notes). This clearly distinguishes it from generic WebSocket/MQTT bridge 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 is provided on when to use this tool versus alternatives like connect_mqtt_iot_bus or connect_websocket_control_bus. The description does not mention prerequisites (e.g., Home Assistant base URL or credentials) or exclusions, so the agent has to infer usage from the name/title alone.

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

• connect_kafka_event_busB
  3.3/5.0
  Behavior2/5

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

  Annotations include readOnlyHint:false and openWorldHint:true, so the description's 'Create' aligns with a write operation, but it adds little beyond that. It does not disclose side effects, what 'scaffold' entails, whether an existing COMP is modified, or what 'policy-gated producer notes' means.

  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 that efficiently states the action and key features. However, the phrase 'policy-gated producer notes' and the jargon-heavy list reduce clarity, preventing a perfect 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?

  For a tool with 10 parameters and no output schema, the description leaves many gaps: it does not explain what the scaffold actually creates, how parameters map to the listed components, or the significance of each feature. The schema covers only half the parameters, and the description does not compensate for the rest.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 50%, the description indirectly refers to some parameters (adapter ingest hints at adapter_mode, topic maps at topic_root/topic_count, schema hints at schema_format, consumer group metadata at consumer_group) but does not explicitly map them. The remaining parameters like active, broker, server_url, and parent_path are left to the schema, which partially covers them.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 Kafka/Redpanda event-bus scaffold and lists its key components (adapter ingest, topic maps, schema hints, consumer group metadata, policy-gated producer notes). This specific verb+resource combination distinguishes it from sibling bus-connection tools like connect_mqtt_iot_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 only implies usage via the tool name and the mention of Kafka/Redpanda, but it does not explicitly state when to use this tool versus alternatives such as connect_redis_pubsub_bus or connect_websocket_control_bus. No prerequisites or exclusions are provided, making the guidance minimal.

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

• connect_matrix_room_busB
  3.3/5.0
  Behavior3/5

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

  Annotations (readOnlyHint=false, destructiveHint=false) align with the 'Create' action, and the description adds useful detail about what the scaffold includes (e.g., token/encryption safety notes). However, it does not disclose side effects, required permissions, or network interactions beyond the basic create action. The annotations reduce the burden, so a baseline 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 a single sentence, front-loaded with the primary verb and resource, and lists the key components without rambling. Every word contributes to 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, no required fields, and no output schema, the description is too brief. It does not explain the purpose of the 'bus', the meaning of adapter modes, the expected return value, or the context in which a Matrix room scaffold is needed. The annotation openWorldHint=true implies flexibility, but the description leaves too much to inference.

  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), and the tool description adds no parameter information. It does not compensate for the low coverage, leaving many parameters (reaction_count, adapter_mode, approval_required, etc.) without semantic explanation beyond their names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 a Matrix room scaffold' and enumerates specific components included (sanitized room events, reaction maps, approval policy, adapter source, token/encryption safety notes). This verb-resource pairing is specific and distinguishes it from many sibling 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 is provided on when to use this tool versus alternatives. The description is purely declarative and does not mention exclusions, prerequisites, or alternative tool recommendations.

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

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, meaning it's a write operation but not destructive. The description adds no disclosure about side effects, whether it modifies an existing network, requires Notion credentials, or affects external services. It merely states the creation of a scaffold without describing behavioral traits 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 a single, focused sentence that front-loads the primary action and resource and then lists key components. Every word contributes meaning; there is no fluff or repetition of schema defaults.

  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 10 parameters, no output schema, and sparse annotations. The description lists high-level components but omits crucial context: what the scaffold actually contains structurally, prerequisites (e.g., Notion access), how parameters relate to the scaffold, and expected result. This is insufficient for an agent to fully understand the tool's operation and effects.

  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 described). The description mentions concepts like scene maps, property maps, and approval policy, which loosely map to scene_count, property_count, and approval_required, but it does not explain parameters such as database_id, adapter_mode, rundown_label, or adapter_url. The description only minimally compensates for the schema gaps and provides no detailed 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's function: 'Create a Notion show-rundown scaffold' and lists specific included components (scene maps, property maps, approval policy, adapter source, token-safety notes). This is a specific verb+resource (Create + scaffold) and the Notion qualifier distinguishes it from the many generic create_ and scaffold_ 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 usage scenario is implied by the name and description: use when you want to scaffold a Notion-based show rundown. However, no explicit guidance on when not to use it or which sibling alternative to prefer (e.g., scaffold_show) is provided. The context is not fully explicit but is inferable.

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

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

  The description adds that it creates namespace, scaffold, and action maps, which gives some context beyond the annotations (readOnly=false, destructive=false). However, it does not disclose side effects like whether it starts HTTP services, generates COMPs, or modifies existing nodes. It is not contradictory, but it is only minimally transparent 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, front-loaded sentence that conveys the core purpose without wasted words. It is appropriately sized for the tool type, though it sacrifices detail 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?

  For a tool with 9 parameters, no output schema, and minimal annotations, this description is incomplete. It does not explain what the scaffold includes, how the OSCQuery namespace is used, or what 'action maps' mean. It lacks the needed context for an agent to select and invoke it correctly among many connection 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?

  With only 44% schema description coverage, the description's single sentence provides no additional parameter explanations. Parameter names are self-explanatory to limited extent, but the description does not clarify relationships (e.g., how action_count relates to action maps, or how ports are wired). It fails to compensate for the schema's 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 action ('Create an OSCQuery HTTP namespace and OSC send/receive scaffold with action maps') with a defined resource and purpose ('for live-control apps'). It distinguishes itself from sibling tools like connect_ableton_link_session or create_midi_map by naming the OSCQuery HTTP namespace and OSC 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?

  The description gives no explicit guidance on when to use this tool versus alternatives. It only implies it is for live-control apps, but does not mention prerequisites, exclusions, or preferred sibling tools. There is no 'when not to use' or alternative recommendation.

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

• connect_slack_ops_bridgeB
  3.3/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 mutation/non-destructive safety profile is known. The description adds context about what the scaffold contains (adapter, alert rows, approval-gated commands, safety notes) but doesn't disclose any side effects, permissions, or reversibility beyond the annotations. This is acceptable but adds only moderate 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?

  The description is a single, dense sentence with no wasted words. It front-loads the main purpose ('Create a Slack operator-alert scaffold') and then lists the included components. Every phrase adds value, and it is 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.

  Completeness2/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 mutation annotations, the description is incomplete. It does not describe the return value, side effects, how the scaffold integrates with the project, or the significance of key parameters like channel_name or adapter_mode. While the scaffold composition is mentioned, essential operational context for an agent to invoke the tool correctly 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 very low (18%: only 'name' and 'parent_path' have descriptions). The description mentions 'webhook/socket adapter', 'alert rows', 'approval-gated command rows', and 'token/signing safety notes' which loosely map to parameters like adapter_mode/socket_url, alert_count, approval_required/command_count, but it does not explain the meaning of most parameters (active, channel_name, workspace_label, etc.) or their expected values. The description does not compensate adequately for the lack of 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 will 'Create a Slack operator-alert scaffold' with specific components (webhook/socket adapter, alert rows, approval-gated command rows, token/signing safety notes). The verb 'Create' plus the resource 'Slack operator-alert scaffold' is specific and distinguishes this from sibling connect_* tools like connect_qlab_cue_stack or connect_webrtc_browser_input by focusing on Slack and alert scaffolding.

  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 usage guidance is provided. The description does not indicate when to use this tool vs. alternatives (e.g., other connect_* bridges), nor does it mention prerequisites or exclusions. There is no 'use this when...' or 'for other integrations, see...' phrasing.

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

• connect_vdmx_workspaceB
  3.3/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, which covers the safety profile. The description adds a bit of context by mentioning OSC/Syphon and scaffold maps, but it does not detail side effects, required permissions, or the nature of the created workspace.

  Agents need to know what a tool does to the world before 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 with no filler. It efficiently conveys the core function and key artifacts, making it easy to parse at a glance.

  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 low schema coverage, the description is too sparse. It does not clarify return values, the meaning of 'maps,' or how the parameters affect the scaffold, leaving significant gaps for the 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 22% (2 of 9 parameters have descriptions), so the description must compensate. It mentions 'layer, clip, preview, and setup maps' which loosely relates to layer_count, clip_count, and preview_mode, but it does not clarify ports, host, 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 clearly states the action ('Create') and the resource ('VDMX OSC/Syphon workspace scaffold'), including specific components like layer, clip, preview, and setup maps. This distinguishes it from sibling tools about other platforms or workflow 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 guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison with similar tools such as connect_resolume_arena or scaffold_vj_deck.

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

• connect_vmix_productionB
  3.3/5.0
  Behavior3/5

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

  Annotations indicate a write operation (readOnlyHint=false) with no destructive intent. The description adds context about the scaffold type and command templates but does not disclose side effects, external interactions, or whether vMix must be running.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 action verb and resource. It contains no filler or redundant content.

  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 is under-specified for an 8-parameter integration tool. It lacks prerequisites (e.g., vMix running), output format, and details on how the scaffold is added to the project, leaving the agent to infer from parameter 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?

  With only 25% schema description coverage, the description provides no explicit parameter explanations. It vaguely references features like input switching, overlays, and recording, which hint at input_count, overlay_count, and include_record_stream, but does not clarify ambiguous parameters such as active or api_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 tool creates a vMix HTTP/API production-control scaffold, specifying the resource and functional purpose (input switching, overlays, recording, streaming command templates). This distinguishes it from sibling integration tools like connect_obs_recorder or connect_resolume_arena.

  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 given on when to use this tool versus alternatives. The intended use is only implied by the vMix name and the description, with no stated prerequisites, exclusions, or selection criteria.

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

• create_artnet_discovery_panelB
  3.3/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, but the description does not elaborate on what changes it makes, whether it creates new COMPs or modifies existing ones, or any external side effects. It adds minimal behavioral detail beyond the annotation 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 a single sentence that efficiently conveys the core purpose without redundancy. It is front-loaded with the main action and resource, followed by optional features.

  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, this description is too brief. It lacks parameter semantics, usage context, and behavioral details, making it insufficient for correct invocation, though sufficient for selection.

  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 should explain key parameters, but it only vaguely references 'optional DMX In monitor, device maps, and universe maps' without linking to specific parameters like include_dmx_monitor, device_count, or universe_count. It does not clarify net/subnet ranges or parent_path.

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

  Purpose5/5

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

  The description clearly identifies the tool's function: creating an Art-Net DAT discovery scaffold, with specific optional components (DMX In monitor, device maps, universe maps). This differentiates it from sibling creation tools like create_control_panel or create_dmx_fixture_pipeline.

  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 choose this tool over alternatives, nor any prerequisites or context. It merely states what it does, leaving the decision to the agent without explicit when-to-use or when-not-to-use signals.

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

• create_ltc_timecode_bridgeB
  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 it's a non-destructive write. The description adds scaffold composition details but does not disclose side effects like creating nodes at parent_path, potential overwrites, or environment requirements.

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

  Conciseness5/5

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

  The description is a single, direct sentence that front-loads the primary action and lists concrete scaffold components. Every phrase adds value with no unnecessary 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?

  Despite having 8 parameters and no output schema, the description omits how parameters affect the scaffold, what the tool returns, and the resulting network structure. It reads as a high-level overview rather than a complete specification 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?

  Only 2 of 8 parameters have schema descriptions (25% coverage). The description does not compensate, offering no explanation of mode, cue_count, frame_rate, or device parameters. Agents must rely on names and enums, which is insufficient for a tool with this many 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 an LTC receive/generate scaffold with specific components (LTC In/Out CHOP placeholders, cue maps, routing notes). It distinguishes itself from siblings like sync_timecode by emphasizing it is a scaffold rather than a working bridge.

  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 such as sync_timecode or add_timecode_overlay. No prerequisites, use-case context, or exclusions are provided, leaving the agent to infer when a scaffold is appropriate.

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

• create_openxr_controller_bridgeB
  3.3/5.0
  Behavior2/5

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

  Descriptions adds little beyond the annotations. While readOnlyHint=false and openWorldHint=true indicate a mutating, externally-interacting tool, the description does not disclose what the scaffold creates, whether it attempts connections, or any side effects on the existing scene. No extra behavioral context is provided.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose. Every word is informative, with 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.

  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, no required fields, and no output schema, the description is insufficient. It does not explain the scaffold's structure, the role of parameters, or any setup/connection behavior expected from an external adapter. The sparse description is not enough to guide use in a complex open-world 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 low (25%), with only name and parent_path having descriptions. The tool description mentions streams like pose and trigger but does not explain parameters such as source_mode, receive_port, controller_count, or coordinate_space. The description fails to compensate for the schema's weak 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: creating an OpenXR/SteamVR controller input scaffold. It names the specific input streams (pose, trigger, grip, thumbstick, button) and the external adapter source, distinguishing it from sibling bridge and setup 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 phrase 'supplied by an external adapter' implies the tool is for integrating external controller data, but there is no explicit guidance on when to use it versus alternatives like other bridge tools or when not to use it. Usage is implied rather than stated.

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

• create_optitrack_tracking_busB
  3.3/5.0
  Behavior3/5

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

  The annotations already indicate this is a creation (readOnlyHint=false) with open-world side effects (openWorldHint=true) and non-destructive (destructiveHint=false). The description adds useful context that it creates a 'scaffold' with specific internal components, implying a starting template rather than a fully configured system. However, it does not disclose details like whether an existing component is required, connection prerequisites, or what happens on repeated 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?

  The description is a single focused sentence of 17 words. It front-loads the action and resource, and avoids any filler or redundant wording. 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?

  With 8 parameters, no output schema, and minimal parameter documentation, the description is insufficient for an agent to fully understand the tool's behavior. It does not explain what the tool returns (e.g., the created scaffold), how parameters map to the receiver/rigid-body/marker setup, or any preconditions. The high-level scaffold concept is clear, but the operational details are 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 25% (only name and parent_path have descriptions). The description does not explicitly explain any of the parameters such as data_port, command_port, marker_count, server_address, or rigid_body_count. While the components (receiver, maps) loosely map to these parameters, the description fails to compensate for the low schema coverage by relating them.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 resource ('OptiTrack/NatNet tracking scaffold'), and differentiates from sibling tracking tools by naming OptiTrack/NatNet and listing the scaffold components (receiver, rigid-body maps, marker maps, calibration notes). This is a specific and distinctive purpose.

  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 does not mention when to choose this over other tracking bus tools (e.g., create_blacktrax_tracking_bus) or any prerequisites such as needing a running NatNet server or an existing parent component.

  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.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, and the description is consistent with them, so there is no contradiction. It adds some context about the deliverable ('channel mapping and setup notes') but does not disclose side effects such as what is written under parent_path or whether a live VCV Rack connection is required.

  Agents need to know what a tool does to the world before 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 with no filler; every phrase adds information (protocols, modulation bridge, scaffold, channel mapping, setup notes). It is appropriately sized for a tool 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?

  With 10 parameters, 20% schema coverage, and no output schema, this one-line description leaves a large configuration surface largely unexplained. It does not state what the scaffold contains, how ports/device settings are used, or what the setup notes will cover.

  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% (just 'name' and 'parent_path' are described), yet the description does not compensate for the other eight parameters. It hints at mode via 'OSC/MIDI/CV' and channel mapping via 'channel_count', but send_port, receive_port, midi_device, bipolar, active, and rack_host remain 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 action ('Create') and a specific resource ('VCV Rack OSC/MIDI/CV modulation bridge scaffold'), naming both the target platform and the protocol modalities. This distinguishes it from sibling bridge/creation tools by specifying VCV Rack and its channel-mapping deliverable.

  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 the many sibling bridge creators (e.g., create_midi_map, qlab_osc_bridge, create_external_io). The description only states what it does, with no context, 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_gtfs_transit_feedB
  3.4/5.0
  Behavior3/5

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

  Annotations already flag readOnly=false and destructiveHint=false, consistent with 'Create'. Description adds that it builds maps and predictions but doesn't disclose side effects like external connections, file/component modifications, or requirements for the adapter URL. It adds modest context 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?

  Single sentence, clear verb, front-loaded. The list of scaffold components is compact but comprehensive enough for an overview. No redundant 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 9 parameters and no output schema, the description is too sparse. It omits how feed_mode affects the scaffold, whether adapter_url must point to a live service, what public-data notes include, and how the scaffold integrates with the parent_path. Ambiguity remains about the scaffold's runtime 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 22%, with 7 of 9 parameters undocumented in schema. The description mentions route maps, stop maps, arrival predictions, and adapter source, which loosely correspond to route_count, stop_count, prediction_count, and adapter_url, but does not explain feed_mode, active, agency_label, or parent_path meanings. Insufficiently compensates for 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?

  Clearly states it creates a GTFS transit scaffold with enumerated deliverables (route maps, stop maps, arrival predictions, adapter source, public-data notes). Differentiates from generic create_* siblings by naming specific transit domain and scaffold 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?

  No explicit when-to-use or alternatives. The description implies usage for generating a GTFS feed scaffold, but does not specify when to choose this over other connect_* tools or any prerequisites.

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

• connect_houdini_engine_bridgeB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so no contradiction. The description adds that it creates a scaffold with listed components, which is some behavioral context, but it doesn't explain side effects, network modifications, or what 'handoff scaffold' means operationally. With annotations covering the core mutation trait, 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.

  Conciseness4/5

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

  The description is a single, efficient sentence that front-loads the main purpose. It lists four components in a compact list, which is readable but somewhat packed. No wasted words, but slightly dense for easy parsing.

  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 only 20% parameter documentation, this description is under-specified. It tells the agent what scaffold to create but not how the bridge operates, what the parameters control, or how it integrates with the existing network. The description lacks the depth needed 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 params). The description mentions concepts like HDA, cache, parameter maps, and cook-status, which loosely relate to parameters but does not map or explain any specific parameters. It fails to compensate for the low schema coverage, so it falls below 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 ('Create') and identifies a clear resource ('Houdini Engine/HDA/cache handoff scaffold') with concrete components (manifests, parameter maps, cook-status ingest, geometry cache notes). This clearly distinguishes it from sibling tools like create_engine_comp or connect_unreal_livelink_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 a Houdini Engine/HDA/cache handoff is needed, but it does not explicitly state when to use this vs alternatives, nor any exclusions or prerequisites. It relies on the purpose to imply usage, so it earns a baseline 3.

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

• connect_ticketing_checkin_busB
  3.4/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 is open-world, and the description does not contradict these. It adds context about what the scaffold includes (e.g., gate status, PII/token safety notes) but does not disclose side effects like network connections or file writes beyond what annotations imply. The description provides moderate additional value.

  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, but it is dense with jargon and lists many components in a compressed way. It is appropriately sized but could be better structured for readability.

  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 a complex scaffold operation, the description is incomplete. It does not explain what the output or result looks like, what 'adapter source' means, or how parameters like provider, adapter_mode, or expected_capacity affect the scaffold. This is insufficient 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 18%, with only 'name' and 'parent_path' described. The description vaguely mentions 'aggregate gate counts' and 'ticket-tier maps', hinting at gate_count and ticket_tier_count, but does not explicitly map parameters or explain their meanings. 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 purpose: 'Create a ticketing/check-in scaffold' with specific components listed (aggregate gate counts, ticket-tier maps, gate status, adapter source, PII/token safety notes). This is specific and distinguishes it from siblings like connect_oscquery_namespace or connect_mqtt_iot_bus, which are general connectivity 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 when a ticketing/check-in system is needed, but it does not explicitly state when to use it versus alternatives or provide exclusions. No mention of alternative tools like connect_pos_sales_telemetry or connect_people_counting_bus is made, leaving usage guidance implicit.

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

• create_hokuyo_lidar_busB
  3.4/5.0
  Behavior3/5

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

  Annotations already mark the tool as readOnly=false and destructiveHint=false, so the description adds some contextual traits like 'hardware-gated' and 'CHOP setup' without contradicting annotations. However, it doesn't disclose side effects (e.g., creating components, requiring network or serial connection) or prerequisites, so it only partially fulfills the transparency burden.

  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 purpose and names three key deliverables. It has no filler, but lacks structural breakdown and could be slightly more detailed without becoming verbose.

  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 schema descriptions, the description is too brief to be complete. It fails to explain the significance of interface_mode, net_address, serial_port, start_step, end_step, active, or high_sensitivity, leaving the agent without sufficient context to invoke the tool safely or 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 does not compensate by explaining any of the 10 parameters. It vaguely references 'scan-zone maps' which could relate to scan_zones, but offers no explicit mapping. With such low coverage, the description should clarify parameters but instead 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 a specific verb and resource: 'Create a Hokuyo LiDAR scanner scaffold' with identifiable components (CHOP setup, scan-zone maps, calibration notes). It is distinguished from sibling tools like create_ouster_lidar_bus or create_livox_lidar_bus by explicitly naming Hokuyo.

  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 Hokuyo LiDAR scanners, but does not explicitly state when to use it or when not to use it compared to similar LiDAR bus creation tools. There are no mentions of alternatives or exclusions, but the name and title make the primary use case somewhat obvious.

  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.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 nor destructive. The description adds detail about what will be created (monitor maps, GPU maps, preflight checks, setup notes), which is useful context beyond the annotations. However, it does not disclose side effects like potential overwrites or failure behavior if the baseCOMP name already 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?

  A single, concise sentence that immediately states the action and key deliverables. No filler or redundant phrasing—it is front-loaded and efficient.

  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 plus schema covers the basic purpose and two parameters, but important gaps remain: no output schema, no explanation of the boolean parameter, and no mention of return values or whether the scaffold is created at the specified parent path. While the listed components give a sense of the result, details are sparse for a multi-parameter 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 40%; only 'name' and 'parent_path' have descriptions. The tool description fails to explain the meaning of 'gpu_count', 'monitor_count', or 'include_direct_display_hint', leaving these parameters inadequately described for an agent to use 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 creates a 'Monitors DAT inventory scaffold' with specific contents (monitor maps, GPU maps, preflight checks, setup notes). This distinguishes it from other creation tools in the sibling list by identifying the exact resource type and 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 Guidelines2/5

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

  The description implies usage (when you need to scaffold a monitor layout), but provides no explicit when-to-use guidance or alternatives. It does not mention exclusions or scenarios where a different tool 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.

• 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 not read-only, not destructive, and open-world. The description adds that it creates a scaffold with specific maps, which is helpful but doesn't disclose side effects, dependencies, or prerequisites 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?

  The description is a single, front-loaded sentence that states the core action and key components with no filler. Every word contributes to understanding 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 a 7-parameter tool with no output schema and low schema coverage, this description is under-specified. It omits how the scaffold behaves, prerequisites (e.g., iPhone app, OSC setup), and what happens after creation, leaving the agent with insufficient context to use the tool effectively.

  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 should compensate but doesn't mention any parameters. It only vaguely references 'blendshape and head-transform maps' without explaining how parameters like face_count or include_head_transform relate. The schema provides defaults but the description adds no 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 uses a specific verb 'Create' and a specific resource 'ARKit Face Capture OSC scaffold' with details about blendshape and head-transform maps. It clearly distinguishes this from sibling tools by targeting a niche ARKit/OSC workflow.

  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 usage context, but there is no explicit guidance on when to use this versus alternatives like setup_face_tracking or other connect_* tools. No 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_blackmagic_atemA
  3.5/5.0
  Behavior4/5

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

  The description adds valuable behavioral context beyond the annotations by clarifying that this creates a scaffold with UDP transport placeholders and operator approval notes—not a live functional connection. This nuance is not captured by readOnlyHint=false or openWorldHint=true, though it stops short of detailing side effects like created COMP placement or overwrite 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, front-loaded sentence with no filler or redundancy. It efficiently conveys the core purpose and key deliverables.

  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, this one-sentence description is not enough to be fully actionable. It omits explanation of the individual parameters, defaults, side effects, or what the resulting scaffold actually looks like (e.g., how 'operator approval notes' are structured). The scaffold concept is underspecified.

  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 33% schema description coverage, the description needs to compensate for the 9 parameters, but it only mentions high-level concepts like 'input maps' and 'macro maps' without referencing parameters such as atem_host, send_port, input_count, macro_count, or include_cut_auto. It does not meaningfully clarify parameter meanings beyond what the schema already provides for the three described 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 a specific resource ('Blackmagic ATEM command-map scaffold') with concrete contents (UDP transport placeholders, input maps, macro maps, operator approval notes). This clearly distinguishes it from sibling tools like atem_switcher_control, which is for actual control rather than scaffolding.

  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 given on when to use this tool versus alternatives. While the sibling atem_switcher_control implies a distinction between scaffold creation and actual control, the description never states this exclusion or provides any usage context.

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

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

  The description adds context about safety gating and OSC-only (not direct DMX), but it does not explain what 'safety-gated' means, what side effects the scaffold creation has, or any prerequisites. Annotations (readOnly=false, openWorld=true, destructive=false) are not contradicted, but the description provides only modest additional behavioral disclosure.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no redundant or filler words. It efficiently states the tool's function, scope, and key differentiator.

  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 and no output schema, a one-sentence description is insufficient. It omits what the scaffold concretely produces, how parameters interact, prerequisites for use, and what the final result looks like, 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.

  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), and the tool description itself provides no parameter-specific explanation. Terms like 'safety_mode', 'executor_count', and 'cue_count' are left to inference, so 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 uses a specific verb ('Create') and a precise resource ('safety-gated OSC command scaffold' for lighting consoles), listing supported brands (grandMA3, ETC Eos, ChamSys, Avolites, generic) and explicitly stating it does not send direct DMX. This clearly distinguishes it from sibling tools like create_dmx_fixture_pipeline.

  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 an OSC-based scaffold for lighting consoles is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it give exclusions beyond the DMX note. No alternative tools are mentioned, 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.

• connect_map_tile_overlayA
  3.5/5.0
  Behavior4/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 useful behavioral context by specifying what the scaffold includes (tile layer maps, viewport metadata, attribution rows, adapter source, token/cache safety notes). This goes beyond the annotations and clarifies the tool's creation behavior without contradicting the 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 sentence that front-loads the primary action and resource, then lists key components efficiently. There is no unnecessary repetition or fluff.

  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 low schema coverage, this complex creation tool requires a more complete description. The one-sentence description does not address parameter usage, expected outputs, or how the scaffold integrates into a project. It leaves significant ambiguity for the 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 18% (only name and parent_path have descriptions). The description does not explain any of the 11 parameters, nor does it relate the listed scaffold components to specific parameters. It adds no meaning beyond the schema, failing to compensate for the low 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 clearly identifies the resource as a 'map-tile overlay scaffold' with enumerated components (tile layer maps, viewport metadata, attribution rows, adapter source, token/cache safety notes). This clearly distinguishes it from sibling tools like create_raytk_op or connect_webrtc_browser_input.

  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 exclusions, prerequisites, or preferred scenarios. The only implied usage is that it creates a map-tile overlay scaffold, which is not enough to inform selection among many similar creation 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.5/5.0
  Behavior3/5

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

  Annotations indicate this is a write operation (readOnlyHint false) and modifies the world (openWorldHint true). The description's 'Create' is consistent with this. It adds context about the scaffold's purpose but does not disclose any side effects like whether it actually connects to a broker or just creates 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?

  The description is a single sentence with no filler. It is front-loaded with the action, 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?

  For a tool with 9 parameters and no output schema, a one-sentence description is insufficient. It lacks details on prerequisites, behavior, and any return values, making it hard for an agent to know what to expect.

  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 44%, and the description itself does not mention any parameter specifics. It does not explain the meaning of qos, active, client_id, broker_port, or topic_count, leaving gaps for 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 clearly states a specific action ('Create an MQTT Client DAT bus scaffold') and specifies the purpose (IoT sensors, installation telemetry, policy-gated operator commands). This distinguishes it from other connection tools like WebSocket or serial 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 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 MQTT-based IoT connectivity, but it does not explicitly state when to use it over alternatives such as other bus/connection tools. No exclusions or comparisons are provided.

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

• connect_prometheus_metrics_panelA
  3.5/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 that this is a 'scaffold' (not a live connection) and lists included components, which provides some behavioral context. Yet it does not disclose side effects like file creation, network modifications, or external integrations, leaving gaps beyond what annotations 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 a single, information-dense sentence with a clear active verb. Every phrase adds value (scaffold, adapter notes, metric maps, alert routes, safety guidance) without 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 9 parameters, no output schema, and low schema coverage, the description provides only a high-level overview. It lacks specifics on how parameters interact, what the scaffold looks like, and what 'active' or 'job_name' control. The tool is complex enough that this minimal description leaves 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 22%, with just 'name' and 'parent_path' documented. The description mentions high-level concepts like 'metric maps' and 'alert routes' but does not map them to parameters (metric_count, alert_count, adapter_mode, endpoint_url, etc.). 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 creates a Prometheus metrics scaffold, listing specific components (PromQL/client adapter notes, metric maps, alert routes, safety guidance). This specific verb and resource distinguish it from sibling tools like 'connect_webrtc_browser_input' and 'connect_grafana_annotation_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?

  Usage context is implied by the name and description – you would use this to set up a Prometheus metrics scaffold. However, there is no explicit guidance on when to choose this tool over alternatives, no exclusions, and no mention of prerequisites or typical scenarios.

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

• connect_redis_pubsub_busA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate read-write (readOnlyHint=false) and non-destructive (destructiveHint=false) behavior. The description adds useful context such as 'read-first operations policy' and 'keyspace safety notes', suggesting the scaffold enforces safe patterns. However, it does not disclose side effects, re-run behavior, or prerequisites, leaving the agent with only partial 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?

  A single, well-structured sentence that front-loads the core action and resource, then efficiently lists key features. There is no filler or redundancy; 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 12 parameters and no output schema, this description is too sparse. It does not explain the tool's return value, prerequisites (e.g., Redis server), or integration with TouchDesigner. The one-sentence description leaves critical gaps for an agent to effectively use the tool in 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 low (17%: only 2 of 12 parameters have descriptions). The description mentions adapter ingest and channel maps but does not connect these to specific parameters like adapter_mode or channel_root. With low schema coverage, the description should compensate, but it fails to explain parameter meanings, defaults, or relationships, leaving most parameters opaque.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 resource 'Redis Pub/Sub/Streams scaffold', and enriches this with key components (adapter ingest, channel maps, keyspace safety notes, read-first operations policy). This distinguishes it from other bus-related sibling tools (e.g., connect_mqtt_iot_bus, connect_kafka_event_bus) by its Redis-specific 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 the tool is for creating a Redis Pub/Sub/Streams scaffold, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. An agent can infer the primary use case from the name and resource, but there is no direct 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.

• connect_replicate_prediction_bridgeA
  3.5/5.0
  Behavior3/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, so side effects are possible but not destructive. The description adds context by enumerating the scaffold's contents, including 'credential-safety notes' and 'polling/webhook maps', which offer insight into expected behavior. However, it does not explain whether the tool makes external API calls or just creates local project files.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 immediately states the purpose and lists key components. There is no redundant or filler content, and 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.

  Completeness3/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 adequate but not thorough. It communicates the core purpose and main artifacts, but does not describe prerequisites, resulting scaffold structure, expected usage flow, or how the parameters affect the output. For an advanced integration tool, more context would be beneficial.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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%, leaving some parameters undocumented in the schema. The description references high-level concepts like 'polling/webhook maps' and 'output contracts' that loosely map to parameters like poll_seconds, webhook_url, and output_mode, but it does not explicitly explain any parameter. It adds some contextual meaning but does not fully compensate 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 ('Create') and resource ('Replicate-style prediction handoff scaffold') and enumerates concrete deliverables (request templates, polling/webhook maps, output contracts, credential-safety notes). The 'Replicate-style' qualifier clearly distinguishes it from sibling bridge tools like connect_huggingface_inference_bridge or connect_runway_video_bridge.

  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. It does not name any sibling tools, state conditions for use, or mention exclusions. The implied usage is that you would use it when you want a Replicate prediction bridge, but that is not explicit.

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

• connect_runway_video_bridgeA
  3.5/5.0
  Behavior4/5

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

  Annotations (openWorldHint=true, readOnlyHint=false) already indicate side effects and non-read-only behavior. The description adds context that it creates a scaffold with prompt maps, contracts, polling status, and adapter notes, but does not detail external interactions or failure modes. Given annotation coverage, this is acceptable 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?

  One sentence, front-loaded verb and object, no redundancy or 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?

  The description gives a high-level overview but omits parameter semantics, usage context, and expected output details. With 9 parameters and no output schema, the description alone is insufficient for correct invocation without guessing.

  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 only 22% schema description coverage, most parameters have only defaults and no explanation. The description references 'prompt maps' and 'contracts' but does not map to any specific parameter, leaving agents to guess semantics for fields like generation_mode, input_clip_path, etc.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 explicitly states 'Create a Runway-style video generation handoff scaffold' with specific deliverables (prompt maps, input/result contracts, polling status, adapter notes). This clearly distinguishes it from sibling connect_* and create_* tools by the Runway video generation focus.

  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 when-to-use or alternative tools are mentioned. Usage is only implied by the name and description—use when you need a Runway video bridge scaffold—but no explicit guidance or exclusions are provided.

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

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

  Annotations already indicate write, open-world, non-destructive behavior. The description adds context by listing scaffold components and mentions 'credential/signing safety notes', which hints at auth handling. However, it does not clarify whether the tool actually connects to an external S3 service or just creates a local scaffold, leaving a behavioral 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, well-front-loaded sentence with no redundant words. It efficiently conveys the core purpose and key elements, earning its place without any fluff.

  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 only sparse annotations, the description is too short to fully inform an agent. It lacks crucial details such as whether an actual S3 connection is established, how credentials are handled, or what the scaffold's manifest and cache policy entail. The tool is complex enough to require a richer 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?

  Schema description coverage is only 20% (2 of 10 params described). The description does not map its mentioned features (e.g., 'cache policy', 'adapter source') to specific parameters like cache_policy or adapter_mode. It provides minimal semantic help; the burden falls on the schema, which is mostly 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 ('Create') and clearly identifies the resource ('S3-compatible media-bucket scaffold') and key deliverables ('manifest rows, cache policy, ingest status, adapter source, credential/signing safety notes'). This distinguishes it from sibling tools, which are mostly about other connections or scene 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 implies the tool is used when you need to set up an S3-compatible media bucket, but it does not explicitly state when to use it vs alternatives, nor does it mention prerequisites or exclusions. Context is clear but guidance is not explicit.

  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?

  The description discloses that the tool creates a scaffold including TUIO DAT, optional raw OSC, cursor maps, and surface maps, which is useful behavioral context. However, it does not describe side effects such as whether existing nodes at 'parent_path' are modified, whether the operation can be safely repeated, or what the resulting scaffold structure looks like. Annotations (destructiveHint=false, readOnlyHint=false) are not contradicted, but the description adds only partial transparency 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, concise sentence that front-loads the core purpose and lists key components. It contains no redundancy, filler, or tangential detail—every word contributes to understanding the tool's function. Ideal for quick agent parsing.

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

  Completeness3/5

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

  Given the tool has 7 parameters, no output schema, and sparse annotations, the description provides only a high-level overview. It omits details about the listening port, active state, parent path behavior, and what the scaffold actually looks like when created. While the name and schema defaults fill some gaps, an agent would still have moderate uncertainty about invocation specifics and outcomes.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 (29%), so the description must compensate. It partially does: 'optional raw OSC' clarifies the include_raw_osc boolean, and 'cursor maps' / 'surface maps' relate to cursor_count and surface_count. However, other parameters like listen_port and active remain without semantic explanation, and the description does not address all 7 parameters. It adds value but is incomplete.

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

  Purpose5/5

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

  The description identifies a specific action ('Create') and a specific resource: 'a TUIO touch-surface scaffold'. It also enumerates the key components (TUIO DAT, optional raw OSC, cursor maps, surface maps), making it clear what the tool produces and distinguishing it from sibling connection tools like 'connect_touchengine_notch' or 'create_multitouch_panel_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. It does not state prerequisites, typical scenarios, or explicitly mention any exclusions. The name and description imply use for TUIO touch surfaces, but there is no direct comparison to sibling tools or clarification of when this scaffold is preferable to other input or touch setups.

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

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

  Annotations already declare readOnlyHint=false, and the description's 'Create' aligns. It adds that the scaffold includes stream maps and setup notes, but lacks details on side effects, network access, or prerequisites. 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?

  A single sentence that is front-loaded with the verb 'Create' and the resource 'Video Stream In TOP scaffold', with no redundant or extraneous 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 communicates the core purpose and protocol support, but the tool has 6 parameters, no output schema, and no mention of network behavior or node creation side effects. It is adequate but leaves meaningful gaps for a mutation 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 33% (name and parent_path have descriptions). The description indirectly hints at mode via protocols and url via 'ingest', but does not explain active, latency_ms, or url specifics, leaving most 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 it creates a Video Stream In TOP scaffold for RTSP/HLS/SRT/WebRTC ingest, which is specific and actionable. It does not explicitly distinguish from sibling tools like connect_webrtc_browser_input, but the protocol list gives a 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 Guidelines4/5

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

  The description provides clear context that this is for video streaming ingest via RTSP, HLS, SRT, or WebRTC. It does not mention when not to use it or alternative tools, but the protocol scope serves as a practical guideline.

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

• connect_webrtc_browser_inputA
  3.5/5.0
  Behavior3/5

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

  Annotations already convey that the tool is not read-only and is open-world, so the description does not need to repeat that. The description adds that it creates a 'scaffold' and relies on an external signaling app, but it does not disclose potential side effects (e.g., whether it opens a WebRTC connection immediately, requires the signaling server to be reachable, or modifies existing components). This is partial 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 that delivers the core purpose without excessive detail. Every word contributes meaning, making it appropriately 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?

  The tool has 7 parameters, no output schema, and low schema coverage, so the description should provide more context about what the scaffold includes, how parameters interact, and what the user can expect after creation. The single-sentence description does not explain the internal behavior or the composition of the scaffold, 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.

  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 must compensate for the undocumented parameters. It loosely maps to input_mode by listing 'webcam, screen, pointer, and sensor', and to signaling_url via 'external signaling app', but it leaves active, room_id, and include_data_channels unexplained. The description provides some meaning but not enough 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 a specific action ('Create a browser/WebRTC input scaffold') and enumerates the data types (webcam, screen, pointer, sensor) it handles. This distinguishes it from sibling tools like connect_websocket_control_bus or create_control_surface, which serve different input/output purposes.

  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 the user needs to bring browser/WebRTC data (webcam, screen, pointer, sensors) into TouchDesigner, and notes the dependency on an external signaling app. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.

  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 indicate readOnlyHint=false and destructiveHint=false. The description adds that the scaffold includes placeholders, stream maps, and calibration notes, providing some context about what is created. However, it does not disclose prerequisites like device connection or potential side effects, so transparency 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, front-loaded sentence that communicates the tool's purpose and key output components without unnecessary 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 7 parameters and no output schema, the description is too brief. It mentions scaffold components but does not explain the impact of parameters, integration requirements, or how the scaffold is structured in the network. This leaves significant gaps for an agent deciding whether to use the 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 29% (2/7 params described). The tool description does not explain any of the parameters such as body_count, device_index, include_color_top, or include_depth_top, nor does it relate them to the scaffold contents. Thus 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 it creates an Azure Kinect body/depth scaffold with specific contents (TOP/CHOP placeholders, stream maps, calibration notes). This is a specific verb+resource and distinguishes it from other depth-sensor tools like create_realsense_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 provides clear context that this tool is for creating an Azure Kinect body/depth scaffold, which implies when to use it. It does not mention alternatives or exclusions, but the purpose is specific enough to avoid ambiguity for an agent selecting this tool.

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

• create_blender_scene_bridgeA
  3.5/5.0
  Behavior3/5

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

  Annotations already indicate the tool is write-capable (readOnlyHint=false) and open-world (openWorldHint=true). The description adds the concept of a 'scaffold' and metadata workflow types, but does not disclose specifics like what operators are created or whether the network is modified. With annotations providing the safety profile, this adds some but not 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 a single, dense sentence that front-loads the primary action ('Create') and clearly specifies the deliverable and purpose. No filler or redundant content.

  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 creation tool with no output schema and low parameter coverage, the description is under-specified. It does not explain what the scaffold includes, prerequisites, or how the selected parameters affect the result, leaving significant gaps for the agent to infer.

  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%, leaving 8 of 10 parameters undocumented in the schema. The description does not compensate by explaining parameters; it only lists workflow types that loosely map to the 'handoff_mode' enum. Most parameter meanings remain opaque, so the description adds minimal value over 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 function: 'Create a Blender-to-TouchDesigner scene handoff scaffold' with specific workflow types (file-watch, OSC, WebSocket). This distinguishes it from sibling tools like blender_scene_import (which imports models) by emphasizing the handoff scaffold aspect.

  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 by naming the three supported workflow types, implying when the tool would be used. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, leaving usage guidance 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_voice_prompt_pipelineA
  3.5/5.0
  Behavior4/5

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

  Given annotations already declare readOnlyHint=false and destructiveHint=false, the description adds valuable context by emphasizing the dry-run/approval-gated nature and that policy/operator approval remains authoritative, which is beyond the structured fields. However, it doesn't detail other behavioral traits like network modification 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?

  Two sentences, front-loaded with the core purpose, with the second sentence adding an important safety qualifier. No filler or redundant information.

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

  Completeness3/5

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

  The tool has 9 parameters (4 with enums), no output schema, and minimal schema descriptions, so the description bears a heavy burden. It provides a clear high-level purpose and a critical safety guarantee, but lacks details on how the scaffold is created, what the parameters do, or what the result looks like. For a scaffold creation tool, this is adequate but not thorough.

  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 only describes 2 of 9 parameters (22% coverage), and the description mentions no parameters at all. It doesn't clarify the meaning or relationship of stt_mode, llm_target, approval_mode, or other fields, so 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 the verb 'Create' with a specific resource ('dry-run/approval-gated voice-to-prompt TouchDesigner scaffold') and scopes it to 'AI Party-style workflows.' This distinguishes it from common create_* siblings by its approval-gated, voice-to-prompt-specific scope, though it doesn't explicitly contrast with similar tools like create_llm_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 phrase 'for AI Party-style workflows' gives a use context, and 'It never dispatches raw hardware effects' implies a limitation (not for direct hardware control). However, it doesn't explicitly state when to use this over alternatives or mention exclusions, 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_tidalcycles_livecodingA
  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, and the description's 'Create' aligns with a non-read-only operation. The description adds that it builds a scaffold with pattern and orbit maps, which gives some sense of the generated structure. However, it does not disclose side effects such as potential overwriting at parent_path or external dependencies like a running SuperDirt instance.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 about 15 words, front-loading the main verb and object. It is concise, avoids redundancy, and every word contributes meaning.

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

  Completeness3/5

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

  The description gives a clear high-level purpose but lacks details about the scaffold's internal structure, prerequisites, and behavior. As a creation tool with 8 parameters and no output schema, more specifics about what gets created and any requirements would improve completeness, though the core intent is clear.

  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% (3 of 8 parameters have descriptions). The description mentions 'pattern' and 'orbit' which loosely relate to pattern_count and orbit_count, but it does not compensate for the majority of undocumented parameters like send_port, receive_port, active, etc. The parameter names are self-explanatory, but the description adds little semantic depth 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 action ('Create a TidalCycles/SuperDirt OSC scaffold') and the specific resource ('pattern and orbit maps') for live-coded audiovisual sets. It distinguishes itself from sibling connectivity tools by naming the exact technology and the scaffold nature of the operation.

  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-coded audiovisual sets' provides implied usage context, but the description does not explicitly mention when to use this tool over alternatives like connect_supercollider_synth, nor does it state prerequisites or exclusions. There is no differentiation from similar OSC bridge tools.

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

• create_depthai_oak_pipelineA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate the tool is mutating (readOnlyHint=false) and not destructive. The description adds context about scaffold components and 'hardware-gated setup notes,' but does not disclose potential side effects like overwriting existing nodes or idempotency. It neither contradicts annotations nor adds deep 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 one concise, front-loaded sentence that efficiently lists the scaffold's key components without wasted words. Every phrase adds value.

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

  Completeness3/5

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

  For a tool with 7 parameters and no output schema, the description is minimal but gives an adequate high-level idea. However, it lacks details on prerequisites, concrete usage scenarios, or how hardware-gating works, making it incomplete for confident execution without further investigation.

  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 tool description does not explain any parameter meanings beyond the schema's sparse descriptions. The description mentions components like 'stream maps' but does not map them to parameters such as stream_count, include_depth, or include_tracking, leaving the agent to guess.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'DepthAI/OAK camera scaffold' with specific components (OAK Device, TOP/CHOP placeholders, stream maps, setup notes), which is a specific verb+resource and distinguishes it from other create_* pipeline 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 DepthAI/OAK camera setups but does not explicitly state when to use it versus alternatives like create_voice_prompt_pipeline or create_depth_displacement. No exclusions or alternative mentions are provided.

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

• create_unreal_livelink_bridgeA
  3.6/5.0
  Behavior3/5

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

  Annotations already state readOnlyHint=false and destructiveHint=false, so the description only needs to add behavioral context. It adds that the scaffold includes subject maps, event queue, and runtime setup warnings, which is useful. However, it doesn't disclose side effects such as creating COMPs under parent_path or requiring an open world, so transparency 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, front-loaded, information-dense sentence without fluff. Every word adds value, and it's appropriately concise for the tool's purpose.

  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 11 parameters and no output schema, the description provides a high-level summary of what the scaffold includes. It lacks details about prerequisites, integration with the open world, and runtime behavior, but it is minimally adequate for a creation tool with annotations covering safety.

  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% (name and parent_path have descriptions). The description does not explain the mode parameter (livelink_osc, udp_json, ndi_preview), port settings, sync flags, or subject_name. It vaguely alludes to subject maps but doesn't compensate for the overwhelmingly 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 clearly states it creates an Unreal Engine Live Link/OSC/NDI handoff scaffold with subject maps, event queue, and runtime setup warnings. This specific verb+resource+scope distinguishes it from sibling bridge tools like connect_unity_osc_bridge or create_synesthesia_unreal_osc.

  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 via the description: use when you need an Unreal Engine Live Link/OSC/NDI handoff scaffold. But it doesn't explicitly state when not to use it or mention alternatives, so it lacks explicit exclusions or comparisons to other bridge tools.

  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.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, which aligns with the 'create' action in the description. The description adds that the tool produces a scaffold with specific elements, but does not disclose external dependencies (e.g., VIOSO software), project prerequisites, or implications of the config_file parameter, so it adds only modest 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 15-word sentence that front-loads the core purpose and key deliverables. Every word earns its place, with no redundant or vague phrasing.

  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 useful high-level summary but lacks important operational context: it does not mention prerequisites (e.g., existing project, VIOSO installation), the exact node structure created, behavior without a config_file, or expected output; given the 6 parameters and no output schema, this is a partial but not complete picture.

  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%, leaving active, projector_index, and blend_zone_count undocumented. The tool description loosely references 'blend-zone maps' and 'projector metadata,' which map to blend_zone_count and projector_index, but it does not explicitly explain these parameters or compensate for the missing 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 a specific verb and resource: 'Create a VIOSO projection-warp scaffold' and lists the included components (VIOSO TOP, blend-zone maps, projector metadata, setup notes). This distinguishes it from generic tools like create_projection_mapping or create_mpcdi_projection_mapper.

  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 VIOSO warp panel creation but does not explicitly state when to use it versus alternatives or provide exclusions. No prerequisites or conditions are mentioned, though the name and title make the primary use case somewhat evident.

  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
  3.6/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 that it is read-only and does not write files or touch the TD bridge. This adds minimal behavioral context beyond the annotations, but it is consistent and confirms no 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 (20 words) that efficiently communicates the core purpose and key constraints. 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.

  Completeness4/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 (2 required), 100% schema coverage, and an output schema exists, the description is adequately complete. It covers the main operation and constraints. However, it could provide more context about the strict parameter or the RecipeSchema draft format, but the schema and output schema handle those 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%, so the input schema already provides detailed parameter descriptions. The description only hints at the key inputs (technique with GLSL source) but does not add additional meaning beyond what the schema offers. With high coverage, baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the action (convert), input (embedded TD technique with GLSL source), and output (RecipeSchema draft). It emphasizes the read-only nature, distinguishing it from write operations. However, it does not explicitly differentiate from sibling tools like draft_recipe_from_operator_chain, though the title and domain ('from technique') provide implicit distinction.

  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 have a technique with GLSL source) and states a key constraint (read-only, no TD bridge touch). However, it does not provide explicit guidance on when not to use it or mention alternative tools like draft_recipe_from_operator_chain or draft_recipe_from_tutorial, which are among its siblings.

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

• connect_companion_surfaceA
  3.7/5.0
  Behavior4/5

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

  Annotations only indicate readOnly=false, destructive=false, openWorld=true. The description adds behavioral context by detailing the internal structure: OSC In CHOP listens, each button gets Select/Null CHOP rows, optional target parameters are expression-bound, and an OSC Out CHOP is configured for feedback. It also discloses that a mapping table records entries for later editing, which is useful 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 one long sentence, but it is information-dense and front-loaded with the main action ('Build an OSC Companion-style button surface'). It packs multiple clauses and a mapping table mention without excessive fluff, though it is slightly verbose and could be split 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 a tool with 7 parameters and no output schema, the description covers the overall build process, the CHOP structure, and the mapping table outcome, which is sufficient for an agent to understand the tool's role. It does not explain prerequisites like existing TouchDesigner connection or behavior on name conflicts, but the schema handles parameter details. Given the complexity, the description is complete enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 7 parameters, including nested button objects with mode, label, target, address, feedback_channel. The description itself references the target and mapping table fields (label/address/target/mode/feedback), reinforcing but not extending the schema. Per the baseline, a score of 3 is appropriate.

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

  Purpose4/5

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

  The description uses the verb 'Build' with a specific resource: 'OSC Companion-style button surface inside TouchDesigner'. It enumerates key components (OSC In CHOP, Select CHOP, Null CHOP, OSC Out CHOP) and a mapping table, clearly stating the tool's function. It does not explicitly differentiate from sibling tools like 'create_companion_surface' or 'create_control_surface', so it misses the top score.

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

  Usage 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 architecture and the mapping table for later editing, but it does not instruct when to use this tool over alternatives such as 'create_control_surface' or 'create_companion_surface'. There is no explicit 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_xsens_mvn_mocapA
  3.7/5.0
  Behavior3/5

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

  Annotations declare readOnlyHint=false and openWorldHint=true, which align with 'Create' in the description. The description adds details about the scaffold's contents, but it does not disclose potential side effects like overwriting existing nodes, required permissions, or connection behavior beyond the generic creation act.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 lists key features compactly. Every listed element (ingest protocols, mapping, tables, notes) adds meaningful value without redundancy or 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?

  With 9 parameters and no output schema, the description should provide more context about what the tool returns or what the scaffold looks like operationally. It lists the scaffold's components but lacks details on prerequisites, defaults, or expected outcomes, leaving it adequate but not thorough 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 coverage is only 22% (only name and parent_path have descriptions). The description mentions 'OSC/UDP/TCP ingest' and 'coordinate-space notes', which map to source_mode and coordinate_space parameters, adding some meaning. However, it does not explain parameters like actor_count, segment_count, receive_port, server_host, or active, so it only partially 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 a specific resource ('Xsens MVN mocap scaffold'), then enumerates distinguishing features (OSC/UDP/TCP ingest, actor/segment mapping, normalized skeleton tables, coordinate-space notes). This clearly sets it apart from sibling mocap 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 Xsens MVN integration through its feature list, but it does not explicitly state when to use this tool vs alternatives (e.g., OptiTrack, other mocap bridges) or any exclusions. It is an implied usage context, not an explicit guideline.

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

• create_body_bubblesA
  3.7/5.0
  Behavior4/5

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

  Annotations provide basic hints (non-readonly, non-destructive, open world). The description adds substantial behavioral context: bubbles stay inside screen, settle on floor, pop after configurable lifetime, and builds a self-contained COMP with physics solver and various controls. 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.

  Conciseness3/5

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

  The description is front-loaded with the main purpose but becomes verbose towards the end listing all sub-components and controls. It could be more concise by grouping technical details. However, it is still readable 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?

  Given the complexity (27 parameters, no output schema), the description covers the system behavior and dependencies well. However, it lacks explicit mention of the output type (a TOP? a COMP?) beyond parameter references. The user may need to infer that the tool creates a component outputting a TOP.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 3. The description provides an overall system overview but does not add significant per-parameter meaning beyond what the schema already gives. The parameter descriptions in schema are already very detailed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 MediaPipe-ready interactive bubble installation with specific behaviors: open palm emits bubbles, body/hand landmarks act as colliders, body contour rendered. This is distinct from sibling tools like create_body_reactive or create_blob_reactive, which likely have different visual outputs.

  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 requiring hand_chop_path and body_chop_path from setup_hand_tracking and setup_body_tracking/create_pose_tracking. It notes default behaviors (low bubble count, disabled wrist emission) but does not explicitly tell the agent when to choose this tool over 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.

• create_chrome_blobsA
  3.7/5.0
  Behavior4/5

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

  Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are present and the description adds value by explaining that the tool creates a baseCOMP with specific exposed parameters (Speed, Blob_Count, Metal_Color, Background). It also describes the shader process and available options (5 tints, 4 backgrounds), which provides meaningful behavioral context beyond what annotations alone offer.

  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 (a single sentence) yet comprehensive. It conveys all essential information without unnecessary fluff. However, it could be slightly improved by breaking into multiple sentences for readability, but overall it is well-structured 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?

  Given the tool's complexity (7 parameters, no output schema), the description adequately explains the tool's function, the generated component, and the exposed controls. It covers the core aspects needed for an AI agent to understand what the tool does and what parameters affect. No major gaps identified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 restates some parameter roles (e.g., 'Speed', 'Blob_Count') but does not add substantial new meaning beyond the schema's own descriptions. The parameter count is high (7), but the description covers the main controls without delving into technical 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 specifies the action ('Builds...'), the resource ('a liquid-chrome / Y2K metaball generator'), and the resulting component ('self-contained baseCOMP'). It provides a step-by-step outline of the process and lists the generated controls, 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 Guidelines2/5

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

  The description does not indicate when to use this tool versus alternatives (e.g., other create_ tools like create_audio_reactive, create_fluid_sim). There is no mention of prerequisites, scenarios, or exclusions. While the purpose is clear, the lack of contextual guidance reduces usability.

  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
  Behavior4/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 valuable context by detailing what the scaffold includes (TOP/DAT, projector maps, region maps, setup notes), going beyond the annotations. It does not disclose side effects like overwriting existing nodes, but the openWorld hint covers the create 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?

  A single sentence that is front-loaded with the verb and object, lists the core deliverables, and contains no filler or redundant content. 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.

  Completeness2/5

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

  Despite the annotations and simple schema, the tool has 6 parameters and no output schema. The description omits how parameters like 'config_file', 'region_count', and 'projector_count' affect the scaffold, and it does not explain what is returned or what the agent should expect after invocation. This leaves significant gaps for reliable 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 50%, and the description does not compensate. It vaguely references 'projector maps' and 'region maps' but never explicitly explains how 'region_count', 'projector_count', 'name', 'active', or 'config_file' are used. Three parameters (active, region_count, projector_count) have no schema descriptions, and the tool description adds no parameter-level 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 identifies the tool's action ('Create') and specific resource ('MPCDI projection-calibration scaffold'), and lists concrete artifacts (MPCDI TOP/DAT, projector maps, region maps, setup notes). This distinguishes it from generic 'create_projection_mapping' and other projection-related 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 MPCDI-specific wording implies the intended use case, but there is no explicit statement of when to use this versus alternatives like 'create_projection_mapping' or 'projector_calibration_wizard'. No exclusions or alternative tool names are mentioned, 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.

• create_ndi_router_matrixA
  3.7/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 description correctly implies a write operation that is not destructive. It adds context beyond annotations by characterizing the result as a 'stable scaffold' and explicitly stating it does not claim live NDI discovery, which manages expectations about the tool's 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, front-loaded sentence with no filler. Every word contributes meaning, and the key qualifier about live NDI discovery is placed at the end without bloating the text.

  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 6 parameters, no output schema, and sparse annotations, the description is underspecified. It does not explain the scaffolding structure, how the source/output counts map to the matrix, or what 'stable' means in practice, leaving the agent with insufficient context to reliably invoke 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 low (33%, only name and parent_path described), and the description does not compensate by clarifying the meaning or relationship of parameters like output_count, source_count, or include_preview. Parameter names provide some obvious semantics, but the description adds no explicit detail, leaving users to guess at how these values shape 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?

  Description states the specific verb 'Create' and resource 'NDI source/output routing matrix scaffold', clearly distinguishing from sibling router tools (e.g., osc_router_matrix, connect_spout_syphon_router). The qualifier 'without claiming live NDI discovery' further scopes the tool's purpose and sets it apart from discovery-focused 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 offers a general sense of when to use the tool (for a stable NDI routing matrix scaffold) and hints at an exclusion (not for live NDI discovery), but it names no explicit alternatives or when-not-to-use scenarios. This leaves usage context implied rather than clearly stated.

  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
  3.7/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 behavior. The description adds useful context about scaffold creation, fallback sources, stable TOP outputs, and validation warnings, but it does not disclose side effects, required SDKs, or failure modes. It is adequate but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 verb and packs four distinct value-adds (type, compatibility, fallbacks, outputs, warnings) with no wasted words. Every clause earns its place.

  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 10 parameters and no output schema, the description gives a helpful summary but omits important context like prerequisites (Orbbec SDK, Kinect hardware) and the precise network structure created. The rich schema and annotations partly cover these gaps, but the description alone leaves some ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 100% of parameters with descriptions, so the baseline is 3. The description does not add parameter-specific guidance beyond the schema; it mentions fallbacks and output TOPs, but these are already embedded in the param descriptions (e.g., source default 'synthetic'). No extra value 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 ('Create') and resource ('Orbbec/Kinect-compatible depth silhouette scaffold'), and further distinguishes itself with unique attributes: synthetic/file fallbacks, stable silhouette_out and depth_preview TOPs, and explicit hardware/SDK validation warnings. This clearly separates it from generic depth tools like create_depth_silhouette.

  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 Orbbec/Kinect depth scenarios and mentions fallbacks, but it does not explicitly state when to use this tool over siblings like create_depth_silhouette, nor does it provide when-not-to-use conditions or alternatives. The context is clear enough for an informed agent, but there is no explicit guidance.

  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.7/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's 'Create' aligns with. The description adds that the scaffold includes Ouster TOP, range selection, zone maps, and calibration notes, providing some detail about the created content. However, it does not disclose side effects, prerequisites, or how these components behave, leaving the agent with moderate 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 a single, concise sentence of 13 words that directly conveys the tool's core action and output components. It avoids unnecessary filler and front-loads 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?

  Despite having 8 parameters and no output schema, the description only provides a high-level overview of the scaffold without explaining parameter meanings (e.g., imu_port, lidar_port, ring_count, zone_count, device_address) or the integration context of parent_path. This leaves the agent dependent on naming conventions and defaults, which is 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 25% (name and parent_path have descriptions; active, imu_port, lidar_port, ring_count, zone_count, device_address do not). The description text does not explain any parameters, and mentions of 'range selection' and 'zone maps' only loosely relate to ring_count and zone_count without explicit mapping. Given the low schema coverage, the description fails 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 clearly states the tool's purpose with a specific verb ('Create') and resource ('Ouster LiDAR scaffold'), and enumerates key included components (Ouster TOP, range selection, zone maps, calibration notes). This distinguishes it from sibling lidar bus tools like create_hokuyo_lidar_bus and create_livox_lidar_bus by explicitly naming Ouster.

  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 by specifying 'Ouster LiDAR', making it evident that this tool is for Ouster devices rather than alternatives such as Hokuyo or Livox. While it does not explicitly state when not to use it or name alternatives, the vendor-specific phrasing provides clear context.

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

• create_zed_depth_busA
  3.7/5.0
  Behavior3/5

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

  The description adds the behavioral traits of 'runtime-gated warnings' and 'placeholders,' indicating the scaffold is not fully wired and may emit warnings under certain conditions. Annotations already declare non-read-only, non-destructive, open-world behavior, so the description adds moderate extra context but does not elaborate on the warnings' content or trigger conditions.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 front-loads the core purpose (ZED camera scaffold) and key specifics (TOP/CHOP/SOP placeholders, runtime-gated warnings). 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.

  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 7 parameters, no output schema, and only a brief description, the information is thin. The description omits return values, parameter effects, and the nature of 'runtime-gated warnings.' Annotations provide some safety context, but the tool's complexity warrants much more detail.

  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% (name and parent_path). The description does not explain any of the seven parameters—active, body_count, camera_index, stream_count, include_pointcloud—or how they affect the scaffold. It only indirectly references point-cloud via the word 'point-cloud' in the description, which is insufficient given 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 identifies the action (Create), the specific resource (ZED camera depth/body/point-cloud scaffold), and key details (ZED TOP/CHOP/SOP placeholders, runtime-gated warnings). It distinguishes this tool from sibling tools like create_realsense_depth_bus by explicitly focusing on ZED cameras.

  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 creating a ZED depth scaffold, implying it should be used when you need a ZED camera pipeline. However, it does not explicitly mention when not to use it or name alternative tools for other depth cameras, so it lacks exclusion guidance.

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

• generate_library_indexA
  3.7/5.0
  Behavior4/5

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

  Annotations provide basic hints (not read-only, not destructive, open-world). The description adds valuable behavioral details: it reads the local vault from disk, writes a file, and requires a configured TDMCP_VAULT_PATH. It also describes the output format and thumbnail source, aiding the agent in understanding 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 a single, well-structured paragraph that front-loads the main action. It covers key points without excessive verbosity, though could be slightly more scannable.

  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 (6 parameters, no output schema) and annotations present, the description provides adequate context: output format, dependencies, prerequisites, and filtering. It does not explain the return value, but the action of writing a file is clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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. The description mentions filtering by kinds and query but does not add significant new meaning beyond the schema. Baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states it writes a Markdown contact-sheet note of the vault library with thumbnail cards, title, tags, and load snippets. The purpose is specific and distinct from siblings, though it does not explicitly differentiate from similar browsing tools like 'browse_vault_library' or '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 Guidelines3/5

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

  The description implies usage contexts: offline indexing ('No TouchDesigner connection required') and option to filter by kinds/query. However, it does not explicitly state when not to use or provide alternatives, leaving 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.

• log_performanceA
  3.7/5.0
  Behavior4/5

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

  Annotations indicate it is not read-only and not destructive. The description adds behavioral details: it reads a snapshot, writes a journal entry with a thumbnail attachment, and requires a vault path. It also mentions the return values (note path, thumbnail saved, counts), which provides valuable context 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 concise with three sentences, front-loading the key actions. It efficiently covers purpose, usage, and returns without unnecessary detail.

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

  Completeness4/5

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

  For a tool with 6 parameters, 100% schema coverage, and no output schema, the description adequately explains the tool's behavior, return values, and a prerequisite (vault path). It is sufficiently complete for an agent 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 coverage is 100% with clear parameter descriptions. The description does not add new semantic information about parameters beyond what the schema provides. 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 action: reading a network snapshot and writing a dated journal entry. It specifies the resource (Performances/<date>-<title>.md) and optional thumbnail. While it is specific, it does not explicitly differentiate from sibling tools, which are many.

  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 suggests using the tool to build a diary of shows, providing a clear use case. However, it does not specify when not to use it or provide alternative tools for similar tasks, limiting guidance on selection.

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

• provenance_stampA
  3.7/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. Description adds that it works offline and includes best-effort git metadata. However, it does not disclose failure modes, permissions, or prerequisites (e.g., artifact must exist).

  Agents need to know what a tool does to the world before 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: first states the action and artifact, second enumerates recorded contents. Front-loaded, no redundancy, every sentence earns its place.

  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 has no output schema, the description adequately explains what is written. However, it does not cover error conditions, required artifact existence, or what happens if the artifact path is invalid. For a 9-parameter write tool, more context on preconditions would improve 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 baseline is 3. Description lists many recorded fields (sha256, size, author, tags, etc.) that align with schema properties, but does not add new meaning beyond the schema descriptions. Marginal added 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?

  Description clearly states the tool writes a .provenance.json sidecar next to an artifact, listing specific recorded fields (sha256, size, mtime, source, etc.). Verb 'Writes' and resource 'sidecar' are specific, and the tool is distinct from siblings like checksum_and_verify_pack or version_library_asset.

  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 provenance metadata is needed) and notes offline capability, but does not explicitly state when to use this tool over alternatives or provide exclusions. No sibling differentiation is mentioned.

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

• sync_timecodeA
  3.7/5.0
  Behavior4/5

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

  Discloses creation of specific operators (input op, Math CHOP, Null CHOP), optional Execute DAT, and macOS permission modal hang risk. Annotations are consistent (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?

  Front-loaded with main purpose, then details. Efficiently structured with separate sentences for warnings and optional functionality, but could be slightly more concise.

  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 parameters, no output schema, and annotations, the description covers main functionality, prerequisites, and warnings. Leaves little ambiguity about what the tool does and its side effects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameters well. The description adds marginal extra meaning, such as explaining the device picker issue, but mostly reiterates what's in 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 verb 'wire' and the resource 'external SMPTE/MTC/LTC/OSC timecode source into the TouchDesigner timeline', specifying scope. However, it does not explicitly distinguish from sibling tools like 'sync_external_clock', leaving 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 Guidelines3/5

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

  Provides context such as the requirement for the project to be playing and a warning about LTC decoder limitations. However, it lacks explicit when-not-to-use scenarios or alternatives to other timecode sync tools.

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

• apply_post_processingA
  3.8/5.0
  Behavior3/5

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

  The description adds behavioral context beyond annotations: it creates a new baseCOMP, wires effects in series, and returns a structured result. Annotations indicate non-read-only (mutating) and non-destructive, which aligns with the description. However, it does not disclose potential side effects, such as whether the parent_path must exist or if the operation is idempotent, leaving some transparency gaps.

  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 (four sentences) and well-structured: purpose, process, output, and alternatives are each addressed in a front-loaded manner. No fluff or redundant information is present.

  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 creation process, return format, and alternative tools, but is missing details like whether the parent_path is created if missing or prerequisites for the source_path. Given the tool's moderate complexity with three parameters and no output schema, the description is adequate 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?

  The input schema has 100% coverage with parameter descriptions. The description adds some nuance, e.g., explaining that source_path is pulled via a Select TOP and that certain effects in the enum redirect to another tool. Overall, the added value is moderate, meeting the baseline for a schema with high 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: 'Chain post-processing effects... onto an existing TOP'. It specifies the verb 'chain' and resource 'TOP', and distinguishes from siblings by naming create_color_grade, create_glitch, and post_passes_3d 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 Guidelines4/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 versus alternatives: 'Use create_color_grade or create_glitch instead when you want a single dedicated effect with its own exposed controls.' It also mentions that 3D-aware modes redirect to post_passes_3d. However, it does not cover all possible alternatives or explicitly state when not to use this tool beyond those cases.

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

• create_control_panelA
  3.8/5.0
  Behavior4/5

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

  Annotations indicate non-readOnly and non-destructive behavior. The description adds context beyond annotations by stating that bind_to targets are switched to expression mode and that rgb/pulse controls cannot use bind_to. This is valuable 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 extremely concise: two sentences that cover purpose, usage, and key details. No wasted words; 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?

  The description, combined with the detailed schema and annotations, provides sufficient context for using the tool. It explains the workflow and key constraints. Minor omissions (e.g., error cases) are acceptable given the schema richness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds little beyond what the schema already provides. The description summarizes the process but does not introduce new parameter semantics. Baseline of 3 is appropriate given 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's purpose: exposing live controls on a COMP and binding them to node parameters. It uses specific verbs ('expose', 'append', 'bind') and identifies the resource type. However, it could better distinguish from the sibling tool 'create_control_surface', which may have overlapping functionality.

  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 explicit instructions on how to use the tool: pointing comp_path at a system container and listing controls with bind_to targets. However, it does not mention when not to use it (e.g., when simple parameter addition is sufficient) or reference alternatives like 'add_custom_parameters'.

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

• create_external_ioA
  3.8/5.0
  Behavior3/5

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

  Annotations indicate openWorldHint=true, readOnlyHint=false, destructiveHint=false. The description adds context about hardware requirements (e.g., NVIDIA GPU needed for RTMP on Windows) and tolerances for missing channels in bindings. But it does not disclose potential side effects like network modifications or behavior when creating duplicate operators.

  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 that packs much information but lacks bullet points or clear segmentation. It is concise for the amount of content, but could be better organized for quick scanning by an AI agent.

  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 17 parameters with 1 required, high schema coverage, and no output schema, the description covers most important aspects: protocol-specific notes, hardware requirements, default behaviors. It could mention return values or error handling, but overall is sufficient for correct 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 description adds moderate value beyond the schema. It provides usage context for parameters like kind (explaining each value's purpose) and source_path (requiring same parent_path). However, most parameter details are already in the schema descriptions, so incremental value is limited.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 concise statement 'Bridge TouchDesigner to the outside world' and enumerates all supported I/O types (OSC/MIDI input/output, DMX/Art-Net, RTMP, NDI/Syphon-Spout), clearly distinguishing what the tool does. It provides a specific verb ('Create external I/O') and resource, effectively differentiating 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 gives context on when to use each kind (e.g., 'To discover which channel a control sends... wiggle it and read the input CHOP'), and includes validation notes ('Validate live where possible'). However, it does not explicitly state when NOT to use this tool or compare it with alternatives like other I/O tools.

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

• create_hand_hologramA
  3.8/5.0
  Behavior4/5

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

  The description reveals key behaviors: defaults to a synthetic cube, open palm controls visibility, float anchor maintains height, opposite-hand pinch drives scale/glow and optional audio. It aligns with annotations (readOnlyHint=false, destructiveHint=false) and adds 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.

  Conciseness4/5

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

  The description is a single paragraph of four sentences, front-loading the core purpose and key interactions. While somewhat dense, it avoids redundancy and uses each sentence to convey important details, earning a slightly above-average score.

  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 main behaviors and workflow but lacks explicit mention of the output (e.g., a hologram component) and does not guide when to adjust many of the 21 parameters. Given no output schema, more completeness would be beneficial, but the description still provides a functional 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?

  With 0% schema description coverage, the description partially compensates by explaining behaviors related to float_height, glow, pinch_scale_amount, and audio_mode, but many parameters (e.g., color, resolution, transparency) remain unexplained, providing moderate added 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 tool builds a palm-anchored hologram visual, specifies the default holographic cube, and details interactions like open palm visibility and pinch-driven scale/glow/audio, distinguishing it from other 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 Guidelines3/5

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

  The description implies use for hand-tracking holograms and mentions its connection to create_hand_gesture_bus, but it does not explicitly state when to use this tool over alternatives or provide exclusions, leaving usage guidance implicit.

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

• create_jfa_voronoiA
  3.8/5.0
  Behavior4/5

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

  Annotations show readOnlyHint=false (writes), destructiveHint=false (non-destructive), openWorldHint=true (creates new nodes). The description adds valuable behavioral context: it creates a self-contained network with multiple GLSL TOPs, auto-derives pass counts, and exposes live controls. It does not contradict annotations and provides extra insight 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?

  The description is two sentences with no wasted words. It front-loads the core purpose and pipeline, then adds an important detail about pass count auto-derivation. 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?

  Given the complexity of 13 parameters and no output schema, the description covers the pipeline, exposed controls, and pass count logic. However, it could clarify the final output (preview TOP) and the meaning of 'null' in the pipeline. Still, it is mostly 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?

  Schema coverage is 100%, so the description adds minimal extra parameter meaning beyond listing a few controls. It mentions exposed live parameters but does not explain interactions or behavior beyond the schema. The baseline of 3 is appropriate as schema already 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 instantiates a Jump-Flooding-Algorithm Voronoi generator with a specific pipeline (seeds → jfa_init → K halving passes → color_pass → null). It distinguishes this from other tool creation tools by detailing the technique and exposed controls, making the purpose very specific and distinct.

  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 provide explicit guidance on when to use this tool versus alternatives like create_particle_system or create_fluid_sim. It implies usage for Voronoi/cell patterns but lacks context for selection or exclusion, which is a gap given the large sibling list.

  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.8/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 create operation. The description adds behavioral context by specifying what the scaffold includes (ingest modes, schema, zone maps, calibration notes), which goes beyond the annotations. It does not mention potential side effects like overwriting an existing node with the same name, but the scaffold contents are useful disclosure.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the core action ('Create a Livox LiDAR adapter scaffold') and then lists key features in a compact enumeration. No wasted words or repetition.

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

  Completeness3/5

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

  The description communicates what the scaffold includes, which is helpful for a create tool with no output schema. However, it lacks details about the scaffold's integration into the project (e.g., how parent_path affects placement), what the defaults do (e.g., default server_url), and any caveats about existing nodes. Given nine parameters and no output schema, the description could be more thorough.

  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% (three of nine parameters have descriptions). The description mentions UDP/WebSocket/file-replay ingest (mapping to adapter_mode) and zone maps (zone_count), but does not clarify the remaining parameters like receive_port, point_rate_hint, active, or server_url. With low schema coverage, the description should compensate more thoroughly but only partially 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 clearly states a specific action ('Create a Livox LiDAR adapter scaffold') and enumerates concrete contents (UDP/WebSocket/file-replay ingest, point-stream schema, zone maps, calibration notes). This distinguishes it from sibling LiDAR bus tools like create_ouster_lidar_bus or create_hokuyo_lidar_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?

  Usage is implied by the tool name and description: it is for creating a Livox LiDAR adapter. However, there is no explicit guidance on when to use this versus alternative LiDAR bus tools, nor any exclusion criteria. The massive sibling list makes explicit differentiation valuable, but the name suffices to infer the intended scenario.

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

• create_pixel_sortA
  3.8/5.0
  Behavior4/5

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

  Description adds behavioral context beyond annotations: it creates a component using glslTOP feedback chain, defaults to noiseTOP, and allows live tweaking. Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are minimal, so description carries burden well, though it could mention node creation 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?

  Description is a single paragraph of 5 sentences, clear and front-loaded with purpose. Could be more scannable with bullet points, but it is concise without waste.

  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?

  Description covers main algorithm, parameters, and default source, but fails to specify what the tool returns (e.g., a component path or created node). Missing output details reduces 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?

  Schema coverage is 100%, baseline 3. Description adds value by summarizing key parameters (Mix, Threshold, Iterations, Direction, Reset) and explaining sort keys (luminance, hue, saturation) 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?

  Description clearly states the tool builds a glitch-art pixel-sort effect with specific details (rows/columns, luminance threshold, multi-pass sort, sort keys, live tweaking). It distinguishes itself from many sibling tools like create_glitch or create_datamosh by focusing on pixel sorting.

  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?

  Description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for pixel-sort effects but offers no when-not or comparison to siblings like create_glitch or create_kaleidoscope.

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

• create_time_echoA
  3.8/5.0
  Behavior4/5

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

  Beyond the annotations (which indicate non-destructive mutation and open-world), the description reveals that the tool builds a container COMP, selects source by absolute path, handles fallbacks for operator name variations, collects warnings on failures, and may return a Null output. It also labels the tool as 'EXPERIMENTAL' and warns about TD build variations. 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.

  Conciseness3/5

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

  The description is verbose and contains implementation details that may not be essential for an agent deciding to use the tool (e.g., internal TD operator fallbacks). While the main purpose is front-loaded, the length reduces clarity and some redundancy exists (e.g., repeated mode explanations).

  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, 3 modes, no output schema), the description is remarkably complete. It explains each mode's mechanism, parameter interactions, edge cases (e.g., feedback loop stability, fallback operators), and the experimental nature. The agent gains a solid understanding of what happens during execution.

  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 8 parameters with descriptions (100% coverage). The description adds meaningful context for several parameters: specifying that resolution is REQUIRED for echo mode to avoid black feedback, explaining the role of feedback opacity and cache-depth, and clarifying that displace_top can be omitted for a built-in ramp. This extra behavioral info aids the agent in configuring the 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 explicitly states the tool applies a per-pixel time effect to a source TOP and details three modes (echo, slit_scan, time_displace). It is specific about the resource and action, but does not directly contrast with sibling tools like create_feedback_network or create_datamosh, leaving some differentiation implicit.

  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 when each mode might be used (e.g., 'echo trails', 'slit-scan', 'time machine melt/slice look') and notes the experimental status. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., creating a feedback network or datamosh), and does not state prerequisites or conditions for use.

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

• export_palette_componentA
  3.8/5.0
  Behavior3/5

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

  Annotations indicate destructiveHint=true and openWorldHint=true, so the description adds context by specifying the write action and target folder. However, it does not mention file overwrite behavior, required permissions, or return value, leaving gaps beyond already provided 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 (20 words) that efficiently communicates the purpose without extraneous information. It is front-loaded and every word adds value.

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

  Completeness4/5

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

  The description covers the core functionality well, but lacks information about return values (e.g., success/failure) and potential side effects like file overwriting. Given the absence of an output schema, this gap could be filled.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 clear parameter descriptions. The tool description does not add additional parameter meaning beyond what the schema already provides, so baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states the action (save a COMP as a .tox), the target location (TouchDesigner's native Palette folder), and the outcome (appears in Palette browser for drag-and-drop reuse). It distinguishes this from sibling export tools like export_look_tox or export_network_to_vault by specifying the palette context.

  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 palette reuse but does not explicitly state when to use this tool versus alternatives (e.g., export_look_tox, export_recipe_bundle). No when-not-to-use or prerequisites are mentioned.

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

• get_technique_detailA
  3.8/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 adds that it's read-only and mentions optional inclusions, but does not detail behavior like error handling or required permissions. It adds moderate value 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 a single sentence, front-loaded with the key action, and contains no redundant words. Every part adds value.

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

  Completeness4/5

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

  Given an output schema exists and the tool is read-only, the description covers essential behavior. It could be more precise about the scope (e.g., what happens when technique_id is omitted), but it is adequate for a simple inspection 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 parameters are well-described. The description mentions "optional code snippets and setup/workflow details" which map to include_code and include_setup, but adds minimal 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 inspects TouchDesigner technique packs and techniques, with optional code snippets and setup details. The verb "inspect" and resource are specific, and it distinguishes from many sibling create/delete 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 says "read-only" implying safe inspection, but it does not explicitly state when to use this tool versus alternatives like search or list tools. No exclusions or context hints are provided.

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

• list_recipesA
  3.8/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, so the agent knows it's a safe read. The description adds that the list is offline and returns specific fields, which provides moderate additional context 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, no redundant words. Information 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.

  Completeness4/5

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

  Given the simplicity (1 optional param, no output schema), the description explains the return fields and offline nature. Lacks details like ordering or pagination, but sufficient for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 one parameter 'tag' described in schema. The description does not add further meaning beyond the schema's description. 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 verb 'List' and the resource 'built-in recipe library', gives examples (feedback tunnel, particle galaxy), and specifies returned fields (id, name, tags, difficulty). It also distinguishes from sibling 'apply_recipe' by suggesting to use that tool to apply a recipe.

  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 'Offline' and suggests 'Apply one with apply_recipe', providing some usage context. However, it does not explicitly state when to use this tool versus alternatives (e.g., browse_library, search_operators) 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.

• macro_recorderA
  3.8/5.0
  Behavior3/5

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

  Annotations already provide destructiveHint=true, so the description need not repeat that. It adds context about actions but does not elaborate on state changes, safety concerns, or what gets 'destroyed' during recording. The schema description for allowUnsafeRecording hints at persistence of secrets, but the description itself could be more explicit about behavioral 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 extremely concise—two sentences that front-load the purpose and actions. Every word is earned; no filler. This is a model of brevity while maintaining 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?

  Despite having 5 parameters and no output schema, the description is very brief and omits important context: the recording lifecycle (start then stop), expected outputs (JSON structure), prerequisites, and failure modes. For a tool with destructive hint and sensitive data concerns, this is incomplete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 20% (only allowUnsafeRecording described). The description adds value by listing the four actions and implying that file/name are relevant, but it does not explain each parameter's meaning or usage beyond the schema. The enum for action is mentioned, which helps, but file, name, redactSensitive, and the boolean flags lack sufficient 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 'Record' and the resource 'sequence of MCP tool calls to a portable JSON macro file'. It lists the specific actions (start, stop, list, load) and distinguishes from the sibling 'run_macro_script' by mentioning replay is separate.

  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 naming the sibling tool for replay, guiding when to use this tool versus alternatives. However, it does not explicitly state when NOT to use or any prerequisites, but the actions listed give practical use cues.

  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
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnly=false and destructive=false, so the mutation profile is known. The description adds that it builds target-specific OSC Out lanes with layer opacity, crossfader, speed, clip trigger, and blackout channels, but does not disclose prerequisites, side effects, or whether existing structures 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 two sentences, front-loaded with the primary purpose and followed by a relevant usage qualifier. It is dense but every clause contributes meaningful information, with 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 builder tool with 7 well-documented parameters and no output schema, the description covers purpose, target applications, channel types, and usage context. It does not detail the resulting network structure or edge cases, but it is sufficient for an agent to understand the tool's role and main 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?

  Schema coverage is 100% with descriptions for all 7 parameters, so the baseline is 3. The description adds context about channel types but does not map them to specific parameters or provide additional syntax/format details 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 an OSC control chain for driving Resolume, VDMX, or both, with specific channels listed. It partially differentiates from output tools by mentioning use beside video/NDI/Syphon tools, but it does not explicitly distinguish from closely related sibling tools like connect_resolume_arena or connect_vdmx_workspace.

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

  Usage Guidelines4/5

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

  The description provides a clear usage context: use it beside video/NDI/Syphon output tools when an external VJ app handles playback or final compositing. It implies when not to use (when no external VJ app), but it does not explicitly 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.

• tag_and_search_libraryA
  3.8/5.0
  Behavior4/5

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

  Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses important behaviors: it explains each operation's effect, mentions preserved '*'-pinned tags during editing, and states the requirement for TDMCP_VAULT_PATH. It adds meaningful 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 (about 5 lines), front-loaded with a summary, and structured logically by operation. Every sentence adds value; 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 (4 operations, 11 parameters, no output schema), the description covers the library scope, operations, and environment requirement. It could be improved by describing the output format for list/search results, but it is largely complete.

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

  Parameters3/5

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

  The input schema already has 100% description coverage, so each parameter is documented. The tool description provides an overview of how operations use parameters but does not add significant meaning beyond the schema details. 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 purpose: 'Faceted browse + tag editing over a vault library (Recipes/ + Components/ markdown notes).' It enumerates four operations with specific verbs (list, search, tag, filter) and the resource, distinguishing it from the large set of 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 does not provide explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it or compare with sibling tools like browse_library or search_operators. The only contextual hint is 'Pure vault I/O — no TouchDesigner bridge required,' but that is insufficient for clear selection.

  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?

  Annotations indicate write (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that compute writes a manifest and verify re-hashes for comparison, and that no TD bridge is needed, providing useful behavioral context 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?

  Two sentences efficiently convey the core functionality and actions. Could be improved by briefly listing key parameters or providing a more structured summary, but it is clear and direct.

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

  Completeness3/5

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

  Given the complexity (9 params, nested objects, no output schema), the description covers the main workflow but lacks details on parameter usage, default exclusions, and manifest format. It is minimally complete for a basic understanding but not fully sufficient.

  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 9 parameters with 0% description coverage. The description only implicitly mentions 'action' and 'path', leaving other parameters like strict, manifest, exclude_globs, etc. unexplained. This does not compensate for the lack of 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 computes or verifies SHA-256 checksums for tdmcp artifacts, with specific actions compute and verify. It distinguishes itself from sibling tools by focusing on checksum operations for packaging 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?

  It explains that action=compute writes a manifest and action=verify reports mismatches. It also mentions 'No TD bridge required,' but does not explicitly state when to use this tool versus alternatives or provide exclusions.

  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?

  Annotations indicate non-read-only and non-destructive. The description adds that the tool may drop or install a .tox file and create a container, providing 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 two sentences with no waste. It front-loads the main verb 'Bridge' and efficiently communicates the two main paths and output structure.

  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 is adequate but lacks details on prerequisites (e.g., needing a running ComfyUI server) and parameter-mode dependencies, which could be more 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 parameter descriptions, so baseline is 3. The tool description adds minimal extra meaning beyond the schema, only briefly referencing mode 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?

  The description clearly states the verb 'Bridge' and the resource 'running ComfyUI server', and distinguishes from siblings like connect_daydream_cloud by specifying ComfyUI-specific actions (dropping .tox or building webclient skeleton).

  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 but lacks explicit when-to-use or when-not-to-use guidance. Mode selection is mentioned, but no prerequisites or alternatives from sibling list are discussed.

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

• connect_daydream_cloudA
  3.9/5.0
  Behavior4/5

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

  Beyond annotations (readOnlyHint false, openWorldHint true), the description adds behavioral details: API key from environment variable, data flow mechanism, and that live probe is skipped. 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 concise (3-4 sentences), front-loaded with purpose, and efficiently covers data flow, security, and a limitation. Every sentence adds value.

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

  Completeness3/5

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

  While the description explains the process well, it lacks information about return values (no output schema) and error handling. Given the complexity (13 params, external service), this gap reduces 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?

  Input schema has 100% description coverage, so parameters are well-documented. The tool description adds process context but does not significantly enhance meaning beyond schema for individual 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 creates a Daydream cloud-hosted StreamDiffusion bridge in TD, specifying the verb 'Create' and the resource. It details the data flow (POST source, receive via receiver) and differentiates from siblings like connect_comfyui by naming Daydream.

  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 prerequisites (Daydream account, outbound HTTPS) and that a live probe is skipped, but does not explicitly guide when to use this tool vs alternatives or provide exclusions. Usage context is implied but not fully specified.

  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.9/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 two useful behavioral traits: it creates a 'scaffold' (not a live connection) and explicitly states 'no code-evaluation behavior'. This provides context not available from structured data 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 a single, front-loaded sentence that efficiently conveys the main action and adds important constraints. Every word earns its place; there is 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?

  With 8 parameters and no output schema, the description lacks critical context about what the scaffold contains, how the ports map to SuperCollider, and what 'active' means. It is too sparse for an agent to reliably invoke the tool with appropriate parameter choices.

  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 elaborate on key parameters such as send_port, receive_port, bus_count, synth_count, or sc_host. The phrase 'explicit port maps' hints at the port parameters but does not explain their roles, leaving most parameters 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 uses a specific verb ('Create') and names the resource ('SuperCollider OSC synth/bus bridge scaffold'), along with distinctive constraints ('explicit port maps', 'no code-evaluation behavior'). This clearly distinguishes it from generic bridge tools and 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 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 creating a SuperCollider-specific OSC bridge scaffold. However, it does not explicitly mention alternatives or 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.

• connect_twitch_eventsub_busA
  3.9/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, open-world behavior. The description adds behavioral nuance with 'scaffold' (implying a template rather than a fully wired connection) and 'OAuth/webhook safety notes' (indicating security considerations). It does not contradict annotations and provides some context beyond the structured 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 sentence that front-loads the main action and resource, then packs the key output components into a concise list. There is no filler or redundancy; every phrase contributes meaningful information about what the scaffold includes.

  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 11 parameters, no output schema, and minimal schema descriptions, a one-sentence description is insufficient. It does not explain the function of key parameters (port, netaddress, event_count, adapter_mode, etc.), nor what the scaffold does after creation, prerequisites, or return behavior. The description leaves significant gaps in the operational picture.

  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 of 11 parameters have descriptions), and the tool description does not map its listed components to any parameter names or explain formats/types. Terms like 'reward maps' and 'moderation policy' hint at reward_count and moderation_level, but this is too indirect to compensate for the large undocumented parameter set.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Twitch EventSub/chat scaffold'), and enumerates concrete components (sanitized event rows, reward maps, moderation policy, adapter source, OAuth/webhook safety notes). This clearly distinguishes it from other connect_*_bus sibling tools by naming Twitch EventSub explicitly.

  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 intended use clear: it is for creating a Twitch EventSub/chat scaffold. It implies when to use this tool (when needing Twitch EventSub integration), and the specificity of 'Twitch' differentiates it from similar chat bus tools (e.g., YouTube, TikTok). However, it does not explicitly mention exclusions or alternatives, 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.

• controlled_disorder_gridA
  3.9/5.0
  Behavior4/5

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

  The description adds significant behavioral context beyond annotations: it reveals that the tool creates a baseCOMP, exposes live controls, returns a summary with JSON and preview, and ensures stability via hashing. Annotations only indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description fully covers the creation side effect and reproducibility. 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 a single, dense sentence that conveys all key information without wasted words. It front-loads the core concept and then details the output. While slightly verbose, it remains efficient. Could be improved with line breaks for readability, but the content 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 14 parameters, full schema coverage, no output schema, and minimal annotations, the description is sufficiently complete. It explains the output (baseCOMP, controls, return format) and the core algorithm (hashing, stable chaos). It does not detail every possible interaction but covers the essential workflow for an AI agent to select and use 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 coverage is 100%, so baseline is 3. The description adds context about the disorder knob scaling multiple jitters together and the outline giving a Schotter look, but these are also hinted at in parameter descriptions. It doesn't add much meaning beyond what the schema provides for each parameter, but it does tie them together into a coherent operation.

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

  Purpose5/5

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

  The description precisely states the tool's function: generating a grid of quads/cells with a single disorder knob controlling position, rotation, and scale jitter. It clearly identifies the resource (grid), the action (generate), and the key parameter, making it distinct from sibling tools which are mostly about other types of creation or effects.

  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 in generative design contexts (mentioning Schotter study) but does not explicitly state when to use this tool over alternatives. It lacks guidance on when not to use it or what conditions are ideal. With many sibling create_* tools, more explicit differentiation would help.

  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.9/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 (destructiveHint=false). The description adds meaningful behavioral context beyond that by stating the scaffold is 'inactive-by-default' and includes 'safety notes', which informs the agent about default state and safety considerations. It doesn't 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 a single, front-loaded sentence that efficiently communicates the core purpose and notable features. Every word earns its place, with no filler 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 7 parameters, no output schema, and low schema description coverage, the description needs to provide more context to guide correct invocation. It does articulate the high-level intent ('scaffold', 'monitor inventory', 'display maps') but lacks details on parameter meanings, configuration semantics, or expected results, 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 description coverage is only 29% (only name and parent_path have descriptions). The description does not compensate for the other five parameters. The only indirect hint is 'inactive-by-default' which subtly implies the active parameter default, but output_count, display_index, resolution_width, and resolution_height are left entirely 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 uses a specific verb ('Create') and resource ('Direct Display Out TOP scaffold'), and adds concrete scope details ('monitor inventory, display maps, and inactive-by-default safety notes'). This clearly distinguishes it from sibling creation tools like create_dome_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 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 this tool: when you need a Direct Display Out TOP scaffold with monitor inventory and display maps. However, it does not explicitly name alternatives 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.

• create_fluid_simA
  3.9/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false; description confirms creation of nodes without destruction, adds detailed behavioral context (simulation method, controls, audio binding). 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?

  Description is well-structured and front-loaded with purpose, but is somewhat long. However, every sentence adds value given the tool's complexity. Could be slightly more concise.

  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 covers the tool's behavior, output format (summary + JSON), and optional features. Lacks explicit error handling but otherwise comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 has 100% parameter description coverage, so baseline is 3. Description mentions some parameters (dye color, injection radius, etc.) but does not add significant new 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 creates a real-time 2D fluid simulation using stable-fluids techniques, exposing artist controls. It distinguishes itself from sibling create tools (e.g., create_particle_system) by specificity to fluid/ink/dye sim.

  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 you need a fluid sim) but does not explicitly say when to use vs alternatives or when not to use. No exclusion criteria or context is provided.

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

• detect_pitchA
  3.9/5.0
  Behavior5/5

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

  The description thoroughly explains inner workings (Audio Spectrum CHOP, Analyze CHOP argmax), source options, knob effects, and limitations (1 Hz resolution, no harmonic/octave correction, monophonic). This goes well beyond the minimal 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.

  Conciseness4/5

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

  The description is fairly long but well-structured: starts with purpose, explains how it works, then lists caveats. Every sentence adds value, though some internal technical details could be more concise.

  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 no output schema, the description clearly explains outputs (pitch_hz, note, confidence) and how to bind them. It covers source options, controls, and limitations, making it complete for an experimental 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 baseline is 3. The description adds some context for parameters like source options and min/max Hz typical values, but does not significantly enhance understanding 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 it is an experimental monophonic pitch tracker with specific outputs (pitch_hz, note, confidence). It distinguishes its purpose from generic audio tools but does not explicitly differentiate from sibling tools like detect_tempo or detect_onsets.

  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 hints at driving visuals from a melody and lists caveats (monophonic, approximate), but does not explicitly specify when to use this tool instead of alternatives or recommend against certain use cases.

  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
  3.9/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. The description adds value by specifying 'conservative operator chain' and 'without writing files or touching the TD bridge', which reinforces non-destructive behavior and clarifies the output format. It does not detail error handling or limitations but is sufficient 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 a single, well-structured sentence that conveys the core purpose, constraints, and output without waste. Every part is essential.

  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 high-level function and output, but with 11 parameters and a complex input schema, it could mention key parameters like 'name' (tutorial identifier) or 'strict' (error behavior) to help agents. Since an output schema exists, the lack of return value description is acceptable. Overall adequate but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 tool description does not add parameter-specific meaning beyond the schema. 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 verb ('extract and draft'), the resource ('operator chain from an embedded TouchDesigner tutorial', 'RecipeSchema JSON'), and includes constraints ('conservative', 'read-only', 'without writing files or touching the TD bridge'). It distinguishes itself from sibling tools like draft_recipe_from_operator_chain or draft_recipe_from_technique by specifying the source as a tutorial.

  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 safe, read-only usage but does not explicitly state when to prefer this tool over alternatives like draft_recipe_from_operator_chain. No exclusions or when-not-to-use guidance is provided. The context is clear but not comparative.

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

• export_look_toxA
  3.9/5.0
  Behavior3/5

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

  Annotations already indicate mutation (readOnlyHint=false) and external side effects (openWorldHint=true). The description adds that it saves a .tox and writes a Markdown note, and names the note fields. However, it does not disclose file overwrite behavior, error handling, or confirmation steps, which are relevant for a mutation tool without destructive hint set to 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 two sentences with no extraneous information. The main action is front-loaded, followed by important defaults and prerequisites. 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 8-parameter tool with no output schema, the description covers the primary action, output artifacts, prerequisites, and integration points. It misses potential file conflict behavior and return values, but those are not critical given the rich schema and annotations.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds value by stating defaults (folder defaults to 'Looks'), listing note fields (name, tags, etc.), and specifying that name defaults to the COMP's name. This provides context beyond the schema descriptions.

  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 saves a COMP as a .tox and writes a Markdown note, specifying the destination path and note content. It distinguishes from sibling export tools by focusing on 'portable looks' and mentioning integration with browse/tag tools, but does not explicitly differentiate from other export tools like export_network_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 provides context on when to use (artist-publishing primitive for portable looks), prerequisites (TDMCP_VAULT_PATH and running TouchDesigner bridge), and integration hints (browse_vault_library, tag_and_search_library). It lacks explicit when-not-to-use instructions or alternative tools, but the specificity helps in usage decisions.

  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
  3.9/5.0
  Behavior4/5

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

  Annotations indicate non-destructive and open-ended behavior. The description adds context by explaining that the tool builds a sub-network, produces a Null DAT and Null CHOP, and details how each transport works. This goes beyond the annotations, providing valuable behavioral insight.

  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, consisting of three sentences that front-load the main purpose and key details. It is efficient and avoids unnecessary elaboration, 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.

  Completeness4/5

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

  Given the complexity of 14 parameters and no output schema, the description adequately covers the high-level behavior, including the output shape (Null DAT and Null CHOP). It could mention more about error states or default behaviors, but it provides sufficient context 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 has 100% description coverage, so the baseline is 3. The description adds marginal value by summarizing the transport types and the downstream shape, but it largely repeats what the schema already says. No significant new meaning is provided 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 that the tool adds extra transports to the data-source fabric, listing specific transports (mqtt, ws-binary, midi-mmc) with brief explanations. It distinguishes itself from the sibling tool 'create_data_source' by noting it goes beyond that, making the purpose 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 usage for adding specific transports beyond the initial creation, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites. The guidance is implicit and could be improved.

  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
  3.9/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 mentions fetching, validation, import process, and constraints like host-allowlisted and size-capped. This supplements the annotations (destructiveHint=true, openWorldHint=true) without contradiction. However, it could elaborate on what 'destructive' entails (e.g., overwriting local files).

  Agents need to know what a tool does to the world before 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 20-word sentence that packs the core action, resource, and constraints. Every word earns its place; there is 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?

  The description covers the main action and key constraints but lacks information about return behavior (e.g., success/failure, imported file paths) and does not explain the validation step. For a tool with no output schema and moderate complexity (4 params), the description is adequate but leaves the agent guessing about post-import state.

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

  Parameters3/5

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

  All four parameters have detailed schema descriptions (100% coverage). The tool description does not add significant extra meaning beyond synthesizing the parameters' roles (e.g., 'size-capped' ties to max_bytes). With high schema coverage, the description's contribution is 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 clearly states the verb (fetch, validate, import), the resource (recipe or recipe-bundle JSON from an HTTPS URL), and the destination (local recipes directory). It also mentions constraints (host-allowlisted, size-capped) that help distinguish from sibling import tools like import_recipe_bundle or import_model.

  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 importing from URLs but does not explicitly state when to use this tool versus alternatives (e.g., import_recipe_bundle for local files, import_model for 3D models). No when-not-to-use or prerequisite guidance is provided, leaving the agent to infer the scope.

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

• library_lineage_graphA
  3.9/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 reiterates 'Read-only, offline' and adds scan scope (Recipes, Shaders, etc.) and output formats. It doesn't disclose more behavioral traits like performance limits or error handling, but with annotations present, the description adds moderate value.

  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-packed sentence that front-loads the core purpose. It is efficient without being overly verbose, though it could be slightly more concise by avoiding mild 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 has 6 parameters and no output schema, the description adequately covers the scanning scope, output formats, and key constraints (offline, read-only). It explains what the tool produces but lacks specifics on output structure; however, the formats are 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?

  Schema description coverage is 100%; all parameters are described in the input schema with defaults, enums, and descriptions. The description does not provide additional meaning beyond what the schema already offers, 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 scans the vault library for lineage frontmatter and emits a lineage graph in multiple formats. The verb 'scans' and resource 'lineage graph' are specific, and it distinguishes from siblings by focusing on lineage extraction and graph generation.

  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 'Read-only, offline tool' and 'No TouchDesigner connection required,' providing clear context for when to use it. It implies usage for lineage analysis but doesn't list alternatives or when-not-to-use; however, among siblings, no other tool serves this specific purpose.

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

• manage_presetsA
  3.9/5.0
  Behavior3/5

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

  Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) already disclose mutation and non-destructive nature. The description adds context about persistence in COMP storage and pairing with create_control_panel, but does not elaborate on delete behavior 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?

  Two sentences, each earning its place. The first sentence summarizes the tool's purpose and action, and the second provides usage guidance and persistence context. 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?

  For a tool with 4 parameters and no output schema, the description explains the core functionality and usage context but does not describe return values (e.g., list returns preset names) or error conditions. This leaves some gaps for an AI 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%, so baseline is 3. The description does not add meaning beyond the schema descriptions for action, comp_path, name, and params. It reinforces that name is required for store/recall/delete, which is not enforced by schema but is helpful.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 (store, recall, list, delete) and the resource (named snapshots of COMP parameter values). It distinguishes from siblings like sync_presets_vault by mentioning the live-performance preset system 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 provides clear context for when to use the tool (live-performance preset system) and recommends pairing with create_control_panel. However, it does not explicitly exclude 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.

• morph_packA
  3.9/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: sha256 verification, portable JSON format, requirement for TDMCP_VAULT_PATH unless inline looks, and reuse of the create_preset_morph engine. These details help the agent understand side effects and constraints, though some behaviors like overwrite and merge are only mentioned in 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 concise at three sentences, with the main action front-loaded. Every sentence adds value: explaining the two actions, clarifying the engine relationship, and stating the vault path prerequisite. No redundancy or 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 the tool's complexity (two modes, 9 parameters, no output schema), the description covers core functionality but lacks details on return values, error handling, or expected outcomes. It does not specify what the agent receives after a successful pack or unpack operation, leaving some ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 does not add significant meaning beyond the schema; it briefly references parameters (action, name, vault path) but does not enhance understanding of param 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's two actions (pack and unpack) with specific verbs and resources: 'Export an existing create_preset_morph container's slots to a vault JSON' and 're-hydrate a pack file back into a create_preset_morph container'. It distinguishes itself from sibling tools like 'create_preset_morph' by noting it reuses that engine.

  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 (for exporting/importing morph slot sets) but lacks explicit guidance on when not to use it or alternatives. There is no mention of specific contexts or comparisons to siblings, so the agent must infer usage.

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

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

  Annotations already indicate destructive and not read-only. The description adds 'Writes a file (destructive)' reinforcing this, and mentions the output passes RecipeSchema, but does not detail side effects beyond file writing.

  Agents need to know what a tool does to the world before 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 succinct sentences with no wasted words. Action-oriented 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 simple tool with no output schema, the description explains the workflow and purpose adequately. However, it could elaborate on the generated template structure and overwrite 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?

  With 0% schema coverage, the description should explain parameters. It mentions id, name, and out_file in context but does not describe their meaning or the overwrite parameter. This is insufficient.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Write') and resource ('recipe JSON template'), clearly distinguishing this tool from siblings like 'scaffold_recipe_from_network' by emphasizing hand-authored bootstrapping.

  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: bootstrap a hand-authored recipe, fill in details, then apply_recipe. It implies a workflow but does not explicitly exclude alternatives or specify 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.

• tutorial_companion_packA
  3.9/5.0
  Behavior4/5

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

  The description discloses behaviors beyond annotations: it writes files to vault (consistent with readOnlyHint=false), captures topology for reference only (not installable recipe), and composes read-only bridge calls. It adds context about output files and post-usage editing by the artist. No contradiction with annotations (although destructiveHint=false, writing files is considered non-destructive custom when composition is read-only).

  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, using about five sentences to convey purpose, outputs, and constraints. It front-loads the action with a clear verb ('Build a teaching/selling companion'). Every sentence adds value, though it could possibly be shortened slightly without losing 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?

  Given the complexity (8 parameters, multiple file outputs, no output schema), the description adequately covers what the tool does, where it writes, and what prerequisites are needed (vault path, running bridge). It also clarifies what the output is not (RecipeSchema-compatible). It lacks a statement about the return value or success indication, but the file outputs serve as implicit response.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 75% of parameters with descriptions. The description mentions 'snapshot the COMP's topology' and 'scaffold an N-step lesson plan', which relates to source_comp and lesson_count respectively, but does not add new semantic meaning beyond the schema's descriptions. Baseline of 3 is appropriate given 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 it scaffolds a teaching companion pack for a network, specifying the exact outputs (tutorial.md, topology.json, etc.) and actions (snapshot topology, capture previews, scaffold lesson plan). It distinguishes from sibling tools like create_macro or scaffold_recipe_template by emphasizing read-only composition and the result not being a RecipeSchema-compatible installable recipe.

  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 (builds companion for network, requires vault path and running TouchDesigner bridge) but does not explicitly state when to use this tool over alternatives or when not to use it. The mention 'Composes existing read-only bridge calls — the artist edits the lesson body afterwards' implies a non-destructive, preparatory role, but no direct comparison to siblings.

  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
  4/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds value by specifying the exact destructive action: 'writes into the package folder (destructive).' It also discloses the registration in the manifest's docs list, providing behavioral context beyond the structured annotations. 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 sentences, front-loaded with the primary action, then usage context and a warning. 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.

  Completeness3/5

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

  The description covers the core workflow and references make_portable_tox for context, but it omits any mention of the optional help_snapshot parameter and its nested structure. Given the tool's moderate complexity (4 params, nested object, no output schema), the description is adequate for the main use case but not comprehensive. The destructive note and usage guidance help, but parameter coverage remains 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 25% (only help_snapshot has a description). The tool description does not explain docs, asset_dir, or manifest_path; it only mentions 'docs list' indirectly. With low schema coverage, the description should compensate for parameter meanings, but it fails to clarify the array format, defaults, or required path. 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 clearly states the action: 'Copy documentation files into a package and register them in its manifest's docs list.' This specifies a concrete verb and resource, distinguishing it from sibling tools like make_portable_tox or bundle_dependencies. The context 'Use after make_portable_tox' further anchors 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 Guidelines4/5

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

  It provides explicit usage context: 'Use after make_portable_tox to bundle a README or usage notes with a component so they travel with it.' This tells the agent when to use the tool and its purpose, but lacks explicit alternatives or when-not conditions. The guidance is clear enough for most cases.

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

• component_link_healthA
  4/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. The description reinforces that it is a 'Read-only diagnostic' and adds behavioral context: it probes live COMPs and reports missing/broken files. 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?

  Two succinct sentences with front-loaded purpose and context. Every word adds value; 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?

  While the description explains the tool's purpose and when to use it, it omits explanation of parameters and does not describe the output format (e.g., what the 'report' looks like). Given no output schema and 0% parameter coverage, this is a gap.

  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%, meaning the description does not explain the parameters 'paths' and 'parent_path'. The description fails to add meaning beyond the schema, such as how to use these parameters or their defaults. Agent cannot infer correct usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 externaltox paths and reports missing/broken linked component files. It is a read-only diagnostic, which distinguishes it from sibling tools like 'manage_component' or 'inspect_component_manifest' that may have different purposes.

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

  Usage Guidelines4/5

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

  The description provides explicit when-to-use guidance: 'run it when externally-linked .tox components may have moved or gone stale, before relying on them in a build.' It does not mention when not to use or list alternatives, but the context is clear enough.

  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
  Behavior4/5

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

  The description discloses that it may prompt for macOS microphone permission if audioSource is omitted, which is important behavioral info. Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with the description. However, it does not elaborate on other potential side effects or error states.

  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-loading the core purpose and mechanism. It is concise without unnecessary fluff, though it could be slightly more structured (e.g., separating usage guidance from output description).

  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 (chroma extraction, FFT), the description covers the basic concept and output type. However, it lacks details on the return value format (besides being a Null CHOP) and potential limitations, and it does not reference any output schema. The experimental tag is noted but not elaborated.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description adds context on the algorithm (FFT bin to pitch-class fold) but does not explain individual parameters beyond what the schema already provides. With schema coverage at 60%, the description partially compensates but not fully for the 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 clearly states it builds a 12-channel pitch-class chroma vector from audio via FFT bin to pitch-class fold. It specifies the resource (chroma reactive) and verb (builds), and distinguishes from siblings by mentioning shared audioSource convention with create_transient_reactive and create_energy_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 notes that the output is a Null CHOP ready for bind_to_channel and shares audioSource convention with similar tools. This gives context on usage, but it does not explicitly state when to use this tool versus alternatives like create_transient_reactive or create_energy_reactive, leaving some ambiguity for the agent.

  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/5.0
  Behavior4/5

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

  The description adds behavioral context beyond annotations: it creates a network with specific outputs, skeleton overlay, and optional relinking of TDA_Mapper. Annotations indicate non-destructive creation, and the description aligns without 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 with clear front-loading of purpose. No unnecessary wording; every sentence provides essential information. 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 key outputs and optional relinking, but for a complex tool with 20 parameters, it omits potential prerequisites (e.g., hand tracking setup) and error handling. However, parameter descriptions fill many 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?

  Schema description coverage is 100%, so baseline is 3. The description summarizes outputs but adds no new parameter details. It complements the schema without adding semantic value beyond what is already in 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 'Build a MediaPipe-hands to TDAbleton TDA_Mapper performance control network', specifying the tool's exact purpose and outputs (map1-map4, skeleton overlay). It distinguishes this from many other 'create_*' sibling tools by focusing on hand-to-Ableton mapping.

  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 ('Uses TDAbleton directly; AbletonMCP is not required') but does not explicitly state when not to use this tool or list alternatives. It implies usage for hand-to-Ableton control but lacks exclusion criteria.

  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/5.0
  Behavior4/5

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

  Annotations already mark this as a write and non-destructive operation. The description adds valuable context: it creates a 'deterministic scaffold', lists generated components (color_out, depth_preview, etc.), and states it 'returns warnings where sender-specific metric depth decoding must be validated live.' This goes beyond the annotations to set expectations about scaffold nature and validation needs.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 zero waste. Each sentence earns its place: first states purpose, second enumerates built components, third warns about validation. Information is front-loaded and scannable.

  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 10 parameters and no output schema, the description gives a solid overview of generated components and the scaffold's limitations. It does not cover prerequisites or error conditions in detail, but for a scaffold generation tool, the key aspects (what's built and validation warnings) are 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?

  Schema coverage is 100% with each parameter described. The description adds minimal param-specific value—it mentions 'optional point-cloud placeholder' which corresponds to create_pointcloud_stub, but the schema already names that. It does not explain parameter interactions or formats 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 uses a specific verb 'Create' and resource 'TouchDesigner scaffold for iPhone depth senders', listing concrete sender types (TDLidar, Record3D, generic NDI/OSC). It clearly distinguishes from sibling create_* tools by focusing on iPhone depth source scaffolds.

  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 iPhone depth source scaffolds but does not explicitly state when to use it over alternatives or exclude other depth cameras. Given many sibling tools for depth buses (e.g., create_realsense_depth_bus, create_azure_kinect_body_bus), explicit guidance on when not to use would strengthen this dimension.

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

• create_macroA
  4/5.0
  Behavior3/5

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

  The description adds behavioral context about remapping and response curves, but does not detail side effects, error conditions, or the creation process beyond what annotations already indicate (non-destructive write).

  Agents need to know what a tool does to the world before calling it. Descriptions 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 every word 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?

  The description covers the tool's behavior and parameters well, but lacks mention of the return value or output, which is not provided in 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?

  The description explains the conceptual purpose of targets' min/max and curve, adding meaningful context beyond the schema descriptions, which already cover all 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 macro knob that drives multiple parameters with remapping, using specific verbs and distinguishing it from sibling tools like create_modulators or 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 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 single fader controlling multiple parameters, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives despite many sibling tools.

  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/5.0
  Behavior4/5

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

  Annotations show readOnlyHint=false and destructiveHint=false, and openWorldHint=true, which are consistent with a tool that creates a new container. The description adds that it 'exposes live CameraZ / Speed / StepCount / Intensity / ColorA / ColorB controls and previews the output TOP', elaborating on the 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 two sentences with no wasted words. The first sentence clearly defines the tool's purpose and its relationship to a sibling, while the second lists scenes and controls, making it 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?

  Given the tool creates a container with many parameters, the description covers the core functionality, scenes, and live controls. It does not detail the output or container structure, but since there is no output schema, this is acceptable. The sibling list is large, but the description effectively positions this tool among them.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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, with each parameter already well-documented. The description adds minimal additional meaning (e.g., '3D complement' context, but no new parameter details), so it does not significantly improve upon 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 'instantiates a self-contained GLSL TOP raymarcher (volumetric / signed-distance-field)', specifies it as the '3D complement to create_shader_lib', and lists three distinct scenes. This distinguishes it from siblings like create_shader_lib and other 3D 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 mentions it is the '3D complement to create_shader_lib', providing some context on when to use this tool versus that sibling. However, it does not explicitly state when not to use it or compare it to other related tools (e.g., create_3d_scene, create_glsl_shader) among the many siblings, limiting its guidance for selection.

  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
  4/5.0
  Behavior3/5

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

  Annotations already indicate non-read-only (readOnlyHint=false), open-world (openWorldHint=true), and non-destructive (destructiveHint=false) behavior, so the description does not need to repeat those. It adds meaningful context by specifying the prerequisite staging and the exact graph structure. Yet it does not disclose potential failure modes (e.g., behavior if RayTK is not staged) or side effects beyond building the graph, so a middle score 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 long, with the first sentence delivering the complete action and component list, and the second giving the essential prerequisite. Every clause carries necessary information; there is no fluff or repetition. It is well-organized 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.

  Completeness4/5

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

  With 10 parameters and no output schema, the description does a good job of providing a clear mental model of the resulting graph and the one critical prerequisite. It could optionally mention what a successful return looks like or clarify 'copied masters' operationally, but given the rich schema and the non-destructive annotation, 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?

  The schema has 100% description coverage for all 10 parameters, so the baseline is 3. The description adds a high-level grouping of parameters (primary, secondary, material, lights, etc.) but does not provide per-parameter details beyond what the schema already offers. It satisfies the baseline without surpassing 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 explicitly states 'Build a RayTK SDF graph' and enumerates the exact constituent nodes (primary SDF, optional secondary, material, camera, light, renderer, Null TOP), making the tool's purpose and scope unambiguous. This clearly differentiates it from sibling tools like create_raytk_op, which likely creates a single RayTK operator, by specifying a multi-node graph assembly.

  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 stating the prerequisite: RayTK must be staged via 'manage_packages install raytk' and loaded from the staged .tox. It also implies the source materials are 'copied RayTK ROP masters.' However, it does not explicitly mention when to choose this tool over alternatives (e.g., create_raytk_scene), 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_sam2_segmentation_bridgeA
  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, so the description adds value by disclosing exactly what gets created (source input, mask receiver, mask_out, matte_out, preview_out) and explicitly noting that no model is bundled. This goes beyond the annotations, though it could further mention prerequisites like needing the external service to be running.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose. Each sentence adds necessary information (what it builds and what it creates/notes) 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 moderate complexity (9 params, 2 enums) and no output schema, the description covers the core purpose and created components, while the schema fully details parameters. It could be more complete by mentioning return behavior or preconditions, but it is sufficient for an agent to understand the tool's role and initiate a build.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 9 parameters are already documented with meaningful descriptions. The tool description adds no additional parameter-level semantics beyond the schema; it only lists output node names, which are not parameter meanings. 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 verb 'Build' and a well-defined resource: a TouchDesigner bridge surface for an external SAM2/FastSAM segmentation service. It enumerates the created nodes (source input, mask receiver, mask_out, matte_out, preview_out), which distinguishes it from sibling tools like setup_segmentation or connect_comfyui.

  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 via 'for an external SAM2/FastSAM segmentation service' but provides no explicit when-to-use or alternatives. It does not mention situations where this tool would be preferred over related sibling tools like create_ai_mirror or setup_segmentation.

  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/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false, indicating the tool modifies or creates but is non-destructive. The description adds context that it creates a self-contained GLSL TOP with live controls and preview, which aligns with annotations. However, it does not detail potential side effects (e.g., overwriting existing COMPs or node path 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.

  Conciseness5/5

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

  The description is two sentences, front-loading the core functionality and key features. Every sentence adds value, and no unnecessary details are included, making it efficient for an AI agent 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?

  Given the tool's complexity (14 parameters, no output schema, openWorldHint), the description covers the essential purpose and controls. It could mention potential constraints like TouchDesigner environment requirements or limitations on primitive count, but it is largely complete for decision-making.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 described in the input schema with defaults, types, and constraints. The description provides an overview of exposed controls but does not add significant meaning beyond what the schema already conveys, such as the purpose of each parameter or how they interact.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 programmable signed-distance-field raymarcher in TouchDesigner as a self-contained GLSL TOP, specifying composition of CSG trees with primitives and exposure of live controls. This distinctly differentiates it from sibling tools like create_raymarch_scene by focusing on SDF and CSG operations.

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

  Usage Guidelines3/5

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

  The description implies usage for creating SDF raymarchers but does not explicitly state when to use this tool versus alternatives like create_raymarch_scene or create_glsl_shader. No guidance is provided for prerequisites, dependencies, or exclusion conditions.

  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/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false. The description adds that it creates a new baseCOMP under parent_path, notes the approximate nature of the mask-to-SDF conversion, and lists exposed controls. No contradictions, and it provides useful behavioral context 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.

  Conciseness3/5

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

  The description is somewhat verbose, listing many controls and details that are already in the schema. It is front-loaded with the core purpose but could be more concise by reducing 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 (17 parameters, no output schema), the description covers purpose, technique, creation behavior, and return information (summary, JSON with paths, preview). It is sufficiently complete for an agent to understand 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 coverage is 100% (all 17 parameters have descriptions). The description adds a high-level summary of exposed controls but does not significantly enhance parameter understanding 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 raymarches a text string as an SDF 3D slab, and explicitly distinguishes it from similar tools create_sdf_field and create_text_3d, making the purpose specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description names two alternative tools (create_sdf_field, create_text_3d) and explains how this tool differs, providing clear context for when to use it. It does not explicitly state when not to use it, but the alternatives cover that.

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

• create_sidechain_pumpA
  4/5.0
  Behavior4/5

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

  Annotations already indicate non-destructive and open-world nature. The description adds details about the internal chain (Select, Lag, Limit, Null CHOPs) and error handling (per-target warnings, fatal only if source missing). 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.

  Conciseness3/5

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

  The description is informative but somewhat lengthy, with some redundancy relative to the schema descriptions. It is well-structured and front-loaded, but 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?

  Given the complexity (9 parameters, no output schema), the description effectively explains the internal chain, behavior, and typical usage. It covers error cases and experimental status, providing sufficient context for an AI 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 provides descriptions for all 9 parameters (100% coverage). The description adds some contextual guidance (e.g., rest_value typical usage) but does not significantly extend beyond 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 clearly states it is a one-call tool to build a sidechain ducking envelope, with a specific verb ('create') and resource ('sidechain pump container'). It explicitly distinguishes itself from create_envelope_follower, 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 provides context on when to use this tool (e.g., for multi-target pump with a single depth knob) and contrasts it with create_envelope_follower. However, it does not explicitly list scenarios where this 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_two_way_surfaceA
  4/5.0
  Behavior4/5

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

  Annotations (readOnlyHint=false, destructiveHint=false) indicate mutation but no destruction. The description adds rich behavioral details: Script CHOP gating, epsilon delta, rate limit, last_in cache, and exposed custom pars. 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 purpose, and each sentence adds essential information without redundancy. 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 complexity (9 params, nested array), the description covers the core mechanism, guard features, and custom pars. Lacks mention of error handling or default behavior, but is sufficient for an agent to understand usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 value by explaining the mapping concept (device address to TD parameter) and the guard mechanism, but does not go into per-parameter 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 it 'build a bidirectional OSC or MIDI control surface' with specific features like feedback guard. It distinguishes from siblings like 'create_control_surface' by emphasizing bidirectionality and oscillation guard.

  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 bidirectional control with oscillation guard is needed but does not explicitly state when to use this tool over alternatives like 'create_control_surface' or 'create_midi_map'. No exclusions or when-not-to-use guidance provided.

  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/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 description does not need to reiterate those. It adds context about container creation, live controls, and return values, but lacks details on side effects or dependencies beyond what annotations indicate.

  Agents need to know what a tool does to the world before calling it. Descriptions 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-loaded with the primary action, and includes all critical information without extraneous 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?

  Given the 9 parameters, full schema descriptions, and annotations, the description adequately covers the tool's purpose, usage, and output. Missing are potential side effects or performance notes, but overall it is complete enough 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 described in the schema. The description adds minimal extra meaning (e.g., 'exposed as a live control') but largely restates information 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 creates an analog video-synthesizer pattern as a GLSL TOP with live controls, listing three specific modes. It distinguishes itself from sibling tools create_shader_lib and create_video_player by explicitly naming them and describing their different purposes.

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

  Usage Guidelines4/5

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

  The description provides explicit guidance on when to use create_video_synth versus create_shader_lib and create_video_player, but does not cover exclusions like prerequisites or performance considerations.

  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
  Behavior4/5

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

  The description adds context beyond annotations by detailing what the diff includes (nodes, connections, parameters with before/after values) and reinforcing that it is read-only. 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 concise, consisting of three sentences that are front-loaded with purpose, usage example, and safety note. 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 nested objects and no output schema, the description adequately explains inputs and outputs. It could be improved by explicitly noting parameter diffs require include_params in snapshots, but this is implied in the input 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% with descriptions for both parameters. The tool description adds little beyond what the schema already provides, such as mentioning 'include_params' in the before parameter description, but this is covered in the schema notes. 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 it compares two network snapshots and returns a readable diff of nodes, connections, and parameter changes. However, it does not explicitly differentiate from sibling tools like snapshot_td_graph or compare_td_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 guidance on when to use the tool (before/after edits, versioning patches) and states it is pure analysis, indicating non-destructive use. It does not, however, list explicit alternatives or when not to use.

  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 provide readOnlyHint and destructiveHint, so the description adds value by explicitly stating 'without writing files or touching the TD bridge,' which reinforces the safe, non-destructive behavior. This addresses what the tool does not do, adding useful 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. It front-loads the key qualifier 'Read-only' and packs the core functionality concisely without extraneous words.

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

  Completeness4/5

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

  Given the tool has 9 parameters and an output schema, the description covers the essential purpose and safety profile. The output schema handles return values, so the description doesn't need to detail that. However, it could be slightly more comprehensive about prerequisites or edge cases, but it is sufficient for an AI 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?

  With high schema description coverage (78%), the baseline is 3. The description adds minimal parameter information beyond mentioning the 'ordered TouchDesigner operator chain' which maps to the required 'chain' parameter. Individual parameters like id, name, tags are not elaborated, but the schema already describes them adequately.

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

  Purpose5/5

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

  The description clearly states the tool converts an ordered TouchDesigner operator chain into a RecipeSchema draft, and explicitly notes it is read-only. The verb 'draft' and resource 'recipe from operator chain' are specific, and the read-only qualifier distinguishes it from sibling tools that may modify or suggest chains.

  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?

  While the description clarifies the tool is read-only and does not write files or touch the TD bridge, it does not explicitly guide when to use this tool versus alternatives like suggest_operator_chain or validate_operator_chain. The usage context is implied but lacks explicit when-not or alternative references.

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

• import_recipe_bundleA
  4/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds important behavioral context: validation before writing prevents corruption, and it explicitly states 'Writes files (destructive)'. This goes beyond annotations but could mention overwrite 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 sentences long, with the main action first. Every sentence adds value: purpose, inverse relationship, validation behavior, and destructiveness. No unnecessary words.

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

  Completeness3/5

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

  Given no output schema, the description does not explain return values. It covers input and validation but lacks detail on success/failure behavior and the overwrite parameter. Adequate but not comprehensive.

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

  Parameters2/5

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

  With 0% schema coverage, the description should compensate, but it only implicitly references two parameters (bundle_file, out_dir) and completely omits the 'overwrite' parameter. It does not describe parameter formats or constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 imports recipes from a JSON bundle into a directory, and specifies it is the inverse of export_recipe_bundle. The verb and resource are specific, and it distinguishes itself from related tools by mentioning the inverse relationship.

  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 mentions it is the inverse of export_recipe_bundle, providing a clear alternative. However, it does not compare to other importing tools like import_recipe_from_url or specify 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.

• notch_touchengine_bridgeA
  4/5.0
  Behavior4/5

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

  The description adds a valuable caveat beyond the annotations: 'This does not validate a Notch license or target runtime; live validation remains explicit.' This discloses a key behavioral limitation. The annotations already indicate a mutating operation (readOnlyHint=false) and non-destructive intent, and the description 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 two sentences, front-loaded with the primary purpose and followed by a precise caveat. Every sentence adds value, and there is 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 10-parameter schema with full descriptions and annotations covering mutation/non-destructiveness, the description is sufficient. It clarifies the scope ('guarded scaffold') and the validation limitation, but does not detail the 'guarded' mechanism or output behavior. Overall, this is adequate 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 the baseline is 3. The description does not add extra meaning to parameters beyond summarizing the scaffold features (notes, output, controls), which is already reflected in the schema properties. No additional parameter-level guidance is provided.

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

  Purpose5/5

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

  The description clearly states the tool's action ('Build a guarded Notch TOP or Engine COMP/TouchEngine bridge scaffold') with specific components (notes, output, optional play/speed controls). It distinguishes itself from potential siblings by specifying that it creates a scaffold and explicitly disclaims license/runtime validation.

  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 what it builds, but it does not explicitly state when to use this tool over alternatives like 'connect_touchengine_notch' or 'create_engine_comp'. No exclusionary guidance is provided, leaving the agent to infer from the scaffold-focused language.

  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/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true; description adds 'without touching TouchDesigner' and lists return items (upgrade boundaries, deltas, checklist). No contradictions. Describes 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?

  Two concise sentences, front-loaded with 'Read-only', no wasted words. Efficient and clear.

  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?

  Output schema covers return values; description explains inputs and outputs sufficiently. For a moderately complex tool (4 params), it provides enough context without being verbose.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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. Description does not add extra semantic meaning beyond what the schema 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?

  Clearly states it plans a TouchDesigner stable-version migration using offline release highlights, operator compatibility, and Python API. Distinct from siblings as no other migration planning tool exists.

  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?

  Indicates it plans a migration and is read-only, but does not explicitly state when to use vs alternatives or provide exclusion criteria. Could be improved with 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.

• qlab_osc_bridgeA
  4/5.0
  Behavior4/5

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

  The description adds details beyond the annotations: the exact OSC routes exposed and that QLab need not be running during build. It aligns with readOnlyHint=false and destructiveHint=false, and the additional context about build-time behavior is valuable. No contradiction detected.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose, and every clause adds value. It is succinct without sacrificing key 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 tool with no output schema, the description adequately explains the core purpose and important constraints (routes, port configurability, build-time behavior). However, it does not mention what the bridge looks like after creation or any runtime prerequisites, but the schema and annotations mitigate 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?

  All 6 parameters have full descriptions in the input schema (100% coverage). The description does not add any parameter-specific semantics, 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 the tool 'Create a QLab OSC control bridge' and lists specific exposed routes (/go, /stop, /panic, /pause, /resume, /reset, optional /cue/{number}/start). It distinguishes this from sibling tools by referencing the OSC router matrix primitive and the build-time 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 implies a usage context: building a control bridge for QLab, and notes that QLab doesn't need to be running during build. However, it does not explicitly mention when to use this tool versus alternatives like connect_qlab_cue_stack or osc_router_matrix, nor does it give 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.

• refresh_asset_previewsA
  4/5.0
  Behavior4/5

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

  Annotations already indicate destructive behavior (destructiveHint: true) and open-world effects (openWorldHint: true). The description adds value by specifying the prerequisite ('Requires a running TouchDesigner bridge'), the overwrite side effect, and the return format ('returns written previews plus per-target warnings'). 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 long, front-loaded with the action verb, and each sentence adds essential information. There is no redundant or vague language.

  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 (3 parameters, nested objects, no output schema), the description covers the use case, prerequisite, side effects, and return values. It could mention what happens if the bridge is not running or clarify the file path format, but it is largely 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%, so the schema fully documents the parameters. The description reiterates the structure 'targets as {node_path,file_path} plus optional width/height' but does not add new semantic information beyond what the schema 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 it captures previews from live TOP nodes and writes them to file paths. The verb 'capture' and resource 'preview PNG assets' are specific, and the context of refreshing thumbnails is explicit. However, it does not explicitly differentiate from sibling tools like 'get_preview' or 'capture_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?

  It provides a clear use case: 'regenerate stale thumbnails after a network changes'. This gives context on when to use the tool. It does not specify when not to use or list alternatives, which would elevate to a 5.

  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/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false, which align with the description's actions of building, adding, and creating components. The description details the behavior: it creates a deck, control surface, and midiinCHOP, and wires them together. It also explains default behavior for parameters. No annotation contradiction is present. However, it does not mention potential side effects like overwriting existing components with the same name.

  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 of approximately 120 words, which is concise given the complexity of the tool. It front-loads the core purpose and then details the components created. While it is relatively dense, it avoids unnecessary repetition. The structure is logical but could benefit from bullet points or clearer separation of 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?

  The tool has 8 parameters, no output schema, and good schema coverage. The description explains the orchestration of sub-tools but does not specify the return value (e.g., the path to the created container). Given the lack of output schema, this omission leaves the agent uncertain about what the tool produces. The description is otherwise complete in terms of what it does, but the absence of output information is a notable 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 100% coverage with descriptions for all 8 parameters. The tool's description adds context by explaining how parameters relate to the composite tool (e.g., 'Pass deck_a/deck_b source TOP paths (or omit for test sources)'). However, the schema itself is already detailed, so the description adds marginal value beyond summarizing relationships. It does not introduce new semantics not 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 starts with 'Compose a complete, playable VJ deck UI in one call', which clearly states the verb 'compose' and the resource 'VJ deck UI'. It distinguishes itself from the lower-level 'create_decks' primitive by explaining it wires multiple primitives into one container. The purpose is specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description explains the tool's role as a higher-level scaffold on top of 'create_decks', implying when to use it versus the underlying primitive. It details the components it builds (mixer, control surface, external I/O) and provides guidance on optional parameters like deck_a/b and midi_map. However, it does not explicitly list alternative tools or state when not to use this tool, missing some differentiation from sibling tools.

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

• score_buildA
  4/5.0
  Behavior4/5

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

  Adds meaningful context beyond annotations: describes read-only nature, optional LLM critique with failure-safe behavior, and that it composes existing endpoints. Annotations already provide safety profile, so the description complements without redundancy.

  Agents need to know what a tool does to the world before 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 core purpose, no filler. Each sentence adds value: purpose, return values, optional feature, and behavioral note.

  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 key aspects: read-only, scoring rubric, return sub-scores and suggestions, optional critique. With output schema present, return values need not be detailed. Minor gap: doesn't explain that scoring requires a built network, but this is implicit from 'score a built network'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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% description coverage, so baseline is 3. The description only mentions 'llmCritique' parameter in context; no additional semantic enrichment for other parameters like scopePath or criteria.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 scores a built network 0-100 on a fixed rubric, returning per-criterion sub-scores and improvement suggestions. Distinguishes from siblings by specifying read-only and composition of existing endpoints, avoiding confusion with creation tools like 'create_*' or analysis tools like 'analyze_project'.

  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 for scoring a built network with optional LLM critique, but does not explicitly state when to use this tool over alternatives or provide exclusions. The description lacks guidance on prerequisites or comparison to similar tools.

  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.0
  Behavior4/5

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

  The description explicitly states 'Read-only', consistent with annotations. It details the serialization scope (immediate children), parameter capture (mode+expression vs evaluated value), and return structure containing warnings and truncation flag. This adds behavioral context 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 concise (3 sentences) and front-loaded with 'Read-only'. Each sentence serves a distinct purpose: stating the action, detailing output, and suggesting use case. No redundant or extraneous information.

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

  Completeness4/5

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

  Given the presence of an output schema, the description need not detail every field. It covers key aspects: serialization of parameters with mode+expression, input wires by source node name, best-effort custom params, return structure including truncated and warnings. However, it does not address error handling or invalid paths.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 paraphrases the schema descriptions for path, max_nodes, and include_custom_params without adding significant new meaning. It adequately reinforces the purpose of each parameter.

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

  Purpose5/5

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

  The description clearly states the tool serializes a COMP's immediate children into a diffable JSON spec, specifying what is included (name, op type, parameters with mode+expression, input wires, position) and the round-trip pairing with rebuild_network. This distinguishes it from other similar 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 says to use it for snapshotting a network to diff or version control, and mentions rebuild_network as the counterpart. However, it does not explicitly contrast with other inspection tools like get_td_nodes or snapshot_td_graph, leaving some ambiguity about when to choose this over alternatives.

  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/5.0
  Behavior4/5

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

  The description discloses key behavioral aspects: loads MediaPipe ENGINE, starts timeline, builds Script CHOP, and connects to webcam. It mentions a prerequisite (install mediapipe-touchdesigner) and notes the output format. Annotations indicate readOnlyHint=false (modifies state) and openWorldHint=true (external I/O), which the description supports 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 dense paragraph that front-loads the core action and efficiently details the setup steps, output, and integration. 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.

  Completeness4/5

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

  For a setup tool with 3 optional parameters and no output schema, the description covers the main workflow, prerequisites, and output format. It lacks info on failure modes or idempotency if run multiple times, but overall is sufficiently complete given the tool's simplicity and annotation 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?

  The input schema has 100% coverage with descriptions for all three parameters (tox_path, parent_path, num_landmarks). The description adds minimal extra meaning beyond the schema, only contextualizing num_landmarks with iris tracking. Baseline 3 is appropriate given 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 it is a one-shot setup for face-landmark tracking from a webcam, specifying the verb (setup), resource (face tracking), and output (468/478-sample CHOP). It distinguishes from sibling tools like setup_body_tracking by focusing on face landmarks.

  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 face tracking and mentions integration with bind_to_channel and create_data_visualization, but does not explicitly state when to use this tool over alternatives like setup_hand_tracking or setup_body_tracking. No when-not-to-use guidance is provided.

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

• add_custom_parametersA
  4.1/5.0
  Behavior5/5

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

  The description provides rich behavioral detail beyond the annotations: it discloses transactional rollback, built-in protection, EXPORT being held with error, and EXPRESSION/BIND requiring specific settings. This significantly enhances the destructiveHint and openWorldHint annotations with concrete safety and failure semantics.

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

  Conciseness4/5

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

  The description is dense but efficient, with each sentence adding unique value about transactionality, types, restrictions, and rollback. It is slightly long but the complexity justifies the length. The main purpose is front-loaded, making the tool's role immediately clear.

  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 transactionality, restrictions, supported types, and failure behavior comprehensively, which is essential for a complex tool with 5 parameters and no output schema. It does not mention return values, but the operational focus makes this acceptable. Overall, it provides enough context 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?

  With 0% schema description coverage, the description partially compensates by listing supported parameter types and explaining modes like EXPRESSION, BIND, and EXPORT. However, it does not elaborate on comp_path, page, operations, or idempotency_key, relying on their self-explanatory names. This is adequate but not thorough.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: transactionally add, edit, delete, sort, and organize a COMP's custom parameters. This specific verb+resource combination distinguishes it from siblings like edit_td_node_metadata or set_parameters_batch, which focus on other parameter management tasks.

  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 managing custom parameters but does not explicitly state when to use this tool over alternatives. It mentions 'Legacy page+params calls remain valid' but does not contrast them with this route, and there is no explicit when-not guidance. Some context is given about restricted mode and required settings, but not enough to clearly guide tool selection.

  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?

  Annotations indicate it's not read-only, not destructive, and open-world. Description adds that failures become warnings (fail-forward) and partial chain returns useful info, which is beyond annotations. However, it does not detail all error behaviors.

  Agents need to know what a tool does to the world before 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 purpose. Every sentence adds value with no waste. Efficient structure.

  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?

  No output schema, description vaguely mentions 'useful info' but doesn't specify return structure. For a tool with nested ops array and partial success behavior, more detail on return format would improve 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?

  Schema coverage is 100%, baseline 3. Description adds meaning beyond schema: explains ops array wiring, parameter resolution (string matching op name resolves to path), and naming conventions. Adds substantial 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 it is a 'Declarative Layer-2 builder for an ordered CHOP processing chain,' using specific verb 'build' and resource 'CHOP chain'. It distinguishes from sibling tools like 'create_node_chain' by focusing on CHOPs and wiring pattern.

  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?

  Includes a usage tip about ending with nullCHOP for bind_to_channel readiness, but does not explicitly state when to use this tool versus alternatives like connect_nodes or create_node_chain. Context is implied but not fully specified.

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

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

  The description discloses the creation of a new baseCOMP, deterministic behavior per seed, the process of generating glyphs, and the return format. While it adds value beyond annotations (which indicate a non-read-only, non-destructive, open-world tool), it does not mention potential side effects or permissions.

  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 but is well-structured: it starts with the tool's purpose, explains the process, differentiates from siblings, and ends with output details. It is slightly verbose but conveys all necessary information 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?

  Given the tool's complexity (11 parameters, creates geometry), the description covers the creation process, output format, and sibling differentiation. It is mostly complete, though it could mention error handling or prerequisites for 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?

  All 11 parameters have descriptions in the schema (100% coverage), so the description only adds marginal context (e.g., listing exposed controls). Baseline score of 3 is appropriate as the description 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 generates 'a page of procedural asemic writing' with random glyph strokes, and explicitly distinguishes it from two sibling tools (create_growth_system and create_vector_lines).

  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 (generating asemic writing) and distinguishes it from two similar tools, but does not explicitly state when not to use it or list alternative tools beyond the two mentioned.

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

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

  Discloses that it creates internal components (Beat CHOP, CHOP Execute DAT) and reuses the cue_morph engine. No contradiction with annotations (readOnlyHint=false, destructiveHint=false). Adds context about quantize units and live controls.

  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?

  Description is a single, dense paragraph that efficiently conveys the core functionality. Could be more structured but remains concise and 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?

  Given the complexity of the tool and missing output schema, the description adequately explains the purpose and behavior. It mentions live controls and reuse of existing cues, though post-creation interaction could be more detailed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 100% of parameters with individual descriptions. The tool description adds high-level context but does not provide significant new insights 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 it builds a bar-quantized cue timeline using specific components (Beat CHOP, CHOP Execute DAT). It distinguishes itself from the sibling create_autopilot by emphasizing deterministic, musically-timed 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 prerequisite: store cues with manage_cue first. Contrasts with create_autopilot, giving context for when to use this tool. Could be more explicit about when not to use it, but the distinction is effective.

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

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

  Annotations are minimal (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds rich behavioral detail: it creates nodes under parent_path, seeds placeholder data, returns a summary with paths, errors, warnings, and preview. It warns about needing to wire real data and notes that graph/points styles render as texture strips with customization warnings.

  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 concise summary, then details the created nodes, usage tip, and return info. It is efficient with no wasted words, though slightly longer than strictly necessary.

  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, but the description explicitly lists return values. It covers what the tool creates, the pipeline, a usage reminder, and return structure. Minor gaps: doesn't specify behavior if parent_path is invalid or naming conflicts, but overall 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?

  Schema description coverage is 100%, so baseline is 3. The description adds architectural context (pipeline flow) but does not significantly expand on parameter-specific semantics beyond what the schema already provides (e.g., chart_style options are only mentioned in schema). Value added is 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 clearly states it builds a data-driven visualization with a specific node pipeline (data source, CHOP, chart TOP). It distinguishes from sibling create_* tools by specifying the data-visualization use case and the exact components created.

  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 building a data-driven chart) but does not provide explicit when-not-to-use guidance or mention alternatives among the many sibling creation tools. The context is clear but lacks exclusionary advice.

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

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

  The description discloses key behaviors: it creates a container, drops a TOX, wires the source, and exposes a depth Null TOP. It warns of a 30-60s first cook for engine compile. It lists return values. Annotations (destructiveHint: false, openWorldHint: true) are consistent with creating but not destroying. It could more explicitly state that it modifies the network by adding nodes, but overall transparency is good.

  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 the core action. It efficiently combines the technical concept, requirements, limitations, and output details in a few sentences. Each sentence adds value, though it could be slightly trimmed without losing 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?

  Given the tool's complexity (reliance on third-party TOX, CUDA, TensorRT) and lack of output schema, the description covers essential aspects: purpose, dependencies, first-cook delay, output paths, and integration with siblings. It lacks explicit error handling or TOX-not-found scenarios, but overall 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.

  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 each parameter's purpose, defaults, and constraints. The description adds value by explaining how outputs (especially depth_top_path) are used by sibling tools, but does not enrich parameter meanings beyond the schema. 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 purpose: converting any 2D image/video TOP into a depth map TOP using Depth Anything v2 via NVIDIA TensorRT/ONNX. It specifies the technique, dependencies, and distinguishes it from hardware-based depth solutions. The mention of sibling tools (create_depth_displacement, etc.) further clarifies its role in a pipeline.

  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: for depth map generation from 2D without requiring depth sensors. It outlines prerequisites (NVIDIA GPU, CUDA, TensorRT, manual installation of .tox) and explicitly states it is not supported on macOS. However, it does not explicitly contrast with alternative depth methods 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_ditherA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate the tool is constructive (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds behavioral details beyond annotations, such as creating a self-contained noise source without device permissions, exposing live-tweakable knobs (Mix, Threshold, Scale), and returning an inline preview image. 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.

  Conciseness4/5

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

  The description is 5 sentences, front-loaded with the main purpose and key features. It efficiently covers patterns, quantization, internal structure, and return values without redundancy. Minor room for improvement: could be more structured (e.g., list of features).

  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 and no output schema, the description adequately explains what the tool creates (baseCOMP with nodes) and returns (summary, node paths, controls, preview). It covers the main behavioral aspects and parameter effects, though a brief example of usage could improve 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?

  The input schema has 100% coverage for all 12 parameters. The description enhances understanding by grouping parameters (e.g., 'Mix, Threshold, and Scale knobs for live tweaking') and explaining effects (e.g., 'larger = chunkier dither' for scale). It also clarifies palette modes and patterns beyond enum values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 retro dither effect with specific patterns (Bayer, checker, noise, error-diffusion), quantization modes (mono, duotone, RGB), and internal components (baseCOMP, GLSL TOP, Null). This clearly distinguishes it from sibling tools 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 Guidelines3/5

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

  The description explains what the tool does but does not explicitly state when to use it versus alternative tools (e.g., create_kaleidoscope, create_halftone). The usage context is implied from the dither-specific details, but no when-not-to-use guidance is provided.

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

• create_dmx_fixture_pipelineA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate mutation (readOnlyHint=false) and open-world (openWorldHint=true). The description adds significant behavioral context: it creates multiple CHOPs, inserts pads, merges, and drives dmxoutCHOP. It also states the return (container + JSON report) and what is not auto-exposed. 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 moderately long but well-structured: starts with purpose, then step-by-step mechanics, and ends with return info and a usage tip. Every sentence contributes value, though some redundancy exists (e.g., 'Constant CHOP' repeated). It is front-loaded and clear, but not extremely concise.

  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 high schema coverage, annotations, and sibling tools, the description covers the tool's behavior, returns, and limitations. It mentions warnings and return report. It could elaborate on prerequisites (e.g., network interface for dmxout) or error handling, but overall comprehensive 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?

  Schema coverage is 100% with parameter descriptions. The description does not add new information about each parameter beyond what the schema provides (e.g., 'Base name for the container COMP' already in schema). However, the overall narrative helps understand parameter roles in the pipeline. At high 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 uses specific verbs and resources: 'Build a DMX/Art-Net output chain from a fixture list.' It details the process (creates Constant CHOPs, pads, merges, drives dmxoutCHOP) and distinguishes this tool from siblings by clearly outlining its unique pipeline construction. The tool name already hints at DMX fixture focus, and the description solidifies 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 implies when to use this tool (to build a DMX pipeline from fixture list) and provides useful guidance on what not to expect: 'Per-fixture sliders are NOT auto-exposed — bind individual channels later with bind_to_channel / animate_parameter.' This tells users they need additional steps, but it does not explicitly exclude scenarios or mention alternative tools. The context is clear but lacks explicit when-not-to-use.

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

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

  Description details what components are created (CHOP, Geometry COMP, etc.) and the automatic previz updates. Annotations already indicate non-readOnly and openWorld. Could be more explicit about side effects like overwriting, but 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?

  Description is long but front-loads core purpose and is well-structured with technical details, sibling comparison, and usage example. Some jargon density, but each sentence adds value.

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

  Completeness4/5

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

  Given 11 parameters and no output schema, the description provides a thorough walkthrough of the internal construction and behavior. It explains the previz mechanics and gives a binding example. Could mention what is returned or created, but overall complete for its 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%, so baseline 3. Description adds meaning by linking parameters like pan_range/tilt_range to expression mapping and mentioning dmxoutCHOP parameters (interface, universe, netaddress, rate) which correspond to net, universe, host, fps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 explicitly states it builds a moving-head rig with both DMX/Art-Net output and 3D previz. It clearly distinguishes from sibling create_dmx_fixture_pipeline (DMX-only). Verb and resource are specific.

  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 mentions the added 3D preview over the sibling tool, providing a clear when-to-use criterion. Also gives an example of later binding channels, but lacks explicit when-not-to-use or prerequisites.

  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?

  The description reveals key behaviors beyond annotations: it reads features, projects coordinates, builds a Script SOP, optionally extrudes using 'height' property, and wraps everything in a Geometry COMP with a camera+light Render TOP. It also notes OSM attribution requirements. No contradictions with annotations (readOnlyHint=false, destructiveHint=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.

  Conciseness4/5

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

  The description is a single paragraph that front-loads the main purpose and then details the process. It is informative without being verbose, though it could be more structured (e.g., separate sections). The OSM attribution note is included but does not detract from 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?

  With no output schema, the description provides sufficient context: input format, geometry support, projection, extrusion, and preview setup. It covers the main use case (city visualization) and legal considerations. Missing details like output appearance (3D city) are 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%, but the description adds meaning by explaining the projection process, how extrusion works (using 'height' property, default_height), and the geojson structure expectations. This adds value beyond the 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 clearly states the tool's purpose: 'Turn GeoJSON... into a 3D city visualization.' It specifies supported geometry types (Point, LineString, Polygon, Multi*), projection method (Mercator), extrusion capability, and preview setup (Geometry COMP + Render TOP). This distinguishes it from sibling tools like 'create_data_visualization' or 'create_3d_scene' by focusing on GeoJSON 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 implicitly indicates usage when you have GeoJSON data, but it lacks explicit guidance on when to use this tool versus alternatives (e.g., for non-geographic data or other 3D visualizations). No prerequisites 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.

• create_glitchA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds that it creates a new baseCOMP, uses a self-contained source if no input (no device permissions), exposes knobs, and returns a summary with JSON. This provides behavioral context beyond annotations, though it could mention error handling 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.

  Conciseness4/5

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

  The description is concise (3 sentences) and front-loaded with the main purpose. It efficiently covers the key aspects: what it builds, input sources, exposed controls, and return value. Some structure (e.g., bullet points) could improve readability, but it's not necessary.

  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 provides a solid overview: it explains the generated system, input options, knobs, and return format. It lacks details on error handling or default behavior when parent_path is invalid, but overall covers the essentials.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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, with each parameter already well-described. The tool description adds high-level context (e.g., Amount is master intensity) but does not significantly augment the parameter semantics beyond what the schema provides. 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 builds a glitch/corrupted-signal visual with specific techniques (RGB channel split, noise-driven displacement, horizontal band tearing). It lists the components created (baseCOMP, source, noise driver, Displace TOP, GLSL RGB-shift pass, Null output). This differentiates it from sibling tools like create_datamosh or create_displacement_warp.

  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 the tool (to create a glitch visual) and provides context on input options (existing TOP vs. self-contained source). However, it does not explicitly state when not to use it or mention alternatives among sibling tools.

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

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

  The description discloses that it creates helper nodes under parent_path and returns component/output paths and a created-node report. It lists debounced channels. Annotations (readOnlyHint=false, openWorldHint=true) align, and no contradiction. Could mention if nodes can be 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?

  The description is concise with three sentences, front-loading the main purpose, then detailing debounced channels and source options. 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?

  For a tool with 20 parameters and no output schema, the description covers overall purpose and source options but lacks details on the return value format and behavior of the created component. This leaves gaps for an agent to fully understand the tool's 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 description coverage is 100%, so baseline is 3. The description does not elaborate on individual parameters beyond the schema; it focuses on overall purpose and output channels, not adding significant 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 creates a TouchDesigner Base COMP converting hand landmarks into stable gesture-control Null CHOP. It specifies the purpose for palm holograms, lasers, audio controls, etc., distinguishing it from many sibling 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 Guidelines4/5

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

  The description provides clear guidance on when to use each source option (synthetic, mediapipe, existing_chop), suitable for different scenarios. However, it does not explicitly mention when not to use the tool or compare with sibling tools like create_hand_hologram.

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

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds value by detailing the tool's output (returns output/debug paths and explicit warnings about camera, blob tracking, and calibration states). It discloses behavior beyond annotations, such as handling fallback to synthetic sources, but does not cover auth needs or rate limits (likely not applicable). 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 is front-loaded with key information (purpose, defaults, outputs). It avoids wasted words, but structuring as bullet points or breaking into sections could improve scannability for a tool with 23 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 high parameter count (23) and no output schema, the description provides a good overview of what the tool does, its defaults, and what it returns (output/debug paths and warnings). However, it lacks explicit detail on the structure of the returned paths or how the warnings are formatted, which would help an agent fully understand 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 baseline is 3. The tool description provides a high-level summary of parameters (e.g., defaults for source, camera_index) but does not add significant meaning beyond the schema's own parameter descriptions. It lists components but not detailed 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 specifies that the tool builds a synthetic-safe interactive projection mapping rig with detailed components (frame-difference motion field, blob mask, visual TOPs, Corner Pin mapping) and states default behavior. It distinguishes from sibling tools like 'create_projection_mapping' by emphasizing interactivity and camera/synthetic inputs.

  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: defaults to 'camera' for installations and 'synthetic' for previews without camera permission. However, it does not explicitly state when to use this tool versus alternatives like 'create_motion_reactive' or 'create_blob_reactive', nor does it include 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_node_chainA
  4.1/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-destructiveness (destructiveHint false). The description adds valuable context: on failure, it stops and reports partial progress without deleting anything, which is not conveyed by annotations. This shows good behavioral transparency beyond 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: first sentence states core action and return value, second sentence explains failure behavior. No redundant words, essential information front-loaded. Excellent conciseness.

  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 covers return value ('all created paths') and partial failure behavior. With 3 parameters, no enums, no nested objects, the description is sufficiently complete for an AI agent to understand the tool's capabilities without ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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%; all parameters are described in the input schema. The description does not add new semantic information beyond what is already in the schema (e.g., 'Parent COMP' is explained, 'Ordered list' is explained, 'connect_sequentially' behavior is explained). Therefore, it meets the baseline but does not exceed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 creates multiple nodes and optionally connects them in sequence. It explicitly mentions returning all created paths and failure behavior, which distinguishes it from single-node creation tools like create_td_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 description implies usage for batch creation of connected nodes but does not explicitly state when to use this tool versus alternative tools like create_td_node (for single nodes) or connect_nodes (for existing nodes). No exclusion criteria or alternative suggestions are provided.

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

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

  Annotations already provide readOnlyHint=false and destructiveHint=false. The description adds value by detailing the FIFO queue, phrase-boundary firing, live controls, and output type, which go 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.

  Conciseness4/5

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

  The description is concise (about 5 sentences) and front-loads the purpose. It could be more structured with bullet points, but it is not 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 tool's complexity (queuing, phraselocking), the description covers the core algorithm, controls, and output. It lacks error conditions but is adequate 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?

  Schema coverage is 100%, so the baseline is 3. The description adds context about the engine's live controls but does not significantly enhance parameter understanding beyond the schema's thorough 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 'phrase-quantized cue-lock engine' for DJ/VJ, specifying the verb 'Build' and resource. It differentiates from siblings by mentioning pairing with create_tempo_sync, bind_to_channel, and manage_cue.

  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 the tool (for queuing pulse CHOPs and firing on phrase boundaries) and mentions two modes ('next' and 'aligned'). However, it does not explicitly list when not to use it or provide alternatives among siblings like create_cue_sequencer.

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

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

  Description discloses key behaviors: produces canonical and keypoints CHOPs, defaults to synthetic source for no-camera preview, supports switching to mediapipe/OSC/existing_chop, includes smoothing and mirror. Annotations already indicate non-read-only and non-destructive, and description adds valuable context 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 paragraph that front-loads purpose, explains outputs, source options, and next steps. It is slightly long but every sentence adds value; could be tightened slightly but overall 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 8 parameters and no output schema, the description covers most needed context: function, outputs, source modes, smoothing/mirror, and integration with sibling tools. It does not cover error conditions or prerequisites, but is sufficient for an open-world 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 baseline 3 is appropriate. The description reiterates source options and smoothing/mirror but does not add significant new information beyond 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 clearly states the tool sets up full-body pose tracking, specifies outputs (pose CHOP with 33 landmarks and keypoints CHOP), and distinguishes itself from siblings like create_pose_skeleton and create_body_reactive by positioning itself as the foundation.

  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 (foundation for body-reactive visuals, counterpart to extract_audio_features) and directs output to related tools (create_pose_skeleton, create_body_reactive). No explicit exclusions or when-not-to-use, but context is sufficient.

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

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

  Annotations indicate mutable and non-destructive. Description adds that it delegates to a built-in recipe, patches shaders, and warns that 'iterations>1' is unverified with effective value 1. This provides useful context 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?

  Single paragraph that is dense but clear. It front-loads the purpose and adds necessary details. Could be slightly more structured (e.g., bullet points), but overall efficient.

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

  Completeness4/5

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

  Given 9 parameters, no output schema, and many siblings, the description is fairly complete. It explains the process, limitations, output node, and control panel. Does not explain return values, but output is a node.

  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 parameter descriptions. Description adds value by explaining how parameters are used as GLSL uniforms and how palette presets work. It goes beyond schema by describing the patching mechanism.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 it builds a Gray-Scott reaction-diffusion GPU simulation as a visual system. It specifies the recipe, parameter overlay, shader patching, and optional color LUT. This differentiates it from sibling tools like 'create_fluid_sim' or 'create_growth_system'.

  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: use to create a reaction-diffusion visual system. No explicit when-not-to-use or alternatives among the many sibling tools. However, context signals show many similar 'create_*' tools, but no guidance on 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.1/5.0
  Behavior4/5

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

  Annotations include openWorldHint=true, so the description's mention of reusing manage_cue's storage adds valuable side-effect disclosure. It also details internal components (Timer-CHOP, Callbacks DAT, segment Table DAT). However, it doesn't fully describe all potential side effects (e.g., overwriting existing comps with the same name) or behavior under repeated calls, which the schema's reuse hint suggests.

  Agents need to know what a tool does to the world before calling it. Descriptions 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, each serving a clear purpose: defining the build, explaining its role in the system, and noting a critical dependency. It is front-loaded with the primary function and avoids any filler or repetition.

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

  Completeness3/5

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

  The description covers the tool's purpose and key behavior, but lacks details about output (e.g., what the tool returns, likely the COMP path), limitations (e.g., number of timers, parent path restrictions), and idempotency considerations hinted by the schema's reuse note. These gaps leave an agent with incomplete knowledge for successful 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?

  With 100% schema coverage, each parameter already has a description. The tool description does not add new information about individual parameters beyond what the schema provides. While it reinforces the dependency on manage_cue, it does not explain parameter interplay or constraints beyond the schema's 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 it builds a Timer-CHOP scheduler COMP with named timers, segments, and callbacks. It explicitly differentiates itself from create_scene_timeline by calling itself an 'atomic timer primitive' that higher-level automation rides on, making its specific role clear 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 usage context by stating it is an atomic primitive for create_scene_timeline and other automation, suggesting it's for building low-level timers rather than high-level timelines. It also mentions the dependency on manage_cue for the 'cue' action, guiding the agent to use manage_cue first. However, it lacks explicit when-not-to-use or alternative recommendations.

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

• create_simulationA
  4.1/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 correctly indicates a creation operation without destructive side effects. It elaborates on simulation behaviors (e.g., 'feedback loop displaced by an evolving noise flow field') but does not detail state changes or side effects beyond 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 two sentences with no fluff, front-loading the purpose and efficiently conveying simulation types and usage alternatives.

  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 fails to specify what is returned or created (e.g., a self-contained component). Given no output schema and 5 optional parameters, it could better explain the outcome and parameter effects, leaving some ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 5 parameters have schema descriptions, covering 100% of the schema. The description adds context about the Decay knob but does not significantly enrich parameter semantics beyond the schema, meeting 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 specifies that the tool builds a GPU simulation and lists three distinct types (reaction_diffusion, slime, fluid) with brief behavioral explanations for each. It distinguishes itself from the sibling tool create_generative_art by targeting specific simulation scenarios.

  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 directs users to create_generative_art for more procedural techniques, providing clear context for when not to use this tool. However, it does not offer explicit guidance on when to choose each simulation type, though the type descriptions partially compensate.

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

• create_test_patternA
  4.1/5.0
  Behavior4/5

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

  The description explains that the shader is baked into the payload with no external dependencies, and the output is a stable handle (Null TOP). Annotations indicate non-destructive, open-world behavior, and the description aligns with that, adding useful 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 paragraph with concise, information-rich sentences. It front-loads the purpose and then details internals and usage. While dense, it avoids verbosity.

  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 10 parameters and no output schema, the description adequately explains what is built and its intended applications. It provides enough context for an agent to understand the tool's role.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 are described in the input schema, providing full coverage. The description reiterates that parameters are configurable but adds no new meaning beyond the schema, so 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's purpose: generating a projector calibration/alignment source with a test-pattern network. It specifies the internal structure (baseCOMP with GLSL TOP and Null TOP) and distinct use cases, setting it apart from general 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 explicitly mentions when to use the tool: as a routing source during projector alignment, LED mapping calibration, or camera registration. However, it does not provide exclusions or compare with alternatives.

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

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

  Annotations provide readOnlyHint and openWorldHint. Description adds significant behavioral context: the lossy split on tabs/newlines for cells, and the return structure (total row/col counts, header, sliced page, preview_rows, row_range). 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.

  Conciseness4/5

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

  Description is informative but slightly verbose. Front-loaded with core purpose. Could be tightened but still efficient.

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

  Completeness4/5

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

  Given no output schema, the description explains return values clearly and includes the important caveat about lossy splitting. Covers pagination behavior and preview feature well.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 well-documented. Description adds minor context (e.g., preview_rows provides a 'stable head preview'), but most parameter meaning is already clear from 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?

  Clearly states 'Read a Text or Table DAT with pagination', specifying the verb (Read), resource (DAT content), and key feature (pagination). Distinguishes from sibling write tools edit_dat_content and set_dat_content.

  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 mentions when to use pagination ('so a large table cannot flood context') and directs to write tools for writing. Does not explicitly state when not to use this tool, but context is clear.

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

• manage_annotationA
  4.1/5.0
  Behavior4/5

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

  The description adds behavioral transparency beyond the annotations by calling the edit action 'structured, verified' and noting it works with raw Python disabled. This gives useful context about safety and constraints, though it does not disclose potential side effects like overwriting existing comments or coordinate validation.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose and a semicolon-separated enumeration of all actions. It is dense without being verbose, and the second sentence adds meaningful constraint context without waste.

  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 multi-action complexity and the absence of an output schema, the description omits return behavior for 'list' and 'enclosed' and does not explicitly map actions to required parameter sets. The schema partially compensates with per-parameter action tags, but the lack of output information is a notable gap 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 input schema already provides 100% descriptive coverage for all 12 parameters, including which action each applies to and value constraints. The description's mention of 'RGBA background' and 'exact node-space bounds' merely echoes the schema, adding no new semantic 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 clear purpose ('Self-document a network') and enumerates five specific actions: create, edit, set comment, list, and inspect enclosure. This makes the tool's scope concrete and distinguishes it from sibling tools like create_td_node or document_network, which focus on other aspects.

  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—whenever annotations, comments, or geometric enclosure inspection are needed—but does not explicitly name alternative tools or state 'use this instead of X'. The note about edit working with raw Python disabled provides a usage condition but no 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.

• manage_cueA
  4.1/5.0
  Behavior4/5

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

  Annotations indicate non-readonly and non-destructive behavior. The description adds valuable context: morph crossfades over N seconds, quantize defers to musical boundaries, and changes are scheduled non-blocking. This information goes beyond annotations and aids agent understanding.

  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. It includes necessary information but lacks structuring (e.g., bullet points). It front-loads the core purpose but could be more succinct and organized for quick parsing.

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

  Completeness3/5

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

  No output schema is provided, so the description should cover return values. It explains morph and recall behavior well but does not specify what 'list' or 'delete' returns or details about error conditions. For a complex tool with multiple actions, it is fairly complete but has 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 description coverage is 100%, so baseline is 3. The description adds meaningful extra context, especially for quantize (explains musical boundary deferral) and morph (crossfade behavior). This enriches understanding 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 states the tool is a live-performance scene system for managing cues with specific actions (store, recall, morph, list, delete). It distinguishes itself from the sibling 'manage_presets' by highlighting the timed morph feature, providing clear purpose and differentiation.

  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 comparing to manage_presets and explaining when to use morph versus recall, including the optional quantize parameter for musical timing. It doesn't explicitly list when not to use other sibling tools, but the differentiation is clear.

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

• watch_nodeA
  4.1/5.0
  Behavior4/5

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

  Adds context beyond annotations by specifying it is read-only and handles missing attributes as warnings. Describes return structure with explicit fields, but does not detail every behavioral aspect.

  Agents need to know what a tool does to the world before 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 fluff. Front-loaded with 'Read-only' and action verb. Efficiently communicates purpose, behavior, and output format.

  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 high schema coverage, annotations, and output schema described, the description is complete. It explains the output structure and handles edge cases (missing attributes). No gaps identified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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. Description does not add specific parameter semantics beyond what schema provides, though it implies usage of parameters like path, samples, interval.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 samples a TouchDesigner operator over a short interval to return runtime state, parameter values, and CHOP channels. Differentiates from sibling creation/effect tools by being a read-only monitoring 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?

  Implies usage for sampling runtime state but does not explicitly guide when to use versus similar tools like 'get_node_state_runtime'. No exclusion criteria or alternative recommendations.

  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.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), the description discloses two critical behavioral prerequisites: TDMCP_RAW_PYTHON=on and TDMCP_BRIDGE_ALLOW_EXEC=1. This adds valuable execution-security context not present in annotations. It does not 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?

  Three sentences, front-loaded with the core action, with no wasted words. It efficiently conveys the operation, requirements, and 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?

  For a build tool with no output schema, the description covers the essential operational context: what it builds, what inputs it needs, and environment requirements. It omits return value details and side effects on existing network state, but given the medium 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 the input schema already explains all parameters. The description adds the qualifier 'pre-translated' and outlines the mapping contents (fragment + uniforms + channels + controls), but this adds marginal value over the schema's 'Pre-built mapping' description. 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 uses a specific verb ('Build') and resource ('self-contained GLSL TOP network') with a precise input ('pre-translated mapping'), making the tool's function immediately clear. It also distinguishes itself from sibling import tools by identifying as the 'foundation primitive' used by Shadertoy and ISF importers.

  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 underlying primitive for Shadertoy/ISF importers and is intended for power users with hand-translated fragments. It implies when to use directly versus through importers, though it does not explicitly name alternatives or exclude other tools.

  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?

  Beyond the annotations, the description adds meaningful behavioral context: it is 'offline-safe', does not rely on the Blackmagic SDK, and builds an OSC matrix specifically for cut/auto/FTB and program/preview control. This helps the agent understand side effects and external dependencies. It does not 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 two sentences and front-loads the primary purpose. Every clause adds value: routing method, SDK disclaimer, offline-safety, and the specific control functions. There is no filler or redundant repetition of the tool name or schema.

  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 six parameters and no output schema, the description gives sufficient context for selection and invocation: it explains what is built, how it is built, and what functions it exposes. It could be slightly more explicit about return values or the created component's location, but the schema covers the parent_path parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 meaningful descriptions. The tool description adds high-level purpose but does not add per-parameter semantics beyond what the schema provides. This 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 uses a specific verb ('Create an OSC control preset') and clearly identifies the resource (ATEM switcher) and routing mechanism (atemOSC, Companion, or similar relay). It explicitly distinguishes itself from direct SDK usage by stating 'This does not use the Blackmagic SDK directly', which separates it from sibling tools like connect_blackmagic_atem.

  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 an offline-safe OSC-based control matrix for an ATEM switcher via a relay. It also gives an implicit when-not by stating it does not use the Blackmagic SDK directly, but it does not explicitly name an alternative tool for direct SDK scenarios, 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.

• author_script_operatorA
  4.2/5.0
  Behavior4/5

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

  Annotations already convey that this is a write/creation operation (readOnly=false, destructiveHint=true). The description adds substantial context beyond that: creates companion callbacks DAT, appends custom params based on type, returns a specific dictionary, requires environment variables, and notes the non-cooking behavior when nothing requests the op. It does not explicitly mention overwrite conflicts, but the added 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?

  Three well-organized sentences: front-loaded purpose, then mechanism, return value, prerequisites, and a practical cooking caveat. Every sentence contributes meaningful information with no filler, 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?

  Covers purpose, mechanism, return structure (explicitly lists keys), environment requirements, and a common behavioral pitfall. No output schema exists, so the return dict mention helps. Lacks details on what happens if an existing op has the same name (destructive potential), but overall the description is 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?

  Schema description coverage is 100%, with each parameter already explained in detail (e.g., family selects operator type and stub signature, custom_params type inference). The description largely mirrors schema information, adding only minimal extra context such as the per-family stub names (chan/row/point/numpy). Baseline 3 is appropriate because 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 uses a specific verb ('Scaffold') with a clear resource ('Script CHOP/DAT/SOP/TOP') and detailed outcome (onCook stub, custom parameters, companion callbacks DAT). It distinguishes from sibling tools like create_python_script and add_custom_parameters by its focus on the full Script op scaffolding 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?

  Provides clear context: when to use it (scaffolding a Script op with optional custom parameters and stub generation). Also states critical prerequisites (TDMCP_RAW_PYTHON=on, TDMCP_BRIDGE_ALLOW_EXEC=1) and a behavioral caveat about cooking. However, it does not explicitly name alternatives or conditions where another tool should be used instead, so it misses 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.

• auto_ui_from_paramsA
  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, and the description adds meaningful behavioral detail: it reads source_path, infers slider/toggle/text controls, appends them as custom parameters on comp_path, and optionally binds each control back to the source parameter. This goes beyond the annotations by explaining the side effects and flow, although it does not discuss failure modes or edge cases like existing custom parameter collisions.

  Agents need to know what a tool does to the world before 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 compact sentences front-load the primary purpose, then outline the mechanism and the intended use case. Every sentence contributes without repetition 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 7-parameter schema with full descriptions and no output schema, the description effectively explains the core workflow and when to use it. It could mention what happens if 'parameters' limits the list or how max_controls interacts with inference, but those are already in the schema, so the description is sufficiently complete for practical 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?

  The input schema already covers all 7 parameters with descriptions (100% coverage), so the baseline is 3. The description adds some relationship context (e.g., comp_path defaults to source_path, controls are inferred from primitive parameters) but does not significantly deepen 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 starts with a specific verb and resource: 'Generate a performable control panel from an existing node/COMP's primitive parameters.' It clearly distinguishes this from siblings like add_custom_parameters by focusing on the infer-and-append workflow and the optional 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 explicit context: 'Use when a generated component has useful parameters but no playable UI yet.' It does not name alternatives or exclusions, but the use case is clear enough to guide selection among the large sibling set.

  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 indicate a non-read-only, non-destructive, open-world operation. The description adds specific behavioral context: it creates a scaffold with listed components, uses a fallback primitive when no path is given, and warns when a .blend may need export. 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?

  Two sentences, front-loaded with purpose, listing components and supported formats without redundancy. 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?

  Given the tool's complexity (11 params, no output schema), the description explains the scaffold, fallback behavior, and format support, and includes a warning about .blend export. It doesn't need to detail return values since there is no output schema. It leaves some ambiguity about how the scaffold integrates with the existing network, but openWorldHint and the reference to parent_path in schema cover that.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 11 parameters have schema descriptions covering 100%, so the schema carries the parameter semantics. The tool description doesn't elaborate on individual parameters but provides broader context about formats and fallback, which is consistent with 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 a specific action ('Create a self-contained TouchDesigner render scaffold') with a defined scope (Blender scene or Blender-exported asset) and enumerates the produced components (File In SOP, Geometry COMP, PBR material, lights, Camera, Render TOP, Null TOP). It distinguishes itself from generic import/model tools by focusing on Blender-specific assets and including a warning about .blend export.

  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: it is for Blender scenes/exported assets and creates a full render scaffold. It mentions supported formats and warns about potential need to export .blend first, which acts as a prerequisite. It doesn't name alternative tools or explicitly say 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.

• browse_libraryA
  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 adds context: it is a read-only discovery step and returns matching recipes/packages for selection. 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?

  Two sentences with no unnecessary words. Information is front-loaded and 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?

  With output schema present and strong annotations, the description adequately covers the tool's purpose, workflow, and return values. No missing critical information.

  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%, but the description hints at the purpose of include_recipes and include_packages. However, tags, query, and package_dir are not explained beyond their names, leaving 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 verb 'browse', the resources (recipes and packages), and the context (read-only discovery step). It distinguishes from siblings like apply_recipe and install_library_package.

  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 says when to use: before instantiating a recipe or installing a package. It does not mention when not to use, but the context is clear given sibling names.

  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 readOnlyHint=false and destructiveHint=false, and the description adds behavioral specifics: it creates a synchronized container with deterministic layout and binds Play/Loop/Speed controls across both lanes. This goes beyond the annotations by describing what the created structure includes, which is useful context 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 two sentences, front-loaded with the main action, and every clause adds meaningful detail (structure, optionality, determinism, controls, use-case). No filler or redundant 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 9-parameter creation tool with no output schema, the description adequately sets expectations by describing the created structure (video lane, audio lane, Null outputs, controls) and the deterministic layout. It doesn't describe return values, but that is not essential for a creation tool. A small gap is lack of mention of error conditions or prerequisites, but overall it is complete enough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 meaning by referencing the Play/Loop/Speed controls and optional Audio File In CHOP lane, which map to parameters like loop, speed, autoplay, and include_audio. However, it doesn't provide substantial additional semantics 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 clearly states the tool's purpose with a specific verb ('Create') and resource ('synchronized clip transport container'), and enumerates its components (Movie File In TOP video lane, optional Audio File In CHOP lane, Null outputs, controls). It explicitly positions the tool as a reusable building block before clip launchers, VJ decks, or stream/output chains, 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 Guidelines4/5

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

  The description provides explicit usage context: 'Use it as a reusable building block before clip launchers, VJ decks, or stream/output chains.' This clearly indicates when to use this tool in relation to higher-level alternatives. It doesn't explicitly say when not to use it, but the relationship to alternatives is clear, which is strong guidance.

  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?

  Annotations already indicate non-destructive and open-world behavior. The description adds transparency by detailing the two execution paths (LLM or grammar parser) and the chaining capability, which are not evident 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 extremely concise with two sentences that front-load the purpose and provide key behavioral details. Every word is necessary, and no information is redundant.

  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 main purpose and execution modes. However, it could be more complete by explaining what 'validated' entails or how errors are handled, but the essentials are present.

  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 description adds value by explaining how parameters like 'apply' and 'containerName' relate to chaining into create_cue_sequencer, providing context 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 clearly states the tool's function: converting natural language to a validated cue list (SetlistSchema variant). It distinguishes itself from siblings by mentioning the optional chaining into create_cue_sequencer and specifying the use of LLM or grammar parser.

  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 cue lists from descriptions, but lacks explicit guidance on when to use this tool versus alternatives like create_cue_sequencer or create_setlist_runner. It mentions the chaining option but doesn't specify conditions for preferring the LLM over the grammar parser.

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

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

  The description adds valuable behavioral details, notably that the OBS password is passed only to the bridge payload and redacted from all returned reports, which is a meaningful security behavior. It also mentions optional publishing paths. Annotations already indicate a non-read-only, non-destructive open-world creation, so the bar is lower and these additions are appreciated.

  Agents need to know what a tool does to the world before 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 packs in the core action and components; the second clarifies security handling. Every clause earns its place, making the description appropriately sized 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 9-parameter creation tool with no output schema, the description gives a solid overview of what is produced (scaffold, DATs, templates) and the optional output mode. It lacks explicit explanation of the scaffold concept or runtime prerequisites, but the schema covers parameter details, so 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 every parameter having a description, so the baseline is 3. The description's mention of the password being optional and redacted adds a small bit beyond the schema, but overall it does not significantly enrich 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 creates a TouchDesigner-side OBS control scaffold with specific components (obs-websocket v5 request templates, status/setup DATs, optional NDI/Syphon/Spout publishing). This distinguishes it from sibling tools like obs_stream_control by focusing on scaffold creation and setup.

  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 when needing to set up OBS recording integration within TouchDesigner, providing clear context on what the tool does. However, it does not explicitly state when to use this over alternatives like obs_stream_control or connect_vmix_production, nor does it provide exclusion criteria.

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

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

  Annotations indicate non-read-only and non-destructive. The description adds important behavioral context: it returns state after action (allowing confirmation) and includes a critical note about pausing freezing downstream chains. This extends beyond annotations, though more detail on side effects (e.g., impact on other timelines) could improve 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 (2 sentences plus note) with no redundant information. It front-loads the primary purpose and ends with a critical behavioral note. Every sentence adds value, 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.

  Completeness4/5

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

  For a tool with 4 parameters and no output schema, the description covers the essential actions, side effects, and return value. It lacks detail on the exact format of the returned timeline state, but the note about pausing and the action list make it functionally complete. Slight improvement could mention required parameters for seek/cue.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 well-documented. The description adds context about the return value but doesn't elaborate on parameter meanings beyond what the schema provides. Baseline 3 is appropriate given full schema coverage and marginal added 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 tool's purpose: drive the TouchDesigner timeline with verbs like play, pause, seek, cue, and rate. It differentiates from siblings by covering all transport actions in one tool, while siblings like create_scene_timeline or manage_cue handle creation or cue management.

  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 listing the actions and noting that it returns timeline state for verification. While it doesn't explicitly exclude alternatives, the scope is well-defined and the note about pausing freezing downstream chains helps with proper usage. No explicit when-not, but sufficient for most cases.

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

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

  Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are consistent with the description's creation behavior. The description adds valuable behavioral context: it creates multiple named TOPs (resolutionTOP, textTOP, glslTOP, nullTOP) inside a new baseCOMP. This goes beyond the annotations by detailing what is produced, though it could mention side effects on existing nodes.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 in three sentences that front-load the main verb and resource. Every sentence carries essential information: purpose, process, mode options, default style, and outputs. 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 11 parameters and no output schema, the description adequately covers the tool's workflow: input source, grid conversion, color modes, and created outputs. It even notes a fallback source for privacy. However, it omits potential error states (e.g., invalid source path) and assumes familiarity with TOP, COMP terminology.

  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 enhances meaning by explaining the overall process (e.g., 'quantise input luminance into a grid') and contextualizing parameters like charset ('Dark→light glyph ramp') and color_mode ('mono', 'source-color', etc.). This adds value beyond 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?

  The description clearly states the tool's core function: 'Turn any TOP into a character-grid ASCII render'. It explains the quantization and lookup process, and distinguishes this from other creation tools by detailing specific outputs and modes. The verb 'create' matches the tool name and effectively communicates the action.

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

  Usage Guidelines3/5

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

  The description does not explicitly compare this tool to alternatives or state when to avoid it. It mentions a default aesthetic ('Phosphor-green default for the Severance / CRT terminal look') which implies a use case, but lacks direct guidance on choosing this over the many sibling create_* tools.

  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.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. The description adds value by stating it is 'pure parameter binding' (not destructive), 'idempotent and composable', and that it 'creates no operators'. This enriches the behavioral profile beyond the annotations alone. 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?

  The description is three sentences with no wasted words. The first sentence front-loads the primary action and resource, followed by concise clarification of traits (no operator creation, idempotent, composable).

  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 (4 parameters, no output schema) and the richness of the input schema, the description sufficiently covers the purpose and key behavioral traits. It could mention error handling or prerequisites, but the schema already enforces constraints and 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 coverage is 100% and the input schema provides detailed descriptions for each parameter. The description does not add additional parameter-level meaning, so it meets the baseline of 3 without extra credit.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 clearly identifies the resource ('seq.vec uniform slots of an existing glslTOP') and the goal ('drive shader uniforms every cook'). It distinguishes itself from sibling tools by stating it creates no operators and is pure parameter binding, and explicitly mentions composability with 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 Guidelines4/5

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

  The description implies when to use this tool (to bind audio channels to GLSL uniforms) and explicitly names a complementary tool (create_glsl_shader). However, it does not provide explicit exclusions or alternative tools for different scenarios, leaving some ambiguity among the many binding-related siblings.

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

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

  Annotations indicate readOnly=false, destructive=false, openWorldHint=true, and the description adds context by describing the creation process, output format (summary + JSON with paths and preview), and that it uses synthetic pose by default. 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 dense paragraph that front-loads the purpose and details. It is informative but could benefit from structured bullets for sources and styles. No wasted sentences.

  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, multiple sources, and styles, the description covers all key aspects: purpose, components, source options, styles, output format, and even mentions the sibling tool. It is fully sufficient for an AI 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?

  Parameter coverage is 100% in the input schema, so the description adds limited new information about parameters. It groups them in context but does not significantly enhance agent 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 it builds a body-reactive visual using full-body pose tracking, creating a baseCOMP with specific components. It distinguishes itself from the sibling create_audio_reactive as its visual counterpart for the body.

  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 synthetic vs. real sources and mentions it is the visual counterpart of create_audio_reactive. However, it does not explicitly state when not to use it or compare to other similar creation tools like create_pose_reactive.

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

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

  Annotations provide minimal info (no readOnly/destructive hints). The description adds significant behavioral context: protocol selection logic, anti-feedback wiring, platform-gated behavior, and the unverified-live nature. This goes well beyond the structured data.

  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 with clear sections and front-loaded purpose. It could be slightly more concise, but 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?

  Despite no output schema, the description comprehensively explains the tool's behavior, including anti-feedback, platform requirements, and relationship to sibling tools. It provides sufficient context for proper usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 substantial meaning beyond the schema's parameter descriptions, though it provides helpful context about protocol and direction 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 specific verbs ('Build', 'receive', 'publish') and resources ('bidirectional inter-app video bridge', 'receiver TOP', 'publisher TOP'). It clearly distinguishes from siblings by naming create_live_source (in) and setup_output (out) 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 Guidelines4/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 (combined in+out version of create_live_source and setup_output) and provides context on platform-gating and anti-feedback. However, it does not explicitly state when not to use it or provide exclusions.

  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 declare readOnlyHint=false and destructiveHint=false, setting the safety profile. The description adds valuable behavioral context by specifying that it will infer primitive controls, bind custom parameters, create a playable panel, and optionally append a read-only preflight report. 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: the first packs the entire pipeline into a clear action list, and the second defines the exact use case. Every word earns its place; 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 12-parameter builder tool with no output schema, the description adequately frames the workflow and purpose. The rich schema covers parameters, and the description supplies the missing context around 'companion surface' and when to use it. It does not explain return values or error cases, but these are not required given the lack of 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%, so the baseline is 3. The description adds high-level context about why parameters exist (inference, binding, hiding/limiting) 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 uses a specific verb and resource: 'Build a companion performance surface for an existing node/COMP' and enumerates concrete sub-actions (infer parameters, add bound custom parameters, create fader/cue panel, optionally append preflight report). This clearly distinguishes it from sibling tools like 'connect_companion_surface' and '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: '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 mention when not to use it or name specific alternatives, 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_decksA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds significant behavioral context: it creates a mixer with specific internal nodes (Select TOP, Cross TOP, Switch TOP, etc.) and outputs a Null. It does not contradict annotations. The description enriches understanding 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 paragraph that is detailed but efficient. It front-loads the purpose and then explains modes. While it could be slightly more structured (e.g., separated paragraphs for modes), it is concise and every sentence adds value. Score 4 for good but not perfect conciseness.

  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, no output schema, and annotations, the description covers both modes, internal architecture, and output behavior ('Output is a Null ready for post-processing or setup_output'). It fully explains the tool's behavior and results, making it contextually 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 detailed parameter descriptions. The description adds minimal new parameter semantics beyond summarizing the overall workflow. It helps contextualize parameters like decks and crossfade but does not provide extra schema-level details. 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 builds a DJ-style VJ mixer, distinguishing between legacy A/B cross mixer and N-deck mixer with 2-8 decks. The verb 'Build' and resource 'DJ-style VJ mixer' are specific, and it differentiates from sibling create tools by specifying the internal architecture and mode switching.

  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 two usage modes: without decks[] (legacy A/B) and with decks[] (N-deck mixer). It implies when to use each mode but does not explicitly state when not to use or provide alternatives. Given the sibling tools are numerous, a clearer exclusion would improve this score.

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

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

  The description adds behavioral traits beyond annotations: 'no CUDA requirement,' auto-reconnect interval for websocket, and the output contract (presence, count, bboxes). Annotations only provide readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the description fills in important 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 three sentences, well-structured, and front-loaded with the main purpose. It includes a parenthetical note about inspiration but 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 8 parameters, two backends, and no output schema, the description is complete. It explains the output format, backend differences, and key constraints (no CUDA, auto-reconnect).

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 minimal extra meaning beyond the schema, summarizing the output structure and backend choice but not providing new parameter-specific 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's purpose: 'Turn object/person detection into TouchDesigner control channels — with NO CUDA requirement.' It distinguishes between two backends and describes the output format, making it unambiguous. The title 'Create object/person detection → parameters' reinforces this.

  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 backend: 'websocket' for external detectors, 'onnx' for CPU inference. It implies context but does not explicitly exclude alternatives or mention when not to use this tool compared 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_engine_compA
  4.2/5.0
  Behavior5/5

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

  Annotations only provide readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds significant behavioral traits: subprocess creation, crash domain, optional GPU thread, guarded parameters with hasattr, and warning about multi-second first cook. 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.

  Conciseness3/5

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

  The description is informative but somewhat lengthy with multiple sentences. It is front-loaded with the main purpose, but some technical details (e.g., hasattr guard) could be condensed without losing 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 tool with 6 parameters and no output schema, the description covers creation behavior, subprocess details, guard mechanisms, and sibling relationship. It does not explain error conditions beyond the hasattr warning, but overall it is fairly complete given the 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 provides context about the reload pulse, perform-mode override, and color-map toggle but does not add significant semantic meaning beyond what the schema already describes for each parameter.

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

  Purpose5/5

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

  The description clearly states the tool creates a TouchDesigner Engine COMP that loads an external .tox in a separate subprocess, specifying the resource and action. It distinguishes from siblings by noting it complements make_portable_tox.

  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 ideal usage for heavy or unstable subgraphs and provides caveats about spin-up time. It mentions complementing make_portable_tox but does not explicitly state when not to use or provide alternative tools.

  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?

  The description discloses that the tool creates nodes, exposes Strength/Edge/Iterations as live uniform parameters while baking others like blur radius and sigmas, and notes that iterations are in-shader without a feedback loop. This goes beyond annotations, but it misses potential prerequisites (e.g., does the parent_path need to exist? is source validated?).

  Agents need to know what a tool does to the world before calling it. Descriptions 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 in 4-5 sentences, front-loading the main purpose and algorithm, then detailing node creation and parameter behavior. Every sentence adds value without redundancy or verbosity.

  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 (11 parameters, no output schema), the description explains the algorithm, nodes created, parameter roles (uniform vs baked), and mentions use of Select TOP and Null TOP. It is complete for a creation tool, though it could mention potential side effects or prerequisites for 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 100% schema coverage, the baseline is 3, but the description adds meaningful context: it identifies which parameters are dynamic uniforms versus baked at build time, and clarifies the behavior of iterations (in-shader, no ping-pong). This enriches 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 builds a two-pass Kyprianidis-style flow abstraction using ETF and FDoG, specifying the exact nodes created (two glslTOPs, textDATs, Select TOP, Null TOP). This is a specific verb+resource that distinguishes it from sibling tools, many of which are generic 'create_*' functions.

  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 generating a specific stylized effect (oil-painting interiors with ink edges) but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it or provide exclusions. The context is implicit, but no direct guidance is given.

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

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

  Annotations indicate a mutating (readOnlyHint=false) but non-destructive operation. The description adds important behavioral details: it creates a baseCOMP with specific generator types, exposes a live Speed knob except for recipe-built techniques, and returns a structured JSON summary. It also discloses fallback behavior and the env-var prerequisite for custom_glsl.

  Agents need to know what a tool does to the world before 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-loaded with the core purpose. Each clause adds value: the container structure, technique handling, knob behavior, and the return summary. 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?

  Covers purpose, per-technique behavior, environmental constraints for custom_glsl, and the full return contract (summary plus JSON with specific fields) despite no output schema. Lacks explicit guidance on alternatives relative to sibling tools, which is a completeness gap given the extensive sibling list.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 six parameters already documented. The description adds high-level technique behavior (validated recipes vs built-in GLSL vs fallback) that enriches the 'technique' enum, but doesn't provide parameter syntax/format 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?

  Description clearly states it 'Creates a new baseCOMP under parent_path' holding a generative generator with explicit structure (recipe network, GLSL TOP + Text DAT, or noise chain) ending in a Null output. The technique enumeration and output contract distinguish 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 description provides conditional usage context: custom_glsl only works when TDMCP_RAW_PYTHON=on and TDMCP_BRIDGE_ALLOW_EXEC=1, unsupported techniques fall back to noise with a warning, and recipe-built techniques don't get the Speed knob. It does not explicitly name alternative sibling tools or state when to choose this over others like create_glsl_shader.

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

• create_kaleidoscopeA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate non-destructive behavior; the description adds value by detailing what the tool creates (baseCOMP with source, GLSL pass, Null output), optional input behavior, and the return summary. 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?

  The description is a single, well-structured paragraph of two sentences. It front-loads the main purpose and then provides necessary details without unnecessary words. Every sentence earns its place, achieving high 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?

  For a tool with 8 parameters and no output schema, the description covers the main behavioral aspects: creation process, optional input, return information (summary + JSON with paths, errors, warnings, preview). It is mostly complete but could be improved by briefly describing the JSON structure more explicitly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 repeats some parameter info (Segments, Rotation, Zoom, Center) but does not significantly elaborate beyond the schema's own descriptions. It adds minor context like '6 is the classic look' but overall relies heavily on 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 ('Wrap a source') and identifies the resource (kaleidoscope/radial-mirror symmetry effect), clearly distinguishing it from sibling tools like create_visual_system or create_feedback_network. It also notes it's a 'signature VJ look', further clarifying its unique 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 clearly states when to use the tool (to wrap a source in a kaleidoscope effect) and provides an alternative (omitting input to generate noise). However, it does not explicitly exclude other use cases or compare to siblings, missing the opportunity to guide the agent away from similar tools.

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

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

  The description discloses that the tool builds nodes (Select, Level, Composite TOPs) and a control strip, and returns a summary with inline preview. This adds context beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) about the non-destructive creation behavior and the return format. However, it could mention prerequisites 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.

  Conciseness4/5

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

  The description is efficiently structured: front-loaded with purpose and key features, then detailed explanation of internal structure and return value. It is verbose but every sentence adds value, fitting 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 fully explains the tool's behavior: parameter usage, internal network nodes, control strip, and return value (summary JSON with paths, errors, preview). No gaps remain given the schema richness and absence of 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 3. The description adds meaningful usage guidance: 'Pass layers (bottom-first) for explicit stack, or omit to build count empty test layers' and explains the internal architecture (Select → Level → Composite). This clarifies the relationship between layers and count 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 'Build a VJ-style N-layer compositor' with specific verb and resource, and details the compositing mechanism (stack 2–8 source TOPs, per-layer blend modes and opacity). It distinguishes from siblings like create_layer_mixer by emphasizing the multi-layer compositing with individual blend modes.

  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 VJ-style compositing with multiple layers but does not explicitly state when to use this tool versus alternatives (e.g., create_layer_mixer). No when-not-to-use guidance or alternative comparisons are provided.

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

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

  Annotations already specify non-read-only, non-destructive, and open-world behavior. The description adds value by disclosing that the tool produces a scaffold, a body_bus CHOP contract, and setup notes, and that live calibration is outside its scope. This transparency 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 compact sentences: the first states the action and available options, the second states the outputs and a key caveat. Every word contributes; 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 scaffold tool with 9 well-documented parameters and no output schema, the description provides a solid high-level view: what it produces (body_bus CHOP contract, setup notes) and a critical limitation (calibration validation). It could detail the CHOP contract format, but the schema already covers inputs, and the description is complete enough for selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 coverage at 100%, each parameter is already described richly. The description mentions the transport modes (matching the 'source' enum) and the 'joint_set' implication via skeleton data, but adds minimal additional meaning beyond the schema. It doesn't compensate for schema gaps because there are none.

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

  Purpose5/5

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

  The description clearly states it creates a TouchDesigner scaffold for Nuitrack skeleton data across multiple transports (OSC, WebSocket, TCP JSON, sample mode). It distinguishes from sibling body-bus tools (e.g., create_optitrack_tracking_bus) by naming Nuitrack specifically and mentioning the body_bus CHOP contract and setup notes.

  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: it is for scaffolding Nuitrack skeleton data into a body_bus CHOP with selectable transports. It also indicates a limitation (calibration must be validated separately), but doesn't explicitly name alternatives 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_pose_reactiveA
  4.2/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false (creates network), destructiveHint=false, openWorldHint=true. The description adds details: it creates a fresh baseCOMP with a node chain (Select→Math→Hold→Filter→Limit→Rename), merges into one null_out, emits warnings for constant tz, and handles binding failures as non-throwing warnings. 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.

  Conciseness3/5

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

  The description is long but well-structured: first sentence introduces purpose, then technical details, then caveats. However, it is dense with information and could be more concise while retaining value.

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

  Completeness4/5

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

  For a tool with no output schema, the description covers the output (null_out), the container created, the Reactive custom page, prerequisites (setup_body_tracking), and warnings. It is fairly complete, though missing explicit mention of the output format (a Null CHOP with channels).

  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 3. The description adds value by explaining the node chain, supported metrics, and the behavior of bindings (array of binds, warnings). It also includes a landmark ID cheat-sheet in the schema description, enhancing 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 states it is a 'Body-pose binder parallel to bind_audio_reactive' and explains it takes a MediaPipe pose CHOP to derive scalar reactive channels, providing specific metrics. It distinguishes itself from sibling tools like bind_audio_reactive and bind_to_channel by naming them and noting similarities.

  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 to run setup_body_tracking first and provides a heads-up about MediaPipe's 2D landmarks. It does not list explicit when-not-to-use conditions, but the context is clear and includes prerequisites.

  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 indicate it is not read-only or destructive. The description adds detailed behavioral context: state transitions, CHOP outputs, and the live session requirement. 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?

  Every sentence adds value without waste. The purpose is front-loaded, and the structure is logical: what, how, outputs, comparison, note.

  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 with full schema coverage and no output schema, the description explains the core algorithm and outputs. It could mention the resulting network structure, but is adequate for the 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%, so baseline is 3. The description does not add extra meaning beyond the schema's parameter descriptions, which are already 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 it builds a Markov-chain step sequencer with specific transition behavior and outputs, and distinguishes itself from siblings create_euclidean_sequencer and create_beat_grid_sequencer.

  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 (probabilistic rhythms, generative state machines) and mentions a prerequisite (live TD session with time.play=1), but doesn't explicitly exclude use cases where siblings would be better.

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

• create_replicatorA
  4.2/5.0
  Behavior4/5

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

  Discloses several behaviors beyond annotations: parameter name probing, destructive re-replication, callback stub creation. Annotations say destructiveHint false, but description says re-replicating is destructive to clones—this is about the replicator's internal behavior, not the tool's effect, so no contradiction. Could mention error handling 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.

  Conciseness4/5

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

  Front-loaded with main purpose, but middle section on parameter probing and re-replication is slightly verbose. Efficient overall, but could trim details like 'each is set probe-first' without losing clarity.

  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?

  No output schema, but description does not explicitly state what the tool returns (e.g., path to created replicator). Mentions a report within the replicator, not the tool's output. Covers inputs well but lacks output description and error behavior, leaving gaps for a 6-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?

  Adds meaning beyond schema: explains behavior when template_path or table_path are omitted, demo rows for `rows` parameter, and callback stub generation. Schema coverage is 100%, so baseline 3; description adds value, thus 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?

  Clearly states the tool wires a Replicator COMP that clones a template per row of a Table DAT, using specific verb 'Wire' and resource 'Replicator COMP'. Distinguishes from siblings by naming the replicator mechanism and mentioning 'TouchDesigner's idiomatic N copies from data'.

  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 usage context with examples like menus, scoreboards, per-track decks, and instanced panels, implying when to use. Does not explicitly state when not to use or name alternatives among the many 'create_' siblings, missing some guidance.

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

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

  Annotations already indicate nondestructive, open-world behavior. The description adds that it creates a GLSL TOP with live controls and a self-contained container, which is valuable context. It does not detail potential side effects like network modifications or performance impact, but the core creation behavior is well communicated.

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

  Conciseness5/5

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

  Two sentences with no wasted words. The first sentence states the action and lists examples; the second provides a value proposition and differentiation. Information 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 7-parameter tool with rich annotations, the description covers purpose, differentiation, and key behavioral aspects (creation of GLSL TOP with controls). It does not cover error handling or output beyond the schema, but given the schema and annotation coverage, 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?

  With 100% schema description coverage, the schema already explains each parameter well. The description mentions curated shaders and live controls but does not add new parameter-specific details beyond the schema. It meets the baseline without exceeding 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 instantiates a curated, ready-to-run GLSL shader from a library, listing specific shader names. It distinguishes itself from the sibling create_glsl_shader by emphasizing built-in shaders versus arbitrary code, 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 contrasts with create_glsl_shader, guiding the agent to prefer this tool when built-in shaders are desired. However, it does not address prerequisites, when not to use it, or compare with other sibling tools like create_shader_park, leaving minor gaps.

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

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

  The description discloses that creating an Out variant requires wiring with connect_nodes, warns about raw headerless buffers causing garbled frames, and notes that some combos may not be available (returns friendly fatal). Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with creation behavior. 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 concise, using about 5 sentences that front-load key information (direction, kind, shmName) and include important warnings without unnecessary verbosity.

  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 parameters, nested object) and lack of output schema, the description adequately covers usage and cautions. It could mention the return value (operator path or name) but is otherwise complete enough 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?

  Schema coverage is 100% with descriptions for all parameters. The description adds overall context but does not provide substantial additional meaning beyond what the schema already gives for each parameter, 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 creates a Shared Memory bridge for zero-copy IPC, specifying direction, kind, and shmName. It distinguishes from sibling tools by focusing on external app communication, unlike other create_* tools for internal TD 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?

  It provides clear context for when to use this tool: for zero-copy IPC with external apps on the same host. It mentions platform/build dependencies and warns about exact name matching, but does not explicitly state when not to use it, though the context implies it's for cross-app scenarios.

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

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

  Discloses creation of a Null CHOP at a specified path, the output channel semantics (normalized 0..1), and the existence of a custom parameter page 'Tune' for live tweaking. With openWorldHint=true, it adds useful context about side effects such as modifying parent COMP parameters, which 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?

  Two compact sentences: first sentence explains core function and output location, second provides usage recommendation and customization details. No redundant or unnecessary 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?

  Adequately covers tool purpose, output, parameter customization context, and integration with a sibling tool. Lacks explicit prerequisites for parent existence (though schema mentions it) and error handling, but is reasonably complete for a creation tool with openWorldHint.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 are fully described in the input schema (100% coverage). The description adds marginal value by mentioning the 'Tune' custom parameter page that exposes sensitivity and attack/release, but does not fundamentally augment schema documentation for individual 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?

  Clearly identifies as a 'Layer-1 audio splitter' that separates transient and sustain from audio using two envelope followers. Distinguishes itself from siblings like 'create_envelope_follower' by describing the specific dual-channel output and its use case for driving visuals independently.

  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 context: pairing with 'bind_to_channel' to drive visuals from percussion vs sustain. Implies the tool is for audio-reactive visual setups but does not explicitly state when not to use it or compare to alternatives like 'create_audio_reactive'.

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

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

  The description adds context beyond annotations: it states that a new baseCOMP is created under parent_path, the demo chain is built if target_geo is omitted, and the return includes a summary and detailed JSON. Annotations already indicate readOnlyHint=false and openWorldHint=true, and the description aligns with these.

  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 with concise, informative sentences. It is front-loaded with the main purpose and differences. It could be slightly more structured with bullet points, but remains clear and 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?

  Given the complexity (9 parameters, creation tool, optional demo mode), the description covers the tool's purpose, usage modes, what it creates, the return structure, and key behavioral traits. No output schema is provided, but the description explains the JSON block fields, making it 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 the description does not need to add parameter details. However, it mentions the key controls (Amount, Frequency, Speed) and texture_path usage, but does not provide significant additional semantics 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 that the tool builds a vertex-shader displacement material, specifying the mechanism ('offsets each vertex along its normal') and distinguishing it from sibling tools like create_depth_displacement and create_displacement_warp which operate on 2D pixels.

  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 this tool – either assigning to an existing Geometry COMP or omitting target_geo for a self-contained demo. It explicitly differentiates from related tools, but does not exhaustively list alternatives or scenarios where this tool is inappropriate.

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

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

  While annotations indicate readOnlyHint=false and destructiveHint=false, the description adds significant behavioral context beyond those flags. It states the scaffold is 'deterministic', lists the exact network nodes it creates, and discloses the limitation that live detection depends on external components. This provides transparency about what the tool actually does and its operational requirements.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 efficient: a direct opening sentence, a concise list of created components, and a final sentence covering the live detection requirement. No filler or redundancy. Every sentence contributes useful 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 tool with 10 parameters, all fully documented in the schema, and with annotations covering read/destructive hints, the description provides a solid overview of the build output and the key operational prerequisite. It doesn't explain what 'deterministic' means in practice or detail the scaffold's default state, but the essentials are covered. It is complete enough for an agent to understand the tool's role and limitations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 outputs like 'source input' and 'backend receiver placeholder' that map to parameters (input_top_path, backend), but it doesn't explain parameter values, defaults, or usage beyond what the schema already documents. All parameter semantics are adequately handled by the schema; the description adds no additional parameter-level 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 a specific verb ('Build'/'Creates') and a specific resource ('deterministic TouchDesigner scaffold for YOLO-style object tracking'). It enumerates the key created components (source input, backend receiver placeholder, detections DAT, stable tracks_out CHOP channels, annotated_out TOP, setup notes), which distinguishes it from generic create_* siblings. The purpose is 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 gives clear context that this tool is for building a YOLO/ONNX tracker scaffold and includes an important when-not condition: 'Live detection requires an external detector or validated TouchDesigner Python ONNX runtime.' This implies the scaffold alone isn't sufficient for live detection, providing a practical boundary. It does not explicitly name alternative tools, but the context is sufficient 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.2/5.0
  Behavior4/5

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

  The description reveals key behaviors: it creates a directory tree, writes a JSON manifest and checksum manifest, and supports integrity verification on unpack. These details go beyond the annotations (readOnlyHint=false, destructiveHint=false) which only indicate it is not read-only and not destructive. No contradictions with annotations are 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 concise (4 sentences) with the main purpose front-loaded. Every sentence adds meaningful information: bundling assets, actions, manifest details, offline nature. No redundant or vague statements.

  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, two actions, nested items array) and the absence of an output schema, the description reasonably explains the overall workflow and outputs (directory tree, manifests). It covers the key behavioral aspects and constraints. A slight gap is the lack of mention of error conditions or the return value format, but the schema descriptions compensate.

  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 provides detailed descriptions for 10 of 11 parameters (91% coverage). The description adds contextual value by explaining how the 'action' parameter drives different behaviors and how the 'name' parameter forms the output directory. This goes 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 that the tool bundles vault assets into a portable pack with provenance and integrity. It specifies two distinct actions (pack/unpack) and the resulting outputs (directory tree, manifest). This distinguishes it from siblings like 'checksum_and_verify_pack' which focus on verification, or 'morph_pack' and 'variant_pack' which imply different transformations.

  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 portable, verified packs of assets, and notes that it works fully offline. However, it does not explicitly state when to use this tool versus alternatives such as 'morph_pack' or 'variant_pack', nor does it provide when-not-to-use guidance or prerequisites.

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

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

  The description discloses that the tool performs write/surgical replace actions (consistent with destructiveHint=true) and describes the additional behaviors of error inspection and optional preview. It adds context about using set_dat_content/edit_dat_content under the hood and the required environment settings, which go 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 first sentence front-loading the core purpose and workflow (edit, inspect, preview). The second sentence adds necessary implementation and prerequisite details without verbosity. Every sentence earns its place, and the structure is clear.

  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 high complexity (15 parameters) and no output schema, the description provides a comprehensive overview of the workflow, including the feedback loop, error inspection, and optional preview. It also mentions environment requirements. However, it does not explicitly describe the return format or what the response contains, which could be inferred from the parameters but would benefit from a brief mention.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions for all 15 parameters, so the description doesn't need to repeat them. The description does reinforce the two modes ('write or surgically replace') and the preview feature, which aligns with the 'mode' and 'include_preview' parameters, but it doesn't add 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 clearly specifies the verb (edit), the resource (GLSL/Text DAT), and the scope: it writes or surgically replaces source text, inspects errors, and optionally captures an inline preview. This distinguishes it from the sibling tools like set_dat_content/edit_dat_content by emphasizing the immediate feedback loop, 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 provides clear context on when to use the tool (for an immediate shader feedback loop) and mentions underlying tools (set_dat_content/edit_dat_content) implying alternatives for raw editing. It also lists required environment variables as prerequisites. However, it does not explicitly state when NOT to use it or compare with other preview-capture tools like get_inline_preview.

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

• elicit_missing_argsA
  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 annotations by revealing that the tool uses an LLM to propose values. This provides behavioral context not available from readOnlyHint and openWorldHint alone. However, it could further clarify how it uses the schema or handles failures.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 verb and resource. Every word contributes to explaining the tool's function, with no wasted 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 that an output schema exists, the description is sufficient to convey the tool's basic operation. It does not explain the return format, but the output schema fills that gap. For a simple tool with good annotations and schema coverage, 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?

  Schema coverage is 100%, so the schema already documents all parameters. The description does not add additional meaning to individual parameters beyond what the schema provides, meeting the baseline expectation.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'Use the schema + LLM to propose values for a tool call's missing required args.' It uses a specific verb ('propose') and resource ('tool call's missing required args'), and the sibling list contains no similar tool, so it is well-distinguished.

  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 should be used when a tool call has missing required args, but it does not explicitly state when not to use it or mention alternatives. The context is clear enough for an agent to decide, but lacks exclusionary guidance.

  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.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: it states that the tool records a TOP to a file, writes via TouchDesigner, and documents expected codec/extension/fps. This complements the annotations (readOnlyHint=false, openWorldHint=true) without contradicting them, though it does not cover every side effect (e.g., overwrite 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 two sentences, front-loaded with the core action, and includes meaningful specifics without redundancy. Every sentence adds value, covering both behavior and the preset list 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?

  Given the tool's moderate complexity (6 params, no output schema), the description effectively communicates purpose, preset scope, and key behavior. It falls short of fully explaining prerequisites or lifecycle details (e.g., when stop is required), but the schema fills in 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?

  Schema coverage is 100% and all parameters have descriptions. The tool description adds some context (e.g., named presets, expected codecs for playback) but does not materially explain parameter semantics beyond the schema, 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 the tool starts/stops a movie export using named presets, and specifies the resource (TOP recorded to file). It distinguishes from siblings like record_movie by mentioning the preset-driven approach and reuse of record_movie's recorder.

  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 (preset-based exports with specific codecs) and mentions reuse of record_movie's recorder, implying it is the preset-focused alternative. However, it does not explicitly state when not to use it or name direct alternatives beyond the implicit reference.

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

• generate_readmeA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint and openWorldHint. The description adds useful context: returns Markdown on structured channel, optional preview thumbnail, and use of parameters. No contradictions, but could mention how invalid paths are handled.

  Agents need to know what a tool does to the world before 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-load purpose and list contents, then provide parameter tips. No wasted words; efficient and scannable.

  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 5 parameters and output schema exists, the description covers tool purpose, output format, and key options. Lacks details on error handling or performance, but sufficient for typical use.

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

  Parameters4/5

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

  Schema coverage is 100% with clear parameter descriptions. The description reinforces parameter usage, e.g., 'Use include_mermaid to add a Mermaid flowchart' and 'max_nodes to cap large inventories,' adding 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 clearly states the tool produces a Markdown project document for COMP or project, listing specific content (counts, parameter table, inputs/outputs, inventory, dependencies, preview). It distinguishes from siblings like document_network by specifying scope and 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 generating documentation but does not explicitly state when to use this tool over alternatives like document_network. It provides guidance on parameters (include_mermaid, max_nodes) but lacks exclusions or 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.

• get_operator_workflow_guideA
  4.2/5.0
  Behavior5/5

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

  The description adds valuable behavior beyond the annotations: when an operator is absent from the imported snapshot, it returns candidate guide IDs and an explicit snapshot caveat instead of falsely claiming the operator does not exist. This is a nuanced fallback an agent would not infer from the readOnlyHint/destructiveHint annotations. It also clarifies the data source ('embedded', 'snapshot provenance'), which is not 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 two sentences, front-loaded with the core purpose ('Read-only: return...') and then addresses an important edge case. Every sentence adds distinct value, and there is no 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?

  Given the output schema and annotations, the description is largely complete: it names the output contents, notes the snapshot provenance, and discloses the missing-operator fallback. It could be more explicit about the relationship to the snapshot and what 'embedded' means, but overall it gives an agent enough context 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?

  The input schema already provides full descriptions for all three parameters (operator, next_limit, include_examples) with 100% coverage. The description does not add parameter-specific details beyond what the schema captures, 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 the action ('return') and the resource ('an embedded TouchDesigner operator workflow guide'), and specifies its contents (common inputs, outputs, examples, next-operator suggestions, snapshot provenance). This distinguishes it from sibling tools like get_td_docs or search_operators, which focus on documentation or search rather than a curated workflow guide.

  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 you need a workflow guide for an operator) and notes the read-only nature, but it does not explicitly state when to prefer it over alternatives like get_td_docs or search_operators, nor does it mention exclusions. The missing-operator caveat gives some behavioral context but not usage boundaries.

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

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

  Annotations already declare readOnlyHint=true. Description adds value by noting that output is structured for agent consumption, API names vary by build, and a 'probe' field records reachable attributes. These details help the agent handle variability, going beyond annotation indicators.

  Agents need to know what a tool does to the world before 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 and read-only nature, followed by the three inspection categories, then context and output details. No fluff, 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?

  Given an output schema exists, the description appropriately covers purpose, usage, parameters, and behavioral traits (varying API, probe field). It could add more about the return shape, but the output schema handles that. Complete enough for confident 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 baseline 3 is appropriate. Description adds marginal value by listing what each inclusion returns, but this largely mirrors the schema's parameter descriptions. No new semantic 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?

  Description states a specific verb ('inspect') and resource ('COMP extensions, storage, custom parameters'). It distinguishes from siblings by positioning itself as 'the inspect side of the reusable-component loop' after scaffold_extension and add_custom_parameters, or standalone. No ambiguity about what it 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?

  Explicitly states when to use: after scaffold_extension + add_custom_parameters, or standalone to examine any COMP. Mentions 'without resorting to raw Python' as an alternative. While it doesn't enumerate when not to use, the context is clear and helps differentiate from related tools.

  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?

  Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds useful behavioral context: hardware modes default inactive and remain explicitly 'unverified until a real sensor is connected', which is a safety detail not present in the annotations. It also states the produced outputs, surpassing annotation coverage 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, tightly packed: first states purpose and inputs, second states outputs and a critical safety behavior. No filler, front-loaded with the primary action, and every word contributes. It is concise without losing essential 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 scaffold-building tool with 10 parameters, the description covers key context: what it builds, for which sensors, what outputs are produced, and the rehearse-safe default. It omits post-creation steps like verification or how to enable hardware later, but the openWorldHint and rich schema largely compensate, making it adequately 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 has 100% coverage for its 10 parameters, each with meaningful descriptions. The tool description does not reiterate parameter details but contextually implies the 'active' and 'sensor' parameters through the hardware default note. Since the schema carries the heavy lifting, the description adds no significant parameter semantics 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?

  Description clearly states the tool's function with a specific verb ('Build') and resource ('floor-occupancy tracker scaffold'). It names supported input modes (synthetic rehearsal, Ouster TOP, Leuze ROD4 CHOP, UDP point input) and outputs (tracked_points CHOP, floor preview TOP), distinguishing it from sibling tools like create_ouster_lidar_bus or generic node-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?

  Provides clear context for when to use the tool: building a floor tracker for synthetic rehearsal or specific hardware inputs. It also mentions the safety default of inactive hardware modes. However, it does not explicitly mention alternatives or when not to use it, 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.

• local_marketplace_indexA
  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 the annotations: it explicitly states that the tool writes a file and is destructive, which aligns with the destructiveHint annotation. It also says the index is consumed by other tools, explaining the side effect's role. The description does not contradict annotations (annotation_contradiction=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 extremely concise: two sentences. The first sentence states the action and resources, the second adds usage context and the destructive nature. Every sentence adds value, and it is effectively 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?

  Given the simple parameter set and no output schema, the description covers the tool's purpose, usage, and relation to siblings. It does not detail the index structure or potential errors, but it is sufficient for an agent to understand when and how to invoke the tool. Slightly more detail on the default behavior of out_file would improve 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 input schema has two parameters with 0% description coverage. The description mentions 'Scan a local package directory' (implying package_dir) and 'write an index' (implying out_file), but does not explain parameter details like format, defaults, or constraints. The description provides minimal but functional context for 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 action ('Scan' and 'write an index') and the resource ('local package directory' of installable tdmcp packages). It also explains the purpose: making a folder browsable and installable as a local marketplace, which distinguishes it from sibling tools that consume the index (browse_library, install_library_package).

  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 to use this tool: 'Use it to make a folder of components browsable and installable as a simple local marketplace.' It also names the tools that consume the output, implicitly indicating that this tool is the creation step before using those. It does not define when not to use it or compare to similar sibling tools like generate_library_index, but the guidance is clear enough.

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

• manage_componentA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate write-capable and destructive behavior. The description adds valuable detail: save uses a deferred, verified same-directory temporary export and refuses overwrite by default, with an optional 'ask' policy; load retains legacy behavior. It also notes paths are on the local machine, clarifying the execution context 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 compact, with each sentence covering a distinct aspect: purpose, save behavior, load behavior, and path location. It is front-loaded with the main purpose and efficiently structured 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?

  With 11 parameters and no output schema, the description covers key behavioral nuances (overwrite, deferred export, local paths) while leaving parameter details to the schema. It is sufficiently complete for an agent to understand the tool's scope and operation, though it could mention idempotency or linked behavior for extra clarity.

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

  Parameters4/5

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

  The schema provides descriptions for all 11 parameters, so the description does not need to repeat them. It adds context by explaining the overwrite_policy semantics, the deferred export tied to operation_timeout_ms, and native consent tied to confirmation_timeout_ms. This supplements the schema meaningfully.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 moves COMPs to/from .tox files, with explicit 'save' and 'load' actions. It uses specific verbs (save, load, build) and distinguishes from siblings by focusing on .tox file operations for building a reusable component library.

  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 two actions and their behaviors, giving context for when to use each. However, it does not explicitly mention alternatives or when to prefer another tool, such as manage_component_storage or export_palette_component. Usage is implied 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.

• merge_vaultsA
  4.2/5.0
  Behavior4/5

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

  The description adds significant behavioral context beyond annotations: it details the walking of specific folders, uses sha256 hashing, describes four conflict strategies, explains dry run behavior, and notes LF/CRLF differences count as conflicts. Annotations only indicate destructiveness; description provides the rest.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 four sentences, front-loaded with the primary action, and every sentence provides essential information without redundancy. 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.

  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 (5 parameters, destructive operation, no output schema), the description covers the core functionality, conflict resolution, dry run, folder mapping, and a note on line endings. It is missing some details like error handling or return behavior, but overall it is sufficiently complete for an agent to understand 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?

  With only 40% schema description coverage, the description compensates by explaining the meaning of the 'kinds' parameter (listing folders), the 'strategy' parameter (defining each option), and the 'dryRun' parameter. It also clarifies default values for 'targetVaultPath' and 'kinds'. This adds significant 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 that the tool merges the contents of a source Obsidian vault into a target vault, specifying the folders it walks and conflict resolution strategies. It is specific about the action and resource, distinguishing it from sibling tools like capture or save.

  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 (for merging vaults) but does not explicitly state when not to use it or suggest alternatives among sibling tools. It explains the strategies and dry run but lacks usage boundaries.

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

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds value by disclosing fallback from LLM to deterministic grammar, mentioning that preview may read 0 on a paused timeline (a behavioral quirk), and noting the dependency on a configured local LLM. 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?

  Three sentences with no fluff: first sentence states core purpose, second details the LLM/grammar dual path, third provides a practical troubleshooting note. Front-loaded and every sentence earns its place.

  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 7 parameters, 2 enums, and no output schema, the description covers the workflow but omits what the output of building a generative system looks like (e.g., returned component path or success message). It assumes familiarity with TouchDesigner and does not describe side effects or prerequisites beyond annotations.

  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 parameters are well-described in the schema. The description enriches semantics by explaining how parameters like 'style' and 'generator' influence the LLM or grammar fallback, and the role of 'preferLlm' and 'includePostFx'. 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 clearly states the verb 'Ingest' and 'build', the resource 'moodboard images → generative system', and the target environment 'TouchDesigner'. It distinguishes from sibling tools like 'create_generative_art' by focusing on converting moodboards into a complete system, not just a single generator.

  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 converting moodboards to generative systems but does not explicitly differentiate from sibling 'generate_from_moodboard'. It mentions fallback behavior (LLM vs deterministic) but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like individual generator creation tools.

  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?

  Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description adds valuable behavioral details: 'offline-safe,' deterministic left-to-right layout, per-target CHOP creation, and a structured report of emitted addresses. This meaningfully supplements the structured 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?

  Two tightly written sentences: the first packs the essential purpose and mechanics, the second gives real-world use cases. No filler, every clause earns its place, and the most critical information (create + structure) is front-loaded.

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

  Completeness4/5

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

  For a tool with four well-documented parameters and no output schema, the description is quite complete: it explains the created nodes, layout, address prefixes, and return value (structured report). The absence of an output schema is mitigated by the mention of the report. It could be slightly more explicit about the container name/parent path behaviors, but the schema covers 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?

  The schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds high-level semantics—'one Constant CHOP plus OSC Out CHOP per target'—but does not provide parameter-specific details beyond what the schema already documents, which is acceptable given the schema's completeness.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 an offline-safe OSC control matrix'—a specific verb and resource—then details the exact construction (Constant CHOP + OSC Out CHOP per target, deterministic layout, prefixes, structured report). This fully distinguishes it from sibling tools like create_ndi_router_matrix or connect_resolume_arena, which target different protocols or 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?

  It says 'Use it as the primitive for QLab, atemOSC/Companion, Resolume, VDMX, or any OSC-speaking show-control endpoint,' giving explicit, useful context. It does not name direct alternatives to exclude, but the OSC-specific scope and reference to 'OSC-speaking' provide clear situational guidance.

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

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

  Annotations already indicate destructiveHint=true and readOnlyHint=false. Description confirms files are written to out_dir but does not mention overwriting behavior or side effects beyond what annotations imply. No contradiction, but adds little new 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?

  Two sentences, no fluff. First sentence enumerates outputs, second sentence contrasts with sibling. 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?

  Describes the output package structure completely. No output schema, but the description explains what files are created. Could mention error handling or pre-existing out_dir behavior, but overall adequate for the 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 covers all 5 parameters (100% coverage). Description adds context by explaining the generated files and how include_thumbnails works with thumbs/ and gallery.md. Adds value beyond 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?

  Description states verb 'compose' and resource 'documentation PACKAGE' with specifics: README.md, topology.md with Mermaid, optional thumbnails. Clearly distinguishes from sibling 'generate_readme' by noting multi-file vs single file.

  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 contrasts with generate_readme, indicating when to use this multi-file approach. Implies usage for sharing or archiving projects. Missing explicit 'when not to use' guidance but context is clear.

  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?

  Beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description adds valuable behavioral context: it explicitly notes that live projector alignment is 'unverified until run on the physical outputs,' which sets expectations for safety and reliability. This is more transparent than simply stating 'build' and provides a clear 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?

  The description is concise (two sentences) and front-loaded with the main action. It efficiently enumerates the built components without unnecessary fluff. Every word contributes to understanding the tool's scope and safety profile.

  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 9 parameters and no output schema, the description covers the tool's core purpose and components. It does not mention the return value (e.g., the generated COMP path), but for a build tool this is often implied by the name/parent_path parameters. The safety caveat adds important context. Overall, it is sufficiently complete for an agent to decide when to use it, though a note on return type would improve 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 100% schema coverage, the parameters are individually well-described. The tool description adds architectural context by linking parameters (e.g., source_path as TOP selection, include_corner_pin as corner pin, expose_controls as brightness/gamma controls, projectors as per-projector lanes). This helps users understand how the parameters fit together, going beyond mere schema repetition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('projector calibration network'). It lists concrete components (grid/crosshair, per-projector crop/corner-pin/level/output lanes, preview layout, notes, brightness/gamma controls), distinguishing it from generic mapping tools like create_projection_mapping by emphasizing 'calibration' and 'rehearsal-safe'.

  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: it is rehearsal-safe and alignment remains unverified until run on physical outputs. However, it does not explicitly state when to use this tool versus alternatives like create_projection_mapping, nor does it provide clear exclusions. The note about unverified alignment hints at a limitation but lacks direct guidance.

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

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

  The description discloses the validation step, the structured .pulse() invocation, and the typed bridge errors for missing parameters or non-Pulse styles. Annotations already indicate non-read-only and non-destructive behavior, and the description adds context about validation and error handling 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 sentences long, front-loaded with the primary action, and contains no wasted words. It efficiently covers the action, validation, error behavior, and the no-fallback constraint.

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

  Completeness4/5

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

  For a two-parameter tool with annotations covering safety, the description adequately addresses purpose, validation, invocation, and error cases. It does not specify the exact return format, but for a simple trigger action this is not critical to selecting or invoking 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 both path and parameter, covering 100% of the parameters. The description reinforces that these must refer to an existing operator parameter but adds little beyond the schema definitions, 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: validate a parameter is Pulse style, invoke its structured .pulse() operation, and confirm the result. It also distinguishes itself from siblings by explicitly stating it does not use raw Python fallback and performs validation first.

  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 existing operator parameters that need a Pulse trigger with validation and confirmation. It also notes error conditions for missing/non-Pulse parameters and explicitly excludes raw Python fallback, offering an implicit alternative. It could be more explicit about naming alternative tools like execute_python_script, but the context is sufficient.

  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?

  Beyond annotations (non-read-only, non-destructive, open-world), the description adds that the file is written by TouchDesigner on the TD machine and uses extension to pick format. This is valuable context for agents understanding that the operation is local to TD and not on the client side. 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?

  Two sentences, front-loaded with the main action, and efficient use of an em dash to separate primary purpose from sibling distinction. Every word adds 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?

  For a simple two-parameter tool without output schema, the description covers the main aspects: what it does, format support, location of file writing, and alternative tool. Could mention overwrite behavior or success confirmation but is 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 100% and both parameters are well-described in the schema. The description does not add significant new meaning beyond what is already in the parameter descriptions. The mention of 'pass an absolute path' is already in the file parameter 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 tool saves a TOP to an image file at native full resolution, and explicitly differentiates from get_preview which only provides a small thumbnail. The verb 'Save' and specific resource 'TOP' with format details 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?

  It tells when to use (exporting finished frame) and provides a direct comparison to get_preview. The requirement to pass an absolute path and that the file is written on the TD machine is stated. However, it lacks explicit prerequisites such as that the TOP must be cooked or that the file path must be writable.

  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?

  The description discloses that the tool creates a Text DAT, wires it into an extension slot, optionally promotes members, and reinitializes the COMP. This adds meaningful context beyond the annotation flags (readOnlyHint=false, destructiveHint=false) by detailing the specific actions and side effects, such as the creation and wiring process.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 that front-load the primary action and then provide contextual guidance about pairing with related tools. Every sentence adds value, 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 has 5 parameters and no output schema, the description covers the process well—describing the optional method stubs, promotion, and slot. It also links to sibling tools for complementary tasks. However, it lacks mention of prerequisites (e.g., the COMP must exist) and potential errors, which would make it more 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 description does not add significant new meaning beyond what the input schema already provides for each parameter. The baseline of 3 is appropriate, as the description contextualizes parameters within the workflow but does not elaborate on formats 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 it gives a COMP a Python extension class, specifying the creation of a Text DAT, wiring into an extension slot, optional promotion, and reinitialization. It distinguishes this tool from siblings by mentioning pairing with `add_custom_parameters` and `manage_component`, and the context of making a generated network reusable.

  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 suggests pairing with `add_custom_parameters` and `manage_component`, providing clear context for when to use this tool. However, it does not explicitly state when NOT to use it or list alternative tools for comparison, such as other scaffold_* tools, which would strengthen the guidelines.

  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?

  The description adds important behavioral information beyond annotations, namely that each update reports its own success and failures do not affect others. This is valuable for an agent to understand the tool's 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 consists of two short sentences, both essential. The first states the purpose, and the second adds critical behavioral context. No extraneous 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 nested parameters and no output schema, the description adequately covers the main purpose and key behavioral trait (non-transactional). It could be improved by hinting at the format of per-update results, but it is still complete enough 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?

  The schema covers 100% of parameters, and the description does not add new semantic information beyond what is in the schema. The behavioral note is already in the schema's description of the 'updates' 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 clearly states the tool updates parameters on multiple nodes in a single batch request. The verb 'Update' and resource 'parameters on multiple nodes' are specific, and the batch aspect distinguishes it from similar single-node update 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 (batch updates) and explains the non-transactional behavior (each update independent, no rollback). However, it does not explicitly mention when not to use it or suggest alternatives like single-node updates.

  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 clearly discloses the tool's write operations (bumping, sidecar creation, frontmatter update) and adds context beyond annotations. It explains the read_only behavior for inspection without mutation, and clarifies there is no TouchDesigner bridge interference. Annotations (destructiveHint=false) align with the described additive writes.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 focused sentences, each essential. The first covers the main action and its effects, the second explains the read_only option, and the third adds important context (pure I/O, requirement). No extraneous 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 is self-contained and covers the tool's purpose, parameters, and behavioral traits. It lacks explicit error-handling details (e.g., missing asset_path) but otherwise provides enough context for an AI agent to use the tool effectively. The sidecar structure and frontmatter update are well described.

  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 descriptions in the schema (100% coverage), and the tool description adds meaningful context: explaining the sidecar structure, bump types (patch/minor/major), and the effect of read_only. This enriches understanding beyond 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?

  The description starts with a specific verb ('Apply a SemVer bump') and identifies the resource ('vault recipe or component note'). It details exactly what the tool does (recording sidecar JSON, writing frontmatter) and distinguishes itself by noting 'Pure vault I/O — no TouchDesigner bridge required' and the required environment variable, setting it apart 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 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 version bumping and optionally inspecting via read_only:true, but it does not explicitly state when to use this tool versus alternatives (e.g., provenance_stamp, manage_checkpoint) nor does it provide exclusion criteria. The guidance is minimal beyond the core function.

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

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

  Beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description reveals key behaviors: the text expression re-evaluates every frame, composite method, FPS probing, Null TOP output, and mode-specific behaviors (e.g., count_down clamps at zero). 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 detailed but efficiently packed; every sentence serves a purpose (purpose, mode explanation, technical mechanics, sibling distinction). Slightly long but well-structured with key information 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?

  The description gives a complete mental model for a tool with 8 parameters, no output schema. It covers purpose, behavior, modes, and technical implementation. The Null TOP output is mentioned. Minor gap: no mention of performance considerations or error 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?

  Schema coverage is 100% with descriptions for each parameter. The tool description adds context like the clock mode's timing origin (project start, not OS clock) and the formatter module, but does not provide additional semantics for individual parameters beyond what the schema already offers.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 overlays a timecode as visual pixels onto a TOP, specifying modes (clock, count_up, count_down). It clearly distinguishes from sibling sync_timecode which syncs a clock signal without pixels.

  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 directly compares with sync_timecode, indicating when to use this tool (for visual timecode) vs the sibling. However, it does not explicitly state when not to use this tool (e.g., if only clock signal is needed).

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

• analyze_projectA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate readOnlyHint and openWorldHint. The description adds behavioral traits: it is conservative, each flagged item carries a human-readable reason, and lists specific types of issues reported. This 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?

  The description is two sentences long, front-loaded with actions and results, and every sentence adds value. No waste.

  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 two parameters with full schema descriptions, an output schema, and annotations, the description covers purpose, usage context, behavioral details, and output characteristics. It 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 descriptions cover both parameters (path and recursive) with clear meanings. The description does not add additional meaning beyond the schema, so 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 diagnoses a network for cleanup, listing specific items like dead operators, broken dependencies, orphan COMPs, and a dependency map. It distinguishes itself from siblings by naming complementary 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 it complements plan_visual and snapshot_td_graph, providing context for when to use this tool versus alternatives. It does not state explicit conditions for when not to use, but the complement statement is strong.

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

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

  The description adds significant detail beyond the annotations: it explains the deterministic heuristic, the dry-run vs. write mode, the preservation of '*'-pinned user tags, and the required configuration. This provides rich behavioral context that the annotations alone 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.

  Conciseness4/5

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

  The description is front-loaded with the core action and key behaviors (write flag, use case, prerequisites). While it is relatively long, every sentence adds necessary context. It could be slightly more concise but remains clear 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 (10 parameters, no output schema), the description covers purpose, usage, prerequisites, and the key behavior of writing. It does not detail error handling or edge cases, but it is sufficient for correct selection and invocation 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?

  All 10 parameters have descriptions in the input schema (100% coverage), which is thorough. The tool description does not repeat or augment these parameter-level details; it offers an overview but no additional semantics. As per guidelines, this results in a baseline score 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 that the tool inspects a library asset and emits a suggested tag set, difficulty, and description. It explicitly ties this to the goal of backfilling consistent tags for browsing by category, which distinguishes it from related siblings like tag_and_search_library (which combines tagging and search) and browse_vault_library (which only searches).

  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 primary use case ('Use this to backfill consistent tags across a library') and lists prerequisites (TDMCP_VAULT_PATH and bridge for td_comp). However, it does not explicitly describe when not to use the tool or provide direct alternatives, though the sibling context makes it implicit.

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

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

  Annotations already indicate readOnly=false (not read-only) and destructive=false (non-destructive). The description adds important behavioral context: 'POPs are Experimental — result carries `unverified` marker', 'unknown par names become warnings (fail-forward)', and per-kind safe defaults. This complements the annotations well.

  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 paragraph that front-loads key info (purpose), then explains usage, defaults, experimental note, and a tip. It is concise with no wasted words, though it could be slightly more structured (e.g., bullet points) for easier 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?

  Given the complexity (3 parameters with a nested array), the description covers purpose, wiring logic, defaults, experimental nature, and a tip. No output schema exists, so return values are not expected. It is fairly complete for a builder tool, though it could mention that it creates a network of POP operators.

  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: for `chain`, it explains wiring logic and defaults; for `params`, it notes that string values resolving to op paths add functionality; for `parent`, it references sibling tool semantics. This adds moderate 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 'Declarative Layer-2 builder for an ordered POP chain', specifying the verb (build), resource (POP chain), and distinguishing it from siblings like build_chop_chain and build_sop_geometry. The term 'POP (Point OPerator)' is domain-specific but precise.

  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 detailed usage guidance: how to pass a `chain` list, wiring rules, default behavior for `parent`, per-kind defaults, and a tip to end with `null_pop`. It does not explicitly exclude any use cases or compare with alternatives, but the context of sibling tools implies appropriate usage.

  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.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, so the description must add behavioral context. It details the internal mechanism (Table DAT, CHOP Execute DAT), explains actions (param/cue), and warns about offline timing. However, it does not explicitly state that the tool creates operators in the network or list potential side effects beyond the sequencer itself.

  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 long paragraph mixing purpose, mechanism, examples, and warnings. While all information is relevant, it lacks clear structure (e.g., bullets or sections) that would improve readability for an AI agent. It is somewhat verbose for the complexity.

  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 creates a sequencer component, the description does not state the return value or output (e.g., path of created COMP). It covers main use cases and warnings but omits what the agent can expect as a result. With no output schema, this gap reduces 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?

  Schema description coverage is 100%, so the schema documents each parameter. The description adds value by explaining how parameters relate to the mechanism (e.g., pattern values vs 1/0 flags for param vs cue actions) and connects to external concepts like manage_cue. This goes beyond the schema's individual 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 'Build a programmable step-grid sequencer' and distinguishes it from siblings by positioning it as a deterministic repeating-rhythm instrument between create_autopilot (random drift) and create_cue_sequencer (linear list). Specific examples like strobe on beats 1+3 and hue shift on the bar further clarify 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 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 versus alternatives: 'deterministic, repeating-rhythm instrument between create_autopilot (random drift) and create_cue_sequencer (linear list)'. It also includes a crucial caveat about offline timing ('beat-callback timing is UNVERIFIED offline') guiding when the tool may not work correctly.

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

• create_blob_reactiveA
  4.3/5.0
  Behavior5/5

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

  Discloses macOS permission prompt, variable tracker behavior by build, normalizing CHOP, and return format, going well beyond 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.

  Conciseness3/5

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

  Packs substantial detail but is verbose; front-loaded with purpose but could be tighter without losing essential info.

  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 (including nested objects) and no output schema, the description thoroughly covers the chain, return values, warnings, and edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description adds little to individual parameter understanding; it does provide context on how threshold interacts across operators but not 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 'Build a blob-position-tracking chain' and explicitly contrasts with create_motion_reactive, making the purpose and distinct resource 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?

  Distinguishes from create_motion_reactive and mentions macOS permission dialog and fail-forward behavior, but could more explicitly state when alternatives are preferable.

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

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

  Describes the pipeline steps, creation of a baseCOMP, potential macOS permission prompt, and return value. Annotations are minimal, and description adds significant 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.

  Conciseness4/5

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

  Description is a single paragraph that front-loads purpose and pipeline, but is slightly verbose. Still efficient 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?

  No output schema, but description explains return structure. With 13 parameters, the description and schema together cover the main aspects. Some edge cases (e.g., error handling) not detailed, but 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?

  Input schema has 100% description coverage. Description adds overall context but does not provide additional semantics beyond what each parameter's own description 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 traces blob contour/outline into vector line art, uses specific verbs and resources, and explicitly distinguishes from sibling tools like create_vector_lines and create_blob_reactive.

  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 (contour tracing) vs. alternatives (full vectorization, blob reactivity) and describes source options (camera, file, synthetic, existing TOP) with context for each.

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

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

  The description discloses key behaviors beyond the annotations: re-entrancy, persistence of the last take in comp.store, large-take disk offloading, and a known limitation (time-dependent playback reads 0 when paused). The annotations only declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the description adds substantial behavioral 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.

  Conciseness4/5

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

  The description is a single coherent paragraph that front-loads the main purpose and then adds essential details. Every sentence serves a purpose (behavior, re-entrancy, persistence, large-take handling, limitation note). It is not overly verbose, though it could be slightly more structured (e.g., bullet points for clarity). The efficiency is high given 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?

  Given the tool's complexity (8 parameters, 2 required, no output schema), the description covers the core workflow, re-entrancy, persistence, large-take behavior, and a known limitation. It sets clear expectations for the agent (e.g., the Null CHOP output ready for bind_to_channel). While it does not detail every edge case (e.g., what happens if sourceChop changes after creation), the provided information is sufficient for effective 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?

  With 100% schema description coverage, the baseline is 3. The description adds value by explaining the overall workflow (e.g., how 'takeName' acts as a storage key, 'recordOnCreate' sets Record=1, 'autoBind' relates to the Null CHOP). While individual parameter details are already in the schema, the description contextualizes their role in the system, justifying a slightly higher 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 identifies the tool's purpose: building a CHOP recorder/player container that captures and replays channels via specific TouchDesigner components (Trail CHOP, Table DAT, Datto CHOP, etc.). The verb 'Build' and resource 'CHOP recorder/player container' make the action and output distinct. The description differentiates from siblings like 'create_capture_loop' by detailing the internal mechanism, ensuring unique identity.

  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 re-entrant behavior ('re-running with the same name updates controls without rebuilding') and persistence details, but it does not explicitly state when to use this tool versus alternatives (e.g., other capture tools among siblings). It provides context for the typical use case (recording and playing back CHOP channels) without offering exclusion criteria or comparisons.

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

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

  Annotations indicate it's not read-only, not destructive, and open-world. The description adds substantial behavioral context: uses webclientDAT, timerCHOP, websocketDAT, auto-reconnect, JSONPath-lite selectors, and mentions limitations like self-signed certs. This goes beyond annotations, though annotations already cover basic safety traits.

  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 efficiently conveys purpose, usage guidelines, and key details. It is front-loaded with the main purpose and distinguishes from sibling. Every sentence adds value, though slightly more structure (e.g., bullet points) could improve 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 the tool's complexity (12 parameters, 2 required, no output schema), the description covers the main functionality, distinguishes from sibling, mentions limitations (e.g., self-signed certs), and indicates output format (Null CHOP, Null DAT). It is sufficiently complete for an agent to understand and use 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?

  All 12 parameters have schema descriptions, so baseline is 3. The description provides a high-level overview but does not add significant detail beyond the schema. It summarizes key parameters (e.g., mode, url, selectors) but the schema already covers individual 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's purpose: 'Advanced live-data ingest for HTTP polling and WebSocket streams'. It distinguishes itself from the sibling tool 'create_data_source' by calling itself the 'richer-transport sibling' and explicitly listing the use cases where it is preferable.

  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 versus the sibling: '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 clearly delineates usage scenarios.

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

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

  Despite annotations already indicating a non-read-only, non-destructive action, the description adds crucial context: required TDMCP settings, creation of companion Text DATs, wiring to GLSL TOP parameters, best-effort uniform binding, and manual wiring needs for sampler2D. 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?

  Four sentences, each dense with information: purpose, prerequisites, behavior, and return values. No redundancy or filler. Exceptionally 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 creation tool with no output schema, the description thoroughly covers prerequisites, side effects, and return values (path, DAT paths, warnings). It fully equips the agent to understand what will happen and what to expect, even mentioning edge cases like sampler2D manual wiring.

  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 integration semantics beyond the schema—e.g., numeric uniforms bind to the Vectors page, sampler2D maps to TOP input and requires manual wiring, and resolution is set. This enhances understanding of how parameters affect the output.

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

  Purpose5/5

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

  The description clearly states 'Create a GLSL TOP under parent_path that renders a custom fragment shader' with specific verb and resource, distinguishing it from sibling tools like create_glsl_material or apply_glsl_top_mapping.

  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 on when to use this tool versus alternatives. It describes the action but omits exclusions or alternative tool recommendations, which is a gap given the large sibling set.

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

• create_halftoneA
  4.3/5.0
  Behavior5/5

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

  The description goes beyond annotations by detailing what the tool creates (baseCOMP, GLSL TOP, Select TOP, Null), how it handles source vs. noise, and the exposed knobs. It also discloses that no device permissions are needed when no source is provided. The annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are consistent and the description 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.

  Conciseness4/5

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

  The description is a single paragraph that is relatively long but each sentence adds unique information. It is front-loaded with the core effect description. While not overly concise, it avoids redundancy and is 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 (8 parameters, no output schema), the description adequately explains what is created, the return value (summary with JSON block containing paths and preview), and the exposed controls. It covers key aspects but could be slightly more structured about the output format.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents each parameter well. The description adds overall architectural context (e.g., 'inline shader', 'Select TOP') but does not add significant per-parameter meaning beyond what is in the schema. 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's purpose: to build a print/comic print-look effect with styles like halftone dots, CMYK separation, dithering, or posterization. It specifies the verb 'build' and the resource (a baseCOMP with GLSL TOP), distinguishing it from sibling 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 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 retro aesthetics and classic print looks. It explains the difference when a source is provided versus omitted, but does not explicitly state when not to use it or mention alternatives, though the sibling list is extensive.

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

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

  Annotations indicate readOnlyHint=false, destructiveHint=false, openWorldHint=true. Description adds beyond this by detailing behavior: creates a baseCOMP, returns paths, warns about dependencies (Ollama serve, Anthropic headers, TOX unverified), and clarifies API keys are never seen by MCP server. 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?

  Description is a single dense paragraph, front-loaded with purpose. It efficiently covers modes, providers, return values, and caveats. Could benefit from bullet points for readability, but no wasted sentences.

  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 moderate complexity (14 params, two modes, multiple providers) and no output schema, description explains return values and includes important notes (webclientDAT details, TOX par names unverified). Fairly complete for agent 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?

  Schema description coverage is 100% (all 14 parameters described). The description does not add extra meaning beyond summarizing modes; it mostly repeats schema info. Baseline 3 is appropriate as schema covers parameter semantics adequately.

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

  Purpose5/5

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

  Description clearly states the tool 'stands up a prompt → response LLM chain' as a self-contained baseCOMP in TouchDesigner. It specifies two modes (webclient and tox_drop) and distinguishes itself from siblings that create different components like create_3d_scene 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?

  Description provides explicit guidance on when to use each mode (webclient for stock chain via webclientDAT, tox_drop for dropping TOX) and default provider (ollama). It also includes provider-specific notes (Anthropic uses x-api-key, Ollama requires ollama serve). However, it does not explicitly state when not to use this tool or suggest alternatives.

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

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

  Discloses creation of Table DAT, buttons, morph knob, and that pulses/strings are skipped. Reuses manage_cue engine and mirrors slots into cues, providing behavioral context 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?

  Description is dense but each sentence adds value. Front-loaded with core purpose, but could be slightly more streamlined. Still 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?

  Covers the tool's purpose, components, behavior, dependencies, and interoperability sufficiently. Without output schema, return behavior is not detailed, but overall context is 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 coverage is 100%, so baseline is 3. Description adds meaning by explaining how parameters like slot, morph_seconds, and quantize fit into recall actions, and ties parameters to overall functionality.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 creates a playable snapshot row for storing and recalling looks of a control COMP. Distinguishes from siblings by mentioning 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?

  Provides context: prerequisites (build cues/params with create_control_panel first), and mentions what is always skipped. Does not explicitly list exclusions or alternatives but gives 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_midi_note_reactiveA
  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. The description adds context beyond annotations by detailing the chain structure (midiinCHOP → eventCHOP → Null CHOP), explaining the binding behavior, and warning about hardware gating. This provides meaningful behavioral insight.

  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 primary purpose and contrast with a sibling. It uses clear, structured sentences. While slightly verbose, it efficiently conveys key 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?

  Given the tool's complexity (creating a multi-CHOP chain), the description covers the chain architecture, source options, and note channel exposure. It lacks an explicit statement about what the tool returns (likely the created component), but the overall context is sufficient for an agent to understand the tool's behavior.

  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 described. The description adds value by explaining the semantic difference between 'synthetic' and 'device' sources, the hardware gating for device_name, and the note channel naming convention for 'notes'. This enhances 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 purpose: building a MIDI note to per-note trigger/velocity chain exposing bindable channels on a Null CHOP. It distinguishes from sibling 'learn_control' by contrasting that it binds one CC versus this tool creating a full note-event chain, demonstrating specific verb and resource.

  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 on using the 'source' parameter, explaining when to use 'synthetic' (preview without hardware) vs 'device' (when MIDI keyboard is connected), and notes that device path is hardware-gated and held from release. It contrasts with 'learn_control' as an alternative but does not provide a comprehensive when-not-to-use list.

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

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

  The description discloses that it renders a TOP (consistent with readOnlyHint=false), uses GPU rasterization, and optionally auto-wires to senders. This adds value beyond the annotations, which only indicate non-destructive and 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?

  The description is a single, concise paragraph that front-loads the main action and packs all essential information without redundancy. 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 complexity (15 parameters, no output schema) and rich annotations, the description provides a complete understanding of its role, output, and integration with ControlNet and external senders. 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?

  Schema description coverage is 100%, so the schema already fully documents each parameter. The tool description does not add parameter-specific details, but it provides overall context. A score of 3 is appropriate as per guidelines.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Render a canonical OpenPose-colored stick figure TOP') and the resource (from a pose CHOP). It differentiates from siblings like `create_pose_tracking` by specifying it's the driver that produces the conditioning image, not the tracker 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 implies usage context: 'from an existing pose CHOP produced by create_pose_tracking' and explicitly says 'No model inference — this tool produces the driver conditioning image that ControlNet consumes,' guiding when to use. It does not explicitly mention alternatives for visualization, but the context is clear enough.

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

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

  Annotations show it is not read-only, not destructive, and open-world. The description adds substantial behavioral detail: it builds a baseCOMP with specific subcomponents, creates an output Null TOP, and includes live custom params for overrides. This is more than sufficient 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 detailed but well-structured, front-loading the purpose and rows usage, then listing built components and output. While it could be slightly trimmed, every sentence adds value and it is not 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 (8 params, nested objects, no output schema), the description covers the overall function, input structure, built components, output location, and live parameters. It also distinguishes from siblings. Minor omissions include error behavior or performance notes, but it is largely 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 input schema already has 100% parameter descriptions, but the description adds meaning by explaining that rows define the setlist with source, duration, and transition, and maps to the built components. It also explains the default_transition and loop 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 clearly states it creates a layer-1 wall-clock setlist player for VJ shows, specifies the resources it builds (baseCOMP, Select TOPs, Switch TOP, etc.), and explicitly distinguishes itself from sibling tools create_clip_launcher and create_cue_sequencer.

  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 use for rehearsed VJ shows and differentiates from manual grid (clip launcher) and music-aligned sequencer, providing clear context. However, it does not explicitly list when not to use it or prerequisites.

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

• create_spectrumA
  4.3/5.0
  Behavior4/5

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

  The description details behavioral aspects beyond annotations: it creates a Null CHOP with bindable channels, includes a Sensitivity knob, and lists source options with their implications (e.g., permission popup, testing). It does not mention error handling or replacement behavior, but overall covers key behaviors.

  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 core purpose and then provides guidance. While packed with information, it is efficient and avoids redundancy. Could be slightly more scannable, but overall concise.

  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 explains the output (Null CHOP with frequency bins) and covers source variants and key controls. It lacks details on error cases or exact output structure, but is sufficient for a creation tool with 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%, so the description adds limited new meaning. It reinforces usage context (e.g., '16 or 32 is typical') but largely mirrors schema descriptions. A score of 3 is appropriate as the description does not significantly deepen 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 purpose: 'Build an FFT audio-spectrum analyzer that exposes N separate, ready-to-bind frequency-bin channels (band0..band{N-1}) on a Null CHOP.' It distinguishes itself from siblings like extract_audio_features and create_audio_reactive, making selection 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?

  Explicit guidance is given on when to use this tool versus 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.' Also mentions potential macOS permission popup for 'device' source.

  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
  Behavior5/5

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

  The description thoroughly discloses behavioral traits: it creates a web server that listens on all interfaces, accepts unauthenticated writes, and includes security implications. It also explains how the dashboard interacts with other tools (manage_cue, create_panic). This adds significant value 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.

  Conciseness4/5

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

  The description is a single paragraph of about 120 words, packing essential information without redundancy. It fronts the main purpose and includes security and prerequisite details. While dense, it remains readable and organized.

  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 (all well-documented) and no output schema, the description explains the tool's purpose, components, prerequisites, security, and layout options (v1/v2). It covers all necessary context for an AI agent to understand when and how to use 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?

  With 100% schema coverage, each parameter already has detailed descriptions. The overall description adds context by explaining how parameters like 'cues' and 'faders' work together (e.g., 'cue buttons fire that COMP's cues') and why port numbers should be distinct. This enriches understanding 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 'live-performance cockpit' and lists its components (cue buttons, faders, panic button, readout). It mentions similarities to 'create_phone_remote' but doesn't explicitly differentiate its unique purpose from other sibling tools like '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 provides context on when to use the tool (unified web dashboard) and mentions prerequisites and alternatives ('Store cues with manage_cue, expose params with create_control_panel, and run create_panic first'). It also includes a security warning about trusted networks, but 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_tempo_syncA
  4.3/5.0
  Behavior4/5

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

  The description explains that emit_events broadcasts a beat event over WebSocket, providing behavioral context beyond annotations. It does not contradict annotations (readOnlyHint=false, destructiveHint=false). The description adds value by detailing channels and event broadcasting.

  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 function and then details channels and pairing. It is slightly verbose but every sentence contributes meaningful guidance. 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 no output schema, the description adequately explains the return values (channels, event). It suggests pairing with another tool, covering usage context. It lacks prerequisites but is sufficient for a self-contained 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 all 4 parameters described. The description adds meaning by explaining how period affects ramp and bar channels and that expose_controls retunes the beat division on the fly, enriching 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 that the tool creates a tempo clock driven by TouchDesigner's global tempo, exposing specific beat-synced channels (ramp, pulse, beat/bar counters, bpm) on a Null CHOP. This distinguishes it from siblings like create_audio_reactive or create_beat_grid_sequencer.

  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 binding parameters to lock visuals to the beat and suggests pairing with extract_audio_features for full musical reactivity. It does not explicitly state when not to use, but the specific function makes usage clear.

  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.3/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 workflow, camera opt-in, default synthetic source, and return details (container, paths, warnings, preview). Annotations are readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description does not contradict them. It adds valuable context about the system's 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 detailed but somewhat long (7-8 sentences). It front-loads the main purpose and key behaviors, making it informative. However, it could be slightly more concise without losing clarity. Still, it is well-structured and avoids 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?

  Given the tool's complexity (22 parameters, no output schema), the description is fairly complete. It explains the workflow, non-realtime aspect, source options, and output. It lacks details on error states or prerequisites, but overall provides sufficient context for an AI agent to select and 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?

  The input schema has 100% description coverage for all 22 parameters, so the description does not need to add much. The description mentions a few key parameters (Threshold, PreBlur, etc.) but does not add significant meaning beyond what is already 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?

  The description clearly states the tool's purpose: building a pulse-driven image-to-vector-lines system. It details the specific steps (capture frame, prepare mask, trace, generate overlay, composite) and the intended use case. The tool name and title align well, and the description helps distinguish it from sibling tools like 'create_halftone' or 'create_generic_art'.

  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 about when to use this tool: it mentions the non-realtime nature (Phase 1 is intentionally not realtime) and that the artist presses the Vectorize pulse. It also explains that source defaults to synthetic for preview without camera permissions. However, it does not explicitly state when not to use it or list 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.

• create_xy_padA
  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. The description adds behavioral context: it mentions that the pad reads drag via a Panel CHOP, that u/v drag-channel names are probed at build time and mismatches are warned, and that it creates a Container COMP. 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 moderately lengthy but well-structured: it starts with main purpose, then details customization options, usage instructions, and technical specifics. Every sentence provides relevant information. Minor redundancy could be trimmed, but overall it is efficient.

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

  Completeness4/5

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

  Given the complexity (11 parameters, no output schema), the description covers the tool's behavior comprehensively: it explains the created component, how to use it, optional Z axis, and remapping. It does not mention error handling or performance, but is adequate 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?

  Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of z_target ('adds a slider when set'), the remapping via ranges, and the option to leave targets empty for later binding. This goes 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 clearly states the tool's purpose: 'Build a draggable 2D (XY) gesture pad'. It provides specific verb (Build) and resource (gesture pad), and distinguishes from sibling tools (e.g., create_audio_reactive, create_3d_scene) by specifying its unique 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 offers usage guidance: it explains when to use the tool (to build a 2D pad), how to customize with optional targets and ranges, and even suggests alternative use when leaving targets empty and binding later with bind_to_channel. However, it does not explicitly state when not to use it or list direct alternatives alongside.

  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. The description adds behavioral context by confirming it does not mutate the project and detailing the return format (PASS/WARNING/FAIL/UNVERIFIED checks), which 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 compact at three sentences, front-loading the core action and providing necessary context without redundancy. 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 has a clear purpose, well-documented parameters with 100% schema coverage, annotations, and an output schema, the description provides all necessary context 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?

  With 100% schema description coverage, all three parameters are already well-documented in the schema. The tool description does not add additional meaning to the parameters, so it meets the baseline expectation.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: to check TouchDesigner reachability, display/projector topology, and status DAT health for physical installations. It distinguishes itself from other diagnostic tools by specifying it is a room/hardware preflight and that it returns PASS/WARNING/FAIL/UNVERIFIED checks without mutation.

  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 frames the tool as a 'room/hardware preflight for physical installations,' which provides clear context for when to use it. However, it does not explicitly state when not to use it or compare it to alternatives like inspect_gpu_and_displays, though the purpose is distinct enough.

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

• enhance_buildA
  4.3/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 important safety behavior: preview-only defaults, native Apply/Keep approval, CAS/readback, compensating restore, and that autoApply never bypasses approval. This is rich behavioral context not present in the 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.

  Conciseness4/5

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

  The description is concise, with the core purpose front-loaded in the first sentence. The second sentence packs many technical safeguards into a dense list, which is efficient but potentially jargon-heavy for an agent not familiar with terms like CAS/readback.

  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 7 parameters, a nested visualCritique object, and an output schema, the description plus schema covers the essential context. It explains the LLM-driven workflow and key safety constraints, though it doesn't clarify prerequisites like 'configured LLM' or define 'allowlisted' in concrete terms.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 explains all 7 parameters. The description adds some high-level context (e.g., visualCritique uses a calibrated receipt), but it doesn't meaningfully extend 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 clearly states the tool runs score_build and asks a configured LLM for bounded, allowlisted improvements, which is a specific verb+resource. It distinguishes itself from siblings like score_build and optimize_performance by framing itself as the LLM-planned enhancement layer.

  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 schema's focusCriterion param explicitly excludes errors/perf and points to summarize_td_errors / optimize_performance, giving clear alternative guidance. The description also sets preview-only defaults and warns about apply behavior, though it doesn't fully enumerate when to prefer this over related tools like auto_repair_loop.

  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.3/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 explains specific effects: replaces stale selection, sets explicit current operator, suppresses focus in Perform/headless/disabled states, and returns fail-closed readback. This directly supplements the structured 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 about 70 words in 4 sentences, front-loaded with the core purpose. The final sentence about 'smooth colour highlights remain held pending live compare-and-swap proof' is cryptic but adds behavioral detail; it could be clearer but is not wasteful.

  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 no output schema, but the description mentions the return type ('applied or fail-closed suppression readback'). It covers boundaries (no panes/topology) and state interactions. Given the moderate complexity and 100% schema coverage, this is adequately 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?

  All 5 parameters have schema descriptions (100% coverage), so the baseline is 3. The description doesn't add parameter-specific details beyond the schema, but it provides context that helps interpret the 'action' and 'framing' 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 'Safely follow one same-parent operator group in an existing TouchDesigner Network Editor,' which is a specific verb and resource. It differentiates from siblings like arrange_network by emphasizing 'UI-only' and 'never creates panes or changes project topology.'

  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 reuses the active pane, is UI-only, and doesn't change topology, implying when it's appropriate. However, it doesn't explicitly name alternatives or state clear when/when-not conditions, 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.

• generative_classics_packA
  4.3/5.0
  Behavior4/5

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

  Annotations declare destructiveHint=true, and description confirms by stating 'writes a portable bundle JSON'. Adds context about being pure Node, avoiding bridge. 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?

  Single paragraph with three sentences, front-loads purpose. Efficient, though could be slightly more structured (e.g., bullet points). 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 3 parameters, no output schema, description adequately covers behavior, output format (technique cards + list of recipes, bundle JSON), and environment requirement. Not missing critical info.

  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 description adds meaning: explains what list_only controls, default install_path location, and overwrite flag behavior. Exceeds 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?

  Description clearly states it is a curated technique pack of generative looks, and specifies two modes (list_only vs full export). This distinguishes it from siblings like 'curated_collection_pack' or individual '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 Guidelines4/5

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

  Describes when to use each mode (list_only vs false) and highlights 'Pure Node — no TouchDesigner bridge required'. However, it does not explicitly state when NOT to use or compare with alternatives like 'curated_collection_pack'.

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

• import_setlistA
  4.3/5.0
  Behavior4/5

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

  Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses creation behavior, skipping logic, dry-run capability, and dependency on external vault path. It provides context that annotations alone do not.

  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 efficient, front-loading the main action. Each sentence adds value, though slightly long. It uses clear formatting with capitalization for key terms.

  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 explains the return value (resolved note path, lists of built/skipped tracks). It covers prerequisites and dry-run mode. Could mention whether operators are created anew or updated, but overall 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% (all 3 params described). The description adds meaning by explaining the note parameter's structure (frontmatter fields) and how the name is resolved, and that parent_path defaults to /project1. This enhances the schema's 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 it reads a setlist note and builds scenes by creating operators in TouchDesigner. It specifies the data formats (frontmatter tracks/scenes) and distinguishes from siblings like setlist_runner for skipped 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 explains when to use (pre-stage visuals) and when not (preset-only/cue-only scenes, which should be handled by setlist_runner). It also mentions using dry_run for validation. Prerequisites like configured vault path are noted.

  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?

  Annotations already declare readOnlyHint=true. The description adds value by specifying the offline fallback behavior and listing exact data returned (name, driver, VRAM, etc.), which enriches understanding 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 plus a brief offline note, front-loaded with essential information. No wasted words; 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 simple read-only tool with one optional parameter and no output schema, the description covers purpose, usage, return content, and error state completely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 only parameter 'include', so baseline is 3. The description adds no further semantic detail beyond stating that omitting it returns all three sections, which is already implied. Minimal added 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 it is read-only and returns specific data (GPU info, monitor topology, perform mode). It distinguishes its purpose for planning output mapping, dome rigs, and multi-display shows, which is a concrete use case 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?

  The description explicitly advises using it for planning output and mentions it is offline-safe, guiding when to use. It does not list alternatives or when not to use, but the context is clear enough for the agent.

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

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

  Annotations show readOnlyHint=false and destructiveHint=false. The description adds behavioral context: it may create a default skeleton if the file is missing and can overwrite with defaults via reset=true. 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 contributing: first sentence specifies action and location, second explains caching rationale, third adds edge-case behavior. No redundancy, properly 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 covers purpose, when to use, parameter effects, and edge cases (missing file, reset). With good annotations and output schema, it is sufficient for correct agent 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 both parameters described. The description restates parameter behavior (default path for profile_path, overwrite for reset) and adds output info about resolved path, but does not significantly enhance schema 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 verb 'reads' and the resource 'session-profile.json', specifying it returns a unified JSON snapshot for agent startup. It also distinguishes from sibling tools like learn_conventions by explaining it caches their outputs.

  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 using it at the start of every session and explains its caching benefit over running four other tools. However, it doesn't explicitly state when not to use it or provide alternatives beyond the cached tools.

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

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

  The description discloses that the tool 'writes/overwrites local files in out_dir' and 'Requires a running bridge', adding context beyond the annotations (readOnlyHint=false, destructiveHint=true). It also mentions the return values. No contradiction exists, so it adds meaningful 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 two sentences long, starts with the core action, then gives usage guidance, prerequisites, side effects, and return values. Every sentence adds useful information 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?

  With 12 parameters and no output schema, the description covers the primary workflow, side effects, and return values, but omits context for complex parameters like help_snapshot, idempotency_key, and provenance_policy. It is adequate for basic use but not fully complete 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 58%, leaving several parameters (idempotency_key, provenance_policy, expected_git_commit, operation_timeout_ms, confirmation_timeout_ms) without descriptions. The tool description provides some semantic context (e.g., out_dir receives .tox/manifest/README/docs, optional copy of docs/README) but does not explain these advanced parameters, so it only partially compensates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 resource ('one live TouchDesigner COMP') and clearly states the output (portable .tox package with manifest and optional docs/README). It distinguishes from sibling 'bundle_dependencies' by name and use case, leaving no ambiguity about 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?

  It explicitly says 'Use this for packaging a finished component' and directs to 'bundle_dependencies instead when external media must be collected and relinked'. This provides clear when-to-use and when-not-to-use guidance, naming the alternative sibling tool.

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

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

  Beyond the sparse annotations, the description discloses atomic replacement semantics, revision requirements for replace, root resolution precedence, and the critical caveat that brief text cannot override safety policies or user intent. This provides substantial behavioral context not available from 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?

  Three concise sentences pack critical information: main action, atomicity, revision check, root precedence, and safety constraints. Every sentence adds value, and the most important facts 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 presence of an output schema and the detailed description covering key behaviors (atomicity, revision handling, root precedence, safety limitations), the description is complete for an agent to correctly invoke the tool. No obvious information gap remains.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 compensates for some parameters: it explains expected_revision values ('absent' vs. exact revision) and project_root precedence. However, it does not elaborate on the 'brief' or 'action' parameters beyond common-sense inference from schema and overall 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's function with a specific verb and resource: 'Reads or atomically replaces the versioned brief at <project_root>/.tdmcp/agent-brief.json.' This unequivocally distinguishes it from sibling tools focused on operator creation and media connections.

  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 by detailing root precedence and stating 'cwd is never used,' but it does not explicitly contrast with alternatives or state conditions for when reading vs. replacing is appropriate. No sibling tool is mentioned as an alternative.

  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.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 valuable context beyond this: 'offline', 'deterministic', and the specific brief types (colorway, motion, texture, spatial reframe, performance cue). It aligns with annotations and enriches the behavioral 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 two sentences long, front-loaded with the core function, and the second sentence delivers important usage context (offline/read-only, planning purpose). Every word serves a purpose 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, the description correctly avoids detailing return values. It covers the tool's purpose, usage timing, non-mutating nature, deterministic behavior, and output categories, making it complete for a planning 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 for all five parameters, so the schema itself is fully descriptive. The description only echoes the source input concept ('one source node, asset, or package entry') without adding parameter-specific details, meriting 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's function with a specific verb ('turn') and resource ('one source node, asset, or package entry'), and specifies the exact output ('five deterministic remix briefs' in named categories). It distinguishes itself from sibling creation tools by emphasizing its planning/remix nature.

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

  Usage Guidelines4/5

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

  The description provides clear context: it is an 'offline/read-only planning tool for agents before mutating TouchDesigner networks,' implying use as a precursor to mutation. It does not explicitly name alternative tools or exclusion criteria, but the 'before mutating' guidance effectively communicates 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.

• profile_cook_costA
  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 behavioral details: it samples over a window, ranks by p95, and returns a structured object with hotspots and warnings. 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?

  Two sentences: first states what it does and how, second gives usage guidance and the return structure. Every word carries weight; no fluff. Well 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 that annotations exist, schema covers all parameters, and the description explicitly lists the return fields (enough to understand the output), the description is fully complete for the tool's complexity. No missing critical 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 coverage is 100% with detailed parameter descriptions. The description mentions 'N samples × intervalMs' which aligns with the samples and intervalMs parameters, but adds no new semantic meaning beyond what the schema provides. 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 ('profile', 'rank') and clearly identifies the resource (cook times over a window, hotspot nodes) with p95 ranking. It explicitly contrasts with the sibling tool get_td_performance, 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 second sentence directly advises when to use this tool: 'diagnose intermittent stalls that a single get_td_performance snapshot misses.' It names the alternative tool, providing clear context. However, it does not explicitly state when NOT to use it, leaving a minor gap.

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

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

  The description explicitly states it operates on the local filesystem without TouchDesigner bridge calls, and notes it returns an integration hint. While annotations indicate non-read-only and non-destructive, the description adds concrete behavioral context beyond annotations, though it could mention potential file overwriting (handled via parameter).

  Agents need to know what a tool does to the world before calling it. Descriptions 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, using two sentences to convey purpose, behavior, and constraints. It front-loads key information and avoids redundancy, each phrase earning 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 lack of an output schema, the description adequately explains what the tool returns (integration-hint) and its local filesystem nature. It covers all necessary contextual aspects for an agent to understand the tool's role in scaffolding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 has a clear description in the schema. The description adds marginal value by referring to a 'one-line idea' for the description parameter, but overall 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 identifies the tool as a meta-development tool that scaffolds a new tdmcp tool file and corresponding unit test from a one-line idea. It explicitly mentions the outputs (xSchema + xImpl + registerX and integration-hint), distinguishing it from sibling scaffold tools that focus on other 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 states it is a 'Meta DX tool' and clarifies that it involves 'No TouchDesigner bridge call — pure local filesystem generator,' helping agents understand it is for local file generation only. However, it does not explicitly contrast with sibling scaffold tools like scaffold_recipe_template or scaffold_extension, leaving partial ambiguity.

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

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

  Annotations already indicate readOnlyHint and destructiveHint. The description adds context about being offline-based and applying conservative version filtering, which complements 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.

  Conciseness5/5

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

  The description is two sentences, front-loading the key purpose and key features. Every sentence adds value with 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 presence of an output schema and annotations, the description sufficiently explains the tool's purpose, input parameters, and behavioral traits (read-only, offline, filtering). No obvious 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?

  Input schema covers all 5 parameters with descriptions (100% coverage). The description mentions filters (category, version) but does not add significant 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 searches TouchDesigner Python API classes, methods, and members from an offline knowledge base. It specifies the resource (Python API) and verb (search), and the mention of class category and version filters distinguishes 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?

  The description indicates when to use this tool (for Python API searches) and clarifies its read-only nature. It does not explicitly mention alternatives or when not to use, but the context of sibling tools provides implicit 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?

  Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by confirming 'Read-only' and describing the output format (normalized results with resource URIs and tool hints), which goes beyond what annotations provide. 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?

  The description is two sentences, front-loaded with 'Read-only' and the core purpose. No extraneous words; every phrase adds value. 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.

  Completeness5/5

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

  Given the existence of an output schema (not shown but stated), the description does not need to detail return values. It sufficiently covers the search scope, output format hints, and safety profile. Combined with thorough parameter schema, the description is 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?

  Schema coverage is 100% with clear descriptions for each parameter. The description adds context by listing the knowledge surfaces (operators, workflows, etc.) that align with the surface enum, slightly enhancing understanding beyond the schema. Baseline is 3, and the 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 clearly states it is a read-only search across multiple specific TouchDesigner knowledge domains (operators, workflows, examples, etc.) and mentions the return format (normalized results with URIs and tool hints). This provides a specific verb-resource pair and distinguishes from siblings like search_operators and search_python_api.

  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 does not explicitly state when to use this tool versus alternatives such as search_operators or search_python_api. While the broad scope is implied, there is no direct comparison or exclusion guidance, leaving the agent to infer usage context.

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

• set_parameter_expressionA
  4.3/5.0
  Behavior4/5

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

  The description discloses fail-forward behavior (per-item failures accumulate as warnings, partial batch still returns results), which is beyond the annotations. It also explains what each mode does at the internal API level (par.expr, par.bindExpr, par.val, par.reset()), adding transparency about effects. No contradiction 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 logically structured: first lists modes, then restrictions, then error behavior. It is slightly dense but every sentence adds unique value. The fail-forward sentence could be trimmed, but overall it is 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.

  Completeness4/5

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

  For a tool with five modes, array assignments, and environmental restrictions, the description covers the key behavioral nuances: mode semantics, restricted mode availability, and partial failure handling. It does not describe return values, but no output schema exists and the description is adequate 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 meaningful semantics by mapping modes to actual parameter fields (par.expr, par.bindExpr, par.val) and clarifying that 'constant' uses the `value` parameter, plus an example expression. This exceeds simply restating 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 ('Set') and resource ('parameters on a node') and enumerates five distinct modes ('expression', 'bind', 'constant', 'reset', 'unbind'), making the tool's function clear and distinct from siblings like set_parameters_batch which likely handles simple value assignments.

  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 usage context by explaining that expression/bind modes require TDMCP_RAW_PYTHON=on and TDMCP_BRIDGE_ALLOW_EXEC=1, and that in restricted mode only constant/reset/unbind are available via the structured endpoint. This gives clear guidance on when modes are usable, though it does not explicitly name alternative tools for simple parameter setting.

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

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

  Annotations indicate non-read-only, non-destructive, open-world. Description adds context: engine loading, timeline start, output CHOP structure, and coordinate space behavior. 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?

  Single, dense paragraph that front-loads the main action. Each sentence adds value, though could be broken into more structured points.

  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 inputs, outputs (CHOP details), and relationship to body tracking. Parameter descriptions are detailed. Lacks explicit explanation of return format but compensated by 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%, and description adds value by explaining output CHOP format and coordinate_space implications, complementing schema 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?

  The description clearly states it sets up MediaPipe hand tracking from a webcam, with specific details on engine loading, timeline starting, and CHOP building. It distinguishes from sibling setup_body_tracking by noting shared engine.

  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 for use: one-shot setup, coordinate_space advice for gesture detection, and engine sharing with body tracking. Does not specify when not to use, but offers clear guidance.

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

• setup_outputA
  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. The description adds behavioral details beyond annotations, explaining wiring specifics (e.g., bridging via Select TOP, winop assignment) and return values including warnings. 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 spans 4 sentences, is front-loaded with purpose, and each sentence adds value. It efficiently covers purpose, usage, parameter details, and return values without excess.

  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 return values (path, type, source, warnings) in the absence of an output schema, covers all output types, and notes non-fatal warnings. It could mention error cases or prerequisites but is adequate for a 5-param tool with openWorldHint=true.

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

  Parameters4/5

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

  Schema coverage is 100% with descriptions for all parameters. The description adds context about how parameters affect behavior (e.g., resolution is only for window, record_format for record type), and explains internal wiring details, complementing 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 routes a finished TOP to one of several output destinations (window, NDI, etc.) and creates the appropriate output node. This distinguishes it from sibling create_* tools which build visual elements, not route to outputs.

  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 'Typically the LAST step after building a visual' and advises feeding it output from create_* tools or create_layer_mixer. This provides clear usage context, though it lacks explicit 'when not to use' statements.

  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.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, so the description's reinforcement is consistent. It adds valuable behavioral context beyond annotations: the tool returns a categorized status report and covers specific check categories. 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 sentences, front-loaded with the core purpose and key capabilities. Every phrase earns its place 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?

  Given a read-only annotation, full parameter documentation, an output schema, and a description that covers purpose and usage timing, the tool is well contextualized. The description is complete 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% and each of the 5 parameters has its own explanatory description. The tool description does not add parameter-specific details, but the schema fully documents them, 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 the tool is a read-only pre-show check that aggregates multiple system statuses (bridge reachability, node errors, topology, cook-time budget, GPU/display, perform-mode) into a single PASS/UNVERIFIED/WARN/FAIL report. It uses specific verbs and resource scope, and the 'without mutating the project' phrase distinguishes it from mutation-centric 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?

  Explicitly states when to use it: 'before rehearsals or venue handoff.' It also clarifies the purpose of the report (to see what is safe/unverified/suspicious/failing) and that it does not mutate. It does not name alternative tools or explicit when-not-to-use, but the context is clear enough.

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

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

  Annotations already declare readOnlyHint=true, and the description adds that it uses offline operator docs and workflow patterns, and returns connection hints and next tool hints, providing useful 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 efficiently conveys the tool's purpose and behavior without extraneous 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's complexity, the presence of an output schema, and full schema parameter coverage, the description is succinct yet complete, covering purpose, behavior, and key constraints.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions for all parameters. The description does not add additional meaning to any parameter beyond what the schema provides, 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 suggests an ordered operator chain for a goal, and explicitly distinguishes it from creation tools by stating 'it does not create 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 indicates it is read-only and provides suggestions rather than creating nodes, giving clear context for when to use it, though it does not name specific sibling tools as alternatives.

  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.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 reinforces this with 'Read-only' and 'does not create or modify'. It adds specific behavioral context by listing validation targets (operator docs, connections, filters, version compatibility), 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 two sentences, front-loaded with 'Read-only', and contains no redundant words. Every sentence adds value: first states purpose and read-only nature, second clarifies it does not mutate.

  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 5 parameters, full schema coverage, annotations, and an output schema, the description sufficiently covers the tool's purpose and constraints. It explains what the tool validates against without needing to detail return values (covered by 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 description coverage is 100%, so baseline is 3. The description does not add new meaning to individual parameters beyond what the schema already provides (e.g., 'optional expected operator family' is already in the schema). No additional semantic value from 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 explicitly states the verb 'validate' and the resource 'ordered TouchDesigner operator chain'. It specifies what it validates against (operator docs, connections, filters, version compatibility) and clearly distinguishes itself from sibling tools by emphasizing it is read-only and does not create or modify 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 states when to use the tool (for validation) and notes it does not create or modify, guiding away from mutation tasks. However, it does not explicitly exclude other read-only alternatives (e.g., get_td_nodes, search_operators) or provide 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.

• animate_parameterA
  4.4/5.0
  Behavior4/5

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

  The description discloses key behaviors: creates LFO CHOP, binds targets, switches to expression mode. It does not mention side effects like performance or re-invocation behavior, but annotations provide safety hints (non-destructive, open world).

  Agents need to know what a tool does to the world before 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 wasted words. Front-loaded with core purpose, immediately 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?

  The description covers main behavior and parameter usage adequately. With 7 parameters all described in schema, the description fills the gap for behavioral context. No output schema, but return value is 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%, and the description adds context beyond schema, e.g., target format and behavior, waveform range sweep. This adds meaningful value despite 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 drives node parameters over time using an LFO, distinguishing it from manual keyframing. It specifies verb, resource, and mechanism, effectively differentiating from siblings like create_keyframe_animation.

  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 use for parameter animation without manual keyframing, creating a clear contrast. However, it lacks explicit when-not-to-use or alternative guidance, though the contrast is strong.

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

• apply_recipeA
  4.4/5.0
  Behavior4/5

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

  Annotations indicate non-destructive and open-world. The description confirms creation of new entities (baseCOMP, nodes) and adds behavioral details like auto-layout, verification, and preview. It does not contradict annotations and provides extra context 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.

  Conciseness4/5

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

  The description is a single paragraph that is efficient but could be slightly more structured. It front-loads the primary action and includes necessary details without excess.

  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 comprehensive for a tool with two parameters and no output schema. It explains return values (summary, JSON block), error handling, and the full workflow. No missing critical information.

  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 both parameters with descriptions, but the description adds meaning: id must come from list_recipes, parent_path is a COMP. This clarifies constraints and usage beyond 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: instantiating a built-in recipe by ID inside a COMP. It details the steps (create baseCOMP, add/wire nodes, expose controls, auto-layout, verify, preview) and distinguishes from siblings like list_recipes and other recipe-related 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 have a recipe ID and want to build a ready-made network. It mentions error handling for unknown IDs, guiding appropriate usage. It could explicitly mention alternatives like scaffold_recipe_from_network or import_recipe_bundle, but the context is sufficient.

  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?

  Discloses the full workflow: sampling, fingerprint extraction, heuristic mapping, parameter tuning, dispatch, and optional compositing via apply_top_op. Also explains the dry_run behavior and the rationale for the synthetic default. No contradictions with annotations (readOnlyHint=false, destructiveHint=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.

  Conciseness4/5

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

  The description is a single dense paragraph covering the core algorithm, default behavior, and key options. It front-loads the main action, but could be more structured (e.g., bullet points for clarity). Still 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?

  Given 9 parameters, no output schema, the description explains the algorithm and default rationale but does not describe the normal return value (the generated generator) or details of the heuristic mapping. The gap for normal-case output reduces 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 100% schema description coverage, the baseline is 3. The description adds value beyond the schema by explaining why 'synthetic' is the default (macOS permission hangs) and clarifying dry_run's purpose (returns mapping without building). 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 clearly states what the tool does: sample audio, compute a 4-feature fingerprint, run a deterministic heuristic to pick a Layer 1 generator (naming specific options), and dispatch it with tuned parameters. This distinguishes it from sibling create_* tools as an orchestrator.

  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 guidance on audio_source defaulting to 'synthetic' to avoid macOS mic-permission hangs, and mentions dry_run for testing. However, it does not explicitly contrast with using individual create_* tools directly, limiting when-not-to-use advice.

  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.4/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 specific side effects: node creation and reading the note file, while explicitly stating it does NOT write to the vault. It also explains the sync behavior, return values, and configuration requirements. This addresses operational expectations comprehensively.

  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 action and then adds side effects, usage guidance, return values, and prerequisites. Every sentence contributes useful information, but the length is somewhat dense; a slight trimming could improve conciseness without losing critical 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 (node creation, sync behavior, external file access, return values), the description covers all essential aspects: side effects, does-not-do clarification, configuration prerequisites, and output. Since there is no output schema, the explicit list of returned fields is especially valuable. The description 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% for all 4 parameters, so the baseline is 3. The description reinforces the 'file' parameter pointing at a vault note and mentions sync with 'sync:true', but these details are already present in the schema property descriptions. Thus, the description adds minimal additional semantic value 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 action ('CREATE a Text DAT in TouchDesigner'), the specific resource (a Text DAT whose `file` parameter points at a vault note), and the intended outcome (note text loads into TD). It is distinct from generic node creation siblings by emphasizing the vault binding and sync 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?

  The description provides clear usage context, including the intended visual use case ('text/lyrics source for your visuals') and a concrete integration step ('Wire the DAT into a Text TOP to render it'). It also lists explicit prerequisites (TDMCP_VAULT_PATH, TDMCP_RAW_PYTHON=on, TDMCP_BRIDGE_ALLOW_EXEC=1). It does not explicitly name alternatives or exclusions, but the guidance is sufficiently clear for most scenarios.

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

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds valuable behavioral context: it 'survives TDMCP_BRIDGE_ALLOW_EXEC=0' (important for safety), explains the reconciliation process, and the optional inclusion of undocumented optypes. 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?

  Four sentences, each serving a purpose: main function, optional behavior, single operator usage, and a safety constraint. No redundancy, front-loaded with key 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 simplicity of the tool (2 optional params, no output schema) and good annotations, the description is largely complete. It covers both modes and the constraint. However, it does not explicitly describe the return format or what 'flags' means, which would be helpful 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 both parameters described. The description adds that omitting operator checks the whole knowledge base and passing one checks only that one, which aligns with the schema's optional nature. This adds marginal value beyond the schema, but not enough to exceed 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 clearly states the verb 'reconcile' and the resources: 'operator knowledge base' vs 'ground-truth creatable-optype list'. It specifies the exact function: flag documented operators that are creatable vs deprecated/unavailable, and optionally list undocumented live optypes. This distinguishes it from sibling tools like search_operators or 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 provides clear context: use to check availability of operators, optionally for a single operator or the whole knowledge base. It mentions the constraint 'Survives TDMCP_BRIDGE_ALLOW_EXEC=0'. However, it does not explicitly state when not to use or name alternative tools.

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

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

  The description details the append-only nature, file format (JSONL), storage location, and offline capability, going well beyond the sparse annotations. It also explains the behavior of each action, providing comprehensive 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.

  Conciseness4/5

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

  The description is front-loaded with the main purpose and is concise, though slightly dense. It effectively communicates key information without 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 no output schema, the description explains return formats (JSON for read, markdown for export) and the trail file format. It covers all three actions and their parameters adequately 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?

  With 100% schema description coverage, the description adds some value by explaining defaults and context (e.g., 'Ignored for read/export'), but does not significantly enhance 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 it maintains an append-only per-component revision history as a JSONL trail, listing three distinct actions (append, read, export). It distinguishes from siblings by mentioning it pairs with save_component_to_vault and provenance_stamp.

  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 when to use the tool (offline, no TD bridge required) and mentions related tools. However, it does not explicitly state when not to use it or provide direct comparisons with alternatives, which slightly limits guidance.

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

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

  The description discloses extensive behavioral traits: scanning folder, building specific TOP/CHOP network, exposing custom pars, handling missing folder gracefully (empty montage instead of error). Annotations are consistent and the description adds context beyond the simple flags.

  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 but packs many details. It is front-loaded with the main action ('Point at a folder and build...') and then elaborates. Could be more structured with breaks, but 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 tool's complexity (14 params, internal node network), the description covers functionality, error handling, output signals, and parameter roles. It is complete for an agent to understand 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?

  All 14 parameters are described in the schema (100% coverage), but the description adds meaning by explaining how parameters like 'mode', 'clock', 'crossfade' affect the montage behavior. This goes beyond schema definitions, providing operational 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 builds a self-running clip montage from a folder. It provides a step-by-step breakdown of internal node construction, distinguishing it from other creation tools like 'create_video_player' or 'create_audio_reactive' 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 by stating 'Point at a folder', but does not explicitly state when to use this tool versus alternatives, nor provide exclusion criteria. It assumes the agent will understand the context from the detailed description.

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

• create_autopilotA
  4.4/5.0
  Behavior5/5

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

  Discloses that the tool modifies target COMP live at runtime and creates new nodes under parent_path. Notes return format with summary and JSON block, and states no preview image. No contradictions with 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.

  Conciseness4/5

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

  Single paragraph is well-structured and front-loaded with purpose. Could be slightly more structured with bullet points for readability, but it is concise and informative.

  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, description fully explains return value (summary + JSON block) and covers all parameters. Addresses edge case ('no preview image') and mentions dependencies (tempo clock, randomize_controls, manage_cue).

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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. The tool description adds minimal extra context (e.g., usage of comp_path with modes), but baseline of 3 is appropriate as schema already explains parameters well.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specific verb 'Build a beat-driven auto-VJ' and clearly identifies resources (Beat CHOP, CHOP Execute DAT, target COMP). It distinguishes itself from siblings like create_cue_sequencer by focusing on beat-driven randomization and cue cycling.

  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?

  States to 'Pair with a generated system (or a control panel) as the target' and implies use for beat-driven auto-VJ. Lacks explicit when-not-to-use or direct alternatives among siblings, but context is clear enough.

  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.4/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. The description adds behavioral details: the launcher fires cues instantly or with a crossfade (morph_time), and it is built inside a specified Control COMP. No contradictions observed.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 includes both usage instructions and a prerequisite note. 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?

  For a tool with 6 parameters and no output schema, the description covers the essential behavior (grid of clip buttons, instant vs. morph). It references related tools (manage_cue, create_control_panel) and explains the interaction mode. Minor gap: no mention of layout defaults beyond 'derived from cues length'.

  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 parameters are well-described. The description adds meaning by explaining the grid layout concept and morph_time behavior (crossfade, eased). This goes beyond the schema, which lists defaults and constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 an Ableton-style clip launcher grid panel with buttons for each named cue. It uses specific verbs ('Build', 'Open', 'tap') and resources ('Container COMP', 'cue'), distinguishing it from other 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 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 (after storing cues with manage_cue/create_control_panel) and how to interact with the result (open in Perform/Panel mode). It does not explicitly list when-not or alternatives, but the guidance is sufficient.

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

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

  Discloses creation of baseCOMP, parameters mapping to specific TOPs, exposure of knobs, and output format including errors and preview. Annotations are minimal, so description carries full burden and does so well.

  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?

  Front-loaded with purpose, each paragraph adds value. Could be slightly more concise but overall well-organized.

  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 all major aspects: creation, parameter behavior, optional inputs, output format, and even error reporting. No output schema but description 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 descriptions already cover each parameter fully (100% coverage). The description adds high-level context but no new parameter-specific information, so baseline score of 3 applies.

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

  Purpose5/5

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

  The description clearly states the tool builds a colour-grading/LUT finishing stage, using Level/HSV Adjust TOPs and optional LUT. It distinguishes itself from 'apply_post_processing' by specifying 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 Guidelines4/5

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

  Provides explicit alternative: 'Use apply_post_processing instead to chain several distinct effects in series.' Also describes when input_path is needed and when standalone ramp is used, but does not list exclusions.

  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.4/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, and openWorldHint=true. The description adds detail about creating a new baseCOMP under parent_path, listing created node types (cube-map source, GLSL remap, Null). It also mentions the return value includes a JSON block with paths and warnings. This goes beyond the annotations to disclose the tool's 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.

  Conciseness4/5

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

  The description is a single paragraph that front-loads the primary purpose and then provides technical details. It is relatively concise for the amount of information conveyed, though some sentences are dense with technical jargon. Overall, it communicates efficiently without excessive 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?

  Given the tool's complexity (7 parameters, no output schema, no nested objects), the description is highly complete. It explains the entire pipeline from source to output, covers all parameters implicitly in context, and describes the return value (summary + JSON block). It also provides warnings about errors and preview images, leaving minimal gaps for the 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?

  The input schema has 100% description coverage, so baseline is 3. The description adds context beyond the schema by explaining how parameters relate to the process (e.g., fov sets fisheye coverage, expose_controls exposes Fov and Rotation knobs, source can be omitted for a test scene). This provides meaningful semantics without being 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 the tool's purpose: creating a cube-map dome master, a higher-fidelity alternative to create_dome_output. It specifies the rendering process (cube-map mode, GLSL sampling) and differentiates from the sibling by mentioning it avoids pole-pinch/seam. This provides a specific verb+resource and explicit differentiation.

  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 the alternative create_dome_output and states this tool is the 'higher-fidelity follow-up'. It also explains when to use this over a flat equirectangular source by noting the avoidance of pole-pinch. While it doesn't explicitly list when-not-to-use, the context is clear and the alternative is named, providing good guidance.

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

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

  Describes internal signal chain (Blur TOP, Threshold TOP, Level TOP, Constant, Composite) and that it creates a container under parent_path. Mentions synthetic source requires no permissions while real sensor may prompt. Does not cover all edge cases but is thorough 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?

  Efficiently structured: front-loads purpose, then signal chain, source options, controls, and alternative. Length is appropriate for the tool's complexity; no redundant sentences.

  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 output schema, description fully explains return format (summary + JSON block with paths, errors, preview). Covers all major aspects: source, internal ops, controls, and 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?

  Schema has 100% coverage with detailed parameter descriptions. The tool description adds overall context (e.g., synthetic default, threshold as bindable knob) but does not significantly augment individual parameter meanings 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 starts with 'Extract a silhouette / body mask from a depth or video source', a specific verb+resource. It also explicitly distinguishes from sibling 'create_depth_displacement', 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?

  Provides clear guidance: synthetic for preview (no permissions), file for clips, sensor for live; also explicitly names alternative 'create_depth_displacement' for 3D relief. Covers when/why to use each option.

  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 indicate non-read-only, open-world, and non-destructive behavior. The description adds specifics: it builds a network with branches, Null outputs, and preview composite, and clarifies that it's a skeleton for later calibration. This provides useful context 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 concise, using three sentences to convey the core pipeline, its purpose as a calibration skeleton, and limitations. It is front-loaded with the key action, and every sentence adds useful 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 complex tool with 13 parameters and no output schema, the description provides a solid overview of the generated structure and its limitations. It lacks explicit mention of the return value or what the agent should expect after invocation, but schema coverage covers parameter details well.

  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 13 parameters have schema descriptions (100% coverage). The tool description adds value by explaining how parameters like blend_curve and blend_width relate to the pipeline (e.g., 'alpha gradient via Level gamma'). It doesn't repeat schema details but gives integrative 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 it builds a multi-projector architectural facade rig, detailing specific components like Crop, Corner Pin, and edge-blend masks. It distinguishes itself from sibling tools like create_projection_mapping by focusing on multi-projector setups and calibration skeleton delivery.

  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 initial rig building, noting that fine-tuning (corners, color match, camera transforms) is left for live alignment. While it doesn't explicitly mention alternatives or when-not-to-use, it provides clear context for its intended stage in the workflow.

  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.4/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 context by detailing what nodes are created, that a live knob is exposed, and that the return includes errors, warnings, and a preview. 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 well-structured with key purpose first, followed by details and a usage note. It is thorough but not excessively verbose; each sentence serves a purpose. Could be slightly trimmed without loss, but overall 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?

  Given the tool has 6 parameters and no output schema, the description covers the purpose, usage guidance, behavioral details, and return structure (summary, JSON block, preview). It is complete enough 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%, so baseline is 3. The description largely echoes the schema's parameter descriptions (e.g., seed_type list, feedback_gain range) but adds general context like 'Great for evolving, hypnotic visuals' which is not semantic. It does not significantly enhance 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 uses a specific verb ('Build') and resource ('feedback-based visual system'), lists the exact nodes created, and explicitly distinguishes from the sibling tool 'create_feedback_tunnel' by name and 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?

  Provides explicit guidance: 'Use this for a general feedback look...; for the specific infinite-zoom/rotate spiral... use create_feedback_tunnel instead.' It names the alternative and contrasts when to use each.

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

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

  Annotations are minimal (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds significant behavioral context: it creates components, loads assets, binds cameras, exposes controls, and warns about OOM crashes for high resolutions. 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 paragraph that front-loads the main action and then lists requirements and returns. It is well-structured and each sentence adds value, though it could be slightly more concise by breaking into separate sections.

  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 purpose, inputs, requirements, warnings, and integration with other tools (camera rigs). It mentions return values and provides a preview image reference, making it complete for an AI agent to understand and use 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 descriptions for all 7 parameters. The description adds value beyond the schema by explaining the purpose of each parameter in context (e.g., camera binding, VRAM warnings for output_res, bypassing standard candidate walk for tox_path).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 (creates a Gaussian splat scene) and the specific resources involved (drops TDGS .tox into baseCOMP, loads .ply/.splat asset, optionally binds camera, exposes renderTOP). It distinguishes from sibling creation tools by specifying the unique domain of 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 explicit requirements (TDGS installed, TD build, CUDA GPU, Windows) and VRAM warnings for different resolutions. It gives clear context on when to use (for Gaussian splat scenes) but does not explicitly state when not to use or list alternative 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.4/5.0
  Behavior4/5

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

  Annotations (readOnlyHint=false, openWorldHint=true) set a low bar; description adds value by explaining the GPU pipeline, output as Null TOP, parameter rebuild restrictions (bins, log_scale), and the informational-only nature of bar_style. Also warns of potential hang with device source. 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: purpose, pipeline, differentiation. No filler. Every sentence contributes meaning. Front-loaded with the core action. Ideal conciseness 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?

  Given 12 parameters, no output schema, and the complexity of building a histogram scope, the description is comprehensive. It covers technical approach, output type, sibling tool comparison, and known limitations. Could detail the output's format more, but sufficient for agent 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 baseline is 3. Description adds context beyond schema for some parameters: 'changing after build requires rebuild' for bins and log_scale, and 'reserved—informational only' for bar_style. This extra detail 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?

  Clearly states it builds a luminance and optional RGB histogram video scope for any TOP. Distinguishes from sibling create_video_scopes by noting it's the single-scope working histogram that the other cannot render, establishing a unique identity.

  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 says when to use this vs the alternative create_video_scopes for combined monitors. Provides context for source types (e.g., device may cause macOS permission modal). Could add more when-not-to-use scenarios, but the guidance is clear and helpful.

  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.4/5.0
  Behavior4/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 discloses that the tool creates a baseCOMP container with an Execute DAT that writes target parameter values each frame, loops, and returns warnings/errors. It does not contradict annotations and adds context about the creation and 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 a single paragraph that front-loads the purpose and differentiator, then details behavior and output. It is concise without unnecessary information, though could be slightly more 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 tool's complexity (5 parameters, nested keyframes, no output schema), the description comprehensively covers input requirements, creation process, interpolation types, looping, return format, and error handling. It leaves 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?

  Schema description coverage is 100%, but the description adds operational detail beyond the schema: it explains that keyframes create an interpolated curve, how looping works, and what the output contains. This adds value for the agent despite thorough 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 animates parameters using keyframes on a timeline, distinguishing it from animate_parameter's LFO oscillation. It specifies the verb 'animate' and the resource 'parameters along a keyframed curve', and explicitly contrasts with the sibling 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 provides clear guidance on when to use this tool (choreographed moves like build-up, drop, sweep) and explicitly advises using animate_parameter instead for continuous LFO oscillation. It does not mention other exclusions, but the context is sufficient.

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

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

  Annotations are readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds behavioral context: it creates a specific node chain (Select TOP → GLSL TOP → Null TOP), exposes parent parameters, and notes that glsl_compile_verified is always false offline, requiring post-cook verification with get_td_node_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?

  The description is detailed yet concise, front-loaded with the purpose, followed by algorithmic details, node chain construction, and return values. Every sentence provides necessary 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?

  Given the tool's complexity (9 parameters, no output schema), the description covers the creation process, return values, and verification steps. It explains the required source_path and modes but could elaborate on return format details. Overall, it is sufficiently complete for agent use.

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

  Parameters4/5

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

  Schema description coverage is 100%, and the description adds value by explaining the Kuwahara algorithm, mode differences, cost implications (O(radius²·sectors)), and live control exposure. While the schema already documents parameters, the description deepens understanding moderately.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Apply a non-photorealistic painterly filter to an existing TOP.' It specifies the verb (apply), resource (painterly filter), and target (existing TOP), and distinguishes itself from sibling tools like create_glsl_shader by focusing on the NPR filter 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 Guidelines3/5

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

  The description explains when to use the tool (for applying a painterly filter) and lists different modes, but does not explicitly state when not to use it or mention alternative tools. Given the extensive sibling list, more guidance on prerequisites or comparisons would improve the score.

  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
  Behavior4/5

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

  Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds context about creating a baseCOMP, exposing a Null CHOP, and returning a summary/warnings. It does not contradict annotations and explains the non-destructive nature of the build.

  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 efficient, front-loading the main purpose and then specifying the demo and node details. Each sentence adds value, though it could be slightly trimmed without losing clarity.

  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 5 parameters, no output schema, and is a creation tool, the description thoroughly explains what is built (CHOP chain, Null, demo), how to control it (parameters), and what is returned (path, warnings). It leaves 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?

  Schema coverage is 100%, so baseline is 3. The description goes beyond schema by explaining how parameters like 'demo' affect the visible output, 'sensitivity' gains all channels, and 'multitouch' is reserved for future. This adds meaningful 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 tool 'turns mouse/pointer position and click into a first-class creative seed' and details the CHOP and Null outputs. It distinguishes itself from siblings by focusing on pointer-reactive functionality, not just a generic 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 Guidelines4/5

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

  The description explains when to use demo=false (to build only the CHOP chain) and mentions the multitouch limitation. However, it does not explicitly compare against other creation tools or provide exclusion criteria, leaving some ambiguity about when this tool is preferred.

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

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

  Annotations provide readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description goes beyond by detailing the internal POP chain (particle_pop, noise_pop, force_pop, feedback_pop), the output path (Null TOP via poptoSOP), that POPs are experimental and fail-forward, and warns when feedback_gain×(1−decay)≥1.0. 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 comprehensive but somewhat lengthy; it front-loads the main purpose and then details internal structure. Every sentence adds information, but could be slightly more condensed without losing clarity.

  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, no required fields, and no output schema, the description covers the architecture, three presets, experimental nature, divergence warning, and the expected output (Null TOP). It is fully informative for an AI agent to understand what the tool does and how it works.

  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 documented. The description adds value by linking parameters to the system (e.g., 'growth_rate drives particle_pop birth/rate par defensively') and explaining interactions (like feedback_gain and decay leading to divergence). This enhances 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 builds a POP-native reaction-diffusion/growth system inside a fresh baseCOMP, with three named presets (dendritic, coral, lichen). This distinguishes it from siblings like create_growth_system or create_pop_field by specifying POP-native and the exact mode options.

  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 organic growth systems but does not explicitly state when to use this tool versus alternatives like create_growth_system or create_pop_particle_system. It includes an experimental warning and divergence risk, but no direct comparison or exclusion criteria.

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

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

  Annotations indicate non-destructive creation. The description explains that it creates a self-contained container with a Select TOP and Null output, adding behavioral context beyond annotations. 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?

  Three sentences, all informative with no filler. Front-loaded with the core action, then details on source and output. Every sentence contributes value.

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

  Completeness4/5

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

  Given the tool's moderate complexity with two optional parameters and no output schema, the description covers the main workflow, output, and parameter usage adequately. It could mention the Corner Pin operator explicitly, but overall 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%. The description adds meaning by explaining that omitting source_path gives a demo grid and that parent_path defines where the container is created, complementing the schema's 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 that the tool wraps a source TOP in a Corner Pin warp for projection mapping, explaining the drag-and-line-up usage. It distinguishes this from sibling 'create_*' tools by specifying its unique purpose in 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 Guidelines4/5

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

  The description provides context on when to use: for projection mapping on physical surfaces. It explains the source and output structure, and mentions that corner positions can be driven or saved. However, it does not explicitly state when not to use or list alternatives.

  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.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. The description adds that the tool resolves the install-dependent master path live (never hardcoded) and uses the same COMP.copy primitive as RayTK's palette, 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 action, and includes all necessary context 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 9-parameter tool with no output schema and inherent complexity (RayTK dependency), the description covers the main action, prerequisite, alternative tool, and copy method, leaving minimal 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 baseline is 3. The description adds context about master path resolution and the copy mechanism but does not significantly deepen parameter understanding 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 states the tool copies a RayTK ROP master into a network and optionally wires an existing op. It distinguishes from sibling `create_raymarch_scene` by noting this uses RayTK's operators instead of authoring a shader.

  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: when to use (to create RayTK operators), prerequisite (RayTK toolkit must be staged+loaded), and alternative (`create_raymarch_scene` for shader authoring).

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

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

  Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds behavioral context: operators are 'copied at runtime', the tool fails forward with guidance if the library is absent. 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?

  Two sentences: first sentence states the core action and comparison, second covers options and prerequisites. No wasted words, front-loaded with the essential purpose. Every sentence serves a clear 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 tool with 7 fully described parameters and no output schema, the description covers prerequisites, failure mode, and sibling differentiation. It omits details on the exact return value (though the tool creates a node graph, which is implicit). Adequate for the 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%, so baseline is 3. The description briefly summarizes the optional flags (union, material, camera, light), adding meaning beyond the schema descriptions by explaining their role in the node graph. It does not detail each parameter but adds high-level 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 builds a minimal RayTK node graph (sphereSdf → raymarchRender3D → Null TOP) and distinguishes itself from the sibling create_raymarch_scene as the 'node-graph-native complement'. The verb 'Build' and the specific resource and structure 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 explicitly states prerequisites ('requires the RayTK toolkit staged + loaded') and provides a fallback behavior ('fails forward with guidance'). It contrasts with create_raymarch_scene, implying this tool is for full node-graph control. No explicit exclusions or 'when not to use', but the context is clear enough.

  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?

  Adds behavioral details beyond annotations: explains bar-to-seconds conversion fixed at build, exposure of custom pars and playhead Null CHOP. Annotations already indicate non-readonly and non-destructive, so description supplements well.

  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?

  Front-loaded with core purpose and hierarchy, then technical details. Slightly verbose but each sentence adds value. Could be trimmed slightly, but remains 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?

  Fully covers what the tool does, its outputs (exposed pars, Null CHOP), and behavioral constraints. No output schema, but description compensates. Sibling list is large, but description clearly differentiates.

  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, baseline is 3. The description adds context for several parameters (e.g., setlist_path triggers side effects, units conversion behavior). Does not repeat schema but enhances 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 'Build' and the resource 'scrubbable show timeline', distinguishing it from siblings like create_cue_sequencer and create_scheduler by positioning it as the 'master clock'.

  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 names alternatives and their characteristics (beat-quantized vs event-firing) and implies when to use this tool as the overarching timeline. Mentions prerequisite to store cues via manage_cue. Lacks explicit 'when not to use' but sufficient context.

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

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

  The description discloses behavioral traits: it is hands-light, drives manage_cue recall, and optionally quantizes GO. This adds value beyond annotations, which show no read-only or destructive hints. However, more details on state persistence or side effects could improve 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 two sentences, front-loaded with the purpose and functionality. 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 no output schema, the description adequately explains what the navigator does and its usage. It covers key aspects but could explicitly mention the output COMP structure or return value.

  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 6 parameters have schema descriptions, and the tool description adds contextual meaning (e.g., scenes can be omitted to read existing cues, go_on_beat needs a tempo source). This enhances 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 builds a 'hands-light stage navigator' for stepping through cues, with specific UI elements (Next, Prev, Go, Index). It distinguishes from siblings by focusing on the QLab model and hands-light operation.

  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 advises using this tool after building a control panel with manage_cue cues, and suggests using Next+Go instead of recalling by name. This provides context but lacks explicit alternatives or when-not-to-use scenarios.

  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 indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the creation nature is already clear. The description adds valuable behavioral context: it compiles code with shader-park-core, requires specific execution environment flags, and produces a self-contained scene with live controls. This goes beyond the annotations by disclosing execution requirements and output 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?

  Two sentences, with the core purpose front-loaded in the first sentence. The second sentence adds environment requirements and an alternative workflow. No wasted words; every clause contributes to selection or invocation.

  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 11 parameters and nested objects, the description provides essential context: what the tool does, environment prerequisites, and an alternative workflow. The schema covers parameter details, and the description clarifies the output is a self-contained GLSL MAT scene. Minor gap: it doesn't mention return value, but no output schema exists and the creation purpose implies the created COMP is the primary 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 description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description does not add parameter-specific semantics beyond what the schema provides, 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 compiles Shader Park JavaScript code and instantiates it as a TouchDesigner GLSL MAT scene with live controls. It distinguishes itself from siblings like create_raytk_op and create_glsl_shader by focusing on Shader Park specifically, and even mentions a companion script for an alternative workflow.

  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 (general Shader Park code compilation with live controls) and when to use the alternative (official .tox plugin workflow via companion script). Also provides environment prerequisites (TDMCP_RAW_PYTHON=on, TDMCP_BRIDGE_ALLOW_EXEC=1), helping the agent decide if this tool is viable.

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

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

  Description comprehensively explains behavior: failover triggers (stall or errors), crossfade smoothing, sticky-recover logic, control exposure, and return values. Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are consistent, and description adds significant 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 informative, front-loading the purpose. While somewhat lengthy, each sentence adds value and avoids redundancy. Could be slightly more concise without losing detail.

  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 9 parameters and no output schema, the description fully explains the system, controls, and return values. It covers all relevant aspects 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?

  All 9 parameters are documented in schema (100% coverage). The description adds value by explaining parameter interactions (e.g., recover_ms depends on sticky_recover) and providing context 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 states it builds a 'live-show watchdog' with specific failover logic (primary source, fallback, stall detection, crossfade). It distinguishes from siblings by detailing unique failover mechanisms.

  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 for live shows needing automatic failover, but no explicit when-to-use vs alternatives or when-not-to-use. Among siblings like create_live_source or create_video_player, this tool is specific but guidance is absent.

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

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

  The description thoroughly explains behavioral aspects beyond the annotations: it creates a self-contained container, uses a GLSL shader, defaults to a noise source when no source is provided, outputs a nullTOP, and returns a summary with JSON and preview. This adds significant value beyond the annotations (readOnlyHint: false, openWorldHint: true, destructiveHint: false) 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 well-structured and informative, with the main purpose stated first followed by key details. It is concise (3-4 sentences) but contains relevant information about the internal mechanism, default behavior, and return value. Slightly verbose in places ('all computed per-cell in a single GLSL TOP shader'), but overall 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?

  Given the complexity (9 parameters, no required, no output schema), the description provides complete context: what the tool does, how it works (GLSL, stock TOPs), default behavior, output type (nullTOP), and return value (summary+JSON+preview). This enables an agent to fully understand the tool's purpose and outcome without 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?

  All 9 parameters are fully described in the input schema (100% coverage). The description adds only high-level context (e.g., 'per-cell gap') but does not introduce new meaning beyond what the schema already provides. 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 purpose: tiling a source TOP into a brick/grid pattern with customizable parameters. It uses specific verbs ('Tile') and identifies the resource (source TOP). The tool is distinct from siblings as it focuses on step-repeat tiling, which is a unique operation among the many '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 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 (when a tiled grid with jitter and brick offset is needed) but does not explicitly mention alternatives or when not to use it. It gives enough information for an agent to infer appropriate usage.

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

• create_stipple_pointcloudA
  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 the agent knows this is a mutation tool but not destructive. The description adds useful behavioral context: it outputs a Render TOP through a Geometry COMP in points render mode. 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 a single, well-structured paragraph. It front-loads the core purpose, lists modes, and mentions siblings. Every sentence 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?

  With 11 parameters, 100% schema coverage, and no output schema, the description covers the overall output (Render TOP through Geometry COMP) and explains visual modes. It provides enough context for an AI agent to understand the tool's behavior and output, but could optionally include a note about the return value or pipeline steps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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%, meaning all 11 parameters have descriptions. The description provides overall conceptual context but does not add significant detail beyond what the schema already provides. 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 starts by clearly stating the tool's purpose: 'Density-weighted particle scatter rendered as discrete points — a stippled/halftone-engraving point cloud'. It explicitly distinguishes from three sibling tools: create_pop_geometry, create_dither, create_halftone, making it easy to select the correct tool.

  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 explains when to use this tool (for stippled/halftone point clouds) and lists three visual modes. It directly contrasts with siblings: create_pop_geometry for procedural SOP geo, and the rasterized create_dither/create_halftone for TOP-space operations. This provides clear guidance on alternatives.

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

• create_transitionA
  4.4/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds context: creates a baseCOMP, uses test sources if omitted, exposes live knobs, and output is a Null. It does not mention fallback behavior for existing nodes, but covers main behaviors 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 somewhat long but front-loaded with the core purpose. Every sentence adds value, though some details could be tightened. It is well-structured but not minimalist.

  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 covers the transition mechanics, controls, and return value. It lacks explicit error handling or naming conventions, but is complete for typical usage.

  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 100% schema coverage, the description adds significant meaning: it explains the function of each style, the role of sources, and describes the return structure (summary+JSON block). This goes well 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 uses specific verbs and resources: 'Build a parameterized A→B transition over a single 0–1 Progress knob' and explains it's the 'executable core of VJ cutting.' It clearly differentiates from siblings by focusing on transitions and listing five specific styles.

  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: for VJ cutting, and mentions driving Progress from manage_cue/bind_to_channel. It implies use for transitions but does not explicitly mention when not to use or alternatives among many sibling tools.

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

• create_waveformA
  4.4/5.0
  Behavior4/5

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

  Annotations indicate not read-only and not destructive; description adds that it creates a new node (Null TOP), may prompt macOS permission, and describes internal 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?

  Front-loaded purpose then internal details. Dense but every sentence adds value. Could be slightly streamlined by separating usage from implementation, but still 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?

  Covers all parameters, explains output (Null TOP), addresses permission prompt, distinguishes from siblings. No output schema needed as description covers return. Complete for a node-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?

  All 8 parameters have schema descriptions (100% coverage). Description adds context: Scale = vertical zoom, TimeWindow = horizontal span, color = phosphor green default, source options explained with permission note. Enhances understanding 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 clearly states it builds a time-domain audio waveform/oscilloscope showing raw signal, distinguishes from create_spectrum (frequency bins) and detect_onsets (transients), and mentions alternative create_audio_reactive for spectrum. Specific verb 'build' and resource 'waveform/oscilloscope'.

  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 (to see raw waveform) and contrasts with create_audio_reactive (spectrum). Mentions source options and potential macOS permission prompt. Could include more explicit when-not-to-use but current 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.

• diagnose_tdableton_mapperA
  4.4/5.0
  Behavior4/5

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

  Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds that repair modifies parameters but is safe without external connections. It mentions reporting symptoms but lacks specificity on what symptoms are identified.

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

  Conciseness5/5

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

  The description consists of two concise sentences that front-load the main action ('Inspect... and its source CHOP') followed by optional repair behavior. 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?

  The tool is moderately complex with 5 parameters and no output schema. The description covers inspecting and repairing but does not enumerate possible symptoms or output format. Given high schema coverage, it is largely 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% with parameter descriptions. The tool description adds context by linking to 'Oscinputchop, Reorder, Bypass, and Min/Max parameters,' which are not explicit in schema but relate to the 'repair' and 'expected_reorder' 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 inspects a TDAbleton mapper COMP and its source CHOP, and optionally repairs specific parameters. It distinguishes from sibling tools like 'setup_tdableton' or 'create_hand_ableton_mapper' by focusing on diagnosis and 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?

  The description explicitly notes that repairs can be done 'without requiring AbletonMCP or a live Ableton connection,' providing a key usage context. However, it does not specify when to use alternatives like 'repair_network' or 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.

• diff_library_assetsA
  4.4/5.0
  Behavior4/5

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

  Annotations already mark the tool as read-only and non-destructive. The description adds valuable context: it emphasizes offline operation ('Does not touch TouchDesigner') and details what differences are reported (keys, values, and for recipes also nodes/params/connections), which 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?

  Three sentences efficiently convey purpose, output, and key behavioral note. No redundant or extraneous information.

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

  Completeness4/5

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

  The description covers the tool's main purpose, supported asset types, and behavior. Since an output schema exists, the lack of return format details is acceptable. Minor gap: no mention of error handling or file existence checks, but overall sufficient for an informed 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%, so the schema already documents all three parameters. The description adds moderate extra value by explaining the effect of the 'mode' parameter (recipe-aware vs generic diff) and listing the mode options, but this overlaps with the schema's enum 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 performs an offline deep diff of two saved library assets on disk, listing specific file types and what it reports. It explicitly contrasts with the sibling tool diff_snapshots, which compares live TD graphs.

  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 directs users to use diff_snapshots when comparing live TD graphs, providing a clear alternative and unambiguous usage context.

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

• document_networkA
  4.4/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 aligns perfectly, stating 'read its nodes and connections' (read-only) and 'return a readable map'. It adds behavioral detail about the output (counts, flowchart) beyond annotations, 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?

  Two sentences, no wasted words, front-loaded with the action verb and resource. Provides clear distinction from a sibling tool and a usage hint in a compact form.

  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 output (readable map, counts, Mermaid flowchart) even though there is no output schema. It positions the tool well against plan_visual. However, it does not mention error scenarios or format details for the output, which could be improved but is acceptable given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters (path, recursive) with clear defaults and descriptions. The description adds no additional detail about parameters, 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 specific verb 'Document' and resource 'EXISTING network', and explicitly contrasts with sibling 'plan_visual' by stating it describes what's actually in the project vs planning from a description. The output is clearly defined: counts by operator family/type and a Mermaid flowchart.

  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: 'Use it to explain or hand off a patch.' It also contrasts with plan_visual for when not to use (if planning from a description). However, it does not mention prerequisites or other alternatives beyond plan_visual.

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

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

  The description goes beyond annotations by detailing atomicity, prevalidation of fields, read-back verification, rollback on partial failures, safe parent moves (copy and validate before destroying source), and return format (final path and per-field results). This significantly enhances the agent's understanding of the tool's behavior, complementing the destructiveHint and 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?

  The description is three concise, information-dense sentences. It front-loads the core purpose, then covers safety and return behavior, with no wasted words 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 covers core functionality, atomicity, rollback, parent move safety, return values, and fallback behavior. It lacks some context around error conditions, valid flag combinations, or permission requirements, but is reasonably complete 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 50% schema description coverage, the description adds some context by grouping fields (e.g., 'exact Network Editor position' for node_x/node_y, 'parent moves' for parent_path, 'writable flags' for booleans). However, it does not elaborate on the meaning of undocumented flags like lock, bypass, render, viewer, display, cloneImmune, or allowCooking, leaving gaps for the agent to infer.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 atomic editor for an operator's name, parent, position, color, comment, and writable flags, using specific verbs and resources. It distinguishes itself from sibling tools like update_td_node_parameters by focusing on metadata rather than parameter values, and from create/delete tools by explicitly stating it edits.

  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 editing metadata fields atomically—and mentions behavior such as prevalidation and rollback. However, it does not explicitly name alternative tools like update_td_node_parameters or delete_td_node for exclusion, leaving some inference to the agent. The mention of 'Does not use raw Python fallback' implicitly steers away from execute_python_script.

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

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

  Annotations indicate destructiveHint=true and openWorldHint=true. The description's 'escape hatch' label and destructive example (.destroy()) reinforce the risk. It could be more explicit about potential side effects, but overall complements annotations 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?

  Two sentences, front-loaded with purpose and usage guidelines. No extraneous words. 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?

  Complex tool with arbitrary method invocation. Description covers purpose, usage boundaries, and examples. No output schema, but returns are method-dependent. Could mention error handling, but not essential given the open-ended nature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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% description coverage, so parameters are documented. The description adds minimal value beyond examples of method names. No clarification on path format or args/kwargs usage 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 the tool invokes arbitrary Python methods on nodes, positioning itself as an escape hatch. It distinguishes from other tools by specifying it should be used only when structured tools are insufficient. Examples like .cook(), .copy(), and .destroy() 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 Guidelines5/5

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

  Explicitly advises preferring structured tools and reserving this for uncovered operations. This provides clear selection criteria and context, making it easy for an agent to decide 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.

• execute_python_scriptA
  4.4/5.0
  Behavior4/5

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

  Annotations indicate destructiveHint=true and openWorldHint=true. The description adds the key behavioral constraint that 'Code runs in TD only, never on the local machine,' which goes beyond the annotations and clarifies the execution scope. 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?

  The description is extremely concise: two sentences that front-load the core purpose and then add usage guidance. Every sentence adds value with 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 the tool's nature as an arbitrary code execution escape hatch, the description covers purpose, usage boundaries, and scope limitation. It does not detail error handling or security implications, but the annotations (destructive, open world) and the 'escape hatch' label imply risks sufficiently. Almost complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, so baseline is 3. The tool description does not add any parameter-specific meaning beyond the schema's existing descriptions. The parameters are adequately described in the schema 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 clearly states the tool runs an arbitrary Python script inside TouchDesigner. It uses a specific verb ('run') and resource ('arbitrary Python script inside TouchDesigner process'), and differentiates from structured tools by calling itself an 'escape hatch' and listing the preferred 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 advises to prefer structured tools and to only use this when no structured tool can express the operation. It lists several sibling tools as alternatives, providing clear 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.

• export_externalized_treeA
  4.4/5.0
  Behavior5/5

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

  The description explicitly mentions that the tool writes files to out_dir (destructive) and mutates the live COMP's externaltox parameters, which aligns with and adds detail beyond the annotations (destructiveHint=true, readOnlyHint=false). 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 concise (3 sentences) and front-loaded with the main action. Every sentence adds value, avoiding 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 the presence of an output schema (not shown), the description does not need to explain return values. It covers the key effects (writing files, mutating parameters), constraints (out_dir path requirement), and the optional recurse behavior. Missing example or mention of expected output, but overall 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 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds high-level context for parameters but does not significantly enhance understanding of individual parameter syntax or options 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: to save a COMP as a git-diffable externalized .tox tree using TouchDesigner's 'save external' method. It specifically contrasts with opaque binary saves, distinguishing it from export_look_tox and other export 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 explains when to use: for version-controlled projects to get per-node diffs. It mentions destructive nature and mutation of externaltox pars but does not explicitly list alternative tools or conditions 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.

• export_sop_to_svgA
  4.4/5.0
  Behavior5/5

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

  The description discloses key behaviors beyond annotations: projects to x/y (drops z), auto-fits viewBox, supports stroke/fill/scale/flip_y, writes to disk when output_path supplied, always returns SVG string. No contradiction with annotations (readOnlyHint=false, destructiveHint=true, 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 concise (4 sentences) and front-loaded with the key action and resource. Each sentence adds value without redundancy. Structure is clear 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?

  Given the tool has 7 parameters and complex behavior (SVG generation, file output), the description is mostly complete. It covers input, process, output format, and file writing. Missing details like coordinate system origin or error handling, but overall 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 description coverage is 100%, so the baseline is 3. The description adds some semantic context (e.g., 'each primitive becomes one <polyline>', 'auto-fits viewBox'), but most parameter meanings are already well-defined in the schema. No significant additional insight 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 it exports SOP geometry to SVG, detailing the process (walk primitives, emit polylines) and use cases (pen-plotter, laser, print). The tool name is self-explanatory, and the description adds specific context that distinguishes it from siblings (e.g., no other export SVG tool listed).

  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 on when to use the tool (for vector output like pen-plotter/laser/print) but does not explicitly state when not to use it or mention alternatives. While the use cases are clear, the lack of explicit exclusions lowers the score slightly.

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

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

  Description adds that it reports validation problems instead of throwing, beyond the readOnlyHint and destructiveHint already in annotations. 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 sentences, front-loaded with action. 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?

  Given single parameter, no output schema, and detailed annotations, description covers purpose, usage, and behavior. Could be slightly richer but adequately 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 0% schema coverage, description adds context that path can be a folder or file. Provides basic meaning but lacks format or extension 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 it reads and validates a manifest, using specific verbs. It distinguishes from siblings by mentioning pre-check before install_library_package or make_portable_tox.

  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: before install_library_package or make_portable_tox. Provides clear context for usage and mentions alternative tools.

  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
  Behavior4/5

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

  The description discloses the stateful and experimental nature, including the snapshot storage in parent COMP and the live binding. Annotations confirm readOnlyHint=false and openWorldHint=true, and the description adds context about the two-step process and potential side effects. No contradiction exists, but it could mention more about the expression mode switching.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 paragraph that front-loads the core concept and efficiently covers all necessary details without redundancy. Every sentence contributes to understanding the tool's procedure and requirements.

  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 (two-step stateful process) and the absence of an output schema, the description adequately explains the workflow and parameter semantics. It mentions a report from the tool, but does not detail its structure or error cases, which would make it more 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 significant value by explaining the overall workflow, the min_delta normalization logic, and how parameters interact. It goes beyond the schema descriptions, providing practical 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 it's an experimental two-step 'MIDI learn' process. It distinguishes itself from sibling tools like 'bind_to_channel' or 'create_midi_map' by specifying the snapshot and bind modes, making its purpose very specific and actionable.

  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 the user to call with mode:'snapshot' first, then wiggle a control and call with mode:'bind'. It also details the required source CHOP and the stateful storage. However, it does not explicitly state when to avoid using this tool or compare it to alternative approaches, 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.

• learn_from_my_corpusA
  4.4/5.0
  Behavior4/5

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

  Description reveals write behavior (to Memory files) despite annotations saying readOnlyHint=false (non-read-only) and destructiveHint=false (non-destructive). Adds context that it is a pure filesystem read but also writes, providing clarity 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 concise sentences with front-loaded purpose and key details. No redundant information; 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?

  Covers core function, parameter context, behavioral notes, and dependencies. Lacks explanation of return values for dry_run, but does not have an output schema; still sufficient 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?

  Schema coverage is 100% with descriptions. Description adds value by noting environment variable TDMCP_VAULT_PATH and hinting that 'observe' subsets keep runs cheap, which aids effective parameter use.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 walks the Obsidian vault corpus and distills preferences into Memory/corpus_style.md. Distinguishes from sibling 'learn_conventions' by being an offline companion with 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?

  Explicitly frames as offline companion to 'learn_conventions' and notes no TouchDesigner required, implying when to use. Does not explicitly list alternatives or when-not-to-use, but provides enough context for an AI agent.

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

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

  Annotations already indicate destructive and open-world behavior. Description adds that it modifies the storage dictionary and does not create operators, consistent with annotations. 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?

  Two sentences: first states purpose and lists actions, second adds constraint and prerequisite. No wasted words, 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?

  Covers main behavior, prerequisite, and action types. Lacks details on error handling or return values, but no output schema exists. Annotations cover destructive aspect. Adequate for the tool's simplicity.

  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 with descriptions, but description adds value by grouping actions, specifying which parameters are required for which actions, and noting value must be JSON-serialisable. Goes 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?

  Clearly states CRUD operations on a COMP operator's .storage dictionary, listing four actions and the prerequisite that the COMP must exist. Distinguishes from sibling tools like manage_component which manage other aspects.

  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?

  Specifies actions and prerequisite (target COMP must exist). Implicitly contrasts with tools like manage_component, but lacks explicit 'when not to use' or alternative guidance.

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

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

  The description discloses a critical behavioral trait beyond annotations: tdmcp never stores OBS passwords and requires manual Identify authentication if enabled. This adds specific security context that annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) 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?

  The description is appropriately sized and front-loaded with the main purpose. It packs technical specifics (op:6 requests, component names, auth caveat) without extraneous filler, ensuring 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 complex tool with 9 parameters and no output schema, the description covers core components, command types, and an important authentication caveat. It does not mention execution defaults like auto_connect, but the schema already documents that behavior, so completeness 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 description coverage is 100%, and the description does not add additional parameter meaning beyond what the schema already provides. The baseline of 3 applies because the schema does the heavy lifting for 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 the tool's purpose: 'Create an OBS WebSocket v5 control rig in TouchDesigner.' It lists specific components (websocketDAT, Constant CHOP, chopExecute DAT) and concrete commands (StartStream, StopStream, ToggleStream, etc.), making it distinct from sibling tools like connect_obs_recorder that focus on recording only.

  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 building a complete OBS control rig in TouchDesigner, providing clear context. 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.

• optimize_performanceA
  4.4/5.0
  Behavior3/5

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

  Annotations already indicate this is a mutating tool (readOnlyHint=false, destructiveHint=true), and the description substantiates that by noting that with apply=true it 'mutates flagged TOP resolutions by scale and returns the before/after sizes.' It also clarifies the default safety posture (read-only unless apply=true). However, it doesn't detail specific destructive side effects (e.g., whether mutations can be reverted, whether it permanently overwrites original TOPs) beyond the annotations, and it doesn't mention rate limits or authorization requirements. Given the annotations already carry the core safety signal, the description adds meaningful context without fully disclosing all mutation 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 three sentences with no fluff. The first sentence front-loads the core purpose, the second qualifies the mutation behavior and return info, and the third provides explicit sibling guidance. Every clause carries information—there are no wasted words or filler phrases like 'this tool is designed to' or 'it should be noted that.' It is the ideal size 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?

  For a tool with 4 self-documenting params, 100% schema coverage, and a clear output described as 'returns the before/after sizes,' the description covers the essentials: operation, mutation flag, safe default, and sibling differentiation. There is no output schema, but the description states the before/after return values, which compensates. The only gaps are details about error conditions, what happens if there are no flagged nodes, or whether the returned sizes are filesystem sizes vs. resolution sizes, but these are minor for an agent selecting and 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?

  The input schema already covers 100% of parameters with descriptions, so the baseline is 3. However, the description adds valuable semantic context: it explains that apply=true 'mutates flagged TOP resolutions by scale' and that the default false is a 'plan-only pass,' effectively tying the boolean and scale parameters together. It also gives concrete examples for scale ('0.5 = half on each axis'), which enriches the schema's bare number constraint. The description does not restate schema fields verbatim; it amplifies their 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 opens with 'Scan a network for cook-time bottlenecks and report the slowest nodes with concrete suggestions,' which captures exactly what the tool does. It clearly distinguishes this from the sibling 'get_td_performance' by explaining that this tool is for bounded resolution changes while the sibling is for metrics-only. The verb 'scan and report' plus the mutation qualification with apply=true makes the 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?

  The description explicitly states when to use this tool vs. the alternative: '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 is textbook guidance—it names the sibling, gives a concrete decision rule, and clarifies the safe default (apply=false) for a plan-only pass.

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

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

  Annotations already indicate destructive hint and open world. Description adds context: it's a filesystem write tool, returns artifact paths and checksums, and highlights that overwrite=false protects existing artifacts and missing ids are reported. 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 essential. First sentence states purpose and specific files. Second explains key parameters. Third lists return values. No wasted words, front-loaded with key info.

  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 enumerates return values (artifact paths, checksums, etc.). Parameters well covered. Could add more on error handling or side effects, but adequate for a mutation tool with good annotations.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. Description adds meaning: explains `name` becomes filename after sanitization, `overwrite` protects artifacts when false, `include_all` vs `recipe_ids` behavior, and mentions missing ids in output.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 writes local, versioned recipe-bundle publish artifacts (three specific files). It distinguishes from siblings like export_recipe_bundle and import_recipe_bundle by focusing on the publish process with checksums and missing ids.

  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?

  Mentions use for CI upload or handoff. Does not explicitly state when not to use or list alternatives, but the context is clear and the sibling list provides differentiation.

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

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

  Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds 'Read-only vault search' and 'Offline; requires TDMCP_VAULT_PATH', providing additional behavioral context beyond annotations. 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, front-loaded with the primary purpose. Every sentence adds value with no wasted words. 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?

  Given the tool's complexity (6 parameters, output schema exists), the description covers key aspects: purpose, search mechanism, return fields, and requirements. It could mention sorting order explicitly, but it is largely 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% with all parameters described. The description adds meaning by explaining how the query is used ('Scores by query-token overlap with title/intent/prompt/tags/body') and the role of tags and ops boosts, enhancing 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 purpose: 'Read-only vault search: rank past memory notes by similarity to a new visual goal so the agent can reuse prior recipes, params, and prompts instead of rebuilding from scratch.' This is a specific verb+resource and distinguishes from sibling tools that involve creation, analysis, or other 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 on when to use the tool (to recall past work for reuse) and constraints ('Offline; requires TDMCP_VAULT_PATH'). It does not explicitly state when not to use or offer alternatives, but the purpose is well-defined.

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

• record_movieA
  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 valuable context: stop cleans up the recorder node, file is written on the TD machine (path locality), and auto-stop behavior via seconds. This provides practical behavioral details 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 concise (three sentences), front-loaded with the main purpose, and every sentence adds value. No unnecessary words or repetition.

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

  Completeness4/5

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

  Given 5 parameters, no output schema, and existing annotations, the description covers the full recording lifecycle (start/stop/auto-stop), differentiates from sibling, and notes file location on TD machine. It is sufficient for correct agent invocation, though it could mention overwrite behavior or error states for 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?

  Schema coverage is 100% with descriptions, so baseline is 3. The description enriches parameter meaning: it explains action start/stop context, recommends absolute path for file, mentions fps default, and clarifies seconds for auto-stop. This adds semantics 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 records a TOP to a movie file via Movie File Out TOP, and explicitly contrasts with render_output (single frame). The verb 'record' and resource 'TOP to movie file' are specific, and the mention of .mov/.mp4 extentsions adds clarity.

  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 this tool (exporting clips/loops) and contrasts it with render_output (single frames). It also provides usage flow: start with file and fps, optional seconds for auto-stop, then stop to finish. It could be more explicit about not using for single frames, but the guidance is clear and sufficient.

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

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

  Annotations already indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds behavioral context: it dispatches through tool handlers, dryRun plans without invoking, stopOnError halts on failure, raw Python entries are subject to server-side gate, and redacted args may fail. 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 only two sentences, tightly packed with information. It is front-loaded with the core purpose, then lists optional behaviors and a warning. No unnecessary words.

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

  Completeness4/5

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

  Given the tool's complexity (5 parameters, nested objects, no output schema), the description covers the main functionality and parameter behaviors. It warns about redacted args but does not detail the MacroRecord structure or return values. It is adequate 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?

  Schema coverage is 0%, so the description must compensate. It explains all four optional parameters (dryRun, stopOnError, argsOverrides, allowRawPython) with clear purposes. macroPath is implied as the file path. The description adds meaning to the nested argsOverrides object as 'shallow-merge per-tool arg replacements'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 replays a MacroRecord JSON file by dispatching entries through tool handlers. The verb 'replay' and resource 'MacroRecord JSON file' are specific, and it distinguishes from sibling tools like macro_recorder (recording) and create_macro (creation).

  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 optional parameters like dryRun for planning, stopOnError for error handling, argsOverrides for arg replacements, and allowRawPython for raw Python entries. It also warns about redacted args. However, it does not explicitly compare to sibling macro tools or state prerequisites like having a MacroRecord from macro_recorder.

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

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

  The description adds context beyond annotations: it writes files (tox + note), requires environment config, and explains thumbnail capture limitations. Annotations declare readOnlyHint=false and destructiveHint=false, which is consistent.

  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 primary purpose, but slightly lengthy. It could be tightened without losing 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?

  Given no output schema and 8 parameters, the description covers inputs, side effects (file creation), and workflow integration. Missing explicit mention of return value or success confirmation, but otherwise complete.

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

  Parameters5/5

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

  Schema coverage is 100%, and the description adds valuable context: default name and folder, explanation of preview_top and auto_tag, and thumbnail behavior. This goes beyond the schema's 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 saves a COMP as a .tox in the vault and writes a companion markdown note, completing the library packaging loop. It distinguishes from sibling tools like manage_component (for loading).

  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 prerequisites (TDMCP_VAULT_PATH, COMP must exist) and hints at its place in the build-to-library loop, but does not explicitly state when not to use it or compare with alternatives beyond manage_component.

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

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

  The description discloses key behavioral traits: loading an engine, starting the timeline, reading pose data, and building a skeleton. It also warns about macOS camera permission. Annotations indicate non-destructive and open-world, so the description adds meaningful context beyond annotations, though some side effects (e.g., exact component creation) are not fully detailed.

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

  Conciseness5/5

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

  The description is concise (4 sentences) and front-loaded with the main purpose. Each sentence adds value: what it does, prerequisites, process, and a behavioral note. 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 complexity (3 parameters, no output schema), the description covers the setup process, prerequisites, and result (live skeleton). It lacks details on error handling or what happens if the engine is already installed, but overall it's sufficiently complete for a setup 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 descriptions for all 3 parameters. The description adds significant context: explaining tox_path as the full engine vs. bare processor, build_skeleton as visual wiring, and parent_path as target COMP. This 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 clearly states the tool's purpose: 'One-shot body tracking from a webcam'. It details the specific steps (loads engine, starts timeline, reads pose data, builds skeleton) and distinguishes it from sibling tools like setup_face_tracking or create_pose_tracking by focusing on body tracking setup.

  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, including the prerequisite of installing mediapipe-touchdesigner via tdmcp. It implies it's for initial setup but does not explicitly contrast with alternatives like create_body_reactive or manually setting up tracking, lacking explicit when-not guidance.

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

• setup_tdabletonA
  4.4/5.0
  Behavior5/5

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

  The description fully discloses the tool's behavior: probing, cloning, or building OSC fabric, with consistent fallback. It aligns with annotations (readOnlyHint=false, destructiveHint=false) and adds context about non-destructive setup.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 key action, and contains no redundant information. Every sentence adds value, making it efficiently 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?

  Given the 11 parameters are fully described in the schema and annotations are present, the description adequately explains the tool's purpose, modes, and output. It mentions downstream bind_to_channel, but could briefly note error handling or 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%, so the description adds minimal new parameter meaning. It references tempo/beat/track/device channels which relate to parameters, but the schema already provides full descriptions. 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 wires up an Ableton Live bridge inside a container, detailing two modes and the output of binding-ready Null CHOPs. It distinguishes itself from siblings like setup_body_tracking by focusing specifically on Ableton integration.

  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 before bind_to_channel calls and mentions fallback behavior, but lacks explicit guidance on when not to use this tool or direct comparisons with alternatives. The context is clear enough for an experienced user.

  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
  Behavior4/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 'All modes write the global tempo (op('/').time.tempo)' and explains fallback behavior for absent sources. This provides useful behavioral context beyond annotations, such as the side-effect on global tempo and how other tools depend on it. 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 long, covering purpose, mode details, side-effects, and fail-safes without redundancy. Every sentence adds essential information, making it highly 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?

  Given the tool's moderate complexity (3 params, 3 modes, no output schema), the description covers purpose, all modes with dependencies, side-effects, and relationship to other tools. It could mention the container creation more explicitly, but overall it is sufficient 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 coverage is 100%, so baseline is 3. The description adds practical guidance for 'bpm' ('match the DJ's displayed BPM, then fine-tune by tapping') and clarifies 'mode' options with context about source availability. This adds value 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 explicitly states the tool's purpose: 'Lock the project tempo to a live source so beat-synced visuals follow the music.' It identifies the verb 'lock', the resource 'project tempo', and the context. It distinguishes from sibling tools like 'create_tempo_sync' by noting that this tool writes the global tempo and others follow.

  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 when to use the tool to sync to a live source and mentions that 'create_tempo_sync clocks and create_autopilot follow' implying a hierarchy. It also explains hardware gating for Link/MIDI modes and fallback behavior, providing clear usage context. However, it does not explicitly state when not to use it or alternative tools.

  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?

  The description goes well beyond the annotations by disclosing deep mode's disposable quarantine bridge, non-9980 port restriction, structured loadTox-only job, bounded polling, scratch cleanup, and the UNVERIFIED (never PASS) outcome for offline evidence. It adds rich behavioral context without contradicting the readOnlyHint, openWorldHint, or 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?

  The description is concise, front-loaded with the core purpose, and every clause adds value. Despite being dense, the two-sentence structure efficiently covers both modes and key constraints 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?

  Both validation modes, safety/containment details, and evidence semantics are covered, but the description does not fully specify return/error states beyond PASS/UNVERIFIED. With no output schema, a bit more detail on failure results and output format would make it complete, but the core context is solid.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description explains the top-level parameters (path, manifest_path, validation_mode) and the purpose of the deep object, but it does not detail the nested parameters such as quarantine_port, max_nodes, or expected_contract. With 0% schema description coverage, the description only partially compensates for these nested 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 checks a local library asset's existence and optional manifest reference, with specific verbs and resources. It distinguishes between static and deep_roundtrip modes, setting it apart from sibling validation tools like 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?

  It provides explicit guidance to prefer the cheap static mode by default and describes when to opt into deep_roundtrip with its quarantine and authentication requirements. However, it does not explicitly state when not to use the tool or name alternative tools such as inspect_component_manifest.

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

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

  Annotations already signal non-read-only, open-world, non-destructive behavior. The description adds valuable context beyond that: the precise side effect is 'node creation in TD, not file writes,' the return value is the created GLSL TOP, and it clarifies the source note format. This goes beyond the annotations but could be more explicit about error conditions.

  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 every sentence serves a purpose: core action, side-effect clarification, usage guidance, return value, and prerequisites. It is front-loaded with the operation verbs in caps. Slightly long but efficient for the complexity of the 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?

  Given the tool's complexity (reading from vault, creating a node), the description covers the key aspects: source format, action, side effects, return value, alternative tool, and required environment settings. It lacks explicit error handling information, but with no output schema, the return value description is sufficient. The prerequisites are a strong addition.

  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 complete descriptions for all 3 parameters (100% coverage), so baseline is 3. The description adds semantics by describing the expected structure of the note (```glsl fragment block, optional vertex block, frontmatter) and clarifying that the 'name' parameter defaults to frontmatter or 'glsl1', which is already in the schema but reinforces the intended usage. This adds 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's specific action: READ a shader note from the Obsidian vault and CREATE a GLSL TOP in TouchDesigner from it. It explicitly names the resource (vault note) and distinguishes itself from the sibling create_glsl_shader by noting that alternative is for inline shader 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?

  The description provides explicit when-to-use guidance: 'Use this to apply a shader you keep in the vault; to supply shader code inline instead, use create_glsl_shader.' It also lists required configuration prerequisites (TDMCP_VAULT_PATH, TDMCP_RAW_PYTHON=on, TDMCP_BRIDGE_ALLOW_EXEC=1), which informs when the tool is usable.

  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
  Behavior4/5

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

  Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds critical behavior: 'fail-forward, per-operation warnings; not transactional' and 'Names created earlier can be referenced by later operations'. This provides meaningful 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 two sentences, front-loading the core purpose and key differentiator. Every word adds value, 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 tool's complexity (multi-operation chaining, failure behavior, name referencing) and the presence of an output schema, the description covers all essential aspects. It fully prepares 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?

  With 100% schema coverage, baseline is 3. The description adds the important concept that names created earlier can be referenced by later operations, which is not explicit in the schema but crucial for understanding parameter usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Run an ordered list of create / connect / setParam operations in one call', specifying a unique verb and resource. It explicitly distinguishes from sibling 'set_parameters_batch' by noting it only sets 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 explicitly contrasts with set_parameters_batch, providing a clear usage boundary. However, it does not comprehensively cover when not to use this tool or list other alternatives among the many siblings.

  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
  Behavior4/5

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

  Annotations (readOnlyHint=false, destructiveHint=false) provide basic safety info. The description adds behavioral context: parameters are switched to expression mode for live tracking, optional Lag CHOP insertion for smoothing, and envelope follow behavior. This goes well beyond the annotations, though it could mention if existing expressions 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: the first states purpose and typical sources, the second expands on smoothing behavior with a concrete example. Every sentence is substantive, no redundancy, and the most critical information (what it does) is front-loaded.

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

  Completeness4/5

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

  Given the tool's complexity (9 parameters, smoothing options, expression mode) and no output schema, the description covers the primary workflow and smoothing options. It lacks explicit mention of return values or side effects beyond expression mode changes, but overall it is sufficient for correct tool 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?

  All 9 parameters have descriptions in the schema, and the description adds practical meaning: explaining scale/offset as mapping gain, attack/release as envelope follower times, smooth as symmetric convenience, and smoothing_container location. The second sentence provides a usage example that clarifies semantic nuances.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Drive one or more node parameters from a CHOP channel by expression' and specifies the scope (audio_features/tempo_sync channels). It distinguishes from siblings by explicitly naming 'extract_audio_features / create_tempo_sync' as complementary tools, making the purpose and context 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 when to use the tool (to wire audio or tempo data into visuals) and how to apply smoothing (attack/release vs smooth). It gives concrete scenarios like 'fast attack + slow release for a punchy hit'. However, it does not explicitly state when NOT to use it or provide direct comparisons to alternatives like 'bind_audio_reactive'.

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

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

  Annotations indicate write (readOnlyHint=false) and non-destructive (destructiveHint=false) with openWorldHint=true. Description confirms it writes PNG images and appends to note, adding details on file structure and default behavior. 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?

  Three sentences, no wasted words, front-loaded with main action and result. Clearly structured with purpose, mechanism, and usage.

  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 all necessary aspects: what it does, where files go, default behavior, prerequisites. No output schema needed as actions are fully described.

  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 description adds meaning: explains note defaults to today's date for accumulation, gallery subfolder, and width/height defaults. Provides context beyond 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?

  Description clearly states verb 'Captures', resource 'preview still from a TOP', and purpose: appends to a dated gallery note in Obsidian vault. Distinguishes from sibling tools like record_movie or snapshot_td_graph by specifying the exact action and target.

  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.' Also notes prerequisite: 'Requires a configured TDMCP_VAULT_PATH.' Does not explicitly exclude alternatives but gives sufficient 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.5/5.0
  Behavior5/5

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

  The description discloses that the TD scan is read-only, but writing the manifest (when out_manifest is set) may overwrite an existing file, aligning with destructiveHint=true. It also reveals the fallback heuristic for file detection and notes it is UNVERIFIED across TD builds, which is critical 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, well-structured paragraph that front-loads the main purpose. Every sentence provides necessary information: scan target, reporting details, read-only nature, file-writing condition, and detection heuristic caveat. No redundant or extraneous 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?

  Given the tool's complexity (scanning a network, detecting multiple dependency types, varying par support) and the presence of an output schema, the description covers all essential aspects: scope, reporting, mutability, heuristic limitations, and the style_supported flag. It is sufficient for an agent to understand the tool's capabilities and constraints.

  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 three parameters. The description adds context: explains parent_path as root of subtree, out_manifest as optional write path (empty means no file), and include_missing_only as filter. This adds meaning beyond the schema, justifying a score above 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 clearly states the tool scans a COMP subtree for external file dependencies (movie/image, fonts, LUTs, externaltox) and reports each referenced file with node+parameter and existence status. The verb 'scan' and specific resource 'COMP subtree' are precise, and the tool is well-differentiated from siblings like create_media_bin or get_td_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 implies usage when an agent needs to inventory external file dependencies in a TouchDesigner network. However, it does not explicitly state when not to use this tool or provide alternatives. Given the specificity, the usage context is clear but 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.

• compare_td_nodesA
  4.5/5.0
  Behavior4/5

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

  Annotations already convey readOnlyHint and destructiveHint. Description adds value by specifying default diff behavior (only differing values) and the exact return structure, but the read-only note is redundant 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 concise sentences front-loaded with key info (read-only, diff, returns), no filler, 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?

  Covers purpose, usage context, behavioral traits, and return values. Output schema exists and is referenced in description. Distinguishes from sibling. 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?

  Schema coverage is 100% and description does not add additional parameter-level context beyond what the schema already provides. 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?

  Description clearly states it diffs parameters of two nodes, mentions read-only nature, and distinguishes from sibling tool diff_snapshots by specifying that it compares live nodes versus whole-network 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?

  Explicitly says 'useful for aligning settings across similar operators' and contrasts with diff_snapshots, providing clear 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_automation_laneA
  4.5/5.0
  Behavior5/5

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

  Annotations indicate mutation (readOnlyHint=false) and no destruction (destructiveHint=false). The description adds rich behavioral details: internal component chain (Beat CHOP → Select CHOP → Lookup CHOP), state tracking via COMP storage, and the re-call flip mechanism. 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 reasonably concise, spanning multiple sentences but without fluff. It is front-loaded with the main purpose, then details modes, re-call behavior, internal components, and return value. Could be slightly more structured but effectively communicates all necessary information.

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

  Completeness4/5

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

  Given the tool's complexity (6 parameters, no output schema), the description covers purpose, modes, re-call behavior, internal architecture, and return format. It lacks error conditions or prerequisites but is otherwise complete for an experienced user.

  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 50% schema description coverage, the description compensates by explaining key parameters: name as container name, targetParam as OP+param tuple, bars as number of bars for the buffer, bpm as tempo, and modes as record/loop. The optional parent parameter is briefly mentioned in schema but not in description, which is acceptable.

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

  Purpose5/5

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

  The description clearly states the tool builds a per-parameter automation lane for recording and looping parameter sweeps. It specifies the resource (automation lane) and action (build), distinguishing it from sibling tools like 'animate_parameter' or 'bind_to_channel' by focusing on the circular buffer and bar-phase clock mechanism.

  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 two modes (record/loop) and the ability to flip states by re-calling with the same name and different mode without rebuilding. This provides clear contextual guidance for using the tool effectively, though it does not explicitly contrast with alternatives.

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

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

  Description explains that faders drive parameters and cue buttons fire scenes with optional crossfade. Annotations (non-readonly, non-destructive, open-world) are consistent. Beyond annotations, it adds behavior like 'touchable surface' and 'fire scenes'.

  Agents need to know what a tool does to the world before 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 purpose, no wasted words. Efficiently conveys core functionality and usage hint.

  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 all parameters and usage pattern. Missing output schema but description adequately implies result (a container). Could mention lifecycle or post-build steps, but sufficient given 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?

  Description adds significant context beyond schema: clarifies that faders drive parameters, cue buttons recall cues from manage_cue, and morph_seconds controls crossfade. This enhances understanding of nested object 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?

  Description clearly states the tool builds a control surface (Container COMP) with faders and buttons for live performance. It uses specific verbs and distinguishes from sibling tools like create_control_panel and manage_cue.

  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 gives functional context: 'for live use, beyond the parameter dialog' and instructs to 'Open the container in Perform/Panel mode'. However, it does not explicitly compare with alternatives or state when not to use.

  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
  Behavior4/5

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

  Annotations indicate mutability and non-destructiveness; the description adds specific behavioral details: it creates a container with Select CHOP, Lag CHOP, Logic+Math CHOP, and Null CHOP. It discloses that gate threshold uses unverified par names across TD builds and recommends live tuning. This goes beyond annotations, though annotations already 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.

  Conciseness4/5

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

  The description is a single paragraph that effectively front-loads the purpose and experimental warning. While it contains substantial detail, every sentence serves a purpose (e.g., explaining internal nodes, alternatives, tuning). It could be slightly more structured, but it balances completeness with 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 9 parameters and no output schema, the description explains the output (Null CHOP) and optional binding. It covers the tool's full functionality, including internal node composition and experimental caveats. It doesn't address error handling or performance, but for a complex creative tool, it is sufficiently 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%, but the description adds value by explaining how parameters relate to the overall chain (e.g., attack/release shaping, threshold tuning, mode purpose) and provides usage tips (e.g., 'start low 0.05-0.2 and raise'). It enriches the schema descriptions without being 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 the tool builds a 'reactive signal-shaping chain (attack/release envelope + threshold gate or sidechain ducking)' from a CHOP channel, with an example 'pump the whole layer on every kick'. It uses specific verbs and resources, and distinguishes from siblings like the simpler 'bind_to_channel' which is mentioned 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?

  The description explicitly says when to use the tool (for sidechain effects) and provides an alternative: 'Use bind_to_channel with attack/release for a simpler Lag-only envelope without a gate.' It also gives tuning advice and warns about experimental gate parameters, offering clear context on 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_euclidean_sequencerA
  4.5/5.0
  Behavior4/5

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

  Annotations indicate non-readOnly, non-destructive, open-world. The description adds behavioral context: live parameter sweeping reshapes the table, and beat-callback timing is unverified offline. This supplements 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?

  Description is detailed but well-structured: purpose, algorithm, examples, live behavior, and caveat. Every sentence adds value, though slightly verbose for a quick scan. Could be tighter.

  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 11 parameters and no output schema, the description thoroughly covers build process, algorithm, usage examples, real-time modulation, action types, and a timing caveat. Missing nothing critical for an agent.

  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 description adds critical nuances: pulses clamped to steps, rotation as downbeat offset, on/off value roles, and action enum semantics. It enriches understanding beyond 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 it builds a Euclidean rhythm sequencer using Bjorklund's algorithm, writing patterns to a Table DAT and dispatching on beat boundaries. It explicitly distinguishes from the sibling create_beat_grid_sequencer, 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 contrasts this deterministic sequencer with the beat-grid alternative, provides example rhythms (tresillo, cinquillo, four-on-the-floor), and explains live modulation and action types. It lacks explicit 'when not to use' guidance but is highly informative.

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

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

  The description discloses key behaviors beyond annotations: creates a baseCOMP, opt-in audio routing, timeline dependency, return format with JSON block, and no preview image (CHOP vs TOP). Annotations indicate read/write but the description adds 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.

  Conciseness5/5

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

  The description is comprehensive yet efficient, with a clear opening verb ('SYNTHESIZE'). Every sentence carries useful information, and it is well-structured without 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's complexity (9 parameters, 3 synth types), the description covers all critical aspects: synthesis methods, opt-in playback, time-dependency, return structure, and warnings. No output schema, but the description adequately explains the 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?

  Schema coverage is 100% with detailed parameter descriptions. The tool description adds context for parameters like volume ('start moderate') and to_device ('default OFF'), but this is marginal value given schema completeness.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 synthesizes audio, differentiating it from reactive audio tools. It explains three synthesis methods and notes the output feeds specific sibling tools (create_spectrum/create_waveform), establishing clear purpose and boundaries.

  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 on when to use (generate rather than react) and mentions opt-in playback to avoid hardware prompts. It does not explicitly list exclusions but gives sufficient guidance for informed selection among siblings.

  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.5/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 explains the tool's ability to create FreenectTOP when enabled, extract hand centroids, divide into musical zones, trigger plucks, render curtain visuals, and expose diagnostics. It also warns about hardware unavailability and fallback behavior, which is 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.

  Conciseness4/5

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

  The description is relatively long but well-structured, starting with the main purpose and then detailing features. While every sentence adds useful information, it could be condensed slightly without losing 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?

  Given the tool's complexity (47 parameters, no output schema), the description covers the tool's behavior, input sources, fallback mechanism, and diagnostics adequately. However, it does not explicitly describe the output of the tool (e.g., what the generated Base COMP contains), which is a minor gap.

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

  Parameters4/5

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

  With 91% schema description coverage, the schema already provides good parameter explanations. The description adds value by explaining the purpose of parameters like 'activate_freenect' regarding macOS instability and 'fallback_to_synthetic' for safety. This slightly 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 explicitly states the tool builds a 'synthetic-safe Kinect v2 / FreenectTD projected wall harp in an isolated Base COMP', specifying the verb 'build', the resource 'wall harp', and key details about source options. It clearly distinguishes this from sibling creation tools by its unique functionality.

  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 when the tool can be used offline via synthetic fallback and mentions alternatives for input sources (freenect, synthetic, osc_kinect). It doesn't explicitly state when not to use it, but the context is clear for this specialized tool.

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

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

  Description discloses experimental status, hard cap at 8192 (CPU O(N·k)), and that result carries extra.unverified. Annotations (readOnlyHint: false, destructiveHint: false, openWorldHint: true) are consistent and not contradicted.

  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 comprehensive but slightly dense; it front-loads the purpose and follows a logical flow. Minor redundancy could be trimmed, but overall efficient 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?

  Given 15 parameters, no output schema, and complexity, the description covers the pipeline, constraints, and experimental warning. It hints at the output (Geometry COMP, Render TOP, Null TOP) but could be more explicit about what the tool returns.

  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 15 parameters have schema descriptions (100% coverage). The description adds value by explaining parameter interactions (e.g., count cap, color_mode drives Cd, max_distance drives density) and 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 creates a Plexus-style line-web visual using POP family, neighbor POP, Script SOP, and render pipeline. It distinguishes from siblings by specifying the unique technique and visual style.

  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 workflow and configurable options, implicitly guiding usage. It warns that POPs are experimental and result carries extra.unverified. However, it lacks explicit when-to-use vs alternatives.

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

• create_python_scriptA
  4.5/5.0
  Behavior4/5

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

  The description adds useful behavioral context beyond annotations, such as the Script DAT's companion callbacks DAT and the read-only nature of its own text. Annotations already provide destructiveHint: true, so the description complements 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 two sentences, front-loaded with the primary action and then detailing variants. It packs significant information efficiently, though the second sentence is slightly dense.

  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 4 parameters (2 required) and no output schema, the description covers the key behavioral aspects, return value (path to created DAT), and differentiates from a sibling tool. It provides sufficient 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?

  While schema coverage is 100%, the description adds meaning by explaining each dat_type option ('Text DAT (plain code)', 'Execute DAT (event hooks like onFrameStart)', 'Script DAT (table builder)') and clarifying that code for Script DAT goes to the companion callbacks 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 states it creates a DAT node under a parent path with Python code, and distinguishes three types (text, execute, script) with specific behaviors. It also differentiates from sibling tool 'execute_python_script' by stating that this tool only stores code as a node.

  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 when to use this tool versus the alternative: 'This only stores code as a node; use execute_python_script instead to run Python immediately against the live project.' This provides clear guidance on avoiding misuse.

  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?

  The description goes beyond annotations by detailing the creation of a baseCOMP, the dependency on Cache TOP ring buffer, the unverified GLSL shader, memory cost formula, and the expected freeze behavior. This is comprehensive behavioral disclosure, with no contradiction to 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 paragraph that efficiently conveys purpose, operation, edge cases, and warnings. Each sentence earns its place, and it is front-loaded with the key idea. 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?

  For a complex tool with 7 parameters and no output schema, the description provides full context: what is created, how it works, headless fallback, memory implications, freeze behavior, and the return format (summary with JSON and preview). It 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 coverage is 100% with parameter descriptions. The tool description adds context on the slit-scan effect but does not enhance per-parameter understanding 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 purpose: building a slit-scan visual system with a specific visual effect (time-as-space stretched-time), naming references (Floris Kaayk / Adam Magyar style), and detailing the components created (source TOP, Cache TOP ring buffer, slit GLSL shader, Null output). This distinguishes it from other 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 usage guidance by explaining headless/CI behavior when no source_top_path is given, memory cost warnings, and the expected freeze when timeline is paused. However, it does not explicitly compare with alternatives like create_time_echo or other time-based effects among siblings, limiting usage differentiation.

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

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

  Description details the creation process (Constant CHOP, oscoutCHOP), default port/prefix behavior, and that 'active' defaults off. This adds significant context beyond annotations (readOnlyHint=false, destructiveHint=false), 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.

  Conciseness4/5

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

  Description is relatively long but each sentence adds value; it front-loads the main purpose and explains the mechanism efficiently. Could be slightly more concise but overall 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 8 parameters and no output schema, the description covers the creation process, dependencies (on create_external_io), and intended outcome (OSC-out chain). It also hints at post-creation binding, making it sufficiently 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%, setting baseline at 3. Description adds meaning by explaining how 'preset' sets defaults for 'prefix', 'port', 'controls', and how overrides work, enriching parameter relationships 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 clearly states it builds a named OSC-out preset map for Synesthesia or Unreal Engine, with specific verbs like 'picks', 'builds', 'wires'. It distinguishes from sibling 'create_external_io' by noting it is a preset layer on top, solidifying its unique 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?

  Provides clear context for when to use (driving Synesthesia or Unreal) and mentions it's a preset layer on top of create_external_io, implying alternative for custom setups. However, it does not explicitly list when-not-to-use or all alternatives.

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

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

  The description discloses behavioral traits beyond annotations: it chains four GLSL passes, uses era presets with per-param overrides, and returns a standard envelope. 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 a single well-structured sentence that conveys all essential information without redundancy. It is front-loaded with the main action and efficiently packs 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 8 parameters and no output schema, the description adequately covers tool function, return values, and parameter interaction (presets and overrides). It 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.

  Parameters4/5

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

  Parameter schema coverage is 100%, but the description adds meaning by explaining that era presets set default strengths and per-param overrides win. This clarifies parameter interaction 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 the tool creates a vintage analog-film aesthetic on any TOP, describing the processing chain and return payload. It distinguishes itself from numerous similar 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 Guidelines4/5

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

  The description provides clear context that the tool is for adding vintage film effects over any TOP, but does not explicitly state when not to use it or list alternatives. The context is sufficient given the tool's specific niche.

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

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

  Annotations already indicate it's not read-only or destructive. Description adds detail: it classifies intent, delegates, creates COMP, verifies, previews, returns interpretation and builder result. 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?

  Concise 5-sentence description that front-loads purpose, explains process, compares to sibling, and states return value. 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 4 parameters (1 required), no output schema, but description fully explains behavior, return value, and relation to sibling. No 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 baseline is 3. Description does not add extra meaning beyond what the schema already specifies 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?

  Clearly states it creates a complete visual system from natural language. Distinguishes from sibling 'plan_visual' by specifying that this tool actually builds, while plan_visual is a dry run.

  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 this tool (to create) and when not to (use plan_visual for dry run). No ambiguity.

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

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

  Given annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description adds value by disclosing creation details (instanced Geometry COMP, CHOP chain, hard-caps at 256x256) and structural constraints, which goes beyond the annotation 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 concise yet comprehensive, front-loading the purpose and providing key details in two paragraphs. 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?

  With 11 parameters, full schema, and no output schema, the description covers essential aspects: creation process, parameter meanings, defaults, constraints (256x256 cap), and behavior. It leaves no critical gaps for an agent to misunderstand.

  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 context by explaining parameter behaviors (e.g., color modes, camera modes, expose_controls) and defaults, making the tool more understandable.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 isometric voxel-stack renderer driven by a TOP, with details on how it builds geometry and color modes. This specific verb+resource description distinguishes it from sibling '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 Guidelines4/5

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

  The description provides clear usage context (e.g., 'If source_top_path is omitted, a built-in animated noiseTOP drives the stack'), but does not explicitly mention when not to use this tool or name alternative tools. It implies usage scenarios effectively.

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

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

  The description exceeds the annotations by disclosing the interactive confirmation flow ('asks the artist in TouchDesigner to choose exactly Delete / Bypass / Keep'), the fallback behavior for close/timeout/error/unavailable UI ('means Keep'), the audited skip policy (TDMCP_YOLO), undo block wrapping, and the unverified whole-tool undo. This is far beyond what destructiveHint=true implies and is crucial for a destructive 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 three sentences, front-loaded with the core purpose, and every sentence adds distinct value: mode behavior, safety policy, undo/return information. There is 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 destructive mutation tool with external UI interaction and an open world, the description covers behavior, safety, fallback semantics, undo, and return values. Even though there's no output schema, the description explicitly lists 'decision, action applied, final path, confirmation policy/request id and undo label' which fully satisfies return-value transparency. The tool is complex, yet the description 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%, so the baseline is 3. The schema already thoroughly explains each parameter (mode, path, confirmation_timeout_ms). The tool description adds some behavioral context (e.g., 'bypass is immediate and reversible') but mostly restates what the schema says. 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 opens with 'Safely remove or bypass one TouchDesigner node', which is a specific verb+resource pair that clearly states the tool's core function. It also distinguishes between the two modes (delete vs. bypass), aligning with the 'delete_td_node' name and setting it apart from siblings like create_td_node and 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 provides clear usage context for each mode: 'delete' asks the artist and falls back to Keep, while 'bypass' is immediate and reversible. This implicitly guides when to choose each mode. However, it does not explicitly state when NOT to use this tool or name alternatives (e.g., 'disconnect_nodes' for non-destructive removal), 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.

• disconnect_nodesA
  4.5/5.0
  Behavior4/5

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

  Annotations (readOnlyHint: false, destructiveHint: false) are present; the description adds context: partial removals with warnings succeed, returns list of removed wires, and probe of Connector API. No contradiction. The description adds behavioral detail 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 a single paragraph of 4 sentences, front-loading the purpose and then adding detail efficiently. 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?

  Given the tool's complexity (3 params, 1 required, no output schema), the description covers purpose, parameter usage, default behavior, error handling, and return value. It 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.

  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 schema by explaining defaults ('removes every incoming wire') and how from_path and to_input narrow the scope. It also mentions return value, which is not in 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: 'Remove one or more input wires from a node in TouchDesigner.' It uses specific verb+resource (remove wires) and distinguishes from the sibling 'connect_nodes' by explicitly calling it 'the inverse of connect_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 the tool and how to narrow scope: 'By default removes every incoming wire into to_path; narrow the scope with from_path... and/or to_input.' It also clarifies error behavior: 'Fatal only when to_path is not found — partial removals with per-wire warnings still succeed.' It does not explicitly state when not to use, but the guidance is clear.

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

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

  Beyond annotations (readOnlyHint=false, destructiveHint=true), the description adds meaningful behavioral details: unknown IDs are reported in missing rather than silently substituted, and the return payload includes bundle kind, version, timestamp, exported recipes, and missing IDs. 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?

  Four sentences, front-loaded with the core purpose, and every sentence earns its place: purpose, behavior, sibling alternatives, and return value. 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?

  Given the tool has a rich schema, annotations, and an output schema, the description is still self-contained: it covers the main action, the include_all/recipe_ids interaction, unknown ID behavior, alternatives, and return fields. Nothing critical 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 coverage is 100% with clear per-parameter descriptions, so the baseline is 3. The description adds the conditional relationship (include_all=true ignores recipe_ids) and the unknown-ID handling, but these are largely implied by the schema's own descriptions, providing minimal additional 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 opens with a specific action, 'Write a portable JSON recipe bundle to out_file,' clearly identifying the verb, object, and destination. It also distinguishes the tool from siblings by naming import_recipe_bundle and publish_recipe_bundle with 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?

  Explicitly provides when-to-use guidance: 'Use import_recipe_bundle to restore the bundle on another machine or publish_recipe_bundle when you need checksums/versioned handoff artifacts.' It also clarifies the include_all toggle behavior, giving clear context 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.

• export_setlist_to_vaultA
  4.5/5.0
  Behavior4/5

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

  Annotations already indicate non-readOnly and non-destructive. The description adds that it writes a note with a specific frontmatter format and requires a vault path. It does not mention that it only reads from the COMP and does not modify it, but this is implied by 'serialize' and the non-destructive 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 plus a brief explanation of the frontmatter format and re-import capability. It is concise, front-loaded with the main action, and 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 complexity (4 params, no output schema), the description covers the workflow, prerequisites, parameter mappings, and linkage to sibling import_setlist. The agent has sufficient information 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?

  All four parameters are documented in the schema with 100% coverage. The description further contextualizes each parameter (e.g., target as COMP, folder matching import_setlist, include_tempo capturing global tempo). This reinforces 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 action (serialize cues into a setlist note), the resource (COMP managed cues, Obsidian vault), and the purpose (round-trip, git-diffable). It distinguishes from the sibling import_setlist by mentioning the round-trip 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 explains the tool's context: it exports cues from a COMP to a vault note for later re-import. It mentions the prerequisite TDMCP_VAULT_PATH. However, it does not explicitly state when not to use it or directly compare with alternatives beyond import_setlist.

  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; description adds algorithm details (k-means, PNG capture) and output structure. No contradiction. Provides good 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.

  Conciseness5/5

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

  Two well-structured sentences. First sentence states action and method; second lists return fields and use cases. No extraneous information, front-loaded with key info.

  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 100% schema coverage and annotations, the description covers all aspects: what it does, how it works, what it returns, and when to use it. No 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%, but description adds context: preview resolution parameters (width, height) are for sampling speed, and k is the number of colors. This adds meaning 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 the tool extracts dominant colors from a TOP using k-means, distinguishes from siblings like 'create_palette' and 'color_grade' by specifying its role in feeding AI grading and palette creation.

  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 for usage: feeds AI grading prompts, create_palette, and design hand-offs. Also notes read-only nature. However, does not explicitly state when to avoid use or directly compare to alternatives beyond mentioning create_palette.

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

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

  Annotations already declare readOnlyHint and destructiveHint=false, but the description adds behavioral details beyond that: it is 'compact', does not transfer topology, returns a specific structure {count, truncated, matches/paths, search_metadata}, and falls back to list/topology reads on older bridges. This is useful 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.

  Conciseness5/5

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

  The description is extremely concise: two sentences, front-loaded with the core purpose ('Read-only: compact bridge-side node search'), and includes usage guidance and return format without redundancy. 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 13-parameter schema has full descriptions and an output schema exists, the description only needs to fill the gaps: usage recommendations, behavioral limits (no topology transfer), and fallback behavior. It does this completely, making it sufficient 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.

  Parameters3/5

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

  Schema coverage is 100% with every parameter well-described, so baseline is 3. The description summarizes search dimensions (name/path glob, operator type, family, bounded depth) but does not add new meaning beyond the schema's per-parameter descriptions. The terms map directly to existing schema fields like pattern, path_glob, type, family, and max_depth.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 performs a read-only search for TouchDesigner nodes by name/path glob, exact or partial operator type, family, and bounded depth. The verb 'search' with specific filter dimensions clearly distinguishes it from sibling tools like get_td_nodes and get_td_topology.

  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 direct usage guidance: 'Prefer this over get_td_nodes when looking through a sub-tree; use get_td_topology only when you need wiring.' It also mentions fallback behavior for older bridges, providing clear context on when 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.

• find_td_parametersA
  4.5/5.0
  Behavior5/5

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

  Annotations already declare read-only and non-destructive, but the description adds substantial behavioral context: bounded search, point-in-time snapshots, secret redaction preventing value/expression matches, completeness caveat via scan_truncated/count_complete, and no fallback to raw Python. This goes well beyond annotation basics.

  Agents need to know what a tool does to the world before 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 key safety property ('Read-only:'), and each sentence adds distinct value: scope, snapshot semantics, and completeness/fallback caveats. 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 17-parameter search tool with an output schema, the description covers essential operational aspects: boundedness, snapshot semantics, secret redaction, completeness signals, and route requirements. The output schema handles return-value details, so the description is appropriately 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 covers 53% of parameters; the description maps to filter categories and notes that redacted secrets cannot satisfy value/expression filters. However, it does not explain undocumented parameters like limit, time_budget_ms, node_scan_limit, parameter_scan_limit, or non_default_only, so it only partially compensates for 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 states a specific verb ('search') and resource ('live TouchDesigner parameters') with explicit filter dimensions (node, operator type/family, parameter name, value, expression, mode, non-default state). This clearly distinguishes it from siblings like get_td_node_parameters or find_td_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 clear context: read-only, bounded, bridge-side, point-in-time snapshots, and a prerequisite (current structured bridge route). It does not explicitly name alternatives or when-not-to-use, but the context is sufficient for most selection decisions.

  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 readOnlyHint=true and destructiveHint=false. The description adds value by stating it is offline and describing the return shape (object or {found:false, suggestions[]}), which is helpful 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 with no wasted words. The first sentence front-loads the key purpose, read-only nature, and offline context. Second sentence adds return structure 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?

  For a simple tool with one parameter and full schema coverage, the description adequately explains the return value, offline behavior, and suggestions on failure. No 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% with a well-described parameter 'class_name' and an example. The description does not add additional 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 clearly specifies the action ('get'), resource ('structured documentation for one TouchDesigner Python class'), and differentiates from sibling 'get_module_help' by noting structured JSON vs 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 says when to use the alternative 'get_module_help' for Markdown output, implying this tool is for structured JSON. Provides clear context for choosing between them.

  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 indicate read-only and non-destructive. The description adds that it works offline and never touches TD, and specifies the return format, supplementing annotations 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?

  Three concise sentences, front-loaded with 'Read-only', no filler, each sentence adding 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 explicitly states the return format. For a simple single-parameter tool, this is fully 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 a clear description of the 'filter' parameter. The description only reiterates 'Optionally filter by name', adding no new meaning; 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 lists TouchDesigner Python API class names from an embedded knowledge base, emphasizing offline and safe operation. It distinguishes from siblings by referencing get_td_class_details and get_module_help for expansion.

  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 the tool (listing classes) and directs to alternatives for expanding a class into members and methods, providing clear usage context.

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

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

  The description adds rich behavioral detail beyond the annotations: source resolution order (OfflineHelp first, then embedded KB), output nature (section ids, build provenance), web fallback policy (off by default, restricted to docs.derivative.ca, labeled as latest-web), and constraints (never accepts paths, never returns raw HTML). This fully discloses the tool's behavior 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 three sentences, front-loaded with 'Read-only' and the core function. Each sentence earns its place: the first states the main purpose, the second describes the output and provenance, and the third covers web fallback and constraints. 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?

  Given the tool has 6 parameters, an output schema, and annotations, the description is complete. It covers the source hierarchy, output format hints, safety constraints, and web fallback behavior. The output schema handles return value specifics, so the description only needs to provide high-level context, which it does thoroughly.

  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 clarifying the query constraint ('Never accepts a filesystem path') and the web_fallback behavior ('restricted to docs.derivative.ca and labeled as latest-web'), which enriches the meaning of the source and web_fallback parameters. It does not duplicate 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: 'resolve compact TouchDesigner operator, Python API, or concept documentation from the installed OfflineHelp corpus first, then the embedded KB.' It specifies the resource type (documentation), the sources, and the output (section ids, provenance). This distinguishes it from siblings like get_td_info or search_operators by emphasizing the offline-first, build-aware nature.

  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 (for documentation lookup) and provides constraints like 'Web fallback is off by default' and 'Never accepts a filesystem path.' However, it does not explicitly name alternatives or exclusions (e.g., 'for web docs, use search_touchdesigner_knowledge'). Guidance is present but implicit, so it meets the minimum viable level.

  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 discloses rich behavioral traits: atomicity, compare-and-swap semantics, idempotency key, bounded before/after connector receipts, rollback state, preservation of fan-out siblings, ALLOW_EXEC=0, and exclusion of raw Python/mouse interactions. Annotations only provide readOnlyHint:false, openWorldHint:true, destructiveHint:false, so the description adds substantial safety and side-effect context beyond 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 dense sentences are front-loaded with the core purpose, followed by concise behavioral guarantees. Every clause adds meaningful information, and there is 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 (editor-context compare-and-swap, idempotency, atomic placement), the description is remarkably complete: it covers atomicity, exact-selection requirements, rollback, preservation of fan-outs, and execution restrictions. An output schema exists, so return-value details are not required here, and no major 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 reinforces the purpose of expected_context ('exact editor-context compare-and-swap') and idempotency_key but does not add extra syntax, formatting, or parameter-specific details 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 states a precise action: 'Atomically insert one same-family operator on one deterministic downstream edge of the exactly selected/current TouchDesigner operator.' This distinguishes the tool from generic creation (create_td_node) and connection (connect_nodes) by emphasizing atomicity, deterministic downstream edge, and exact selection.

  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 by stating requirements: 'exact editor-context compare-and-swap' and 'idempotency key.' It also discloses exclusions ('never invokes raw Python, mouse-interactive placeOPs, or implicit pane selection'), giving clear operational boundaries. However, it does not explicitly name alternative sibling tools for different scenarios.

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

• learn_conventionsA
  4.5/5.0
  Behavior5/5

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

  The description clearly discloses that while the TD side is read-only, the tool mutates vault files, and specifies the default behavior (writes Memory/conventions.md, may merge into Memory/style.md). It also explains how to avoid writes with dry_run=true and mentions the TDMCP_VAULT_PATH requirement. 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 four sentences and richly informative, front-loading the main purpose. While slightly long, each sentence contributes distinct value: purpose, side effects, dry-run, alternatives, and requirements.

  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 stating the return value ('sampled conventions plus write flags'). It covers prerequisites, side effects, and alternatives. The tool is complex, but the description provides enough context 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?

  Schema description coverage is 100%, so the schema already documents all six parameters. The description adds context about the overall workflow and explicitly mentions dry_run, but does not add new semantic 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 clearly identifies the tool's purpose: reading a TD subtree, inferring conventions, and writing results to an Obsidian vault. It uses specific verbs and resources (read, infer, write) and distinguishes itself from learn_from_my_corpus and load_session_profile by naming them 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?

  The description provides explicit guidance on when to use this tool vs alternatives: '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.' It also mentions a dry_run mode for inspection, making the decision context clear.

  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?

  Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses crucial safety behaviors: reconciliation is dry-run-first, proves marker ownership, requires Delete/Bypass/Keep consent, and legacy uninstall returns a safe plan instead of deleting first. It also explicitly states what the tool never does (run third-party scripts, pip installs, model downloads, external app setup), adding significant context beyond the structured 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?

  Three sentences, with the first sentence front-loading the core purpose, the second detailing the reconciliation safety protocol, and the third clarifying legacy behavior and explicit exclusions. Every sentence adds value, and the description is compact given the 17-parameter 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 destructive, open-world package manager tool with 17 parameters, the description covers essential context: scope, safety protocols, consent flow, legacy uninstall behavior, and explicit non-actions. It is sufficient for an agent to invoke the tool safely and understand its side effects, even without 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 already provides 100% coverage with detailed parameter descriptions, so the baseline is 3. The tool description does not add any parameter-specific semantics beyond what the schema offers, but it does contextualize actions like 'reconcile' and 'install' that are relevant to parameter usage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Search, list, inspect, doctor, install, reconcile, and uninstall') tied to a clear resource ('manifest-driven TouchDesigner community packages') and scope ('user or project scope'). This distinguishes it from sibling tools, which focus on node creation or external integrations, not package lifecycle management.

  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 operational scope ('at explicit user or project scope') and explains the safe reconciliation workflow (dry-run-first, consent before pruning). However, it does not name alternative tools or explicitly state when NOT to use it, though the context is strong enough to infer its package-management niche.

  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.5/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, open-world. Description adds detail on wiring order (SSAO after Render, no TOP between), exposed controls (Spin, Zoom, Ssao toggle), and return value structure (summary + JSON block with paths, errors). Does not mention potential side effects or performance impact.

  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 well-structured: main purpose, comparison, wiring details, parameter hints, and return info. Each sentence serves a purpose, though some details could be more concise. Front-loaded with key 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?

  Given the tool has 8 parameters and no output schema, the description covers creation steps, parameter roles, wiring constraints, and return format (summary + JSON). It lacks an explicit list of return fields but is sufficient for an agent to use 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?

  Input schema provides 100% description coverage, so baseline is 3. The description adds context for 'expose_depth' (its purpose for downstream tools) and 'ssao' (for contact shadows). This extra clarity warrants 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 clearly states the tool builds a 3D scene with specific components (Geometry, Camera, Light, Render TOP) and optional SSAO and Depth outputs. It explicitly compares to sibling 'create_3d_scene', providing distinct 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 explains when to use this tool over the sibling 'create_3d_scene' (for SSAO/depth), and provides downstream usage hints for depth output with 'create_depth_displacement' or 'create_depth_silhouette'. It also notes that no depth camera is needed.

  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.5/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: fixed pass order, skip/fallback behaviors for missing AOVs, automatic depthTOP creation, and return values. Annotations are readOnlyHint=false, destructiveHint=false, openWorldHint=true, and the description consistently describes a constructive, non-destructive operation.

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

  Conciseness5/5

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

  The description is a single, dense paragraph that efficiently conveys purpose, order, fallbacks, and return values. Every sentence adds distinct value, and the key 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 complex tool with 17 parameters and no output schema, the description provides complete context: it explains the pass chain, fallback conditions, auto-creation logic, and return data (paths, warnings). The agent has sufficient information to use 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 low (35%), but the description compensates by explaining how key parameters affect behavior (e.g., normal_top empty skips SSR, depth_top auto-derivation). This adds meaning 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 verb 'Compose' and the resource 'a chain of 3D-aware post-processing passes inside a new baseCOMP'. It lists the specific passes (SSAO, SSR, DOF, motion blur), distinguishing this tool 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 usage for creating a fixed-order post-processing chain with 3D AOVs, but does not explicitly state when to use this tool versus alternatives (e.g., apply_post_processing). No exclusions or when-not-to-use guidance is provided.

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

• read_parameter_modesA
  4.5/5.0
  Behavior4/5

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

  The description begins with 'Read-only,' consistent with the annotation 'readOnlyHint: true.' It details the exact data reported (mode, value, raw strings) and the use case. It adds context beyond the annotations by clarifying the scope and purpose, though it doesn't mention any additional behavioral traits like response format or pagination.

  Agents need to know what a tool does to the world before 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 well-structured sentences: the first defines the tool's action and output, the second provides usage guidance and a parameter hint. No redundant words; 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?

  Given the tool's complexity (3 parameters, 1 required, output schema provided), the description covers purpose, output details, and usage context. The output schema handles return value specification, so no further detail is needed.

  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 adds significant value for the 'non_default_only' parameter by explaining its purpose in the context of round-trip editing. It also reinforces the overall intent, making parameter semantics clearer than 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?

  The description clearly states the verb 'report' and the resource 'parameter modes' of a node, listing the exact information returned (mode, evaluated value, raw strings). It distinguishes this tool from siblings like 'get_td_node_parameters' by focusing on modes for round-trip editing, diffing, or debugging.

  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 tells when to use the tool: for faithfully serializing a network for round-trip editing, diffing, or debugging. It explains why evaluated values alone are insufficient. While it doesn't name specific alternatives, it implies that other tools might be used for plain value copies.

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

• reload_bridgeA
  4.5/5.0
  Behavior4/5

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

  The description adds behavioral context beyond annotations: it details that the tool reimports loaded mcp.*/utils.* modules, returns a list, and performs a hot-reload. Annotations already indicate non-read-only and non-destructive, but the description clarifies the mutation is limited to reimports.

  Agents need to know what a tool does to the world before 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 no redundancy: first states the action, second explains the mechanism, third advises when to use. Every sentence is essential and 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 no parameters and no output schema, the description covers all key aspects: purpose, mechanism (reimports specific modules), return value (list), and usage timing. It is self-contained and adequate for the tool's simplicity.

  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 zero parameters, the description correctly implies no inputs are needed, which adds value by confirming simplicity. Schema coverage is irrelevant, but the description reinforces the lack of required arguments.

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

  Purpose5/5

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

  The description clearly identifies the tool's purpose: hot-reload the bridge's Python within TouchDesigner. It specifies the verb (reload) and resource (bridge's Python), and distinguishes it from sibling tools like get_bridge_logs by focusing on reimporting modules.

  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 'Use after editing bridge code,' providing clear context for when to invoke. It lacks explicit exclusion or alternatives, but the guidance is sufficient for the tool's narrow scope.

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

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

  The description discloses that the tool reads the current network state and writes to vault. It states it refuses to overwrite unless overwrite:true. It also mentions the required environment variable. Annotations indicate it's not read-only and not destructive, consistent with description.

  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, each serving a purpose: explaining the action, the use case, the overwrite policy, and the return values. It is front-loaded with the main purpose. No extraneous information, though it could be slightly more concise.

  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 (10 parameters, no output schema), the description provides sufficient context: it explains the operation, the return value (path, id, counts), and a prerequisite (env var). It does not detail each parameter, but the schema covers that. It could be improved by differentiating from similar save tools like save_component_to_vault, but overall it 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 10 parameters have descriptions in the input schema (100% coverage). The tool description does not add new semantic information about individual parameters beyond what is in the schema; it only mentions id and overwrite in passing. Thus the description does not 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 explicitly states the tool captures a COMP's network and writes it as a reusable recipe note in the vault. It distinguishes itself from the sibling apply_recipe by noting that apply_recipe is for instantiating a template. The verb 'save to vault' 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 Guidelines5/5

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

  The description provides clear guidance: use this to turn an existing patch into a template, and use apply_recipe to instantiate a template. It also warns about the overwrite behavior and the requirement for TDMCP_VAULT_PATH. No explicit 'when not to use' but the alternative is 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 declare destructiveHint=true and readOnlyHint=false, but the description adds critical behavioral detail: bounded native overwrite consent, fail-closed to Keep on timeout/error, no native dialog, and no raw Python fallback. It also discloses return values, which is valuable beyond annotations. 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?

  Three dense sentences, each carrying essential information: main action, consent/fail-closed behavior, and return values. No filler or redundancy; 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?

  Given the tool's complexity (overwrite consent, fail-closed behavior, return metadata) and absence of output schema, the description covers all crucial aspects: path handling, timeout bounds, failure behavior, and return contents. An agent can invoke this correctly without additional 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% and both parameters are well-described. The description adds some nuance (e.g., 'fail closed to Keep' relates to timeout behavior) but mostly restates the schema's path and timeout 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 clearly states the tool saves the current TouchDesigner project or performs Save As to an explicit path, using a specific verb and resource. It distinguishes itself from sibling tools by being the only project-save action, with no 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 gives clear context: it works on the current project, requires a path for unsaved projects, and for existing paths requires overwrite consent. It also states explicit non-behaviors (never opens a native file dialog, never loads/quits, never falls back to raw Python), but does not name alternative tools or explicitly say 'when not to use'. This is a minor gap, so 4.

  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?

  Annotations (readOnlyHint=false, destructiveHint=false) already indicate a non-read, non-destructive creation. The description adds context: creates container and nodes, returns paths, and clarifies no scenes or look are created, which aligns with 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?

  Three sentences with no wasted words. Front-loaded with purpose, then contrast with sibling, then return info, then guidance. 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?

  For a simple creation tool with two parameters and no output schema, the description covers purpose, components created, what is not created, alternative tool, and return value. It is 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 coverage is 100% with clear descriptions for both parameters. The description reiterates 'container under parent_path' and mentions 'name' implicitly but adds no additional 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 explicitly states it creates a skeleton for a live show with a container, master output, and tempo beat clock, using specific verbs and resources. It clearly distinguishes from scaffold_genre by stating what it does not include (scenes, look).

  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 on when to use this tool versus scaffold_genre: 'Use scaffold_genre instead when you want a genre-flavored start...' Also implies it's for a blank-canvas start.

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

• scaffold_vaultA
  4.5/5.0
  Behavior4/5

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

  The description details writing behavior, skipping existing files, and the overwrite option. It adds context beyond annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) by explaining file creation. Could mention if folders are created, but still clear.

  Agents need to know what a tool does to the world before 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 covering purpose, behavior, and usage, all front-loaded. 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?

  For a simple tool with one optional parameter and no output schema, the description covers purpose, behavior, prerequisites, return values, and usage context completely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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, so baseline is 3. The description adds minimal extra context beyond the schema's description, mostly reiterating the overwrite effect.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 populates an Obsidian vault with a starter layout and examples, distinguishing it from sibling tools like save_recipe_to_vault and import_setlist by specifying it's a first-time 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?

  Explicitly says to run once when first setting up a vault, before other tools, and notes the prerequisite TDMCP_VAULT_PATH. Explains behavior with existing files and the overwrite parameter.

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

• search_td_codeA
  4.5/5.0
  Behavior5/5

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

  It discloses read-only behavior, bounded search, redacted output, completeness metadata, and exclusion of fallback to raw Python/whole DAT exports. This complements the readOnlyHint and openWorldHint annotations with actionable 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 three dense sentences that front-load the core behavior and add critical constraints 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.

  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 annotations, the description supplies necessary context: scope (live project), behavior (read-only, bounded), result shape (redacted excerpts with provenance), and environmental constraints (works with exec disabled). This is sufficient for an agent to decide 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 description clarifies that query is a lexical search string and source_kinds covers DAT text/parameter expressions, but it does not explain the numerous limit/scan parameters or filters like family and type_match. Schema descriptions cover about half the parameters, so the description only partially compensates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 unique action: bounded BM25-style lexical search across DAT text and parameter expressions, with result characteristics (redacted excerpts and provenance). It clearly distinguishes from sibling tools like execute_python_script or search_operators by stating it never falls back to raw Python or exports whole DATs.

  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 notes the tool works even when TDMCP_BRIDGE_ALLOW_EXEC=0, giving a concrete usage scenario. However, it does not name alternative tools or say when not to use it, relying on the scope to imply appropriate usage.

  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.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 by starting with 'Read-only'. It adds useful behavioral context beyond annotations: the clustering logic, the 'suggested order to investigate', and that group samples retain error/warning severity. This provides a clear picture of the tool's operation 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 composed of three well-structured sentences, front-loaded with the tool's core purpose. Every sentence adds value: the first explains what the tool does, the second outlines the return structure, and the third gives usage guidance. 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?

  The description is comprehensive for a read-only network diagnostics summary tool. It explains the return structure, grouping options, the suggested investigation order, and explicitly distinguishes it from the raw-error alternative. Given the presence of an output schema, the description does not need to detail every return field; it provides sufficient 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?

  Schema coverage is 100%, so the parameters are fully described in the schema. The description does not add new meaning beyond what the schema already provides, though it does mention grouping by 'message, severity type, or parent container', which aligns with the group_by enum. 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 clearly states the tool's function: collecting and clustering errors/warnings across a network. It specifies grouping dimensions (message, severity type, parent container) and output components. It explicitly differentiates itself from the sibling get_td_node_errors by describing what this tool does versus that 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?

  The description provides explicit guidance: use this for network-wide triage instead of reading each node's diagnostics individually, and use get_td_node_errors when the raw list for a single node or sub-tree is needed. This clearly defines when to use this tool versus an alternative.

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

• apply_lutA
  4.6/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. The description adds substantial behavioral details beyond annotations: it creates a container, exposes Strength and Bypass controls, has fallback logic for OCIO vs lookup, and explains Python parsing for .cube files without OCIO. This fully discloses the tool's 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 efficiently structured with a clear purpose statement first, followed by functional details. Every sentence adds value. It is not overly verbose, though it could be slightly more concise without losing information. Good front-loading.

  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, multiple file formats, fallback logic, exposed controls), the description covers all essential behaviors: how different file types are handled, the role of each parameter, and the result (container with controls). No output schema exists, so the description adequately explains the tool's output and side effects.

  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 well-described parameters. The description adds extra meaning by explaining the purpose of source_path (grade vs standalone) and providing context for the prefer parameter (auto, ocio, lookup). This enriches understanding beyond 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?

  The description clearly states the tool applies a colour LUT to an existing TOP inside a baseCOMP. It uses specific verbs and resources, and distinguishes itself from sibling tools by focusing on LUT application without confusion with other apply 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 guidance on when to use the tool and how to use it: passing source_path for grading an existing TOP or omitting it for standalone preview. It explains the preferred method for different file types, but does not explicitly compare to siblings like apply_glsl_top_mapping. The guidance is clear for the intended purpose.

  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 discloses important behavioral traits beyond the annotations: atomicity, stale-context checks, readback, rollback, and legacy response preservation. It also guarantees no structural changes to nodes, which adds significant context beyond readOnlyHint:false and 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 three sentences, front-loaded with the core purpose in the first clause, and each sentence adds distinct, non-redundant information: core function, mode-specific behavior, and non-destructive guarantee. No word is wasted.

  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 10-parameter tool with no output schema, the description provides a solid high-level orientation, covering modes, atomicity, safety guarantees, and legacy behavior. It doesn't describe return values, but given 100% schema parameter coverage, the description need not compensate for schema gaps. The main missing piece is return-value expectations, but this is acceptable given the schema richness.

  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 10 parameters already have descriptions in the schema (100% coverage), raising the baseline to 3. The description adds value by contextualizing layout_mode (auto vs explicit), mentioning annotation-aware behavior, and connecting idempotency_key to the atomic/rollback guarantees, but it doesn't deeply elaborate individual parameter meanings.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Tidy an existing network into a readable left→right data-flow layout' with a specific verb and resource. It also distinguishes itself from topology-changing sibling tools by explicitly stating 'It never adds, deletes, or rewires 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 gives clear mode-specific guidance, such as 'use layout_mode=explicit for one bounded, atomic exact-coordinate mutation' and notes that annotation-aware automatic layout remains available. However, it does not explicitly name alternative sibling tools or provide 'when-not-to-use' exclusions beyond the implicit 'never adds, deletes, or rewires nodes.'

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

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

  The description states it is read-only, requires no TouchDesigner connection, reads from local disk, and returns a flat items array with per-category counts. This aligns with annotations (readOnlyHint, destructiveHint=false) and adds valuable 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?

  The description is two sentences plus a final requirement line, front-loaded with purpose and key features. Every sentence adds value with no 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?

  Given the tool's simplicity, the description covers inputs, behavior, and output format. However, it does not mention if there is any limit on results or pagination; this is minor given that an output schema exists but is not shown. Still, a complete description would address potential result size.

  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 coverage is 100% and the description elaborates that 'kinds' filters by category and 'query' is a case-insensitive substring filter on title/tags, adding clarity beyond the schema alone. The description could also mention that 'all' lists every known category.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'vault's recipes, shaders, presets, components, and setlists'. It explicitly distinguishes from sibling tools like 'browse_library' and 'list_recipes' by specifying it lists vault items with title/tags/description for selection without opening notes.

  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 when to use ('so the agent can pick from the library without opening individual notes'), provides filter options (category and substring query), and notes the prerequisite (TDMCP_VAULT_PATH). It does not explicitly exclude alternative tools, but the context is sufficient. A slight improvement could be noting 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.

• caption_topA
  4.6/5.0
  Behavior5/5

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

  Annotations declare readOnlyHint and destructiveHint; description adds implementation details (vision vs histogram), fallback behavior, and return structure. 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?

  Single paragraph front-loads purpose, then explains paths, return, and usage. Generally efficient, though slightly verbose in listing return 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 4 parameters, no output schema, the description explains return structure, usage context, and warns about vision path inertness. Fully sufficient for this simple 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 covers 100% of parameters, description adds context like 'Smaller is faster' for width/height and explains use_vision behavior, adding 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 clearly states the verb (render/describe), resource (TOP preview), and scope (check if alive). It distinguishes itself from sibling tools which are mostly creation or other utilities.

  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 says to use after a build to confirm rendering, not just black frame. Mentions two paths and that vision is currently inert. Does not list alternatives but context is clear.

  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 substantial behavioral context beyond the readOnlyHint and destructiveHint annotations. It discloses egress requirements (loopback vs. remote), return fields ('redacted egress locality/transport' and 'calibration: not_checked'), role limitations ('NOT the calibrated visual-mutation authority'), and implementation details (uses ctx.llm.complete() with an image part). 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?

  Four sentences, each earning its place: purpose, egress conditions, return/limitations, implementation, and sibling differentiation. The description is front-loaded with the primary action and avoids 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?

  The description covers the tool's purpose, egress constraints, return summary, and differentiates it from a sibling. Without an output schema, it does not fully specify the complete return structure, but the primary output (the LLM's answer) is implied. It is adequate given the tool's complexity and annotation 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?

  With 100% schema coverage, the baseline is 3. The description enriches parameter semantics by explaining when `allow_remote_image_egress` is required (remote, client-managed, or unknown backends) and clarifies that `source_top` is captured as a preview image. This adds meaning beyond the schema's generic wording.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 TOP as a preview image and ask the configured multimodal LLM a question about it.' This clearly states what the tool does and distinguishes it from the sibling `caption_top` by explicitly noting it is 'Different from `caption_top`, which is deterministic-by-default.'

  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 by contrasting with `caption_top` and by stating it is 'NOT the calibrated visual-mutation authority,' which excludes calibration/mutation use. However, it does not explicitly say 'use this when you need an open-ended or non-deterministic answer' or provide explicit usage scenarios beyond the core action.

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

• create_datamoshA
  4.6/5.0
  Behavior4/5

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

  Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are present. The description adds behavioral details: creates a container with Null TOP output, exposed controls, live preview, and fallback behavior. 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 concise (about 150 words), efficiently structured with a purpose first then details, and 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 7 parameters, no output schema, and rich sibling context, the description covers all aspects: parameters well explained, return type described (container with Null TOP, controls, preview), and modes detailed.

  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 significantly enriches each parameter's meaning: explains internal algorithms for modes, specific TOP operations for decay and displace, and resolution forced on feedback loop to prevent flickering.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 datamosh/time-smear effect network in one call, lists three distinct modes with explanations, and distinguishes itself from siblings like create_time_echo by incorporating that mode as one of its 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 context on when to use each mode and notes that time_echo is unverified with a fallback. However, it does not explicitly state when not to use this tool versus alternatives, missing some comparative guidance.

  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.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, openWorldHint=true), the description discloses detailed behavioral traits: offline cooking behavior when no URL is given, that live OSC/serial values appear only when a sender/device is present, and the output format (Null CHOP for numeric fields, Null DAT for raw text). 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 paragraph containing all necessary information without redundancy, but it is relatively long (123 words). The structure is logical: main purpose, kind-specific details, then output behavior. Could be slightly more concise but remains 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 complexity (10 params, no output schema), the description fully covers the tool's behavior: it explains offline fallback, live data conditions, output format, and binding capability. It leaves no significant gaps for an intelligent agent to infer.

  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 provides 100% description coverage for parameters. However, the description adds value by summarizing how parameters relate to each other (e.g., url and kind interaction, fields becoming channels) and explaining the overall output structure 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 'Ingest live external data onto a binding-ready channel/table', specifies the four kinds (json, csv, osc, serial) and contrasts itself as the 'input counterpart' to create_data_visualization and bind_to_channel, 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 Guidelines4/5

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

  The description provides context for when to use each kind (e.g., 'json/csv poll a URL', 'osc listens on a UDP port') and identifies related tools (create_data_visualization, bind_to_channel). However, it does not explicitly state when not to use this tool or offer direct alternatives, 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.

• create_depth_pop_fieldA
  4.6/5.0
  Behavior5/5

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

  The description thoroughly discloses behavioral traits: it consumes a depth/mask TOP, uses lookup_texture_pop, and auto-spins-up a MediaPipe chain. It warns that POPs are Experimental with fail-forward op types, and notes unverified probe for depth-weighted birth. Annotations are readOnlyHint=false, destructiveHint=false, openWorldHint=true, which align; 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 relatively long but well-structured, with a clear front-loaded purpose. Every sentence adds information, though some redundancy (e.g., repeating mode explanations) could be tightened. The experimental warning is important but adds length. Overall effective but not maximally 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 complexity (12 parameters, no output schema), the description is complete: it explains the tool's purpose, usage scenarios, behavioral details, parameter roles (supported by schema), and specifies the return JSON block (container path, depth source info, etc.). No critical gaps remain.

  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 beyond the schema by explaining the auto-setup behavior for depth_top_path, the experimental note on true depth-weighted birth for scatter_mode, and the return format. This additional context merits a score of 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 clearly states the tool's purpose: 'Build a depth-driven GPU POP scatter field.' It specifies the resource (depth/mask TOP) and the action (creating a POP field with displacement/ scatter proxies). The description also distinguishes modes ('displace', 'emit', 'both') and mentions forward compatibility, setting it apart from sibling tools like create_pop_field.

  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, including handling of depth_top_path omission and auto-setup of a segmentation chain. It explains scatter modes and when to pass create_depth_from_2d output. However, it does not explicitly exclude alternatives or provide when-not-to-use guidance, limiting the score to 4.

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

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

  Description details what happens: creates a baseCOMP with Select TOP, GLSL remap, Null output. Exposes controls like Rotation knob. Annotations (readOnlyHint=false, destructiveHint=false) align with creation behavior. Could add more about error handling but 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?

  Well-structured with front-loaded action and clear breakdown. However, it is somewhat lengthy (5 sentences). Could be trimmed slightly without losing clarity.

  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 (6 params, no output schema), the description covers purpose, internal nodes, output format (summary with JSON block), and includes warnings. No gaps identified.

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

  Parameters4/5

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

  Schema coverage is 100% with descriptions. Description adds value by explaining projection modes (fisheye vs equirectangular) and fov coverage in context. Slightly beyond repetition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: remapping a source TOP into a dome master for planetarium fulldomes. It distinguishes itself from sibling create_multi_output (flat tiling) and create_cubemap_dome (cube-map render).

  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 (dome/fulldome output) and when-not-to-use (use create_cubemap_dome for higher fidelity). Names specific alternative tools and explains trade-offs.

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

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

  The description extensively discloses behaviors beyond the annotations: it creates a Script CHOP with rolling buffer, adaptive threshold, hysteresis, exposes custom parameters, may trigger macOS permission dialog, and describes output channels. Given annotations only provide readOnlyHint and destructiveHint, the description fully compensates.

  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 well-structured, starting with the main purpose and then detailing algorithm, parameters, and side effects. Every sentence adds necessary information, though minor redundant phrasing could be trimmed.

  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), the description covers all essential aspects: algorithm, parameter meanings, output channels, side effects, and usage options. It is thoroughly complete for an agent to understand 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%, so baseline is 3. The description adds significant meaning: explains that buildThreshold and dropThreshold are k-multipliers not absolute amplitudes, details hysteresis counts, and clarifies default audio source behavior. This adds 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 specifies the tool creates a 'song-structure (build / drop / breakdown) edge detector COMP with adaptive thresholds'. It uses specific verbs and resources, distinguishing it from sibling tools like create_audio_reactive or create_beat_grid_sequencer by focusing on energy-based structure detection.

  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 this tool (for creating a structure-detection COMP) and provides context on audio source options (existing CHOP or new Audio Device In). However, it does not explicitly state when not to use it or name alternatives, though the unique functionality implicitly guides usage.

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

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

  Annotations indicate creation (readOnlyHint=false) and non-destructive (destructiveHint=false). Description fully details the created topology, return values (summary, paths, controls, errors, preview), and built-in noise seed behavior. 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?

  Description is front-loaded and efficient, but somewhat lengthy with many technical details. Still 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?

  Given no output schema, the description fully covers return values and behavior. Includes topology, controls, live performance context, and alternative usage. Complete for a tool with 8 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 coverage is 88% (high), so baseline 3. Description adds overall context but does not significantly enhance parameter understanding beyond the schema's existing 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 states specific verb+resource: 'Build a parameterized infinite-zoom/rotate feedback tunnel' and distinguishes from sibling tool 'create_feedback_network' by explicitly calling out the fixed preset vs general loop.

  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 on when to use this tool: 'for a general feedback loop... use create_feedback_network instead.' Also mentions live performance applicability via audio-bind-ready controls.

  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 (readOnlyHint=false, openWorldHint=true, destructiveHint=false) align with the description, which details the internal chain created (motion-energy TOP, cropTOP, analyzeTOP, etc.), output as a CHOP, and warns of no preview image. The description adds significant behavioral context 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 detailed but each sentence contributes useful information. It could be slightly more concise, but it is well-structured with a logical flow from purpose to output.

  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 (creates a chain of operators), the description covers all essential aspects: output format, channel names, bind point, zone definitions, threshold, and limitations. No output schema exists, so the description adequately describes return values.

  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 descriptions cover 100% of parameters, but the description adds valuable context such as the normalization convention (top-left to bottom-left uv mapping) and the behavior of source_path when omitted. This augments the schema 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: 'Define N rectangular zones over a camera / motion input; each zone fires when motion in that region crosses a threshold.' It does not merely restate the name and distinguishes it from siblings by describing a specific functional 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 explains when to use (motion detection zones) and provides context: 'Camera-only (no depth cam)', source can be a TOP or synthetic for offline use. It does not explicitly list alternatives, but the context is clear enough for selection among many 'create_*' siblings.

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

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

  Annotations are basic (readOnlyHint=false, openWorldHint=true, destructiveHint=false). Description adds extensive behavioral details: how each mode works (square wave for flash, sine for pulse, translate-X for slide), compositing over input_path, free-running rate, creates nodes, returns summary and JSON. 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 well-structured: purpose first, then behavior, usage guidelines, output. Every sentence adds value, though it is lengthy. Could be slightly more concise but excellent in depth and organization.

  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, 3 modes, node creation) and no output schema, the description is remarkably complete: explains what it does, how it works, when to use, when not, parameter implications, output format (JSON with paths, errors, preview). No 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 description coverage is 100% with detailed param descriptions. The tool description adds structural context (e.g., mode details) but does not significantly enhance per-parameter 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 clearly states it builds a self-contained animated/kinetic typography layer, with specific modes (flash, pulse, slide). It explicitly differentiates from sibling tools create_text_overlay and create_text_crawl, stating when each should be used.

  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: 'single animated word/line', and when-not-to: 'static caption or title use create_text_overlay' and 'multi-line scrolling... use create_text_crawl'. Also gives guidance on binding rate to beat CHOP for tempo sync.

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

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

  Annotations are consistent (readOnlyHint=false, destructiveHint=false, openWorldHint=true). Description adds behavioral details: creates new nodes, uses Select TOPs for input flexibility, outputs a Null, returns container paths and preview image. 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?

  One paragraph of 5-6 sentences, front-loaded with core purpose, then explains modes, source behavior, output, and return. No redundant sentences, every sentence 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?

  Covers inputs, blend modes, demo sources, output node, and return details (summary, JSON block with paths, errors, preview). Lacks explicit error handling or limitations, but sufficient for a create tool with 4 optional params.

  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 4 parameters with descriptions. Description adds value by explaining demo source creation for inputs and the effect of blend modes, and the expose_controls behavior. Adds contextual meaning 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?

  Clearly states the tool builds a VJ-style layer mixer combining source TOPs, with specific verb 'build' and resource 'layer mixer'. Differentiates by describing two modes (crossfade vs other blend modes) and mentions creating a baseCOMP under parent_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?

  Describes when to use: for VJ-style mixing, with crossfade for classic two-deck and other modes for compositing. Explains demo source creation with fewer than two inputs. Lacks explicit exclusions or alternative sibling tools, but provides sufficient context.

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

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

  Discloses important behavioral traits beyond annotations: camera can hang on macOS permission modal, NDI requires runtime, Syphon/Spout are platform-specific. Also mentions defensive probing of parameter names. No contradiction with annotations (readOnlyHint=false, destructiveHint=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.

  Conciseness4/5

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

  Single dense paragraph front-loaded with purpose. Every sentence adds value (warnings, platform details). Could benefit from slight restructuring for clarity, but remains efficiently informative.

  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 enum, no output schema, the description covers all necessary context: warnings, platform limitations, safe defaults, and parameter behaviors. No gaps for agent execution.

  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 description adds context: explains default safety for 'kind', platform/license gating, and that 'source_name' probing is defensive. Provides richer meaning 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?

  Description clearly states it builds a self-contained source COMP that ingests various external feeds, normalizes to target resolution, and exposes a Null TOP output. Distinguishes from siblings like create_video_player or create_data_source by specifying feed types and integration details.

  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 guidance on when to use each kind: default screen_grab is safe, camera is opt-in with macOS permission modal, NDI/Syphon/Spout are platform/license-gated. Does not explicitly name alternative sibling tools but offers sufficient context for decision-making.

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

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

  The description fully discloses behavioral traits: creates new nodes (mutates, consistent with readOnlyHint=false), may prompt for macOS camera permission, optical flow unavailable on macOS, output is CHOP not TOP, and returns a summary with JSON. This adds significant context beyond the annotations (destructiveHint=false, openWorldHint=true) 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 detailed but well-structured: it starts with the main purpose, then explains usage, caveats, and return value. It is not overly long given the complexity, and every sentence adds value. Could be slightly more concise, but overall 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?

  Given no output schema, the description thoroughly explains the return value (summary plus JSON with paths, channel names, etc.). It covers all source options, permissions, macOS limitation, and output type. The tool has moderate complexity with 6 parameters, and the description provides sufficient context 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.

  Parameters4/5

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

  With 100% schema coverage, the schema already describes each parameter. The description adds value by explaining practical details: source='camera' may prompt permission, source='synthetic' for testing, analysis_resolution rationale, and default parent path. This 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 clearly states the tool builds a video-analysis chain exposing reactive channels (brightness and motion energy) on a Null CHOP. It uses specific verbs ('Build') and resource description ('video-analysis chain'), and distinguishes from siblings by mentioning it is the camera counterpart to extract_audio_features and listing alternative 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 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: for motion and brightness reactivity from camera or video. It mentions alternatives (extract_audio_features for audio) and caveats (macOS optical flow unavailable). However, it does not explicitly state when NOT to use it, such as if audio reactivity is needed instead.

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

• create_panicA
  4.6/5.0
  Behavior5/5

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

  The description provides extensive detail beyond annotations: explains the internal mechanism (Level TOP, Cache TOP, Select TOP), output as Null TOP, and return values. It confirms destructive behavior and clarifies what happens under the hood.

  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, but slightly verbose. Every sentence adds value, though some technical details could be streamlined.

  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 covers return values and provides a comprehensive overview of tool behavior, parameter interactions, and 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?

  With 100% schema coverage, the description adds context like why input_path uses Select TOP and how blackout/freeze technically work, enhancing understanding without being 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 clearly states the tool's purpose as building a live-performance safety control with instant kill switches. It uses specific verbs like 'build' and 'wraps', and distinguishes itself from siblings like 'create_safety_blackout_chain' by focusing on dual kill switches and the 'oh no button' metaphor.

  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 live performance scenarios needing instant output freeze or blackout. It explains standalone vs. integrated usage with input_path, but does not explicitly mention when not to use or compare to specific alternatives.

  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.6/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 discloses approximations (attract/repel/vortex via turbulence, fallback render styles) and that warnings are returned. It details exposed knobs and return information, but omits exact node creation paths or error handling 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 moderately long but well-organized: purpose first, then details, sibling guidance, return info. Each sentence adds value; no fluff. Could be slightly more concise but 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?

  For a complex 7-parameter tool with no output schema, the description thoroughly explains the creation process, param effects, return format (summary + JSON with paths, errors, warnings, preview). Covers key behavioral aspects for agent decision-making.

  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, but description adds value: explains force mappings (gravity→Y, noise→turbulence), birth rate formula (count/lifetime), and emitter shape behavior (sphere normals vs point). This enhances agent understanding 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 the tool creates a CPU particle system with specific components (emitter SOP, Particle SOP, Geometry COMP, camera, light). It lists sibling tools for alternative use cases, distinguishing them effectively.

  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 advises when to use siblings: higher counts (create_gpu_particle_field), flocking (create_particle_flock), image reconstruction (image_to_particles), native POP (create_pop_particle_system). This guides the agent on alternatives.

  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
  Behavior4/5

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

  The description details what nodes are created, controls exposed, and return value (summary with JSON block). Annotations (readOnlyHint=false, destructiveHint=false) are consistent. No contradictions. Could mention if cleanup on failure, but overall 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 long but well-structured: purpose, components, alternatives, controls. Every sentence adds value, though could be slightly trimmed. It front-loads the key action and lists 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 no output schema, the description explains the return value (summary + JSON block with paths, errors, preview). It covers all created components, controls, and alternatives among siblings. Complete for a tool with 8 parameters and 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 coverage is 100%, but the description adds meaning beyond schema: explains env_color drives the Constant TOP, rotate shows off reflections, expose_controls allows live tweaking. The description adds context not in 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 it builds a physically-based 3D scene, specifying the components (Geometry COMP, PBR MAT, Environment Light, etc.) and distinguishes from the sibling tool create_3d_scene which is for non-PBR or GPU instancing.

  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_3d_scene instead for basic (non-PBR) shading or GPU instancing' providing clear when-not and alternative. The description also implies usage for PBR scenes.

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

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

  The description thoroughly explains the tool's behavior beyond annotations: it describes the node construction process, experimental status, best-effort approach, and that the output Null is always created. It also details return values including a probe record and preview image, adding significant value.

  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 it is somewhat lengthy. Every sentence serves a purpose, adding details on process, experimental note, and return values. It is not overly verbose given 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?

  The description covers the necessary context: no output schema exists, so the description fully documents return values (summary, JSON block with paths, controls, errors, warnings, probe record, preview image). It also addresses the experimental nature and fail-forward approach, making it 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 description coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: it explains pattern behavior ('noise' vs 'grid' vs 'sphere'), notes that count is approximate for grid/sphere, and clarifies how point_size and spin are exposed as knobs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 GPU point field using TouchDesigner's POP family, specifying patterns ('noise', 'grid', 'sphere') and including a note on experimental status. It distinguishes from siblings like create_pop_geometry and create_gpu_particle_field by detailing the node chain and rendering 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?

  The description provides context for use, such as the experimental nature and fail-forward design, but does not explicitly direct the agent when to choose this tool over alternatives like create_pop_geometry or create_gpu_particle_field. It implies usage for generating point fields but lacks comparative guidance.

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

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

  Annotations already indicate non-readOnly, openWorld, non-destructive. Description adds context: creates new baseCOMP, wires render rig, exposes live controls, and auto-creates noiseTOP if force_texture_path omitted. Experimental note adds 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?

  Description is long but well-structured with clear sentences, each adding value. Front-loaded with main purpose. Slightly verbose due to comprehensive coverage, but 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?

  No output schema, but description fully explains three output modes and what each produces. Mentions delegation to Layer 2 tool. Covers all behavioral aspects needed for an AI agent to use 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?

  100% schema description coverage sets baseline at 3. Description adds that EmissionRate, Lifetime, FeedbackGain, ForceTexture are exposed as live control knobs, providing extra context 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?

  Description clearly states it builds a complete POP particle simulation with specific operator chain and render rig. It explicitly distinguishes from four sibling tools by naming alternatives and specifying non-POP paths.

  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 tells when to use (POP particle simulation) and when not to use (non-POP paths) with four named sibling alternatives. Also notes experimental status and delegation to build_pop_chain for the POP chain.

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

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

  The description discloses deterministic behavior, cook-time Python absence, and the nature of returning multiple node paths, which goes beyond the annotations ('readOnlyHint: false', 'destructiveHint: true', 'openWorldHint: true'). It adds valuable context about safety and reactivity 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, well-structured paragraph that front-loads the main purpose and key features. It is concise without omitting critical information, though it could benefit from slightly more structured formatting for readability.

  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 parameters, no output schema), the description is remarkably complete. It explains the return value (list of node paths), safety features, and relationship to sibling tools. It covers all essential aspects for an AI agent to understand its purpose and 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% with descriptions for all 11 parameters. The description adds context for key parameters like 'hotkey' (opt-in safe, requires modifier) and 'recovery_mode' (manual vs auto), enhancing understanding beyond schema alone. However, many parameters are already well-described 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 it builds a live-show safety primitive at the master output chain, detailing specific features like deterministic fade-to-black, emergency snap, hotkey, watchdog, and recovery. It distinguishes from the sibling tool 'create_panic' by specifying it is the master-output dimmer with grace and recovery.

  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 this tool vs. alternatives by explicitly stating it 'complements create_panic' and positioning it as the master-output safety chain. It also highlights that it is parameter-driven and Python-free, guiding appropriate usage. Lacks explicit when-not-to-use statements.

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

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

  Discloses time-dependent behavior (pauses with timeline), component creation, pipeline details (Script CHOP, SOP, Tube SOP), and return format. 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?

  Description is detailed but efficient relative to complexity; front-loaded with main action and well-structured, though slightly long.

  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, usage, behavioral details, parameters, and return value (summary + JSON) adequately given 13 parameters and 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 coverage is 100%, and description adds context for seed (avoids fixed-point stall) and params (lists ODE constants per system), 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?

  Clearly states it builds a strange-attractor generator, specifies ODE systems (Lorenz/Aizawa/Halvorsen), and distinguishes from sibling tools by naming create_growth_system and create_particle_flock.

  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 for when to use (deterministic CPU-geometry idiom) and a behavioral note about timeline pausing, but lacks explicit exclusions or detailed alternatives beyond the two mentioned siblings.

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

• create_strobeA
  4.6/5.0
  Behavior5/5

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

  The description details how the strobe works internally: using a square-wave LFO CHOP, Level TOP, Constant TOP, Select TOP, and Null TOP. It explains the relationship between duty and the LFO's bias. Annotations already indicate non-destructive and open-world behavior, and the description adds significant context 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, and every sentence adds essential information without waste. It efficiently covers mechanism, parameters, and output.

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

  Completeness4/5

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

  Given the complexity (7 parameters, no output schema), the description covers the core functionality, internal components, and outputs (Null TOP). It lacks some fine-grained wiring details but is sufficient for an AI agent to understand 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?

  All 7 parameters have schema descriptions (100% coverage), and the description adds extra technical context (e.g., 'Bias, which rectangularises the square wave' for duty). 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 tool builds a beat-syncable strobe/flash layer, a full-frame colour flash that pulses on/off. It uses specific verbs and resources ('Build a beat-syncable strobe / flash layer'), and differentiates it from sibling tools like create_glitch or create_kaleidoscope by specifying the signature VJ strobe effect.

  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 basic usage: it outputs a flash that can be composited over an input source if provided, or bare flash otherwise. It also mentions a limitation for v1 (free-running rate) and hints at future beat-lock capability. However, it does not explicitly compare with alternatives 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_terrainA
  4.6/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 explains that the terrain is animated, drift scrolls noise, returns a summary with JSON block, and includes optional water and fog. Annotations only state readonly/world/destructive hints, so the description 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.

  Conciseness4/5

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

  The description is well-structured, front-loading the core purpose, then detailing components, optional features, differentiation, and summary. It is informative but slightly verbose; could be trimmed without losing key 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 13 parameters with full schema coverage and no output schema, the description provides a complete picture: pipeline overview, parameter effects, return format (summary + JSON block), and inline preview. It covers all essential aspects 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?

  All 13 parameters have schema descriptions (100% coverage), but the tool description adds meaning by contextualizing parameters like drift ('so the landscape slowly evolves') and listing exposed controls. This goes beyond the schema, though some parameters (e.g., noise_period) are not elaborated 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 it builds a procedural heightmap landscape with specific components (Noise TOP, Grid SOP, GLSL vertex displacement MAT, etc.). It distinguishes from create_visual_system's terrain keyword, making the purpose explicit and differentiating from a sibling 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 mentions it is distinct from create_visual_system's 'terrain' keyword, providing some differentiation. However, it lacks explicit guidance on when to use this tool versus other sibling tools or when not to use it, which is expected given the large sibling list.

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

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds context: internal node creation, exposed knobs (Spin, Depth), and return format (summary + JSON with paths, errors, warnings, preview). This expands on 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.

  Conciseness5/5

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

  The description is efficient and well-structured. Each sentence contributes essential information, from node pipeline to return format. No redundancy or filler. The distinction from create_kinetic_text is a valuable, concise addition.

  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 thoroughly covers what nodes are created, which parameters are exposed as knobs, and the exact return structure (summary + JSON with preview). It leaves no significant gaps for an agent to understand 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% with descriptions. The description enhances parameter understanding: depth controls 'Extrude SOP's depthscale' with typical values, spin is 'driven by expression on Geometry COMP's ry', and color is explained as setting 'Constant MAT's colorr/g/b'. This adds 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 precisely states the tool's action: 'Build a self-contained 3D text scene' with specific details on the node pipeline. It explicitly differentiates from the sibling tool create_kinetic_text for flat 2D animated text.

  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 use cases: 'title cards, lyric reveals, and 3D text drops' and directs to an alternative tool (create_kinetic_text) for flat 2D animated text. However, it does not explicitly state when not to use this tool, so it misses the full 'when-not' guideline.

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

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

  Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds that it creates a container, exposes live controls, and returns paths. It does not mention potential overwrite behavior, but given openWorldHint, this is acceptable. Adds value 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 paragraph of ~120 words, packing essential information. It front-loads the purpose and uses concise language. Slightly verbose in listing specific operators (Switch TOP, Clip selector), but still efficient.

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

  Completeness4/5

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

  Given no output schema, the description adequately explains return values (clip paths, output Null path, playlist flag). It covers constraints (file paths) and suggests integrations. For a tool with 3 parameters and moderate complexity, this is sufficient 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.

  Parameters5/5

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

  Schema coverage is 100% with good parameter descriptions. The description adds significant meaning: explains behavior based on the number of files (0 = empty player, 1 = single clip, 2+ = playlist with Switch and Clip selector). Also clarifies the effect of expose_controls. Greatly aids 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 tool builds a movie/clip player in a 'video_player' container. It specifies input types (file paths) and output (returned paths, Null TOP). It distinguishes from sibling create_video_synth by contrasting video file playback vs procedural generation.

  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 (play video files) and when not (procedural generation, use create_video_synth instead). Also suggests integration with create_layer_mixer or bind_to_channel for VJ clip playback, providing clear context and alternatives.

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

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

  The description discloses important behavioral traits: default source uses a test pattern (no permissions), device source may hang on macOS due to permission modal, and the histogram panel is silently skipped. These details go beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) and warn the agent about potential issues.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 main purpose, efficiently lists panels and key technical details, and provides necessary context about siblings and source behaviors. 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?

  The tool has 14 parameters and no output schema, but the description together with the schema covers the essential context: what the tool does, how it renders, source options, and the histogram limitation. It could mention the container creation path (though that's in the schema) for completeness, but overall it is sufficiently informative for an agent to use 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 14 parameters, so the baseline is 3. The description adds value by explaining the purpose of the panels (waveform, parade, vectorscope), the histogram caveat, and the source behavior, which enriches 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 builds a broadcast-style video engineering monitor with specific scope panels (waveform, RGB parade, vectorscope). It distinguishes itself from sibling tools like create_waveform (audio) and create_histogram_scope by explicitly mentioning they are companions or alternatives.

  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 this tool: for video scopes, contrasted with audio scopes. It also warns that histogram is unsupported and recommends create_histogram_scope instead. However, it could be more explicit about when not to use this tool or prerequisites beyond the source types.

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

• detect_onsetsA
  4.6/5.0
  Behavior5/5

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

  Annotations show readOnlyHint=false and destructiveHint=false. The description adds valuable context: it creates a self-contained 'onsets' container, may prompt macOS microphone permission, and can emit WebSocket events. This goes beyond annotations to inform the agent of side effects and prerequisites.

  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 well-structured. It is dense with information but not overly verbose, though some sentences could be tightened slightly.

  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 10 parameters, no output schema, the description covers inputs comprehensively and explains what the tool produces (pulse channels, event emissions). It also describes the internal processing chain, making the tool's behavior fully understandable.

  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%, baseline 3. The description adds meaning beyond the schema by explaining the rationale behind the threshold default change (old 0.15 unreachable) and the internal band chain. This enriches the agent's understanding beyond raw 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 it builds a transient/onset detector for kick/snare/hi-hat hits from live audio, exposing per-band pulse channels. It distinguishes itself from create_tempo_sync (fixed clock vs actual audio), so the purpose is specific and well-differentiated.

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

  Usage Guidelines4/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 and explains when to use this tool (for actual audio-following). Source options are detailed with use-case guidance (e.g., oscillator for testing). However, it does not include explicit 'when not to use' scenarios beyond the alternative.

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

• drive_streamdiffusionA
  4.6/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 details the setup process (candidate-path discovery, fresh baseCOMP, wiring, parameter setting), error behavior ('returns a friendly error when .tox not installed'), and output structure (validated_pars). No contradiction with annotations (readOnlyHint=false, destructiveHint=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.

  Conciseness4/5

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

  The description is a single paragraph that efficiently covers the main action, error handling, and result. It front-loads the purpose but could benefit from minor structural improvements like bullet points for different stages.

  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), the description adequately covers workflow, error handling, and result envelope. It lacks detail on return format but mentions validated_pars. Edge cases like invalid tox_path are implied error handling.

  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 meaning beyond schema: explains candidate-path discovery for tox_path, synthetic noise TOP for source_top_path, purpose of validated_pars for downstream tools, and the reserved nature 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 explicitly states the tool wraps a specific community .tox into a one-shot Layer 1 setup, with clear verbs like 'locate', 'drop', 'wire', 'set', and 're-broadcast'. It distinguishes from siblings by specifying the source .tox and mentioning downstream tools like create_ai_mirror.

  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 (one-shot setup, error handling, validated_pars for downstream tools) but does not explicitly state when to avoid this tool or offer alternatives. However, the narrow scope implies clear usage boundaries.

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

• get_previewA
  4.6/5.0
  Behavior5/5

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

  Beyond annotations, it discloses dimension mismatch behavior ('bridge may return the TOP's native output dimensions... caption shows both') and describes the sample_grid return mode in detail. It also notes the TOP-only restriction—meaningful context not captured in the schema or 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 focused sentences: purpose, an edge case, and a cheaper alternative. 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.

  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 capture behavior, dimension mismatch, TOP-only limitation, and the sample_grid alternative. With 100% schema coverage and annotations, it needn't explain every parameter; deferred capture and pre_pulses are adequately documented in 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%, but the description adds value by explaining the width/height dimension caveat and the cost/use case for sample_grid. It doesn't discuss pre_pulses or delay_frames, but those are well-described 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+resource+scope: 'Capture a TOP node's current output as an inline PNG image.' It further clarifies TOP-only support and an alternative sample_grid mode, setting it apart from generic preview or render 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: read-only, TOP-only, and recommends sample_grid for cheap checks. It doesn't explicitly name sibling tools like get_inline_preview or render_output as alternatives, but it provides a strong sense of 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.

• import_isf_shaderA
  4.6/5.0
  Behavior4/5

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

  With annotations already indicating non-read-only and non-destructive, the description adds valuable behavioral context: URL fetches are bounded by fetch_timeout_ms, the tool returns specific artifacts (container/GLSL/output paths, controls, provenance, warnings, preview), and it requires raw Python execution. No contradiction with annotations; it does not explicitly state side effects beyond creation, but the added detail justifies a score 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?

  Four sentences, each earning its place: purpose, source handling, return details, and alternative tools/prerequisites. Front-loaded with the primary action and no redundant fluff. Ideal length 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?

  For an 11-parameter tool with nested objects and no output schema, the description covers the core workflow, source types, return payload, and environment prerequisites. It lacks explicit error scenarios or side-effect disclaimers, but the schema covers parameter details and the description supplies sufficient operational context 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%, baseline is 3. The description enriches parameter meaning by explaining how source types map to the 'source' parameter, how fetch_timeout_ms bounds URLs, how capture_preview enables inline previews, and how warnings relate to manual wiring (channel_overrides). This goes beyond the schema by linking parameters to return behavior and prerequisites.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 new TouchDesigner system container containing an ISF (.fs) shader as a GLSL TOP, companion DATs, and optional live controls.' It clearly distinguishes from siblings by explicitly naming create_glsl_shader and import_shadertoy as alternatives for other 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?

  Provides clear when-to-use guidance: 'Use create_glsl_shader for hand-written GLSL or import_shadertoy for Shadertoy sources.' It also states required environment variables (TDMCP_RAW_PYTHON=on, TDMCP_BRIDGE_ALLOW_EXEC=1) and describes source types (raw, file, URL) with timeout behavior, giving the agent sufficient context to choose correctly.

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

• import_modelA
  4.6/5.0
  Behavior5/5

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

  Annotations indicate mutation and non-destructive behavior; the description elaborates on the exact network built (File In SOP, Geometry COMP, Camera, Light, Render TOP), fallback logic, and exposed controls. No contradiction between description and 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 convey file types, network structure, fallback, controls, and sibling relationship. Every part is essential; 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 inputs, fallback, controls, and network components. Lacks mention of error handling or file accessibility, but for a 6-param tool with no required parameters and no output schema, it is adequately 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?

  With 100% schema coverage, the description adds value by linking parameters (RotateY, Zoom, Scale) to user-facing knobs, clarifying their role in the control interface beyond the schema's literal definition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Import a 3D model file (.obj/.fbx/.usd) and render it to a TOP' with detailed network components, and explicitly distinguishes from sibling 'create_3d_scene' by calling itself 'the imported-model sibling'.

  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 when to omit model_path (fallback to default) and hints at usage via sibling reference. However, it lacks explicit when-not-to-use or alternative selection criteria beyond the sibling mention.

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

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

  Annotations provide only readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description adds substantial behavioral detail: 'copy RayTK masters live', 'wire typed connectors', 'apply simple parameter values', 'lay out copied nodes deterministically'. It also discloses the limitation that 'offline tests validate payload/registration only' versus live render/cook proof, which is valuable context 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, each earning its place: core purpose and capabilities, sibling differentiation, and prerequisites/limitations. It is front-loaded with the main action and contains no filler or redundant repetition of schema fields.

  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, usage context, sibling relationships, prerequisites, and limitations, which is quite complete for a 12-parameter tool. The only slight gap is that it does not describe the return value or result format, but since no output schema exists and the actions are clear, this is a minor omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 12 parameters are already described in detail. The description mentions high-level concepts like 'preset or explicit nodes/edges' and 'deterministically' auto-layout, but does not add any parameter-specific meaning beyond what the input schema already provides, 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 opens with a specific verb+resource: 'Build an editable RayTK ROP expression graph', clearly stating what the tool does. It further distinguishes from siblings by naming 'create_raytk_scene (minimal scene)' and 'create_raytk_op (single ROP)' and describing this tool's broader scope (preset or explicit nodes/edges).

  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 explicit through sibling differentiation: 'Complements create_raytk_scene (minimal scene) and create_raytk_op (single ROP)' indicates when this graph-builder is the right choice over those alternatives. It also states a prerequisite ('Requires RayTK staged and loaded') and a limitation ('live render/cook proof remains explicit'), guiding when not to rely on it for full proof.

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

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

  Beyond annotations (readOnlyHint, destructiveHint), the description specifies read-only behavior, validation against RecipeSchema, the dual output mode (write_path vs structuredContent), and the overwrite flag behavior. This adds 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?

  Three sentences: first states purpose and inverse relation, second details steps and output options, third emphasizes read-only. No redundant 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 10 parameters and no output schema, the description covers the key behavioral aspects (inversion, serialization steps, validation, write mode, read-only). It references RecipeSchema but does not detail its structure; edge cases are not covered. Still, it provides sufficient context for an agent to use 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?

  With 100% schema coverage, baseline is 3. The global description enriches understanding by explaining the overall workflow (inverse of apply_recipe, serialization of nodes/parameters/connections/cross-refs) and the purpose of include_defaults and detect_cross_refs beyond their individual 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 is the inverse of apply_recipe, walks a COMP's child network, and serializes it to a draft RecipeSchema JSON. This distinguishes it from siblings like apply_recipe and serialize_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 positions it as the inverse of apply_recipe, indicating when to use it (to serialize a network to a recipe). It implies context but does not explicitly list when not to use or alternatives, though the inversion is clear.

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

• style_memoryA
  4.6/5.0
  Behavior5/5

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

  The description discloses that updates are field-wise merges with union+dedup for lists and overwrite for scalars, and bumps the updated date. It also states no TouchDesigner side effects. This adds significant behavioral 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?

  The description is concise yet comprehensive, front-loaded with the core purpose, then elaborating on modes, behavior, and requirements. 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?

  The description covers purpose, modes, update behavior, side effects, and prerequisites. The output structure for 'read' is implied by the patch schema but not explicitly stated. Given no output schema, a bit more detail would be ideal, but overall it's fairly 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 value by explaining the purpose of each mode (e.g., 'compact one-line context string' for show) and the merge behavior for update. This helps the agent understand parameter implications better than 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 clearly states the tool reads or updates the artist's style memory note in Obsidian vault. It specifies the resource (Memory/style.md) and actions (READ or UPDATE), distinguishing it from sibling tools by emphasizing it only touches the vault and has no TouchDesigner side 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 explains each mode (show, read, update) and their use cases, such as 'show' being suitable for feeding an LLM. It also mentions the prerequisite TDMCP_VAULT_PATH. While it doesn't explicitly exclude alternatives, the unique domain makes it distinguishable.

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

• swap_operatorA
  4.6/5.0
  Behavior5/5

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

  The description provides extensive behavioral details beyond annotations: snapshots wires and parameters, deletes old node, creates new, re-applies matching parameters, and fail-forward error reporting with specific return fields. This fully informs the agent of the tool's 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 detailed but efficient, listing steps and return fields without extraneous text. It could be slightly more concise, but each sentence contributes useful 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 having no output schema, the description thoroughly explains all return fields and the fail-forward approach. It covers mutation and destructive behavior comprehensively, making the tool's behavior 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?

  The input schema already describes parameters with full coverage. The description adds valuable context about how parameters are re-applied (matching by name) and that others go into dropped_parameters, enhancing 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 that the tool changes an operator's type while preserving name, position, wires, and matching parameters. It distinguishes itself from related operations like deleting and recreating 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 implicitly indicates when to use this tool (to change type without losing connectivity) but does not explicitly mention when not to use it or provide alternative tools like delete_td_node or create_td_node.

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

• variant_packA
  4.6/5.0
  Behavior5/5

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

  The description explains the perturbation process, clamping, and vault writing. Annotations already indicate non-destructive and mutating behavior, which aligns with the description. 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 concise (3 sentences) and front-loaded with the main action. Every sentence adds meaningful information without verbosity.

  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 13 parameters and no output schema, the description covers the essential behavior (probing, clamping, vault writing) and prerequisites. It does not detail return values, but that is acceptable without 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 value by explaining the overall process (clamping, uniform perturbation) and linkage to morph_pack, enhancing understanding 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 the tool generates perturbed variants and writes them to the vault as a JSON file. It distinguishes from sibling tools like morph_pack, which consumes the 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 references prerequisites (TDMCP_VAULT_PATH) and mentions morph_pack as the consumer, providing context on when to use this tool. However, it does not explicitly 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.

• vault_repo_syncA
  4.6/5.0
  Behavior5/5

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

  Description adds significant behavioral context beyond annotations. It states 'read-mostly' but clarifies push is a write operation, and explicitly lists behaviors: never auto-resolves conflicts, never uses --force, never invokes a shell, conflicts returned as structured data. Annotations (readOnlyHint=false, destructiveHint=false) do not contradict and the description enhances 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 four sentences, front-loaded with the core purpose 'Read-mostly git wrapper'. Each sentence adds essential information: available actions, forbidden operations, conflict handling, and prerequisites. 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 the tool's complexity (git operations) and lack of output schema, the description covers key aspects: actions, safety constraints, conflict handling, timeout, and vault path requirement. It could mention that a git repo must be initialized, but overall it provides sufficient context for an agent to use 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 parameter descriptions, but the description adds value by explaining the action enum in detail (e.g., 'pull: fetch + ff-only merge; reports conflicts but never auto-resolves') and default behaviors (branch defaults to currently checked-out). This goes 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 it is a 'read-mostly git wrapper' for the Obsidian vault and lists specific actions (status, pull, push, log) with their effects. It distinguishes itself from sibling tools, which are mostly about creating TouchDesigner nodes and effects, by being the only git-related 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?

  Description explains when to use each action ('see what's changed', 'fetch/fast-forward-only pull', etc.) and explicitly states what it never does (auto-resolve conflicts, use --force, invoke a shell). It lacks explicit advice on when not to use it or mention of alternatives, but given the sibling tools, it is the only option for git operations.

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

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

  Discloses conditional disk write via output_dir, and that guide is always returned. Annotations indicate non-readonly and non-destructive, consistent. 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 sentences, front-loaded with purpose, no extraneous words. Efficient and 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 output schema exists, description covers key behaviors: writing to disk, returning result, dynamic header. 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.

  Parameters5/5

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

  Adds meaning beyond schema by explaining filename defaults, output_dir optionality, and path's role in dynamic header. Schema coverage is 100% but description enriches.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 emits a project-local CLAUDE.md/AGENTS.md with conventions and rules, using specific verbs and resource. It distinguishes from siblings like generate_readme.

  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?

  Describes when to use (for setting up project for future agent), but lacks explicit when-not or alternatives. Still clear contextual guidance.

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

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

  Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds that it is read-only, compares documentation rather than live settings, and pulls from an offline knowledge base. This aligns with annotations and provides 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, efficient sentence. It front-loads 'Read-only' and immediately states the core purpose, 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?

  Given the presence of an output schema, the description does not need to detail return values. It covers the key contextual information: source (offline knowledge base), scope (documentation vs live nodes), and provides an explicit alternative (compare_td_nodes). The sibling list includes that alternative, aiding agent decision-making.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 mentions 'overview metadata plus shared and unique documented parameters' which aligns with the include_parameters parameter, but does not add detailed 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 clearly states the verb 'compare' and the resource 'TouchDesigner operator types' from the embedded offline knowledge base. It distinguishes itself from the sibling tool 'compare_td_nodes' by specifying 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?

  The description explicitly says when to use this tool (compare operator documentation) and when not (for live node parameter diffs, use compare_td_nodes). This provides clear 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.

• connect_nodesA
  4.7/5.0
  Behavior4/5

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

  Description adds behavioral info beyond annotations (e.g., uses batch endpoint when available, falls back to Python). Annotations already indicate non-destructive, open-world. 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?

  Three sentences with no wasted words. First sentence states core purpose; second adds fallback; third differentiates and lists return values.

  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 4 parameters and no output schema, description covers purpose, behavior, return values, and differentiation. Complete for effective use.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. Description adds return value details (paths, indices, method), which enriches understanding of parameter effects.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 it wires one node's output to another's input, creating a single link. It differentiates from the sibling 'create_node_chain' by specifying when to use that 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?

  Explicitly says when to use this tool vs. 'create_node_chain', and mentions fallback behavior. Provides 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_3d_audio_reactiveA
  4.7/5.0
  Behavior4/5

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

  Discloses creation of a new baseCOMP, inclusion of FFT, camera, light, render, and Null TOP output. Mentions potential macOS permission dialog. Annotations indicate non-destructive and non-read-only, which is consistent.

  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?

  Well-structured and informative, but slightly long. Each sentence adds value, but could be tightened. Front-loads purpose and sibling differentiation.

  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 input parameters, behavior, side effects, and return value (summary with JSON block). No output schema, but description compensates by detailing what is returned.

  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?

  Adds meaning beyond schema: explains source options in detail (device permission, oscillator for testing), describes mode visuals, and clarifies parameter effects (spin rotates scene, expose_controls adds knobs). Schema coverage is 100%, but description enriches 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 it builds a 3D scene that reacts to sound, distinguishes from the 2D sibling create_audio_reactive, and specifies the two modes (instanced_bars and bass_pulse) and components (camera, light, render).

  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 tells when to use this tool vs the alternative: 'the 3D counterpart of create_audio_reactive (use that for a 2D spectrum visual instead)'. Also provides guidance on source selection, including permission considerations and testing options.

  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.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 (readOnlyHint, destructiveHint, openWorldHint) by detailing what nodes are created, how instancing works with scale_variation and spin, exposed controls, and the return value 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.

  Conciseness4/5

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

  The description is well-structured: starts with main purpose, then details, then alternatives, then return info. It is slightly verbose with phrases like 'bind RotateY to a tempo ramp' which, while helpful, could be trimmed. Overall efficient 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?

  Given the tool's complexity (6 parameters, no output schema), the description covers purpose, usage, parameters, return value, and alternatives comprehensively. It lacks explicit error handling details but is otherwise very thorough.

  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 input schema already has 100% coverage with descriptions, the tool description adds meaningful context for parameters like 'spin' and 'scale_variation' by explaining their behavior (e.g., 'Each copy rotates in place over time; needs instances > 1'), which adds 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 the tool builds a renderable 3D scene with specific components (Geometry, Camera, Light, Render, Null) and explicitly distinguishes it from siblings create_3d_audio_reactive and create_pbr_scene by naming them and describing their 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 explicit guidance on when to use this tool ('starting point for 3D visuals') and when not to use it (use create_3d_audio_reactive or create_pbr_scene instead for specific needs), making it easy for the agent to select the correct tool.

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

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

  The description discloses critical behavioral details beyond the annotations: macOS permission dialog on first cook, fallback_to_synthetic to keep the rig alive, panel behavior (binding only validated pars, warnings instead of errors). Given openWorldHint=true and no other annotations, the description fully shoulders the transparency 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 a single paragraph of five sentences, each packing essential information. It front-loads the main purpose ('wires the canonical 2026 AI-mirror installation') and efficiently covers platform details, edge cases, and parameter interactions without waste 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 16 parameters, no output schema, and the complexity of the tool (camera, StreamDiffusion, output modes, control panel), the description covers the main pipeline, fallback behavior, parameter binding, and platform-specific notes. It provides enough context for an agent to understand the tool's operation and constraints completely.

  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 (e.g., sliders and textDATs drive SD pars via .expr expressions, panel only binds pars from drive_streamdiffusion's validated_pars). This integration context exceeds mere schema repetition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 wires the 'canonical 2026 AI-mirror installation in one MCP call' and lists the pipeline components (camera → StreamDiffusion → output → control panel). It clearly distinguishes itself by specifying 'Layer 1 COMBO' and detailing specific behaviors, making it unambiguous among 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 context for when to use the tool (e.g., for a Layer 1 COMBO installation, with fallback options) and explains edge cases such as missing parameter warnings and macOS permission dialogs. However, it does not explicitly state when not to use this tool or compare it to alternatives like drive_streamdiffusion alone.

  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?

  Annotations show readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds valuable context beyond annotations: it explains that the tool creates a network of nodes (Displace TOP, Noise TOP, etc.), exposes certain parameters as knobs, and returns a summary with JSON and inline preview. 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 thorough but a bit lengthy. It is well-structured with clear technical details, but a few sentences could be trimmed without losing meaning. However, the front loads the core purpose effectively.

  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 the return value (summary plus JSON with various fields). It also describes the internal chain behavior, preview capabilities, and complementary tools, making the tool's context complete.

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

  Parameters5/5

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

  The schema has 100% coverage with descriptions for all parameters. The description goes further by explaining what underlying parameters each user-facing parameter maps to (e.g., amount maps to displaceweight1, speed drives noise translate) and gives typical value ranges and effects for the modulator enum values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Build a displacement-warp stage over a source' using a specific verb and resource name, and distinguishes the tool by mentioning its pairing with extract_audio_features and apply_post_processing, which are listed as 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 clearly states the tool is for 'VJ sets' and provides example use cases like 'heat-haze, liquid, audio-pushed pixels'. It implies usage context but does not explicitly state when not to use this tool or mention other alternatives.

  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?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses key behaviors: creation of companion DATs, best-effort uniform binding, manual samplers wiring, and known GLSL footguns. This is rich, honest context that helps the agent predict side effects and 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 dense but every sentence is informative: purpose, prerequisites, wiring behavior, return values, and warnings. It is front-loaded with the core action and uses efficient wording without fluff, appropriate for a complex 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 fully covers return values (MAT path, DAT paths, warnings). It also explains the overall pipeline from creation to artist assignment, including known failure modes. Given the 9 parameters and complexity, nothing essential 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?

  The schema already covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds meaningful semantics by explaining how shader sources become companion DATs, how uniforms map to Vectors/Samplers pages, and the 'best-effort' nature of binding—value 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 creates a GLSL MAT under a parent path, with specific details about companion Text DATs and wiring. It distinguishes this from sibling tools like create_glsl_shader by targeting the GLSL MAT resource and its custom-shaded geometry 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 gives explicit prerequisites (TDMCP_RAW_PYTHON=on and TDMCP_BRIDGE_ALLOW_EXEC=1) and a clear use case ('for custom-shaded geometry'). It does not explicitly mention alternatives or 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.

• create_growth_systemA
  4.7/5.0
  Behavior5/5

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

  The description goes beyond annotations to detail key behaviors: generation capped at 7, stochastic rule selection with seed control, the full symbol set, and output format including a JSON block with 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.

  Conciseness4/5

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

  The description is front-loaded with the main purpose and is well-structured, but it is somewhat lengthy. Every sentence is substantive, but could be slightly tightened 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 11 parameters, high complexity, and no output schema, the description comprehensively covers the generative process, symbol set, rule semantics, output format, and behavioral constraints. It provides everything an agent needs 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?

  Despite 100% schema coverage, the description adds significant context beyond the schema: explains the L-system symbols (F, +, -, etc.), the weighted-random stochastic mechanism, the cap on generations, and the purpose of each parameter (e.g., branchAngle used for multiple symbols). This greatly aids agent 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 tool builds an L-system/vine-growth generator using a Script SOP with a rewriting grammar and 3D turtle walk. It distinguishes itself from siblings by calling it the 'deterministic CPU-geometry idiom' versus create_particle_flock and create_gpu_particle_field.

  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 complementary tools and categorizes this as a deterministic CPU-geometry approach, helping the agent choose between alternatives. However, it doesn't provide explicit when-not-to-use guidance, such as cases where GPU-based approaches would be preferable.

  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?

  The description thoroughly details the tool's behavior: it creates a baseCOMP with a full chain (source, key stage, composite, Null TOP), exposes controls, and returns a summary with errors/warnings/preview. No contradiction with annotations (readOnlyHint=false, destructiveHint=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.

  Conciseness4/5

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

  The description is a single paragraph that front-loads the main purpose. It is informative but could be slightly more structured with bullet points or separate sections for clarity, though it remains concise enough.

  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 states what is returned (container path, node paths, exposed controls, errors, warnings, preview image). It covers all key aspects: modes, defaults, chain structure, and fallback behaviors.

  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 100% schema coverage, the description still adds value beyond parameter names and defaults, explaining interactions (e.g., key_color modes, default test cards, tolerance/softness effects, and that controls are exposed on the container).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: compositing a keyed source over a background using chroma-key, luma, or RGB keying. It specifies it's for installations and live camera work, distinguishing it from other 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 explains when to use it (for keying performers/logos/sources) and details behavior when source/background are omitted. It does not explicitly state when not to use it or provide 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.

• create_modulatorsA
  4.7/5.0
  Behavior5/5

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

  The description goes beyond annotations by detailing that modulators are timeline-driven, re-running with same name rebuilds in place (clearing children), and that rates lock to tempo source via expression. 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?

  The description is well-structured, front-loading the main purpose then covering details. Every sentence adds value, with no 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?

  The description covers output format (Null CHOP with named channels), dependencies (tempo source, timeline playing), destructive behavior, and usage notes. For a tool with no output schema, this provides complete context for use.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description adds context beyond the schema, such as output landing on one Null CHOP and the overall workflow. It explains the purpose of phase and shape values like 'random' and 'saw', enhancing understanding without repeating 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 creates a bank of BPM-synced LFOs in a container, specifying verb (build), resource (bank of LFOs), and scope (self-contained, tempo-synced). It distinguishes from siblings like create_tempo_sync by stating its dependency and unique 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 provides context like timeline dependency and destructive behavior, and mentions output is ready for bind_to_channel. However, it does not explicitly state when to use this tool over alternatives, though the purpose is clear enough to imply usage.

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

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

  Annotations provide readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds detailed behavior: output image equation, internal TOP chain, behavior when paused, and default test clip. It also warns about bandwidth sensitivity. This goes 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 comprehensive but somewhat long. It front-loads purpose and then details internals. Each sentence serves a purpose, but it could be slightly more concise 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 complexity (8 parameters, no output schema), the description covers output format, default source, behavior under pause, internal implementation, and performance considerations. It is complete enough 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.

  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 meaning by explaining how parameters map to internal operators (e.g., sensitivity -> mathTOP gain, blur -> blurTOP size) and clarifying the direction_from modes. This adds significant 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 clearly states it builds a CPU motion-energy field and distinguishes from a true dense optical-flow solver. It is specific about the resource (video source) and verb (build), and contrasts with siblings like create_fluid_sim.

  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 notes 'cheap drop-in for displacement / particle chains' and clarifies it is NOT a real optical-flow solver, giving context on when to use it and when not. However, it does not explicitly name alternative tools for dense optical flow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_paletteA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate mutability (readOnlyHint=false) and non-destructiveness. The description adds crucial behavioral context: node creation (Ramp TOP, Constant CHOP, Table DAT), exposure of live controls, fallback to greyscale ramp in from_source mode if source is missing, and count cap due to channel limits. 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, front-loaded with the core purpose, and each sentence adds distinct value (mode explanation, outputs, usage examples, behavioral notes). 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?

  Given no output schema, the description sufficiently explains what is built (Ramp TOP with gradient, Constant CHOP with swatch channels) and how to feed into other tools. It covers both modes, fallback behavior, and control exposure. 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?

  Schema coverage is 100%, but the description adds value by explaining mode-specific parameter relevance, the role of expose_controls, and the meaning of analogous_spread. It avoids redundancy and provides practical 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 creates a reusable colour palette/gradient and distinguishes two modes ('harmony' and 'from_source'). It identifies the resources built (Ramp TOP, Constant CHOP) and how outputs are used with sibling tools (create_color_grade, generate_from_moodboard, bind_to_channel). This differentiates it effectively 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?

  The description provides clear context for each mode: harmony for no source, from_source for sampling from a TOP. It suggests downstream tools but does not explicitly state when not to use this tool or compare with direct alternatives.

  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.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that it listens on all interfaces without authentication, requires trusted networks, and that iOS Safari needs HTTPS for motion permission with fallback to touch-only on HTTP. This adds significant context beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true). 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?

  Three sentences, front-loaded with the main action, then composability, then security notes. No redundant information. 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?

  Despite no output schema, the description describes the output channels (tilt, gyro, shake, touch, clients) and the operators created (Web Server DAT, Null CHOP). It covers all major aspects: functionality, composability, security, and platform-specific behavior.

  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 context like port numbers distinct from 9980/9981, threshold units (m/s^2), and conditions for enableImu (iOS Safari HTTPS). This enriches meaning beyond 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?

  The description explicitly states it streams phone's IMU and multitouch into TouchDesigner as CHOP channels, and distinguishes from sibling create_phone_remote by noting different port and composability. The specific verb 'stream' and resource 'phone gesture' are 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 mentions composability with create_phone_remote on the same COMP, and includes a security note about trusted networks. However, it does not explicitly state when not to use or provide alternatives 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_phone_remoteA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses that it listens on all interfaces and accepts writes without auth, which is critical beyond annotations. Annotations set openWorldHint=true but description adds specific danger.

  Agents need to know what a tool does to the world before 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, how it works, security warning and pairing. No wasted words, 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 no output schema, description still covers usage context, security, and relationships with sibling tools. Complete for 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 covers 100% of parameters with descriptions. Description adds no extra meaning beyond what schema already provides, so 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?

  Clearly states it creates a mobile web panel to control numeric custom parameters from a phone. Distinguishes from siblings by mentioning create_control_panel and manage_cue for 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly pairs with create_control_panel and manage_cue, and warns about security (no auth, trusted network only). Provides when-not-to-use based on network security.

  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.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses key behaviors: Lag CHOP doesn't advance while timeline paused, weight vector is normalized internally, interpolation curves via Lookup CHOP. No annotation contradiction, as readOnlyHint=false and destructiveHint=false align with the description. Minor omission: doesn't specify if the tool overwrites existing containers.

  Agents need to know what a tool does to the world before 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 paragraph, densely packed with essential information. Front-loads the core purpose and comparison. No redundancy; 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 complexity (10 params, nested objects, action enum), the description provides a comprehensive overview of the morph engine's lifecycle (build, store, recall, set_weights, list, delete) and edge cases (Lag CHOP pause). No output schema needed.

  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, baseline is 3. Description adds significant value by explaining how parameters interact (e.g., normalization, Lag CHOP behavior, interpolation curves) and the overall morph engine architecture.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 target-agnostic preset morph engine, snapping any OP's animatable parameters into named slots and blending with weight vectors. It distinguishes itself from create_look_bank by noting it drives any OP and supports >2 weights.

  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 contrasts with create_look_bank, stating when to use this tool (any OP, >2 weights) and when not (limited to control COMP with 2-slot A↔B). Also mentions reuse of manage_cue's MORPH_HOOK for quantized recall.

  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.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description goes beyond these by detailing internal mechanics (TextTOP, TransformTOP, expression parameters, continuous looping), return values (JSON block with detailed fields), and experimental caveats (substring expression unverified). 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, front-loaded with the main function, followed by modes, technical details, and sibling differentiation. Every sentence adds value without redundancy. At approximately 120 words, it is concise yet comprehensive.

  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 complexity of three modes and multiple operators, the description covers all essential aspects: mode operation, underlying TOPs, scroll behavior, return values, and experimental warnings. No output schema exists, but the description explicitly documents the return JSON structure, making it complete for 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 description coverage is 100% with detailed parameter descriptions. The tool description reinforces parameter usage context (e.g., speed fraction, loop wrapping) but does not add significant new semantic meaning beyond what the schema already provides. 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 builds multi-line animated text crawls/tickers/credits rolls/typewriter reveals inside a self-contained baseCOMP. It explicitly distinguishes from siblings create_kinetic_text and create_text_overlay, establishing a specific verb-resource relationship.

  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 (multi-line copy, continuous scrolling, character-reveal) and when not to (use create_kinetic_text for single-string flash/pulse/slide, create_text_overlay for static captions). It also notes the experimental nature of the typewriter mode.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• duplicate_networkA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds valuable context beyond annotations, such as the return values (source path and copy path). It doesn't contradict the annotations. However, it could elaborate on the full scope of what is copied (e.g., all contents, 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?

  Extremely concise: two sentences plus a usage guideline. No redundancy; 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?

  Despite no output schema, the description explains what the tool returns and its core behavior. It also provides context on when to use alternatives, making it 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 parameters are well-documented. The description adds extra context about the default behavior of parent_path (defaults to source's parent), which is helpful 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 copies a node or COMP to a new node, specifying the action (copy) and resource (node/COMP). It also distinguishes from create_container, providing differentiation from a sibling tool.

  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 ('clone a built network') and when to use an alternative ('use create_container instead when you just need a fresh empty COMP'), giving clear guidance.

  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.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Adds rich behavioral context beyond annotations: exact-match error behavior, hidden tool setting when TDMCP_RAW_PYTHON=off, and bridge write requirement. No contradiction with readOnlyHint=false or destructiveHint=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?

  Three dense sentences, front-loaded with the core operation, then behavior, then alternative and safety context. 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?

  Complete for a destructive mutation tool: covers purpose, usage, error conditions, and security gating. Full schema coverage and no output schema mean 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 descriptions cover all parameters (100% coverage). The description restates `replace_all` behavior but does not add new parameter-level meaning beyond what the schema already provides. 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 surgically replaces a substring inside a Text or Table DAT's `.text`, with a specific verb and resource. Distinguishes itself from `set_dat_content` by contrasting targeted edits vs. overwriting entire 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 names `set_dat_content` as the alternative for full overwrites and advises this tool for targeted edits. Also explains the exact-match requirement and when to set `replace_all`, 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.

• generate_from_moodboardA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses side effects (node creation, no file writes), the best-effort nature of color hints, and that it returns the same network as create_generative_art, adding 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences pack all essential information: action, side effects, usage guidance, and prerequisites. 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?

  Covers all aspects: input, behavior, output, prerequisites, and alternatives. No missing information despite lacking 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% with parameter descriptions, and the description does not add significant new semantic detail beyond what is already in the schema (e.g., note resolution, technique override). 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 reads a moodboard note and creates a generative system in TouchDesigner, distinguishing itself from the sibling tool create_generative_art by specifying the use case for moodboard-based seeding.

  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 ('to seed a system from a vault moodboard') and when to use the alternative ('call create_generative_art directly'), plus mentions 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_editor_contextA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint/destructiveHint annotations, the description adds significant behavioral details: unavailable UI fields are omitted with warnings instead of inferred, and the tool returns only available fields. This transparency about inference behavior and scoped output is valuable and 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 concise (three sentences) and front-loaded with the primary purpose. Every sentence adds value: what it does, what it returns/omits, and what it does not do. No redundant 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?

  Even without an output schema, the description enumerates the exact fields returned and explains the warning behavior. It also clarifies exclusions (no topology) and safety (no mutation), making it a complete standalone description for a no-parameter, no-output-schema tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameter semantics, and the schema coverage is trivially 100%. No extra credit 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 ('Read') and resource ('compact project and editor state'), and clearly lists the fields it returns. It also distinguishes itself from siblings by explicitly stating it does not dump project topology, 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?

  It clearly indicates when to use the tool ('for references such as...') and what it will not do ('Does not dump project topology'), but it does not name an alternative tool like get_td_topology. This is a clear contextual guidance, but lacks explicit alternative naming for a 5.

  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.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Description states 'Read-only one-shot inspection', aligns with readOnlyHint annotation. Adds behavioral details like parent error sweep BFS, thumbnail size and lossy nature, and scope of parameters. 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?

  Four sentences, each serving a purpose: first defines the tool's output, second gives use case, third provides alternative, fourth specifies thumbnail quality. Front-loaded and 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?

  Covers all aspects: what the tool does, what it returns (thumbnail, errors, params, stats), when to use, parameter details, and output quality. Output schema exists, but description still sufficiently explains the return payload.

  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, baseline is 3. Description adds meaning by explaining the purpose of each parameter (e.g., format selection impact on payload size, parent_depth for error sweep hops, max_changed_params for top-N defaults). This goes 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 clearly states it performs a read-only inspection of a TOP, returning a thumbnail, error sweep, parameter changes, and cook stats. It distinguishes itself from sibling tools like get_preview and get_td_node_errors by emphasizing it is for quick health checks.

  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 'One call instead of chaining get_preview / get_td_node_errors / get_td_node_parameters' and advises using get_preview/render_output for delivery-grade frames. Provides clear when-to-use and when-not-to.

  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.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds meaningful context beyond annotations: it states the data source is 'embedded knowledge base (offline)', and describes the return behavior for unknown names (suggestions). It does not contradict the readOnlyHint 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: the first covers purpose and output, the second provides usage guidance. It is concise, front-loaded, and 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 simple tool (one parameter, no output schema, clear annotations), the description covers all necessary aspects: what it does, output format, fallback behavior, and when to use alternative. 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?

  The input schema already provides a good description for the single parameter 'name' with examples. The description adds no additional semantic detail beyond what the schema provides, so 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 verb 'get' and resource 'module/class help', specifies the output format (Markdown) and the fallback behavior with suggestions. It also explicitly distinguishes from the sibling tool 'get_td_class_details' by noting the difference in 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 advises when to use the alternative tool 'get_td_class_details' for structured JSON output. It also implies context (read-only, offline knowledge base) and when to use this tool (when human-readable help is desired).

  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.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint and destructiveHint; description adds valuable context: returns 'connected:false' with reason, warns about bridge version mismatch, and changes nothing. 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?

  Front-loaded with core purpose, concise sentences covering key behaviors and edge cases. 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?

  Without an output schema, description fully enumerates return fields and covers offline/stale scenarios. Complete for a zero-param health check tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters (0), so baseline 4 applies. Description adds no parameter info, but none 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?

  Description clearly states it's a read-only health check returning server info and connection status. Distinguishes from sibling tools like 'get_bridge_logs' or 'reload_bridge' by focusing on connectivity and version info.

  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 advises to use this tool first to confirm bridge reachability, explains behavior when TD is offline, and warns about stale bridge, directing to 'reload_bridge' for issues.

  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, destructiveHint=false, openWorldHint=true. The description adds return structure {total, errors[] or by_type} and effects of recursive and summary flags, going beyond 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?

  Three sentences that are front-loaded with the main action, no unnecessary words. Every sentence provides essential 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 3 parameters, annotations, and output schema, the description fully covers usage, return structure, and alternatives. It leaves 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% with good descriptions. The description further clarifies the effect of summary=true and recursive flag, and explains the output format, adding 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 clearly states it checks a node for cook/compile errors and warnings, with scope control via recursive flag. It distinguishes itself from sibling summarize_td_errors by noting when to prefer that 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 mentions using summary=true for grouped counts and advises using summarize_td_errors for large networks, providing clear 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.

• get_td_node_flagsA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and destructiveHint. The description adds context about what is reported (flags, wiring, etc.) and what is hidden (parameter dumps), providing behavioral transparency beyond annotations. 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?

  Single, well-structured paragraph that leads with the main purpose and then clarifies parameters. Every sentence is informative and necessary. 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 tool with 4 params, 100% schema coverage, and an output schema, the description covers the use case completely. It explains the diagnostic role, recursion behavior, and problem-filtering feature without needing to detail return values (handled by 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 meaning beyond schema by explaining the purpose of 'only_problems' in diagnostic context ('conservative — display/render are never used to filter'). Adds value without repeating 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 ('report') and clearly identifies the resource (node's operator flags, input wiring, position, color, comment) and the problem it solves (explaining black/blank output that parameter dumps hide). It distinguishes from siblings like get_td_node_parameters by contrasting what it reveals vs. hides.

  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 recursive ('diagnose its whole network') and only_problems ('surface just the ops whose flags or cook errors would suppress output'). Implies alternative tools when detailed parameter info is needed. No guidance is missing.

  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.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explicitly states 'Read-only' and then discloses behavior that annotations do not capture: default summary mode, how to get the full list, the return shape ({count, by_type/sample or paths/nodes}), and the fact that it only lists direct children. It also adds a token-economy caution, which is a behavioral trade-off not implied 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 a bit longer than two sentences, but every clause is informative: purpose, default behavior, parameter effects, return shape, sibling comparisons, and token advice. It is front-loaded with the key purpose and read-only flag, 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?

  For a tool with 5 parameters and an output schema, the description covers purpose, usage, return shape, alternatives, and even token economy. It anticipates the main concerns a user would have (scope, full vs summary, which sibling to use) and thus feels 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?

  Schema description coverage is 100%, so the baseline is 3. The tool description mentions `detail_level:"full"`, `path_only:true`, and `pattern`, but these are already described in the schema. It does not add new semantic meaning beyond what the schema provides, so no upgrade 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 opens with a specific verb and resource: 'list the DIRECT child nodes of one COMP.' It then explicitly contrasts with sibling tools: 'use find_td_nodes to search recursively and by operator type, or get_td_topology when you also need the connections between nodes.' This makes the tool's niche 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 includes explicit when-to-use guidance: 'Use this to browse one level' and names concrete alternatives with their distinguishing features (recursive search, topology). It also adds practical usage advice about the default compact summary, using `pattern` to scope, and avoiding redundant full listings, which goes beyond generic instructions.

  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?

  Starts with 'Read-only' which aligns with annotations, and adds behavioral details beyond them: flagging structural issues and returning a structured payload with nodeCount, connectionCount, issues, and topology. The recursion advice is also useful. Annotations cover read-only/destructive hints, so this description adds meaningful 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?

  Three sentences, no repetition of schema or annotation. Each sentence earns its place: purpose, alternatives, and practical advice. Front-loaded with 'Read-only' and the core action, making it easy to scan. Highly concise yet complete.

  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 one parameter, a solid output schema, and annotations already present, the description covers all necessary context: what it does, when to use it, what distinguishes it, and practical usage tips. Nothing important is left unaddressed 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.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema covers root_path 100%, and the description enhances it by advising to use a specific network root rather than the project root, plus a note on recursion behavior. This adds practical meaning beyond the default value and basic type, though it does not go into deep 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 states a specific verb and resource ('return the nodes AND the connections under a network root') and clearly distinguishes itself from sibling tools like get_td_nodes and snapshot_td_graph. It also notes a unique function: flagging structural issues. This fully clarifies what the tool does and how it differs.

  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 usage guidance is provided: use when wiring is needed, use get_td_nodes/find_td_nodes for node lists without connections, and snapshot_td_graph when parameters are required for diffing. Even advises token economy by targeting a specific root and leaving recursion off. This is exemplary.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_tutorialA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral details beyond annotations, such as content capping at ~30K chars, the sections_available list, and the drill-down via section. This complements the readOnlyHint annotation well and provides actionable information.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose. Every sentence adds significant 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 the 5 parameters and presence of an output schema, the description covers the main behavioral aspects (list/search/retrieve, content capping, section drilling) comprehensively. It does not leave major gaps for typical 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 baseline is 3. The description adds value by explaining the use of include_content and section together, including the capping and drilling behavior, which is not evident 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?

  The description clearly states the tool's purpose: 'list embedded TouchDesigner tutorials, search tutorial metadata/content, or retrieve one by id/name.' It uses specific verbs and resources, distinguishes from siblings by being a read-only retrieval tool among many creation and editing 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's read-only and offers list, search, and retrieve modes. It does not explicitly state when not to use or compare to specific alternatives, but the context is sufficient for an agent to understand when to invoke this tool.

  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.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint=false, destructiveHint=false) already indicate mutation but non-destructive nature. The description adds significant behavioral context: it builds a new baseCOMP with specific internal nodes (downsampled source, feedback loops, instanced geometry), details audio scattering behavior, and warns about permission dialogs. 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is longer than average but front-loaded with the core idea. It is logically structured: main purpose, network build details, sibling differentiation, defaults, and warnings. All sentences earn their place; minor verbosity could be trimmed but it remains impactful.

  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 high complexity (12 parameters, audio integration, network construction), the description covers all critical aspects: purpose, internal components, alternative tools, defaults, edge cases (mac permission), and return format (summary + JSON with path, count, controls, errors, preview). Without an output schema, it adequately explains what the tool returns.

  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% with detailed descriptions, but the tool description adds substantial meaning beyond the schema: it explains how 'side' maps to particle count and resampling, clarifies source types and their behavior (e.g., video source produces 'video made of points'), and describes the effect of 'audio_source' options. Every parameter's role in the particle system is contextualized.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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') and resource ('image into GPU particle field'), clearly stating the tool's primary function. It distinguishes itself from siblings by explicitly listing alternative tools for non-image-driven particles, 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 provides explicit when-to-use and when-not-to-use guidance, naming four sibling tools (create_gpu_particle_field, create_particle_flock, etc.) and stating conditions for their use. It also covers defaults (Banana.tif, no audio) and potential side effects (macOS mic-permission dialog).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• import_shadertoyA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses significant behavioral traits not captured by annotations: it requires specific TDMCP environment variables, may trigger a macOS network permission prompt, benefits from a Shadertoy API key, and offers an offline mode. It also describes default wiring (iChannels noise) and that it captures a preview.

  Agents need to know what a tool does to the world before 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 adding essential information. The main action is front-loaded, followed by requirements, behavior details, and troubleshooting tips. 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 12-parameter tool with nested objects and no output schema, this description is remarkably complete. It covers network behavior, prerequisites, defaults, platform-specific quirks, and offline workflow. The agent gets enough context to use the tool correctly without needing extra 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 schema description coverage only at 25%, the description compensates by explaining key parameters: 'channels' (iChannels with noise defaults), 'expose_speed_control', 'expose_mouse_control', 'capture_preview', and 'raw_source' (offline safe). It does not cover every parameter, but the most important ones are addressed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Build a GLSL TOP from a Shadertoy URL, ID, or pasted source', which identifies the specific verb (build), the resource (GLSL TOP), and the input source (Shadertoy). This clearly differentiates it from generic shader creation tools like 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: when the user has a Shadertoy URL/ID/source and wants a GLSL TOP. It also includes prerequisites (env vars) and an offline alternative (paste into raw_source). It does not explicitly name alternatives, but the context is unambiguous.

  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.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the annotations (readOnly=false, destructiveHint=true), the description discloses specific behaviors: it copies/extracts files, refuses replacement unless overwrite=true, rejects symlinked directory trees, and returns scope plus resolved paths. These details add significant behavioral context 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?

  The description is compact (two sentences) and front-loaded with the core install action and accepted formats. Every clause adds distinct information—scope options, legacy form, prerequisite, edge-case behaviors, and return 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?

  Given there is no output schema, the description explicitly mentions what the tool returns ('scope plus resolved paths'). It also covers prerequisites, parameter interrelationships, and safety-edge cases (symlinks, overwrite), making it complete for a tool with 6 parameters and a destructive hint.

  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 6 parameters with 100% description coverage, so the baseline is 3. The tool description adds crucial relationships: project scope uses <project_dir>/.tdmcp/packages and requires project_dir, while dest_dir preserves the legacy form. It also implicitly clarifies the role of overwrite by stating refusal 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 ('Install'), names the resource type ('tdmcp component package folder, .zip, .tox, or manifest'), and clearly distinguishes between explicit project/user scope and the legacy dest_dir form. This differentiates it from sibling tools like inspect_component_manifest or make_portable_tox.

  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 prerequisite ('Use inspect_component_manifest first for unknown packages') and explains when project_dir is required for project scope. It does not explicitly name alternative tools to consider instead, but the context is sufficient for an agent to decide 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.

• manage_agent_skillsA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true, but the description goes much further by disclosing safety behaviors: 'Mutations default to dry-run, use exact manifest ownership, reject unowned conflicts and symlinks, and roll back partial filesystem changes.' This is valuable contextual detail 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?

  Three sentences, each earning its place: the first states the core function, the second reveals safety mechanisms, and the third clarifies the scope. Extremely concise with no wasted words, and the most critical information (what the tool does) 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 given the complexity and the existing output schema. It covers purpose, mutation safety, ownership constraints, and exclusions. The schema handles parameter details and return values, so nothing critical 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?

  With 100% schema coverage, the baseline is 3. The description adds beyond the schema by explaining the safety model that ties parameters together: dry-run defaulting, exact manifest ownership (relevant to force_owned_drift), and rollback behavior. This clarifies the intent of the parameters without repeating their syntax.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Safely inspect, install, update, or uninstall the small bundled tdmcp skill catalog for Codex or Claude.' This clearly distinguishes the tool from the many creative/network siblings, and the inclusion of 'bundled' and 'not a remote or arbitrary skill installer' reinforces its 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 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 (managing bundled tdmcp skills) and gives an exclusion: 'Only package-bundled skills are accepted; this is not a remote or arbitrary skill installer.' It lacks named alternatives, but the field is so narrow that the guidance is effectively complete.

  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?

  Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description reveals important behavioral traits: main-thread scheduling, JSON-only job state, compare-and-swap restoration, fail-closed behavior in Perform/headless/conflicted states, and strict no-fallback to raw Python. These give the agent a precise safety and execution model 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?

  Two dense sentences deliver all essential information without redundancy. The first sentence front-loads the action and resource, and the second adds safety and constraint details. 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?

  For a 7-parameter tool with an output schema, the description covers the operational lifecycle, threading model, state handling, and security constraints. It is sufficiently complete to guide correct invocation and understand the tool's boundaries, even without re-explaining return values (covered by 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 covers 71% of parameters. The description enriches parameter understanding by explaining the bridge architecture (bounded workspace, right-hand split, compare-and-swap cleanup) which informs how split_ratio, viewer_mode, network_path, and lease_seconds fit together. It adds context beyond the schema's individual descriptions, though it does not detail 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 states a clear compound verb (open, inspect, restore, or cancel) targeting a specific resource: a bounded TouchDesigner editor workspace built on an existing Network Editor plus a TOP Viewer or Panel split. This distinguishes it from create/delete siblings and specifies exact 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 clear context: this tool is for managing one temporary workspace using an existing Network Editor and a right-hand viewer/panel split. It implies when to use it (when you need a bounded, structured workspace) and describes constraints like ALLOW_EXEC=0, but does not explicitly name 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.

• manage_checkpointA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses destructive behavior (restore prunes/recreates nodes) beyond annotations (destructiveHint=true), adding specific context about what happens during restore. 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?

  Two sentences plus a comparison, no fluff. Front-loaded with purpose and usage context. 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 5 parameters all described in schema, no output schema needed, and annotations providing safety cues, the description completes the picture with behavioral details and 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?

  Schema coverage is 100% with all parameters having descriptions. The description adds minimal extra meaning beyond the schema (e.g., action enum values). Baseline 3 is appropriate since 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's function (store/restore/list/delete checkpoints, an 'undo point' for sub-networks) and distinguishes it from manage_presets by emphasizing the scope difference: full snapshot vs. custom-parameter looks.

  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 recommends using this tool 'before risky live edits' and contrasts it with an alternative (manage_presets), providing clear 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.

• marketplace_index_seedA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The annotations already include destructiveHint=true, so the description's 'guarded' qualifier and 'overwrite=false protects existing index files' adds useful context about when writes are safe and potential destructive behavior. This goes beyond the 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, front-loaded with the core action and followed by practical usage guidance. Every sentence earns its place with no filler or unnecessary repetition of schema/annotation 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?

  For a file-writing tool with an output schema and a related sibling local_marketplace_index, the description covers the workflow position, key parameters, and safety semantics. It leaves out only trivial details that are already handled by the schema and defaults.

  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 description adds semantic meaning by mapping 'built-in seed entries' to include_builtin_starters and 'custom package entries' to entries, which is not fully explicit in the schema. It also explains the overwrite parameter's safety behavior, though out_file and name are not directly described; the schema partially covers these.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Write' and identifies the resource as a 'guarded starter marketplace index JSON'. It clearly differentiates the tool by mentioning 'seed entries' and 'custom package entries', which aligns with its role as a seed generator distinct from the sibling local_marketplace_index.

  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 before local_marketplace_index when planning a local package marketplace', giving a clear workflow position and context. It also notes that 'overwrite=false protects existing index files', providing actionable guidance on the safe default behavior.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• rebuild_networkA
  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=true). It discloses the tool uses /api/exec, explains the fail-forward behavior (unknown operators/missing params/wires become warnings), details the destructive clear_existing option, and states what the return value contains. This is substantial behavioral context not encoded in 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 longer than typical but every sentence is information-dense. It front-loads the core purpose, then covers prerequisites, behavior, options, and return values in a logical order. A few phrases could be tightened (e.g., 'the REBUILD half of a git-diffable round-trip' is repeated implicitly), but overall it is well-structured and earns 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?

  For a complex tool with no output schema, the description is exceptionally complete. It covers the input spec structure, environmental requirements, fail-forward behavior, flag semantics, and the return value format. It also aligns with the destructiveHint annotation by explaining the destructive clear_existing option. No important usage aspect is left unexplained.

  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 has 100% coverage, but the description adds meaning by explaining the spec structure in plain language ('nodes (name, operator type, parameters as constants/expressions/binds, inbound wires by name, optional x/y)') and by clarifying the effects of clear_existing and auto_layout (e.g., auto_layout 'overrides any manual x/y'). 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 function: 'Reconstruct a live network inside a COMP from a serialize_network spec — the REBUILD half of a git-diffable round-trip.' It uses a specific verb ('reconstructs') and names the exact resource (a COMP from a spec). It also distinguishes itself from the sibling tool 'serialize_network' by explicitly calling out the round-trip relationship.

  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 counterpart to serialize_network, implying it should be used when reconstructing a previously serialized network. It also gives explicit constraints (requires TDMCP_RAW_PYTHON=on for expression/bind sources, TDMCP_BRIDGE_ALLOW_EXEC=1) and mentions behavior for constant-only specs. However, it does not explicitly mention when not to use it or name alternative tools for simpler node creation, though the round-trip framing is sufficient guidance.

  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?

  Annotations only indicate readOnly and non-destructive. The description adds critical behavioral details: offline operation, semantic re-ranking dependency, fallback behavior, stale_hint and data_version in results. 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 effectively front-loaded with the core purpose, each sentence adds unique value, and it's concise (~150 words) 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 8 parameters and no output schema, the description covers usage context, parameter interactions (e.g., version and category filters), edge cases (LLM fallback, stale hint), and token economy. It is 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.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 100% schema coverage, baseline is 3. The description adds semantic context beyond schema: explains search mode behavior, semantic opt-in, and version/category filtering purpose. However, most parameter descriptions in schema are already clear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 the embedded operator knowledge base, lists search dimensions (keyword, exact name, tag, category, etc.), and distinguishes from siblings like search_python_api by specifying the resource (operators) and scope (629 operators 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 explicit when-to-use advice: 'Use it to discover the right operator before creating nodes instead of guessing a type'. It also offers token economy tips. However, it lacks explicit when-not-to-use guidance, though the sibling context implies alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_perform_modeA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses all key behaviors: it stores a flag on the TD root op, does not stop the timeline or kill A/V processing. It also explains the advisory guard. No annotations are contradicted; the readOnlyHint=false is consistent with writing a flag.

  Agents need to know what a tool does to the world before 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 that are front-loaded with the action and purpose. The first sentence states the core function, the second explains scope and correct usage. 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 toggle with one parameter and no output schema, the description fully covers behavior, side effects, and usage pattern. It is complete and leaves no 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 single parameter 'enabled' already has a detailed schema description. The tool description adds context about flag storage and the built-in guard, providing 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 clearly states the verb ('Toggle') and the resource ('perform mode'), and explains its purpose as an advisory flag for nonessential compute. It is distinct from sibling tools, which are all about creating or managing other elements.

  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 to use: 'before going live' and after the show. It gives context like 'the one switch the artist flips before going live' but doesn't mention when not to use it or alternatives, though none are needed for a toggle.

  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 adds significant value beyond annotations by detailing that events are high-frequency and coalesced, require the TD event stream to be enabled, and survive TDMCP_BRIDGE_ALLOW_EXEC=0. It also describes the event payload format, which 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 concise (~100 words) and well-structured: it starts with the core purpose, then usage, then caveats. Every sentence adds value 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?

  Given the tool's complexity (3 parameters, event streaming) and the presence of an output schema, the description covers all necessary aspects: subscription actions, scoping, event format, prerequisite (TDMCP_EVENTS), and high-frequency handling. No gaps remain.

  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 adds meaning by explaining the interplay between parameters: 'path' is required for 'watch'/'unwatch' but not 'list', and 'parameters' optionally scopes the watch. This clarifies conditional usage beyond the schema's individual 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 subscribes to `param.changed` events for an operator's parameters, using a specific verb (subscribe) and resource (operator parameters). It distinguishes itself from sibling tools like 'watch_node' by focusing on parameter changes and listing the three actions (watch, unwatch, list).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains when to use the tool (opt-in subscription) and provides context for when events are received (TDMCP_EVENTS enabled). It does not explicitly state when not to use it or compare to alternatives like 'watch_node' or 'animate_parameter', but the information is largely clear.

  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.8/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. Description adds fail-forward behavior (partial chain returns info) and wiring semantics. Minor gap: doesn't specify if existing nodes are overwritten, but openWorldHint provides 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?

  Compact single paragraph with no wasted words. Each sentence serves a purpose: purpose, behavior, tip, sibling differentiation.

  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 core chain-building, error handling, best practice (nullSOP), and alternative for multi-input. No output schema but description mentions useful info from partial chain. Complete for agent 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?

  Description adds significant meaning beyond 100% schema coverage: explains wiring logic, fail-forward on per-op failures, and param string values resolving to op paths. This compensates 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 'Declarative Layer-2 builder for an ordered SOP geometry chain' with specific verb 'build' and resource 'SOP geometry chain'. It distinguishes from siblings like `connect_nodes` and `build_chop_chain`.

  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 advises using `connect_nodes` for multi-input fan-in and recommends ending with `nullSOP` for handoffs. Provides clear context for 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.

• create_audio_reactiveA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description details the exact nodes created (Audio Spectrum CHOP, Analyze level, optional Beat CHOP, etc.), the visual style options, and the return format (summary, JSON block with paths, controls, errors, preview). Annotations (readOnlyHint=false, destructiveHint=false) are consistent, and the description adds significant behavioral context 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 concise, front-loaded with what the tool does, lists visual styles in a compact way, and ends with usage guidelines. Every sentence adds value; 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 14 parameters, no output schema, and the complexity of creating an audio-reactive chain, the description covers the main aspects: what is created, visual styles, return value, and alternatives. It lacks information on prerequisites or failure modes but is otherwise thorough.

  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 overall context (e.g., 'sidechain_duck adds an inverted duck-envelope channel') but does not elaborate on individual parameters beyond what the schema already provides. It slightly enhances understanding of the chain structure.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 an audio analysis chain and a spectrum visual, creating a specific baseCOMP with defined nodes. It distinguishes itself from sibling tools like extract_audio_features, create_spectrum, and bind_audio_reactive, 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 explicitly provides when to use this tool versus alternatives, stating it is the only audio tool that produces a built-in visual and listing what other tools are for (e.g., extract_audio_features for channels without visuals). This gives clear usage guidance.

  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.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses internal build details (Select CHOP, audiofilterCHOP, Analyze, Merge, Lag, Null) and notes about unverified parts with fallbacks (abs envelope, upstream names) and warnings for per-item failures. This adds value beyond 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Well-structured with purpose first, then build steps, route details, sibling reference, and note. Slightly long but each sentence adds value; no superfluous 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?

  Comprehensive for a complex tool with 6 parameters and nested objects. Covers build process, output bands_out, alternative usage, and behavioral notes. No output schema, but output is implicit (container created). Complete guidance.

  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%, baseline 3. Description adds context like band naming convention (band0..bandN-1), log-frequency tiling, and reference to extract_audio_features idiom, enhancing understanding of parameters 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 states the tool splits an audio signal into EQ bands and routes each band to parameters, using a specific verb+resource. It distinguishes itself from sibling extract_audio_features by noting the difference: 'that one extracts named features; this one is the band-split + multi-target router.' 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 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 vs. extract_audio_features and provides guidance on omitting targets to build the split and use bind_to_channel later. It gives clear usage context and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_data_reactiveA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  While annotations already indicate non-destructive and open-world, the description adds critical behavioral details: smoothing via Lag CHOP, fail-forward logic (warnings vs fatal), and implicit remapping mechanism. This exceeds what annotations alone 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 efficient and structured, but slightly verbose (about 150 words). Every sentence adds value, but some repetition in range explanations could be trimmed.

  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 inputs, behavior, prerequisites, error handling, and alternatives. Lacks output specification, but no output schema exists, so acceptable. Completeness is high given 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?

  Despite 100% schema coverage, the description enriches each parameter with context: examples for source_chop, range remapping for mappings, and smoothing behavior for smooth. This goes beyond basic 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 maps live data onto COMP custom parameters, using strong verbs like 'wire' and 'map'. It distinguishes itself from sibling 'bind_audio_reactive' and 'bind_to_channel' by positioning as a broader data counterpart and finer control 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?

  Provides explicit when-to-use (wire arbitrary data to parameters), prerequisites (build data CHOP first with create_data_source), and alternative (bind_to_channel for single-parameter control). Also explains fail-forward behavior for missing sources.

  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.8/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 discloses that it creates a baseCOMP with many nodes, may prompt a macOS camera permission dialog when using camera source, and exposes live Depth and Zoom knobs. It also notes the return value includes a summary and JSON block with 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 well-structured. The first sentence captures the essence and differentiation from a sibling. It then lists source types, key parameters, and outputs. Some redundancy exists (e.g., 'true geometry' repeated), but overall 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?

  Given the tool's complexity (8 parameters, no output schema, many siblings), the description is thorough. It covers all relevant aspects: purpose, source options with permissions, parameter effects, created nodes, exposed controls, and return format including inline preview. It 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?

  Although schema coverage is 100%, the description adds meaningful context beyond the schema: e.g., 'subdivisions' sets relief resolution and mentions vertex count effect; 'depth' explains that 0 is flat; 'invert' explains bright↔near mapping. It also explains the effect of 'expose_controls' and 'parent_path'. This enriches the parameter understanding beyond bare 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 it pushes a flat plane into 3D relief using a depth/luminance map, and contrasts with the sibling 'create_depth_silhouette', which is a flat 2D mask. The verb 'create' and resource 'depth displacement' are 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?

  The description explicitly tells when to use this tool vs. 'create_depth_silhouette', describes source options with context (e.g., synthetic for testing, camera may need permission), and explains that subdivisions affect detail. It provides clear guidance on selecting source type and other parameters.

  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.8/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 adds extensive behavioral details: creates a baseCOMP with specific internal structure (feedback loops, Geometry COMP, Camera, Light, Render TOP), describes particle count limits (up to 512²), exposes knobs, and explains reactivity modes with device-permission dialogs. 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 the main purpose, but it is quite long (10 sentences). Each sentence adds value, but some streamlining could improve conciseness without losing clarity.

  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 thoroughly covers: what it creates (specific nodes), how it works (GPU simulation loop), parameter ranges, return value (summary + JSON block), and side effects (device permission). 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% with descriptive parameter names, but the description adds meaningful context: e.g., side explains the square buffer concept, forces details each force type, reactivity mentions the device-permission dialog. While schema already provides good semantics, the description enriches 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 tool builds a high-count GPU particle/point field with GPU-based simulation, and distinguishes it from siblings like create_particle_system (CPU, lower count), create_particle_flock, image_to_particles, and create_pop_particle_system. The verb 'Build' and resource 'GPU particle field' are 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?

  The description explicitly tells when to use this tool ('general-purpose GPU drift field') and when to use alternatives ('pick a sibling instead for other motion'), listing each sibling's specific purpose. It also notes the CPU counterpart for simpler, lower-count needs, providing clear decision guidance.

  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.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context: hardware-gated scaffold, best-effort CC/note maps, need for validation, and that the tool is held from release. 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 well-formed paragraph that front-loads the main purpose. While clear and compact, it could benefit from bullet points or clearer separation of key aspects (e.g., steps, caveats). But it earns its sentences 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 complexity (5 params, no output schema), the description covers all critical aspects: what is created, supported devices, auto-binding vs explicit, hardware validation warnings, and an alternative tool. No gaps remain for an agent to infer.

  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. The description adds extra meaning by explaining the overall workflow (preset auto-binding, explicit overrides) and hardware validation context, which enriches understanding beyond 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 purpose: 'Build a MIDI controller preset for a supported device', specifying what it creates (midiinCHOP + bind Table DAT) and optional auto-binding. It also distinguishes from the sibling 'learn_control' tool, which is for one-at-a-time MIDI learn.

  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: for creating presets for supported devices. Also provides when-not: 'For one-at-a-time MIDI learn of a single control, use learn_control instead.' Includes caveats about hardware validation and tool status.

  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.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explains side effects: creates a new baseCOMP under parent_path, conditionally exposes controls (NoiseAmount and NoisePeriod only when noise_amount > 0), and omits the Noise SOP when noise_amount=0. Annotations (destructiveHint=false, openWorldHint=true) are consistent and complemented.

  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 slightly long; however, every sentence provides value and it is front-loaded with the core purpose. Could be slightly more concise, but effectively communicates 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 11 optional parameters and no output schema, the description covers the creation process, conditions, and behavior. It doesn't mention error handling or path existence, but for a creation tool, it is quite complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, but the description adds crucial context: conditional knob exposure, inert parameters when noise_amount=0, and the text_string being ignored for non-text primitives. This goes 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 clearly states 'Procedural Op Pattern (POP) geometry generator' and details the exact SOP chain and render pipeline, distinguishing it from sibling tools 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?

  Explicitly provides when to use this tool vs. alternatives: '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.'

  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.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses key behavioral details: it creates a new baseCOMP with specific child nodes (pose source, Geometry COMP, Line MAT, Camera, Render TOP, Null output), exposes controls (LineColor, LineWidth, CamDistance), and returns a summary with paths and errors. This aligns with annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) and adds 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph, but it is well-structured: it starts with the core visual output, then explains source options, created components, sibling comparison, exposed controls, and return value. It is front-loaded with the main purpose, though slightly lengthy; 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 complexity (9 parameters, creates multiple nodes, no output schema), the description covers all critical aspects: main functionality, four data sources, created node hierarchy, exposed controls, return format (summary + JSON block), and an inline preview. It is fully adequate for an agent to understand 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%, with descriptions for all parameters. The description adds value by explaining the purpose of the `source` enum values (e.g., 'synthetic' for instant preview without camera) and mentioning that LineColor/LineWidth/CamDistance are exposed as live knobs. This enhances understanding beyond 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?

  The description clearly states the tool renders a live stick-figure skeleton from full-body pose tracking, specifying 33 landmarks, glowing lines, and the visual output. It distinguishes itself from the sibling `create_body_reactive` by contrasting the stick-figure vs. 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?

  The description provides explicit guidance on when to use this tool and alternatives: it mentions `create_body_reactive` as an alternative for a different visual style. It also details the source options (synthetic, mediapipe, osc, existing_chop) and their use cases, helping the agent select the appropriate configuration.

  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.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) are not contradicted. Description adds key behavioral traits: it's a stacked-2D-slice approximation (not raymarched), no per-pixel ray traversal, returns summary JSON with node paths, preview, etc. Could include more on side effects, but openWorldHint leaves room.

  Agents need to know what a tool does to the world before 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 paragraph with front-loaded purpose, then architecture, caveat, alternative suggestion, performance guidance, and return value summary. No redundant sentences; every line 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 complexity, no output schema, and open annotation, description covers what it creates, how it works (Simplex noise, Beer-Lambert accumulation), limitations (approximation), performance, and output format. Complete for an AI agent to understand 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?

  Schema coverage is 100%, and description adds significant extra meaning: density maps to uDensity shader uniform, turbulence drives displacement weight, slice_count rewires cache stack, color_map enum explained. Each parameter's behavior and constraints are enriched 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?

  Clearly states it builds a stacked-slice fake-volumetric noise field with specific palettes. Explicitly distinguishes from a true raymarcher (planned create_volumetric_raymarch).

  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 (stacked-2D-slice approximation) vs alternatives (true raymarcher). Gives performance and hardware guidance (cook cost linear, default 16 slices as sweet spot, drop to 4-8 on integrated GPUs).

  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.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. The description adds valuable context: values are authoritative, from the running build, include dynamically-populated menus, and explains the fallback mechanism with a warning when raw exec is unavailable. This fully discloses the tool's behavior 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 substantive and well-structured, with key information front-loaded ('Read-only: for each menu parameter...'). While it is relatively long, every sentence adds value, such as the use-case hint, behavioral details, and fallback explanation. Minor redundancy could be trimmed, but overall 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?

  Given the tool has three parameters, a clear output schema (not shown), and annotations, the description covers all essential aspects: purpose, usage, behavioral traits, edge cases (empty menus), prerequisites, and fallback. It is complete enough for an agent to understand 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% with descriptions for all three parameters. The description adds further meaning by explaining the purpose of 'menu_only' (default true, can be set false to see all parameters) and indicating that 'keys' is case-sensitive. This enhances the schema's built-in 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 clearly states the verb 'live-fetch' and the resource 'menu parameter values of a node'. It distinguishes itself from generic parameter tools by focusing specifically on menu parameters, and explicitly states the use case: 'Use this before setting a Menu / StrMenu parameter'.

  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: before setting a Menu/StrMenu parameter. It also explains when not to use (for non-menu parameters) and describes prerequisites (TDMCP_BRIDGE_ALLOW_EXEC=1) and fallback behavior with a stale-catalog warning. It also clarifies the meaning of empty menuNames, preventing misinterpretation.

  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.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnly and non-destructive. Description reinforces offline nature, no calls to TouchDesigner, and lists all checks performed. 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?

  Single paragraph front-loads purpose, then lists checks, then mentions report. No redundant information. 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?

  Lacks output schema but mentions 'structured report'. For a linter, this may be sufficient, but more detail on report format would improve 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?

  Schema covers 100% of parameters with descriptions and enums. Description adds context by listing rule IDs and clarifying default behavior. Minimal extra value but schema already rich.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 is an offline semantic linter for recipes/*.json with a detailed list of checks. Distinguishes from siblings by its specific linting focus.

  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 it never calls TouchDesigner, implying no side effects. Tells when to use (linting) and implies when not to use (when modifications are needed).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• scaffold_genreA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Details are extensive: it creates a master output Null, wires a genre look, writes global tempo, and returns paths. This adds significant value beyond annotations, which already indicate non-read-only and 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is slightly verbose but well-structured with front-loaded purpose and no redundant sentences. Every sentence adds value, though it could be more terse without losing clarity.

  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 explains return values and suggests next steps (add scenes, layer mixer, cues), providing complete context for using the tool despite lacking 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?

  Input schema has 100% description coverage, but the description enriches parameter meaning by explaining what each genre does (e.g., 'techno' gets fast BPM and strobe look). This goes beyond enum labels, earning 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 clearly states the tool creates a genre-flavored starting network, differentiating it from scaffold_show's blank skeleton. It lists specific genres and their behaviors, 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?

  Explicitly recommends using scaffold_show for an empty skeleton, providing a clear alternative. The description implies when to use this tool (when a genre flavor is desired) and includes no misleading guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• setup_segmentationA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses behavioral traits beyond annotations: idempotent, reuses existing engine, requires timeline playing, macOS camera permission. No contradiction with 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?

  Efficiently structured: front-loads purpose and installation, then details behavior, parameters, and wiring instructions. Every sentence serves a clear purpose 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?

  Comprehensive for a tool with 8 parameters and no output schema: explains what is created (mask Null TOP, optional prekeyed RGBA), how to wire to other tools, and handles edge cases (idempotency, camera permission).

  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?

  Adds meaning beyond input schema: explains default paths, model variants (general vs landscape), smoothing behavior, and details on invert_mask (via Level TOP) and feather_px (via Blur TOP). High schema coverage (100%) complemented by operational 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?

  Clearly states it sets up selfie segmentation via MediaPipe TouchDesigner engine, listing specific capabilities (load engine, enable segmentation, build adapter COMP with mask) and distinguishes from siblings by referencing wiring into create_keyer, create_depth_silhouette.

  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 (for segmentation setup), mentions idempotency and prerequisites (timeline playing, camera permission). Does not explicitly exclude alternatives but references specific matte-consuming tools, giving guidance on downstream use.

  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.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Consistent with readOnlyHint=true, adds rich behavioral detail: return format, compact mode hoisting defaults, per-node parameter fetching capped, and token-cheap whole-COMP read. 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?

  Four sentences front-load purpose and return type, then cover parameter options. No redundancy. 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?

  With output schema present and annotations covering safety, the description fully covers purpose, behavior for all parameter modes, and cross-tool usage (diff_snapshots). No gaps.

  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 description adds context beyond field names: explains 'compact' as token-cheap with delta storage, 'include_params' as one request per node capped, and 'include_parameter_modes' preservation. Enhances schema 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 it captures a compact, serializable network snapshot including nodes, connections, structural issues, and optionally parameters. It uses specific verbs ('capture', 'return') and distinguishes from sibling 'diff_snapshots' by name.

  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?

  Describes explicit use cases: review, diffing, documentation, feeding to diff_snapshots. Explains compact mode benefits for whole-COMP reads. Lacks explicit when-not-to-use or alternatives among siblings, but context is clear.

  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.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses both read/write directions for export and import, merging behavior, and return value. Adds context beyond annotations (which indicate non-read-only, non-destructive, open-world).

  Agents need to know what a tool does to the world before 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 action and details. No filler; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Covers key behaviors (export/import, merge, prerequisite, return value). Lacks error handling details but sufficient for a sync tool with given annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, providing baseline 3. Description adds meaning by explaining action enum semantics, default for note, and purpose of comp_path linked to manage_presets.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 bridges manage_presets snapshots with Obsidian vault via export/import actions. Distinguishes from sibling manage_presets by specifying 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?

  Explicitly states when to use (version-control/share presets) and when not (use manage_presets for live capture/recall). Also mentions prerequisite: requires 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_repair_loopA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint=false, destructiveHint=false) are consistent with the description. The description adds rich behavioral context: iterative execution, dry-run mode, convergence detection, and what the loop cannot do. It also details the return object structure, enhancing 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, single paragraph, front-loaded with key actions: scan, cluster, route, re-check, iterate. Every sentence adds value without redundancy. It efficiently conveys the tool's purpose, behavior, and limitations.

  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 fully details return values: status, iterations[], errors_before, errors_after, remaining[], recommended_prompts[], warnings. It also covers parameter interactions (dry_run, allowed_fixers) and edge cases (stalled, exhausted). The description is comprehensive for an iterative repair 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 value by explaining behavior beyond schema, e.g., dry_run implies one iteration, allowed_fixers can be dropped for advisory mode. This extra context justifies a score of 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 clearly states the tool's purpose: scan a subtree for cook errors, cluster them, route to fixers, re-check, and iterate until clean, stalled, or exhausted. It uses specific verbs and resources, and distinguishes from sibling tools by naming specific fixers like repair_network, fix_shader, fix_reactivity.

  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 default dry-run mode (planning only, no writes), the loop's limitation (cannot fix shaders or dead reactivity itself, points agent to recommended_prompts), and the convergence threshold via min_progress parameter. It also explains the allowed_fixers parameter behavior, providing clear guidance on when to use and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_containerA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) align with the description's disclosure that it creates an empty COMP non-destructively. The description adds tiling behavior and return details, providing complete 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?

  Four sentences, front-loaded with main action, no redundancy. Efficiently conveys purpose, behavior, and usage 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?

  Covers all necessary context: creation, tiling, comp types, return values, and when to use alternatives. No missing information for a tool with no required parameters and 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 coverage is 100%, so the description adds value by explaining tiling behavior and return values, slightly enhancing 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 it creates an empty COMP (visual system container) under a parent path, tiles it, and distinguishes between container and base types. It also mentions return values. This differentiates it from sibling tools like create_td_node or create_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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly advises using a higher-level Layer 1 tool for fully built networks, providing clear 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_led_mapperA
  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 detailing network resizing behavior, one-texel-per-pixel sampling, RGB preservation, default moving Ramp test source, returned data (node paths, channel count, warnings), and live Brightness/Universe controls on the parent COMP. This gives the agent a rich behavioral model 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, front-loaded with the primary purpose, then behavioral details, then usage guidance and alternative tool. No filler or redundancy; 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?

  Despite having 11 parameters and no output schema, the description covers what the tool does, what it returns, when to use it versus the sibling tool, and critical operational caveats. 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.

  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, but the description supplements parameter meaning by explaining how width/height relate to the pixel grid, how the Ramp source becomes the default when source is omitted, and how the chain preserves RGB. This adds conceptual context beyond the schema's per-parameter notes.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 pixel-mapping chain from a source TOP to an LED fixture grid and DMX Out CHOP over Art-Net or sACN.' It clearly states both the transformation and the output, and distinguishes itself from create_dmx_fixture_pipeline by focusing on image-to-pixel 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?

  Explicit guidance is provided: 'Use create_dmx_fixture_pipeline for fixture patching and this tool when you specifically need image-to-pixel mapping.' It also adds a practical operational caveat about needing a reachable fixture/node and verifying before sending.

  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.9/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 states that a new baseCOMP is created with many child nodes, that it exposes a Zoom knob, and that the output includes a summary and a JSON block with paths, errors, warnings, and a preview image. This covers creation, outputs, and side effects thoroughly, complementing the annotation's readOnlyHint=false and 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.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately front-loaded with the primary purpose and differentiator, then details the internal build and output. It is somewhat long but every sentence earns its place by providing necessary information for correct invocation. A slight trim could be made, but it remains clear and 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?

  Given the tool has 7 parameters (1 required) and no output schema, the description compensates extremely well by detailing the return format (summary plus JSON block with container path, node paths, output path, exposed controls, errors, warnings, inline preview image). It also covers the internal structure (Geometry COMP, Constant MAT, Camera, Light, Render TOP) and the exposed controls, making the tool's behavior fully predictable.

  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%, providing a baseline of 3, but the description enriches each parameter: source_path is described as 'brought in through a Select TOP'; rows/cols get a performance trade-off note ('more rows/cols give a smoother curve but a heavier mesh'); warp gets a human-readable mapping ('bulge (dome), wave (ripples across X), cylinder (half-cylinder wrap), or flat'); amount is clarified as ignored when warp is 'flat'; expose_controls is linked to a 'live Zoom (camera distance) knob'; parent_path states the default. This added meaning justifies a top 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 uses a specific verb ('Map a source TOP onto a curved or irregular surface via a deformable textured grid') and clearly distinguishes this tool from the sibling create_projection_mapping by calling it the 'curved-surface upgrade to create_projection_mapping's flat corner-pin'. It also lists concrete use cases (domes, columns, sculptures) 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 contrasts this tool with a sibling (create_projection_mapping), saying it is for curved surfaces while the sibling is for flat corner-pin. It also describes the internal components built (Geometry COMP, Constant MAT, orthographic Camera, etc.) and the output structure (Null, Zoom knob, JSON return), giving an agent clear context for when and how 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_multi_outputA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Describes what it creates (baseCOMP, Select TOP, per-tile Crop, Null outputs, optional Window COMPs), the edge-blending behavior, and that windows are left closed. Annotations indicate creation but no destruction, and description aligns.

  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?

  Reasonably concise with all key information; could be slightly more structured with bullet points, but the single paragraph is well-organized and 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?

  Covers all important aspects: function, overlap details, what nodes are created, alternative tools, and return format. No output schema, but description mentions the JSON block summary.

  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%, and the description adds value beyond schema by explaining overlap's edge-blending with GLSL feather and that as_windows windows are left closed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 fans a master TOP across N projectors/displays with cropping and resizing, distinguishing it from siblings like setup_output, create_dome_output, and create_cubemap_dome.

  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 tells when to use alternatives: 'Use setup_output instead for a single-window output; create_dome_output/create_cubemap_dome for curved/fulldome instead of flat tiling.' Also mentions windows are left closed.

  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.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnly=false, openWorld=true, destructive=false. The description adds that the tool creates a new baseCOMP with specific components, exposes live knobs, and only runs while the timeline plays. 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 detailed and well-structured, front-loading the core purpose. While slightly verbose, every sentence adds value for a complex tool. Could be slightly trimmed but is still 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 complexity (9 parameters, no output schema), the description is very complete. It covers the algorithm, components created, exposed controls, return value (summary, paths, errors, preview), and a limitation (timeline dependency).

  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 significant context: explains how count translates to agents (count^2), the role of speed, the boids weights, and the relationship between parameters. It clarifies the neighbor scan cost and the default 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 clearly states the tool builds a boids-style GPU particle flock, specifies the mechanism (separation, alignment, cohesion), and distinguishes from sibling tools like create_gpu_particle_field, image_to_particles, etc. It uses specific verbs and resource names.

  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 tells when to use this tool vs. alternatives: 'The behavioural complement to create_gpu_particle_field (use that instead for curl-noise/gravity drift rather than flocking); also pick a sibling for other motion: image_to_particles...'. Also notes the flock only evolves while the timeline plays, which is a key usage condition.

  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 the minimal annotations (readOnly=false, non-destructive, openWorld), the description discloses key behavioral traits: idempotently reused nodes retain existing coordinates, operator type validation against a knowledge base with non-blocking warnings, and the exact return shape ({node, warnings[]}). This significantly enriches the agent's understanding of 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 four sentences, front-loaded with the primary action and followed by necessary behavioral details. Every sentence contributes value—purpose, placement semantics, idempotency, validation, return value, and sibling differentiation—with no redundant or verbose wording.

  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 covers all essential aspects: what the tool creates, placement options, reuse behavior, validation, warnings, and return value. It also distinguishes from Layer-1 tools, providing sufficient context for an agent to select and invoke it correctly. The only minor gap is the undefined 'legacy bridge behavior', but the description clarifies the practical impact.

  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 with descriptions, so the baseline is 3. The description adds meaningful context beyond schema by explaining that reused nodes keep their coordinates (relevant to 'name') and that type is validated against a knowledge base (relevant to 'type'). It also reinforces placement policies, though those 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 the tool's function: 'Create a single bare operator (node) inside a parent COMP' with specific details about placement and viewer state. It distinguishes itself from sibling tools by explicitly noting that for a 'complete wired+arranged network prefer a Layer-1 create_* tool', making its scope unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage 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 vs alternatives, including when to omit placement (legacy bridge behavior), the semantics of 'auto' vs 'explicit' placement, and directs users to Layer-1 tools for more comprehensive network creation. It also explains that unknown types produce warnings without blocking, which informs usage decisions.

  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.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds behavioral context beyond annotations: it creates a Text TOP with specific attributes, optionally composites over a source TOP via a Composite TOP, and outputs a Null. It confirms the text is static and discloses the process without contradicting the annotations (readOnlyHint=false, openWorldHint=true, 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 concise—3 well-structured sentences. The first sentence states the core action, the second lists use cases, and the third draws clear distinctions from siblings. No redundant 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's complexity (8 simple parameters, no output schema, supportive annotations), the description is complete. It explains what is created, how it works, when to use it, and how it differs from alternatives. The mention of output as a Null is a helpful 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%, so baseline is 3. The description adds value by naturally framing key parameters (font size, color, alignment) as the core attributes of the text, and mentions optional source compositing, providing workflow context that the schema alone 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 explicitly states it composites static text over a visual or on a transparent background. It clearly distinguishes from sibling tools such as create_kinetic_text (for moving text) and create_text_crawl (for scrolling tickers), and also separates itself from bind_vault_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?

  The description provides explicit guidance on when to use this tool (for lyrics, titles, song names, credits) and when not to use it (for moving text use create_kinetic_text, for scrolling tickers use create_text_crawl). It also contrasts with bind_vault_text.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• detect_tempoA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description details the algorithm (onset detection, median filtering), output (bpm channel on Null CHOP), and side effects (optionally writes to global tempo with drive_tempo). Annotations indicate readOnlyHint=false and destructiveHint=false, which align with the description's explanation of non-destructive mutation. The description adds significant behavioral context 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 well-structured: first sentence states purpose, then algorithm, then comparison with siblings, then caveats. It is comprehensive yet concise, with no redundant sentences. 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?

  Given 10 parameters, 100% schema coverage, and no output schema, the description fully covers the tool's behavior, including output format, side effects, and limitations. It provides enough information for an agent to use the tool correctly without needing external 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 descriptions cover all 10 parameters (100% coverage), so the baseline is 3. The description adds extra meaning by explaining the algorithm (e.g., how sensitivity maps to threshold) and how parameters like min_bpm/max_bpm reject implausible intervals. This elevates understanding beyond 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?

  The description clearly states that the tool detects tempo (BPM) automatically from audio, contrasting with manual tapping (sync_external_clock) and onset detection (detect_onsets). It specifies the verb 'detect' and the resource 'tempo', 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 provides explicit guidance: it is for automatic tempo detection without manual tapping, complements sync_external_clock and detect_onsets, and includes caveats about time-dependence, half/double time locking, and the need for live tuning. This helps the agent decide when 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.

• export_network_to_vaultA
  4.9/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 a key behavioral trait. Returns note path, node/connection counts, and truncation status. Annotations (readOnlyHint=false, destructiveHint=false) are consistent with description. 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?

  Description is a single paragraph but efficiently covers purpose, usage guidance, and return values. Front-loaded with key action. Every sentence adds value; 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 3 parameters, no output schema, and moderate complexity, the description fully addresses what the tool does, when to use it, what it returns, and any prerequisites. 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 schema already documents parameters well. Description adds context that note defaults to 'Networks/<path>.md', which enriches understanding beyond the schema. Slight extra 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?

  Description explicitly states the action ('READ' and 'WRITE'), the resource (TD network), and the output (Obsidian note with Mermaid flowchart and wikilinks). It distinguishes from sibling tool document_network by specifying that this tool persists to vault while the other returns results. Very clear and specific.

  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 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.' Also mentions prerequisite: 'Requires a configured TDMCP_VAULT_PATH.' No ambiguity.

  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.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate non-read-only, open-world, non-destructive. Description adds that source='device' may prompt macOS permission, creates a self-contained container, and exposes a Sensitivity knob. 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?

  Single paragraph efficiently conveys purpose, differentiation, usage, and behavioral notes 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?

  No output schema but description explains return value (reactive channels on Null CHOP) and lists bands. References sibling tools and provides enough context 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?

  Schema covers 100% of parameters with descriptions. Description adds context for source values (e.g., macOS permission) and explains the purpose of the tool beyond parameter 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 builds an audio-analysis chain exposing reactive channels on a Null CHOP. It distinguishes itself from siblings like create_audio_reactive (renders spectrum visual) and create_spectrum (fine per-band channels).

  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 contrasts with create_audio_reactive and create_spectrum, advises passing the Null to bind_audio_reactive, and explains when to use each source type (device, file, oscillator, existing_chop).

  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.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond annotations (readOnlyHint, destructiveHint, openWorldHint), the description explains the tool walks the operator tree under `scope`, guarantees operator cook errors/warnings, and performs a best-effort probe of textport/log DATs. It also details the return object structure with probe reporting log source reachability.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 with no fluff. It front-loads the core purpose ('Read-only'), then explains behavior, usage, and return structure. Every sentence is informative and 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 tool's complexity (3 parameters, full schema coverage, output schema), the description is complete. It covers purpose, behavior, usage, and return format comprehensively, enabling an agent to decide when and how 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 context by explaining the tool walks the operator tree under `scope`, linking to that parameter. It also mentions 'guaranteed' for cook errors, though not parameter-specific. This adds some value beyond the schema's 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 collects recent cook errors and warnings from a TouchDesigner project for debugging, with specific verb 'collect' and resource 'cook errors and warnings'. It distinguishes from sibling tools like 'summarize_td_errors' and 'get_td_node_errors' by mentioning it walks the operator tree and provides context without requiring a new REST endpoint.

  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 usage guidance: 'Use this when a script or cook fails and you need more context than the immediate error string — it surfaces the real Python traceback or operator cook errors'. This clearly tells the agent when to use this tool and implies when not to.

  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.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already provide readOnlyHint and destructiveHint; description confirms read-only and adds context: include_info_chop creates a temporary Info CHOP with fail-forward warnings, and the extra map records which attrs were present. 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?

  Two sentences (plus UNVERIFIED note) that front-load the purpose and key details. Every sentence earns its place; 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?

  With output schema present, description covers all necessary context: lists return fields, notes temporary side-effects of include_info_chop, and explains the extra map. Complete for diagnostic use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, baseline 3. Description adds meaning: path example and clear explanation of include_info_chop's behavior (creates temp Info CHOP, fails forward with warnings). Provides 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?

  Clearly states it is a read-only inspection of a single operator's runtime telemetry, listing specific metrics like cook time, cook count, etc. Distinguishes from sibling tool 'get_td_performance' by explicitly stating it provides deep per-op detail versus aggregate network-level data.

  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: for diagnosing 'why is it black / why is it slow' per operator. Mentions alternative 'get_td_performance' for aggregate cook times. Also warns that attribute names are UNVERIFIED and vary by TD build, setting expectations.

  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.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, and the description reinforces this with 'Read-only.' It adds valuable behavioral context beyond annotations: the warning that 'a full parameter dump is large' and the token economy suggestions. This informs the agent about performance/context implications, which is not in the schema or 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. Every sentence earns its place: the first states what it does and the return shape, the second covers optional flags, and the third provides an alternative and token economy warning. No redundant phrasing or 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 simple read tool with an output schema, the description is fully complete. It covers scope, return structure, optional filters, a relevant alternative, and a practical caution about response size. There is no missing information that would prevent an agent from using 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 semantic value by explaining the purpose of `keys` ('project specific parameters') and `omit_io` ('drop the inputs/outputs lists') in plain language, and connects them to the token economy concern. While it largely rephrases the schema, the added rationale for using these flags 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 clearly states the tool's function with a specific verb and resource: 'read the current parameters (and inputs/outputs) of one node.' It distinguishes itself from siblings like compare_td_nodes and get_td_nodes by explicitly limiting scope to a single node and highlighting the return shape.

  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 context: it tells when to use this tool (read one node's parameters) and mentions an alternative (`compare_td_nodes`) for diffing two nodes. It also gives practical guidance on parameter flags for token efficiency, which helps the agent decide when to use optional arguments.

  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?

  Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this by saying 'changes nothing' and listing the exact return structure. It adds detail beyond 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 core function and return shape, then a clear alternative. Every sentence is useful 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 output schema and well-documented input schema, the description sufficiently covers purpose, output structure, and sibling differentiation. No missing information 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?

  The input schema has 100% coverage, so the baseline is high. The description adds context implying the recursive default (default is true) and slowest-first ordering, which are not in the schema. This adds value though not fully necessary.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 reports cook times and warns about budget-exceeding nodes, and distinguishes itself from 'optimize_performance' by specifying it's read-only. This provides a clear, specific verb-resource-scope pairing.

  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 this tool with 'optimize_performance', stating when to use each: 'Use this to just measure; use optimize_performance when you want suggestions...' This gives precise usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• narrate_setA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Description discloses that the tool writes a local file (not read-only) and is append-only, complementing the annotations (readOnlyHint=false, destructiveHint=false). It also mentions timestamping, markdown format, and default file path, offering thorough behavioral context beyond structured 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 concise, with each sentence contributing meaningful information. It is front-loaded with purpose and efficiently covers usage, modes, file details, and sibling differentiation.

  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 (two modes, seven parameters, file writing), the description covers all essential aspects: mode behavior, file path, defaults, pairing suggestion, and comparison to a sibling. With full schema coverage and an output schema present, no critical gaps remain.

  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 how parameters relate to modes (e.g., line required for append, tail for recall) and provides file path defaults and optional fields (section, cue), enhancing semantic 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 tool persists running narration of a VJ/show set for later recall, with specific modes (append/recall). It distinguishes itself from the sibling tool log_performance, which writes a one-shot snapshot instead of an append-only log.

  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?

  Describes when to use: call on each major move during a set to leave a diary/setlist trail. Explicitly contrasts with log_performance as an alternative, providing clear 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.

• plan_visualA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint and destructiveHint=false, but the description adds substantial behavior beyond that: 'every suggested tool, recipe and operator is validated,' 'any unavailable or invalid LLM path falls back deterministically without mutating TouchDesigner.' It also clarifies that the LLM completion is 'grounded' and 'bounded.' This is rich, additive 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 two sentences, front-loaded with the core purpose, and every clause carries useful information. No fluff, no repetition of schema field names. 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.

  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 (4 params, two planner modes, validation and fallback behavior) and existing output schema, the description fully covers what an agent needs to know: purpose, safety, mode selection, and failure handling. It leaves no critical gaps for a planning 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 applies. The description does add meaning beyond the schema by explaining the conceptual role of planner='llm' ('one bounded completion grounded in compact editor/project/recipe/operator evidence') and the fallback guarantee, which the schema's enum description does not fully convey. However, root_path and llm_timeout_ms are largely restated in schema, so it doesn't reach 5.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Turn a visual description into a read-only build plan.' It clearly distinguishes this from sibling create_* tools by emphasizing 'read-only' and 'creates nothing.' The title reinforces this, 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?

  It explicitly says the deterministic planner is the default and 'creates nothing,' implying use this when you want a plan rather than a mutation. It also gives precise guidance on opting into planner='llm' and describes the bounded, validated, fallback behavior. This tells the agent when and how to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• repair_networkA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations indicate readOnlyHint=false, destructiveHint=true, openWorldHint=true. The description expands on these by detailing the bounded autonomous repair mechanism, dry_run default, known-safe fixes, and risky case handling. 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 concise yet comprehensive, front-loading key information (bounded, autonomous, dry_run). Every sentence contributes value, 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?

  Despite no output schema, the description fully explains return fields and behavior. Given the tool's moderate complexity and rich annotations, the description is complete and covers all necessary 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% with descriptions for all 3 parameters, so baseline is 3. The description adds context like 'Root of the subtree' and 'Hard cap on repair attempts', enhancing understanding beyond 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?

  The description provides a specific verb ('repair') and resource ('network') with clear scope: scanning cook errors under a subtree, classifying, and planning safe fixes. It distinguishes itself from sibling tools like summarize_td_errors and get_td_node_errors by noting its use as a diagnostic 'try the obvious safe fixes' loop.

  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 on when to use: 'Use it as the diagnostic "try the obvious safe fixes" loop after a build; for raw triage use summarize_td_errors / get_td_node_errors instead.' This directly tells the agent when to prefer this tool over alternatives.

  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.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate destructiveHint=true, but the description adds non-obvious behavior: it refuses to write empty/whitespace-only text unless `confirm_wipe:true` is passed, and it requires TDMCP_BRIDGE_ALLOW_EXEC=1 for text writes. This exceeds what annotations provide and is crucial for safe operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action, and each sentence adds unique value: purpose, differentiation, usage, safety guard, and execution context. There is 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 tool is destructive and has environment dependencies, and the description covers all essential aspects: what it does, when to use it, the safety mechanism, and required flags. With fully documented parameters and no output schema needed, this is complete for the 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 value by explicitly referencing the `confirm_wipe` safeguard and tying it to the destructive nature, which clarifies the parameter's significance beyond the schema. However, it doesn't add meaning for the other parameters, which are already well-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 'Overwrite a Text or Table DAT's entire `.text` with new content,' providing a specific verb and resource. It also distinguishes itself from `edit_dat_content` by contrasting whole replacement versus surgical find-and-replace, 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 `edit_dat_content` and states when to use this tool ('use it to deploy a full script or template'). This gives clear usage guidance and alternative identification, satisfying the when-to-use criterion.

  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 annotations (readOnlyHint=false, destructiveHint=false), the description reveals key behaviors: the engine loads once, toggles pars, outputs DATs not CHOPs, requires playing timeline, and has a probe order for source video. 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 fairly long but well-structured and front-loaded with the core purpose. Every sentence provides value, though minor redundancy exists (e.g., 'loads the engine ONCE' and 'Drop... ENGINE in one shot' overlap slightly). Still highly informative 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?

  Given the tool's complexity (8 params, no output schema, many sibling tools), the description covers prerequisites, behavioral constraints (DAT vs CHOP, timeline playing), source detection, idempotency, and differences from related tools. It provides all necessary context for correct 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 description coverage, the description adds significant meaning: clarifies tox_path is the full tracker, not bare processors; explains source_video_path probe order; emphasizes container_name for idempotency; and notes GPU cost for segmentation. These details aid 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 the tool drops the torinmb mediapipe-touchdesigner ENGINE and enables any combination of face, hand, body, and segmentation pipelines. It distinguishes itself from siblings like setup_face_tracking and others by explaining the advantage of a single engine load and avoiding competing COMPs.

  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 running individual setup tools, and warns against using them due to re-loading issues. Also includes prerequisite installation instructions (tdmcp install mediapipe-touchdesigner) and important notes about output types and timeline playback.

  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
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Describes strict atomic update: unknown parameter names fail entirely, bad values return partial success with error details. Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false), but description adds critical atomicity and error 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?

  Three sentences: action, error behavior, usage alternatives. Front-loaded with primary purpose, no fluff. Perfectly sized for a mutation tool with moderate 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 2 required params, nested object, and no output schema, the description covers: what the tool does, error handling, parameter expectations, and complementary tools. No gaps for effective use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema provides 100% coverage for both 'path' and 'parameters'. Description adds value by showing parameter structure as key–value pairs with example 'period: 4, amplitude: 0.5' and linking to get_td_node_parameters for valid names.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Modify an existing node by setting one or more of its parameters to constant values.' Verb 'modify' and resource 'node parameters' are explicit. Distinguishes from sibling 'animate_parameter' (dynamic values) and 'set_parameter_expression' (expression-based).

  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 advises using 'get_td_node_parameters' for inspection and 'animate_parameter' for dynamic values. Provides clear when-to-use and when-not-to-use guidance with specific alternative tool names.

  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?

  Disclosures beyond annotations: auto-mapping heuristics, master knob appending, fail-forward warnings, and fatal conditions. 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?

  Concise yet dense, no filler. Front-loaded with core action, then alternatives, then details. 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 5 params, no output schema, and annotations present, description covers usage, behavior, error handling, and sibling contrasts completely.

  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 100%; description adds auto-mapping heuristic details (bright→level, scale/size→bass, etc.) and clarifies intensity scale. Highly informative.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Make a whole COMP react to the music in one call' with specific verb and resource. Explicitly distinguishes from siblings create_audio_reactive and bind_to_channel.

  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 clear when-to-use vs alternatives, lists prerequisites (produce feature CHOP first), and describes fail-forward behavior. Complete guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• bundle_dependenciesA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations declare destructiveHint=true, and the description adds valuable details: 'Rewriting mutates the live network' and explains the rewiring process. The ability to avoid mutation via rewrite_refs=false is clearly stated, surpassing the basic 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 front-loaded with the main action, then a clear step-by-step breakdown, followed by sibling comparison and a behavioral warning. Every sentence adds value, and the structure is logical 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 complexity (scan, copy, rewrite, save), the description covers all essential aspects: purpose, workflow, parameter roles, side effects, and alternatives. The output schema is present, so return value details are not needed. Comprehensive for an agent.

  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% with parameter descriptions, but the description enriches understanding by contextualizing each parameter within the workflow. For example, rewrite_refs is explained in terms of its impact on live network mutation, and include_missing is clarified with behavior when missing files.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 make a COMP self-contained by recursively scanning, copying assets, rewriting references, and saving as a .tox with manifest. It explicitly distinguishes from siblings make_portable_tox and collect_project_assets, providing a precise 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly provides when-use guidance by contrasting with sibling tools: 'Delta vs make_portable_tox (which saves the .tox only, leaving external assets behind) and collect_project_assets (which only reports refs).' It also notes the mutative behavior and the option to set rewrite_refs=false for a non-destructive run.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• compact_graph_digestA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds that it uses getNetworkTopology + getNetworkErrors, and lists the exact return shape, 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?

  Four concise sentences, front-loaded with key purpose and behavior. Every sentence adds value: read-only, compress, return structure, underlying methods, comparison to siblings.

  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 output schema, description lists return keys. Covers use case, limitations, and relationship to other tools. Adequate for a tool with 6 optional parameters and no required fields.

  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?

  All 6 parameters have full schema coverage (100%). Description adds context like 'Hard ceiling on approximate output tokens' and 'Include top-3 grouped error keys. Off for purely structural turns.' Enhances understanding 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?

  Clearly states 'compress a TD subtree into a structured digest' with a specific verb and resource. Distinguishes from siblings by referencing get_td_topology / snapshot_td_graph and noting it's cheaper for planning.

  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' and 'no new bridge work. Cheaper than... for planning turns.' Provides clear context for when to use this tool over alternatives, with named sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_color_wheelsA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the internal chain, value ranges, default behaviors, and knob exposure rationale, adding detail beyond the annotations which only indicate non-readonly and non-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 concise at ~150 words, front-loaded with the core purpose, then details and alternatives. No wasted sentences.

  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 output (Null TOP), parameter effects, internal chain, and usage scenarios, fully equipping an agent.

  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?

  Every parameter description adds mechanistic detail (e.g., lift biased gamma1, expose_controls rationale) beyond the schema's type/min/max, enhancing 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 tool creates a classic color-grading wheels chain with three Level TOPs and HSV Adjust. It differentiates from siblings like create_color_grade and 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explains when to use (classic color grading), what happens with optional source, and explicitly names alternatives for simpler or chained effects.

  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?

  Discloses non-obvious behaviors: empty/missing folder returns a working bin without errors, crossfade behavior via ramping Switch index, and that folder reading occurs inside TD. Adds significant value 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?

  Single paragraph is well-structured, front-loading the core purpose, then detailing behavior and differentiation, with no unnecessary 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?

  Provides complete context for a 7-parameter tool with no output schema: main function, edge cases (empty folder), exposed controls, and rubric for selecting between sibling tools.

  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?

  Adds meaningful context to all parameters, such as folder read location, extension format, max_clips cap, and crossfade control, complementing the already detailed 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 function: scanning a folder to build a clip bin with Movie File In TOPs, a Switch, and a Null TOP, and distinguishes it from create_video_player for playlist-based use.

  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 contrasts with create_video_player, directing agents to use create_media_bin for folder ingestion and VJing, making the choice unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_point_cloudA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Describes the entire node creation process (baseCOMP, GLSL buffer, instanced geometry, Camera, Light, Render TOP, Null), mentions potential macOS camera permission, and explains how point positions are computed. This adds substantial value beyond annotations which only show non-read-only and non-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?

  Long but well-structured: begins with core action, then technical detail, node creation, source options, alternative tool, exposed controls, and return format. Every sentence adds value; 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 purpose, how it works, what is created, source options, alternative tool, exposed controls, and return format (summary + JSON). No output schema exists, but description adequately describes return data. Complete for a complex 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?

  Despite 100% schema coverage, the description adds significant meaning: explains the effect of depth_scale (flat sheet to deep relief), point_size (sphere scale via TOP-instancing), and rotation (Y-axis spin). Clarifies source options in more detail than 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 renders a point cloud from a depth/luminance map, distinguishes itself from create_depth_displacement (continuous shaded mesh), and specifies the output is discrete dots. The verb 'render' and resource 'point cloud' are specific.

  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 advises using create_depth_displacement instead for a continuous mesh, and explains when to use each source type (synthetic for testing, file, camera with permission note, existing). Provides clear context for choosing this tool over alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• randomize_controlsA
  5/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses that only numeric custom parameters are affected, non-numeric untouched, and explains amount behavior, complementing annotations (readOnlyHint false, destructiveHint false, openWorldHint true) with specific 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?

  Two brief sentences front-loaded with action and key point, every word 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?

  Comprehensive for a tool with 4 parameters and no output schema; covers purpose, safety, usage, and pairing with other tools.

  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?

  Adds meaningful context beyond schema: comp_path as control-panel container, params defaults to all numeric, amount with blend explanation, seed for repeatability.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 randomizes numeric custom parameters of a COMP within slider ranges for live improvisation, distinguishing from siblings like manage_presets/manage_cue.

  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?

  Describes when to use (instant variation for live improvisation) and when not to worry (non-numeric controls left untouched), and suggests pairing with manage_presets/manage_cue.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.