Server Quality Checklist

Tool Scores

• asset_listC
  2.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('list') but does not explicitly state that, nor does it mention any side effects, permissions, or return behavior. The lack of detail on pagination, filtering, or error conditions leaves the agent without key information.

  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 extremely short and front-loaded, which is efficient in terms of verbosity. However, it is under-specified to the point of being almost a placeholder. Conciseness is good, but it sacrifices necessary substance, making it only average in this dimension.

  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 one required parameter, no output schema, and no annotations, the description is far from complete. It does not explain what 'provenance' means, what the response format is, any limits or edge cases, or how this tool fits into a workflow. The agent is left with too many unknowns.

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

  Parameters1/5

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

  The schema has 0% description coverage and the description does not explain the 'project_id' parameter at all. The agent must infer its meaning solely from the name, which is insufficient for a required parameter. No format, purpose, or relationship to the output is provided.

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

  Purpose3/5

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

  The description states a clear verb ('list') and resource ('project assets and provenance'), which gives a basic sense of purpose. However, it does not differentiate itself from siblings like 'catalog_inventory' or 'asset_import', which could also involve listing assets. The mention of 'provenance' adds specificity but is ambiguous without elaboration.

  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 exclusions or prerequisites. The description is purely declarative and offers no context about typical use cases or when 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.

• plugin_preset_saveC
  2.3/5.0
  Behavior2/5

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

  No annotations are present, so the description must carry full behavioral disclosure. It only states that a preset ID is returned, but does not explain side effects (e.g., whether the current plugin state is modified, whether the operation is destructive, or whether it requires specific permissions). The vague 'apply a program' wording adds confusion rather than clarity.

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

  Conciseness2/5

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

  The description is extremely short, but conciseness is not a virtue here because it omits critical operational details. The single sentence is under-specified and does not earn its brevity; it leaves too much to inference.

  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?

  Given the high complexity of the input schema (nested objects, arrays, constraints) and the absence of any annotations or output schema, the description is grossly inadequate. It does not explain the meaning of 'program', 'normalized parameters', the plugin object's fields, or how the preset ID is used. An agent would struggle to construct a valid request without additional context.

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

  Parameters1/5

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

  The schema has 0% coverage from the description, and the description only vaguely references 'program/normalized parameters' without explaining the structure of the 'plugin' object, the 'name' field, or the 'tags' field. Required parameters like 'name' and the nested 'plugin' object are not described at all, leaving the agent without guidance on how to populate them correctly.

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

  Purpose4/5

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

  The description clearly states the action (save a named state preset) and the resource (plugin preset), and mentions the return value (preset ID). However, the phrase 'Apply a program/normalized parameters' is ambiguous and does not clearly distinguish this tool from sibling tools like content_bind_preset.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., requiring an existing plugin) or exclusions. The sibling list includes content_bind_preset which may be related, but no differentiation is provided.

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

• project_restoreC
  2.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears the full burden of behavioral disclosure. It mentions 'retaining history,' which implies non-destructive behavior to past revisions, but it does not explain side effects on the current state, permission requirements, or whether the operation is reversible. This is a significant gap for a mutation-like tool.

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

  Conciseness2/5

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

  The description is a single sentence, which is short, but it is under-specified for the complexity of the tool. It lacks essential details about parameters and behavior, so the brevity is not appropriate; it sacrifices needed information for conciseness.

  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 4 required parameters, no output schema, and no annotations, the description must carry a heavy load. It provides only a high-level purpose and omits all operational details, making it inadequate for an agent to call this tool correctly without additional inference.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any of the four required parameters (project_id, base_revision, request_id, revision). It mentions 'previous saved revision' and 'NEW revision' but does not map these to the schema fields. The agent is left completely without guidance on what values to provide.

  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 (restore), the resource (a previous saved revision), and the outcome (a new revision retaining history). It distinguishes from other project tools like project_create or project_apply by specifying that a new revision is created rather than overwriting. However, it does not explicitly name alternatives, so it falls short of a 5.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, conditions, or exclusions. An agent has no information about when project_restore is the appropriate choice compared to project_apply or project_inspect.

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

• batch_renderC
  2.4/5.0
  Behavior2/5

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

  With no annotations, the description bears full responsibility for behavioral disclosure. It reveals two behaviors: 'No implicit cut' and resumability of failed tasks without redoing completed files. However, it omits critical behaviors such as whether the operation is synchronous or asynchronous, what the wait parameter does, authentication requirements, and the nature of the output or job status. These gaps are significant for a complex batch operation.

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

  Conciseness4/5

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

  The description is concise—two sentences with no filler. The purpose is front-loaded, and the behavioral notes are compact. While brevity is a strength, it is too terse given the complexity of the tool, sacrificing essential information. Still, as far as structure, it is efficient and readable.

  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?

  The tool has a highly complex input schema with nested objects (tasks, clips, effects, automation) and no output schema. The description provides almost no context about what mastering entails, expected outputs, job lifecycle, or how to handle errors. An agent would be left guessing at critical details, making this description inadequate for the tool's complexity.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention project_id, tasks, or wait at all. The description provides no guidance on how to structure the tasks array, what each field means, or how the wait flag affects behavior. This is a total failure to aid parameter 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?

  The description clearly states the tool's purpose: mastering multiple source assets in one job. The verb 'Master' is specific and the resource 'source assets' is named. It distinguishes this from single-asset operations by emphasizing 'ONE project job', but it does not explicitly differentiate from sibling tools like batch_render_resume or render_start.

  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 or when-not-to-use guidance is given. The description implies it is for multiple assets but does not mention alternatives or conditions that would favor a different tool. It only provides behavioral notes (no implicit cut, resumability) without connecting them to selection criteria.

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

• batch_render_resumeC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions using a pinned snapshot and task settings, but does not disclose side effects (e.g., whether the original job is updated, whether it creates a new job, idempotency), error handling for missing jobs, or any auth/rate-limit requirements. This is a significant gap for a resume operation.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no fluff. It efficiently communicates the core purpose. However, it is overly brief, sacrificing needed detail, which is a trade-off. Structurally it is well-formed but incomplete.

  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?

  For a tool with 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the parameters, when to use the tool, or what behavioral outcomes to expect. An agent has almost no information to safely invoke this tool correctly. The complexity is low but the missing context is critical.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It does not mention project_id, job_id, or wait at all. An agent cannot infer what these parameters mean or how they relate to the resume operation. The description adds no value beyond the raw 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 states a clear verb ('Resume'), a specific resource ('source-audio batch'), and adds context ('using its pinned snapshot and task settings'). This distinguishes it from sibling tools like batch_render, which would start a new batch, and render_start, which likely handles individual renders. However, it does not explicitly name the sibling it is not, so it is clear but not perfectly differentiated.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. It implies resuming a previously started batch, but does not state prerequisites (e.g., batch must exist, must have a pinned snapshot) or conditions under which to use it instead of batch_render or job_cancel. The agent must infer usage from the word 'resume', which is weak.

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

• effect_indexC
  2.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden. 'Read and store' is ambiguous: it might imply a write operation, but there's no disclosure of side effects, permissions, or reversibility. The note about parameter semantics is vague and does not clarify the tool's operational behavior.

  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 concise at two sentences, but the second sentence is cryptic and adds little value. While brevity is good, it under-specifies key aspects, so it doesn't earn a higher score.

  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?

  Given the tool's complexity (nested schema, many optional fields) and lack of annotations, this description is severely incomplete. An agent cannot infer how to call it correctly, what the expected behavior is, or what the tool returns. It fails to provide essential context.

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

  Parameters1/5

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

  Schema description coverage is 0%, yet the description adds zero explanation of the parameters. The schema is complex (nested plugin object with many fields), but the description only mentions 'plugin parameters and programs' generically, leaving the agent without any semantic guidance for constructing inputs.

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

  Purpose4/5

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

  The description states a clear action ('Read and store') on a specific resource ('plugin parameters and programs'), which is unambiguous. However, it does not differentiate from sibling tools like effect_probe or parameter_annotate, which also deal with plugin parameters, so it's not perfectly 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?

  There is no guidance on when to use this tool versus alternatives. It neither mentions any prerequisite, condition, nor contrasts with other tools. An agent gets no help in deciding between this and the many sibling tools.

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

• effect_probeC
  2.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions returning before/after audio but does not disclose whether the operation is non-destructive, requires specific permissions, or has side effects. It also omits any details about rate limits, state changes, or the nature of the output (format, length). This is a significant gap for a tool that likely renders audio.

  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 and front-loaded with the core action. However, its brevity results in under-specification, omitting critical parameter and usage information. It earns a 3 because it is structurally clean but sacrifices substance for conciseness.

  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?

  Given the tool's complexity (a nested plugin object with many properties), the lack of any parameter explanation, no output schema, and no annotations, the description is severely incomplete. An agent would not know how to fill the required 'plugin' and 'path' fields, what the audio output looks like, or how to handle edge cases. The description fails to provide enough context for safe and correct 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?

  The schema has 0% description coverage, so the description must compensate by explaining the parameters. It does not mention 'plugin' or 'path' at all. The plugin object is complex with many nested fields (preset_id, automation, parameters, state_base64, etc.) and the description provides no guidance on how to construct or use it. The agent is left with only type names, which is insufficient for correct invocation.

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

  Purpose4/5

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

  The description states a specific verb ('Render'), resource ('effect'), and output ('before/after audio'), making the tool's core function clear. It does not explicitly differentiate from sibling tools like sound_probe or effect_search, but the focus on rendering an effect for assessment is fairly distinct. The purpose is not tautological and adds meaningful action.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives such as sound_probe, instrument_probe, or effect_search. No mention of conditions, exclusions, or typical scenarios. The description simply states what it does without contextualizing it against siblings, 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.

• plugin_verifyC
  2.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full behavioral disclosure. It mentions two actual renders, which implies resource usage, but does not state whether the operation is read-only, whether it modifies the plugin or its state, what happens to the plugin, or what the output format is. 'Records version/platform/binary and distinct untested capabilities' is vague about 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, concise sentence that front-loads the core purpose. There is no filler, but it may be too terse given the tool's complexity; nevertheless, for conciseness it is well-formed.

  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?

  Given the complex input schema (nested objects, multiple optional fields), the lack of an output schema, and no annotations, the description is grossly inadequate. It does not explain what constitutes a successful verification, what 'distinct untested capabilities' refers to, or any prerequisites for the plugin object. An agent cannot reliably call this tool correctly based solely on this description.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides zero information about the 'plugin' parameter or its nested fields. An agent would have to rely entirely on the schema, which is complex (with nested objects for automation, parameters, state_base64, etc.), but the description adds no semantic guidance about how to construct or use these fields.

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

  Purpose4/5

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

  The description states a specific action ('load and state roundtrip test') and the resource (plugins/instruments), and mentions recording version/platform/binary. It is clear about what the tool does but does not explicitly differentiate from sibling tools like plugin_inspect or plugin_preset_save, though the intent is evident.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. The phrase 'isolated load and state roundtrip test' implies a testing scenario, but there is no explicit routing to this tool over others.

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

• asset_importC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the asset is immutable and that hashing/analysis occurs, but it does not disclose side effects (e.g., whether existing assets are overwritten), required permissions, error handling, or the return value. This is a significant gap for a mutation-like operation.

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

  Conciseness4/5

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

  The description is compact: two sentences, with the core action in the first sentence and a constraint in the second. It is front-loaded and wastes no words, though the second sentence is tangential to the primary purpose.

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

  Completeness2/5

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

  For a tool with three required parameters and no output schema, the description is incomplete. It does not explain the expected path format, how the role affects processing, what happens on conflict, or what the tool returns. An agent would need to guess or inspect other tools to safely invoke this.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no explanation of the parameters. It does not clarify what 'path' should point to, how 'project_id' is used, or the implications of each 'role' value beyond listing them. The description adds almost no value beyond the bare 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 states a specific action ('Copy') and a specific resource ('immutable source/reference/artwork into the project'), and mentions additional behaviors (hash and analyze). This is clear enough to distinguish from generic import tools, though it does not explicitly name sibling tools like project_import or asset_relink.

  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 includes a constraint ('Reference audio is forbidden as render input') but gives no guidance on when to use this tool versus alternatives. It does not mention scenarios where another tool should be preferred, nor does it state prerequisites or typical use cases.

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

• catalog_feedbackC
  2.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. 'Store' implies a write operation, but the description does not mention side effects, idempotency, permissions, or what happens if a record already exists. It lacks any behavioral context beyond the basic action.

  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 concise sentence with no redundancy, which is efficient. However, it is under-specified, sacrificing necessary detail for brevity. It is not verbose, but it fails to convey essential usage information.

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

  Completeness2/5

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

  With 4 required parameters, no annotations, and no output schema, the description is far from complete. An agent cannot infer what record_id should be, what reviewer format is expected, what comment should contain, or what the tool returns. The minimal description does not adequately cover the tool's complexity.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain the parameters. It only mentions 'one exact probe/assessment' but does not define record_id, reviewer, comment, or the meaning of preference values. The enum is in the schema, but the description adds no context about their semantics or relationships.

  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 verb 'Store' and resource 'user preference for one exact probe/assessment', and explicitly differentiates from a global plugin prohibition, which helps distinguish it from sibling tools like plugin_verify. However, it does not clarify what constitutes a 'probe/assessment' or what record_id refers to, 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 Guidelines2/5

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

  There is no explicit guidance on when to use this tool versus alternatives. The phrase 'not a global plugin prohibition' hints that another tool might handle global settings, but it does not name it or provide conditions for selection. No when-to-use or when-not-to-use guidance is present.

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

• instrument_probe_resumeC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (resume) but does not disclose side effects, such as whether the operation is idempotent, whether it affects successful tasks, or what happens to the batch state. For a mutation tool, this is a significant gap; the agent cannot anticipate the outcome or 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, succinct sentence with no filler or redundant phrasing. It front-loads the core action and object. While minimal, it is appropriately sized for a one-parameter tool, though it sacrifices necessary context 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?

  The tool is a resume operation with a single parameter and no output schema. The description explains the basic action but does not cover crucial context: how to identify the batch, what happens to the tasks, whether it is safe to call multiple times, or what the expected outcome is. For a mutation tool with no annotations or output schema, this is incomplete.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description adds no meaning to the job_id parameter beyond what the schema already provides (a UUID). The description does not explain how job_id relates to the probe batch, how to obtain it, or any format or usage details. The description fails to 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.

  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 ('resume') and a specific resource ('failed/pending tasks in an existing probe batch'). It distinguishes itself from generic resume tools by naming 'probe batch', though it does not explicitly contrast with siblings like batch_render_resume or catalog_inventory_resume. The purpose is clear and actionable, but not maximally differentiated.

  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 scenario (resuming after a probe batch has failed/pending tasks) but provides no explicit guidance on when to use this tool versus alternatives like instrument_probe or batch_render_resume. There is no mention of prerequisites, preconditions, or typical usage patterns. The agent is left to infer the appropriate context.

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

• sound_probeC
  2.6/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It mentions the output (local audio path and hash) and one constraint ('No model/provider configuration'), but does not disclose side effects, safety (e.g., whether it is read-only), or any potential performance or resource implications. For a render operation, this is a notable gap.

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

  Conciseness4/5

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

  The description is concise at two sentences, front-loading the primary purpose and following with a key constraint. It wastes no words, though it could have used the second sentence to convey more behavioral or usage context rather than a minor configuration note.

  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 input schema (nested plugin object, automation, parameters) and the absence of an output schema, the description is incomplete. It does not explain how to construct a valid request, what the returned hash is for, or any side effects. An agent would need to infer most details from the schema, which has no descriptions.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate for the nested plugin object and other parameters. It does not mention bpm, pitches, velocity, or any plugin subfields like preset_id or parameters. The only hint is 'preset audition,' which loosely implies a preset_id, but it provides no meaningful semantic detail for any parameter.

  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: 'Render a short preset audition and return a local audio path and hash for the calling AI to review.' This is a specific verb (render) and resource (preset audition) with a concrete outcome. However, it does not explicitly distinguish itself from siblings like sound_audition_in_context, which may serve a similar audition purpose, so it misses the top score.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to use this tool versus alternatives. It only implies a lightweight audition use case via 'short preset audition' and 'No model/provider configuration,' but does not state when to choose this over sound_audition_in_context or other sibling tools. 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.

• catalog_discoverC
  2.7/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the behavioral burden. It states the tool does not load plugins, which is a useful non-destructive trait, but it does not mention permissions, side effects, or what happens if loading occurs later. Minimal but not misleading.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 short sentences, front-loaded with the main action and a next step. It is efficient with no wasted words, though it could include parameter guidance without sacrificing brevity.

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

  Completeness2/5

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

  With four parameters, one required, and no output schema, the description lacks parameter explanations, usage guidance, and return details. It is insufficient for an agent to correctly call this tool, especially given the 0% schema coverage.

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

  Parameters1/5

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

  Schema coverage is 0%: the description does not explain any of the four parameters (format, limit, offset, search_path) despite one being required and having an enum. The description adds no semantic meaning beyond the schema, failing to help an agent understand parameter usage.

  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 (list) and resource (plugin candidate locations) and adds a key qualifier (without loading them). It is specific and distinguishes from loading operations, though it does not explicitly name sibling tools 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?

  The description gives only an implied sequence with 'Scan individual candidates next,' but no explicit guidance on when to use this tool versus alternatives like catalog_scan or catalog_search. There is no when-not-to-use or exclusion criteria.

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

• content_searchC
  2.7/5.0
  Behavior3/5

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

  With no annotations at all, the description carries the burden of behavioral disclosure. It usefully warns that discovered files are not certified loadable or auditioned, which is valuable context beyond the schema. However, it does not describe read-only behavior, return shape, or any 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 extremely concise, with the main action front-loaded and the critical limitation stated in a separate short sentence. Every sentence adds information, though more structure could have added parameter guidance.

  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 no output schema, no annotations, and four undocumented parameters, the description is too thin. It tells the agent what content is returned but not how parameters influence results, what the return format looks like, or when to choose this over sibling search tools.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention any of the four parameters (query, family, limit, offset). The agent gets no added meaning about how these parameters control the search, so the description fails to compensate for the missing schema descriptions.

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

  Purpose4/5

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

  The description uses a specific verb ('Find') and a specific resource ('library/patch-level candidates and host plugin links'), making the core purpose clear. It does not explicitly differentiate itself from sibling search tools like catalog_search or sound_search, so it falls short of a 5.

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

  Usage Guidelines2/5

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

  There is no guidance about when to use this tool versus the many sibling search tools. The caveat about files not being certified is helpful, but it does not explain when content_search should be preferred over alternatives.

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

• instrument_probeC
  2.7/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the behavioral disclosure burden. It does disclose useful job semantics: bounded batch, atomic job scope, and safely resumable/retryable processing. However, it never states whether probing is read-only, what side effects it has, whether it is asynchronous and returns a job ID, or what the output payload looks like.

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

  Conciseness4/5

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

  The one-sentence description is concise, front-loaded with the core action and scope, and contains no redundant phrasing. It earns its two clauses; the only cost is that the brevity leaves out needed operational 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?

  The tool has a large nested plugin schema, no output schema, and no annotations, so the description needs to explain the job workflow, required plugins structure, and return behavior. It covers only the high-level batching and retry semantics, leaving an agent without enough information to safely invoke a 5-parameter tool with required nested plugins.

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

  Parameters1/5

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

  With 0% schema description coverage, the description was expected to explain the five parameters, but it only loosely references 'preset batch.' bpm, pitches, velocity, max_seconds, and the required plugins object are left undefined in both schema and description, so an agent cannot know valid units or how to construct a request.

  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 names a concrete operation ('probe'), a bounded scope ('preset batch'), and a job-based execution model ('in one job'), so an agent can tell this starts a batch probe rather than a single-item inspection. It still relies on the tool name for the 'instrument' context and never defines what a probe returns, so it is not fully self-contained.

  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 about when to choose this tool over siblings such as instrument_probe_resume, effect_probe, or sound_probe. The phrase 'retry/resume preserves completed tasks' hints that the tool is job-oriented, but the agent is left to infer that instrument_probe_resume would be the follow-up tool.

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

• knowledge_searchC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses one trait—that results retain evidence type and unreviewed probes are not AI listening results—but says nothing about read-only behavior, permissions, performance, or limitations. This is minimal disclosure for a search tool with no annotation safety hints.

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

  Conciseness5/5

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

  The description is two sentences with no filler. It leads with the core purpose and adds a valuable behavioral note, all without wasted words. It is appropriately sized 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?

  Given the tool has three parameters, no output schema, and no annotations, the description is incomplete. It lacks parameter explanations, usage context, and any differentiation from the many sibling tools. An agent would struggle to call this correctly without additional external knowledge.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning the description offers no explanation for any of the three parameters (kind, limit, query). The agent receives no guidance on valid values, defaults, or semantics beyond the schema itself, which is insufficient for a tool with an enum parameter and limits.

  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 searches stored parameters, probes, and assessments, giving a specific verb and resource. It also adds a distinguishing nuance about evidence types and unreviewed probes, but it does not explicitly contrast with sibling search tools like sound_search or effect_search, so it lacks sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or related tools, leaving the agent to infer the use case from the resource names alone.

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

• mixer_inspectC
  2.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It does disclose two behavioral traits: the operation is read-only ('Read') and runs without a GUI. However, it does not mention permissions, error behavior, or whether the operation is blocking. These traits are useful but incomplete for a tool with zero annotation coverage.

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

  Conciseness4/5

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

  The description is a single concise sentence that front-loads the primary function. It avoids unnecessary detail and is easy to parse. However, it is so brief that it sacrifices essential context, which is a structural trade-off rather than an efficiency gain.

  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 one parameter and no output schema, the description should explain what project_id refers to and what kind of result is returned. It does neither. The agent knows what is read but not how to invoke it correctly or what to expect, making the description incomplete.

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

  Parameters1/5

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

  The schema has no property descriptions and the description does not mention project_id at all. An agent receives no explanation of what project_id represents, its format, or why it is required. With 0% schema description coverage, the description fails to compensate, leaving the parameter entirely opaque.

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

  Purpose4/5

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

  The description clearly states a specific verb ('Read') and resource (track strips, sends, FX returns, master chain), which makes the tool's purpose unambiguous. It does not explicitly name sibling tools, so an agent must infer that it is distinct from other inspection tools like plugin_inspect or midi_inspect, but the resource scope is sufficiently unique.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions. An agent has no hints about when mixer_inspect is the right choice over other inspection tools.

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

• effect_searchC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Find') but does not disclose return format, pagination behavior, rate limits, or any side effects. The description is too minimal to inform an agent of what to expect when calling this 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, concise sentence with no filler or redundancy. It directly states the core function, making it efficient for an agent to parse. This is an appropriate length for a search tool, though it sacrifices completeness 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?

  Given the tool has 2 parameters, no output schema, and no annotations, the description is far from complete. An agent would need to know what results look like (structure, pagination, limits) and how the parameters influence output. The description provides none of this, 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?

  The description does not mention either parameter (limit or query), and schema description coverage is 0%. While the schema itself provides defaults and constraints (limit range, query max length), it lacks semantic meaning. The description fails to explain how 'query' and 'limit' affect the search, leaving the agent without essential usage 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 states a clear action ('Find') and a specific resource ('effect records') with a qualifier ('with parameter/effect evidence and current registration'). This distinguishes it from generic search tools, but it does not explicitly differentiate from sibling tools like effect_probe or effect_index, which may serve overlapping purposes.

  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 lacks any conditions, exclusions, or mention of sibling tools that could help an agent decide between effect_search, effect_probe, or effect_index. The only implied usage is for finding effect records, but no explicit direction is given.

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

• project_importC
  2.8/5.0
  Behavior2/5

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

  The description mentions a plugin rescanning prerequisite but does not disclose other behavioral aspects like whether the operation overwrites existing data, if it is idempotent, or any side effects. Since no annotations are provided, the description carries the full burden and falls short.

  Agents need to know what a tool does to the world before calling it. 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 with the primary purpose stated first and an important prerequisite second. There is no redundant or unnecessary 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 tool with nested objects and no output schema, the description is too brief to cover essential nuances such as the expected project data structure, error conditions, or the rationale for the plugin rescan requirement. It leaves significant gaps for an agent trying to understand the tool fully.

  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 phrase 'under a new project ID' adds some meaning to the project_id parameter, but the description does not explain the project parameter or any nested structure. With 0% schema coverage, the description provides minimal value beyond the raw 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 that the tool imports exported project data and creates a new project ID, which distinguishes it from other project-related tools like project_restore. However, it could be more specific about the data format or the difference from project_create.

  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 guidance on when to use this tool versus alternatives such as project_restore or project_apply. It only describes the function 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.

• catalog_inventory_statusC
  2.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden. It discloses a key behavioral trait: 'without running plugin code,' indicating a safe, non-executing read operation. However, it doesn't describe the return format, error behavior, or any side effects. Since it's a read-only operation, this is adequate but not rich.

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

  Conciseness5/5

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

  One concise sentence that front-loads the purpose and key constraint. No redundant words or filler.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is the only source of context. It explains the tool's core function but leaves out critical details: what job_id is, what 'per-candidate failures' refers to, the return format, and when to use it. For a tool with a single parameter and no other documentation, this is incomplete.

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

  Parameters1/5

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

  The schema has a single parameter job_id with 0% description coverage, and the description does not explain what job_id refers to or how it should be used. The agent must infer its meaning from the name alone, which is insufficient. The description adds no value for parameter 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?

  The description states a clear verb ('read') and specific resource ('plugin inventory coverage and per-candidate failures'). It also distinguishes itself by explicitly noting 'without running plugin code,' which separates it from tools that execute plugins. However, it doesn't directly contrast with the sibling tools catalog_inventory or catalog_inventory_resume, so it's not a full 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions. An agent cannot determine whether to pick this over catalog_inventory or other inventory-related tools based on the description alone.

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

• catalog_scanC
  2.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the execution context ('isolated worker') and a limitation ('not render compatibility certification'), but omits details on side effects, failure modes, permissions, or reversibility. It provides some behavioral context but is 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.

  Conciseness4/5

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

  Two concise sentences with no waste. The primary action is front-loaded, and the caveat is placed at the end. It is efficiently 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 (two required parameters, no output schema, no annotations), the description is incomplete. It lacks parameter explanations, return behavior, and clear differentiation from sibling scan tools. The disclaimer is useful but insufficient for an agent to call the tool correctly without additional context.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention either parameter (format or location) at all. It adds no meaning beyond the schema's property definitions, which is a significant gap since the schema only provides the enum and basic type.

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

  Purpose4/5

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

  The description states a specific verb ('scan'), resource ('ONE candidate'), and outcome ('register its plugins'). It is clear and uses 'isolated worker' to hint at a narrower scope than sibling tools like catalog_index, though it does not explicitly name a sibling it is not.

  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 scanning a single candidate and includes a caveat about what success does not certify (render compatibility), but it does not explicitly state when to use this tool versus alternatives like catalog_index or plugin_verify, nor does it provide exclusions.

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

• midi_importC
  2.9/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses that unsupported events require notes_only acknowledgment, hinting at a behavioral constraint, but doesn't mention permissions, reversibility, or return format.

  Agents need to know what a tool does to the world before 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 with no redundancy. It front-loads the main purpose and adds a caveat, maintaining a clean structure.

  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, nested objects, and no output schema, the description is insufficient. It doesn't explain the revision concept, track requirements, or parameter meanings, leaving significant gaps for an agent to fill.

  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%; the description only implicitly references notes_only and instruments. It doesn't explain project_id, base_revision, request_id, path, tracks structure, or adopt_tempo, failing to compensate for the lack of parameter documentation.

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

  Purpose4/5

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

  The description clearly states the action (import), resource (selected MIDI parts), and a key requirement (explicitly assigned instruments) in one revision. It distinguishes from inspection/export tools but doesn't contrast with other import tools like asset_import.

  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 doesn't mention exclusions or conditions, leaving selection to inference from the description alone.

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

• plugin_inspectC
  2.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the read-only intent ('inspect') and the fact that no GUI opens, which is useful. However, it does not mention potential side effects of loading a plugin, required permissions, error behavior, or the exact nature of the output. For a non-annotated tool, this is a moderate gap.

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

  Conciseness4/5

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

  The description is two sentences and very concise, front-loading the core purpose. There is no fluff, but it omits essential details. The conciseness is good, but it sacrifices necessary information for brevity.

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

  Completeness1/5

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

  The tool is complex (a plugin object with many fields, pagination via limit/offset) and has no output schema. The description only provides a high-level summary and fails to explain 'normalized parameter IDs,' 'programs,' or the semantics of the plugin object. The agent lacks enough context to use this tool correctly without additional assumptions.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning the description must explain parameters, but it mentions none. The plugin object, limit, and offset are completely undocumented in the description. The agent must rely solely on the schema, which has many nested fields and constraints, making this a serious deficiency.

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

  Purpose5/5

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

  The description clearly states the tool loads a registered plugin and inspects its normalized parameter IDs and programs, which is a specific verb and resource. It also differentiates from siblings like plugin_verify or plugin_preset_save by focusing on inspection rather than verification or saving. The additional note 'No GUI is opened' reinforces its programmatic nature.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives such as plugin_verify or plugin_inspect. The description only states what it does, not the conditions under which it should be chosen over similar tools. The 'No GUI' note hints at a use case but doesn't explicitly direct the agent.

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

• delivery_recoverB
  3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions recovery from a journal, but does not disclose side effects, idempotency, whether it modifies state, whether it requires specific preconditions (e.g., existence of a journal, publication being in an interrupted state), or what the output looks like. For a recovery operation, this is a significant gap that could lead to misuse.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 extraneous content. It front-loads the action and resource, and every word earns its place. It is appropriately sized for a simple 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?

  Given the tool's simplicity (one parameter), the description is still incomplete. It lacks essential context such as when a journal is created, what qualifies as an interrupted publication, whether recovery is safe (idempotent, destructive), and what the expected outcome is. Without annotations or an output schema, the agent is left without sufficient information to correctly invoke and trust the tool. More detail on prerequisites and behavior is needed.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for the parameter. The only parameter, project_id, is not explained in the description—it does not clarify that this is the project whose interrupted publication should be recovered. While the parameter name is self-explanatory to some degree, the description adds no extra meaning or context beyond the raw schema, failing to compensate for the missing schema descriptions.

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

  Purpose4/5

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

  The description clearly states the action (recover) and the resource (interrupted output publication from its journal). It distinguishes itself from siblings like delivery_publish and batch_delivery_publish by focusing on recovery of an interrupted process rather than starting or continuing publication. However, it does not explicitly differentiate from other 'resume' tools like batch_render_resume or instrument_probe_resume, though the context of delivery 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 Guidelines3/5

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

  The description implies usage after an interrupted output publication, but provides no explicit guidance on when to use this tool versus alternatives like delivery_inspect or delivery_publish. There are no stated prerequisites, conditions for use, or exclusions. The intended use is only inferable from the name and brief description, leaving the agent to reason about context.

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

• project_validateB
  3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does add one useful behavioral caveat (no live plugin compatibility), but omits critical details such as side effects, failure behavior (e.g., what happens if dependencies are missing), or whether it is read-only. This is partial 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.

  Conciseness4/5

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

  The description is concise (two sentences) and front-loads the core purpose before the caveat. Every sentence earns its place, but the structure could be improved by explicitly naming the parameter or providing a clearer action verb. Still, it is efficient and avoids redundancy.

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

  Completeness3/5

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

  For a validation tool with one parameter and no output schema, the description is incomplete. It does not state success/failure conditions, error behavior, or whether the operation is read-only. It also lacks guidance on interpreting 'frozen playback.' While it provides the core purpose, an agent may need additional context to call it correctly and handle 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?

  The schema provides only a pattern for project_id with no description, and the tool description does not explain what project_id refers to or how to format it. Since schema_description_coverage is 0%, the description should compensate, but it adds nothing about the parameter, leaving the agent to infer its meaning.

  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 verb ('check') and resource ('assets and plugin dependencies'), and mentions a specific outcome ('return frozen playback when available'). It distinguishes itself from sibling plugin_verify by focusing on project-level validation rather than plugin-specific checks, so an agent can infer 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 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 like plugin_verify or asset_relink. The caveat 'Does not claim live plugin compatibility' implies a limitation but does not say when to prefer this tool over others. An agent must infer usage context from the purpose alone.

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

• render_startB
  3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses asynchronous behavior (poll job_status) and output details (absolute output path), and explains track_id semantics. However, it omits potential side effects, error handling, or impact on existing renders.

  Agents need to know what a tool does to the world before 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 no fluff. The core purpose is front-loaded, and the track_id nuance is efficiently added. 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?

  For a 5-parameter tool with no output schema and no annotations, the description is incomplete. It lacks explanations of project_id, request_id, tail_seconds, and rerender_tracks, as well as error/edge cases. The agent cannot fully understand how to construct a correct call.

  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%, so the description must compensate. It only explains track_id (a stem with track inserts and without master effects). Required project_id and other params (request_id, tail_seconds, rerender_tracks) are unexplained, leaving the agent without needed semantics.

  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?

  States a specific action ('Start offline WAV rendering of a fixed revision') with a clear resource. It also clarifies track_id behavior, which helps distinguish from batch_render, though it doesn't explicitly name alternatives. The purpose is unambiguous.

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

  Usage Guidelines2/5

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

  Provides minimal context (offline rendering, fixed revision) and a follow-up action (poll job_status), but no explicit when-to-use vs. alternatives like batch_render. No exclusions or prerequisites are stated.

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

• sound_searchB
  3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that results include 'caller assessments' and 'currently registered instrument availability', which are specific behavioral aspects. However, it does not state whether the operation is read-only, requires authentication, or has any side effects. For a search tool this is likely read-only, but that is not explicitly disclosed.

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

  Conciseness5/5

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

  The description is a single, tightly written sentence with no filler. It front-loads the core action and resource. It 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 search tool with no output schema, no annotations, and only two parameters, the description is too thin. It does not describe the return format, how to structure queries, what limit means, or how this search differs from siblings. The agent has no information to make an informed call about parameter values or interpretation of 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 0%, so the description must compensate, but it does not explain how 'query' or 'limit' are used. The description only hints at what the search returns, not what the parameters control. An agent would not know whether 'query' is a free-text search, a filter on assessments, or something else. This is a significant gap given no other documentation.

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

  Purpose4/5

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

  The description uses a clear verb 'Find' with a specific resource 'sound records' and includes distinctive criteria ('caller assessments' and 'currently registered instrument availability'). This distinguishes it from sibling tools like effect_search and catalog_search, though it could be more explicit about what 'caller assessments' means. The purpose is understandable without needing to inspect the schema.

  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 the many sibling search tools (effect_search, catalog_search, content_search, etc.). There is no mention of when this is appropriate, what kinds of queries it best handles, or when to prefer another tool. An agent would have to guess based on the name and brief description.

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

• bundle_importB
  3.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose two important behaviors: 'never substitute missing plugins' and 'includes frozen playback'. However, it does not mention side effects (e.g., whether existing projects are affected, whether the operation is reversible), error handling, or permission requirements. For a mutation tool, this is a moderate 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, concise sentence that front-loads the primary action and includes two key behavioral notes. It has no filler or redundancy, and every clause adds value. It is an exemplar of concise writing for a tool definition.

  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 only two parameters, no output schema, and no annotations, the description is moderately complete. It conveys the core purpose and two behaviors, but it lacks information on return values, error conditions, prerequisites (e.g., that the package must be validated), and what 'frozen playback' entails in practice. For a tool of this simplicity, it is adequate but leaves room for the agent to have questions.

  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%, so the description must compensate. It implicitly references 'project_id' via 'under a new project ID', but it does not explicitly map to the schema's parameters or explain 'path'. There is no mention of format, validation, or constraints for either parameter. The description adds only a slight hint, leaving the agent to infer parameter meaning from the names alone.

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

  Purpose4/5

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

  The description states a specific verb ('import') and resource ('validated portable package') and adds a scoping constraint ('under a new project ID') and a key rule ('never substitute missing plugins'). It is clear, but it does not explicitly differentiate from the sibling tool 'project_import', which could also involve importing a project. The name 'bundle_import' helps, but the description alone doesn't draw the distinction.

  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 such as 'project_import' or 'bundle_export'. It does not state any prerequisites (e.g., that the package must be validated beforehand) or any explicit 'when not to use' conditions. The only contextual hint is the phrase 'validated portable package', which implies a prior validation step, but it is not spelled out.

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

• catalog_inventory_resumeB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing whether it is asynchronous, what side effects occur, whether it blocks, or what the response looks like. This is a significant gap for a mutation-like tool with no other behavioral 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?

  A single, efficient sentence with no filler. It front-loads the verb and purpose and does not waste words. The structure is appropriately concise for the content it provides.

  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 two parameters (one optional) and no output schema, the description is under-specified. It does not explain the meaning of 'pending candidates', the role of max_seconds, or the expected return/behavior. An agent lacks sufficient information to invoke it correctly.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions 'existing plugin inventory job' hinting at job_id, but it does not explain max_seconds at all (e.g., timeout or maximum run time). It adds no meaning beyond the schema's names and defaults, leaving both parameters under-documented.

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

  Purpose5/5

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

  The description uses the verb 'resume' with a specific resource ('pending candidates in an existing plugin inventory job'), clearly stating what it does. It distinguishes itself from siblings like catalog_inventory (which likely starts a new job) and catalog_inventory_status (which checks status), so an agent can tell it apart.

  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 an existing job with pending candidates, but it does not explicitly mention alternatives or when not to use it. It lacks explicit routing to sibling tools such as catalog_inventory or catalog_inventory_status, so the agent must infer the appropriate context.

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

• content_indexB
  3.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the scan is 'bounded' and 'reports gaps, not false completeness', which warns the agent about limitations and output expectations. However, it does not mention side effects, required permissions, or whether the operation is read-only. It adds some value but not comprehensive 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?

  Two sentences with zero wasted words. The primary action and scope are front-loaded, followed by a concise behavioral caveat. Each sentence adds meaningful 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?

  For a tool with 3 parameters and no output schema, the description is incomplete. It omits any parameter semantics, return value expectations, or interaction with registered libraries. The agent cannot reliably construct a correct invocation based on this description alone.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not mention any of the three parameters (root_ids, max_files, max_seconds). The agent is left without any explanation of what these parameters mean or how to use them, so the description fails to compensate for the schema 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 clearly states the action ('Index instrument patches') and the scope ('INSIDE registered libraries'), listing relevant file extensions. It distinguishes from generic indexing tools by specifying 'instrument patches' and 'registered libraries', but does not explicitly name a sibling tool, so it earns a 4 rather than a 5.

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

  Usage Guidelines3/5

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

  It implies usage context: 'registered libraries' tells the agent this requires prior registration, and 'bounded scan' suggests a quick, limited operation. However, it does not state when to use this tool versus alternatives like catalog_index or effect_index, nor does it provide exclusions. The guidance is present but only implicit.

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

• content_register_rootB
  3.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses one behavioral trait: the tool does not move or change files. However, it does not mention whether the root must already exist, whether it indexes or scans the root, whether it requires write permissions, or what the side effects of registration are. This is a partial disclosure, leaving key behaviors unspecified.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 immediately adds a critical constraint ('without moving or changing its files'). Every word earns its place; there is no filler or redundancy.

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

  Completeness2/5

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

  For a tool with three parameters and no output schema, the description is too thin. It does not explain the purpose of registering a root, what prerequisites exist (e.g., does the path need to exist?), how the root integrates with content indexing or search tools, or what the expected outcome is. An agent lacks enough context to safely invoke it without additional probing.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description makes no mention of the parameters (name, path, family). The schema provides basic types and defaults, but the description adds no semantic meaning or context about what each parameter represents or how they interact. With zero coverage, the description must compensate, and it does not.

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

  Purpose4/5

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

  The description states a clear action ('Add an explicit third-party sample library/preset root') and a resource, with a specific qualifier ('without moving or changing its files') that hints at scope. However, it does not distinguish itself from sibling tools like content_discover_roots or content_index, so an agent must infer differences from the qualifier alone.

  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 'without moving or changing its files' implies a use case where the root already exists and should not be altered, but it does not explicitly say when to use this tool over alternatives or list any exclusions. The guidance is implied rather than explicit, and no sibling tools are named.

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

• job_statusB
  3.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. 'Read' implies a non-mutating operation, but it doesn't explicitly state safety or disclose error behavior, output format, or performance implications. Minimal but adequate for a simple read.

  Agents need to know what a tool does to the world before 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 lists the key data types without fluff. Everything 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?

  The description lists the information returned, which is helpful, but lacks details on output format, potential errors, or when to use this over siblings. For a simple status read, it's adequate but not complete.

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

  Parameters2/5

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

  Schema coverage is 0% and the description does not mention the job_id parameter at all. It doesn't clarify what job_id refers to or how to obtain it, leaving the agent to infer from context. The description adds no value beyond the schema's pattern constraint.

  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 reads render progress, errors, finished output, and audio measurements. It distinguishes itself from siblings like queue_status by specifying the types of data returned, though it doesn't explicitly name alternatives.

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

  Usage 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 other status-related siblings like queue_status or batch_render. The context implies it's job-specific, but no exclusions or alternatives are mentioned.

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

• catalog_inventoryB
  3.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful traits: isolation scanning, resumable checkpointing, and fault tolerance for failed plugins. However, it does not mention side effects, permissions, or what happens to the output, leaving some behavioral uncertainty.

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

  Conciseness5/5

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

  The description is two concise sentences with no filler. It front-loads the primary action and quickly covers key behavioral notes, making every sentence earn 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 no output schema and no annotations, the description should clarify return values, job handling, and parameter usage. It covers the core action and fault tolerance but omits usage guidance and parameter details. The lack of return-value information is a significant gap for an agent deciding whether to call this tool.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meaning. It fails to mention 'formats' or 'max_seconds' at all, even though the schema provides defaults and enums. The description adds no insight into how these parameters affect the inventory process, leaving agents to infer from the schema alone.

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

  Purpose4/5

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

  The description clearly states the tool's action: discovering candidates in given formats, scanning each in isolation, indexing parameters/programs, and checkpointing a resumable job. It distinguishes from siblings like catalog_scan by emphasizing isolation and indexing. However, 'candidate' is not explicitly defined as a plugin, though the context of VST3/AudioUnit formats implies it.

  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 want to inventory all plugins in specified formats, and the resumable job suggests a long-running process. It does not explicitly mention alternatives or when not to use it, relying on sibling names for differentiation. There is no guidance on selecting between this and catalog_inventory_resume or catalog_scan.

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

• catalog_searchB
  3.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden. It discloses two non-obvious behaviors: basic GM/builtin candidates are excluded unless include_basic is explicit, and tags on saved presets are user-provided. These go beyond the raw schema and help an agent interpret search results correctly.

  Agents need to know what a tool does to the world before 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 short sentences, each carrying useful information: the search scope, a key default exclusion, and a data provenance note. It is front-loaded with the core purpose and contains no filler or redundancy.

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

  Completeness2/5

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

  With no output schema and no annotations, an agent still lacks crucial invocation context: what fields query searches, exactly how instrument_only behaves, and what the returned results look like. The description gives a good start but is not complete enough for a 4-parameter search 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 0%, so the description must compensate for four parameters. It only meaningfully explains include_basic and gives a hint that tags are user-provided. The query field semantics, instrument_only, and limit behavior remain largely 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 gives a specific verb and resource: 'Find installed plugins and saved presets.' This clearly distinguishes it from many sibling search tools like sound_search, effect_search, and content_search. However, it does not explicitly differentiate from catalog_reference_search, so sibling differentiation is incomplete.

  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 about when to use this tool versus alternatives, and it never names any sibling tools. The only usage-adjacent detail is the default exclusion of basic GM/builtin candidates, which is more of a behavioral note than a selection guideline.

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

• project_createB
  3.2/5.0
  Behavior3/5

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

  The description discloses the tick-based timing system and explicitly states that no music is generated, which adds behavioral context. With no annotations and no output schema, it carries full burden but omits important behaviors like what happens when project_id already exists, whether defaults are applied, or any 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 short sentences where every phrase earns its place. The main verb-resource is front-loaded, followed by a necessary timing convention and a scope-limiting negative guarantee. No 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?

  For a 7-parameter creation tool with no annotations and no output schema, this description is insufficient. An agent doesn't know the creation semantics (overwrite vs error), how defaults interact, what the return value is, or what 'editable' implies for future operations. The timing note is useful but not enough.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only contributes meaning for timing-related parameters ('integer ticks, 960 ticks per quarter note' clarifies length_ticks and bpm context). It does not explain project_id format, name constraints, meter array semantics, duration_frames, or instrument_policy, leaving most parameters undermined.

  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?

  States a specific verb ('create') and resource ('editable project'), with a clarifying detail about timing ticks. It distinguishes itself from project_import/project_restore by emphasizing creation and editability, though it does not explicitly name any 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 Guidelines3/5

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

  'Create an editable project' implies a from-scratch creation scenario, and 'No implicit music generation' sets an exclusion that routes generative-need agents away. However, it does not explicitly state when to prefer project_create over project_import, project_apply, or project_restore.

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

• sound_assessB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden for behavioral disclosure. It states a mutation ('append') but does not mention side effects, permissions, reversibility, failure behavior, or return value. This is a significant gap for a write 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?

  Two sentences with zero waste. The core action is front-loaded, and the conditional guidance is concise. 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?

  For a mutation tool with 8 required parameters, no output schema, and no annotations, the description is far from complete. It omits return behavior, error handling, prerequisites, and semantics for most parameters, leaving agents to guess critical details.

  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%, so the description must compensate for 8 undocumented parameters. It adds meaning for method (via 'metadata_inference') and implies probe_id/audio_sha256 ('tied to exact probe audio'), but leaves description, reviewer, confidence, uses, and tags unexplained. This is insufficient for an 8-param tool.

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

  Purpose4/5

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

  The description clearly states the action 'append' and the resource 'caller or human assessment tied to exact probe audio'. It distinguishes the tool's function from search/probe siblings by focusing on assessment, though it does not explicitly name any 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?

  It gives explicit guidance for the method parameter: 'Use metadata_inference if the audio was not listened to.' This clarifies a key conditional. However, it does not state when to use this tool over alternatives like sound_search or instrument_probe, nor does it provide exclusions.

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

• export_notation_midiB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It does disclose a key behavior: keyswitch notes are excluded and notation output is separated from performance MIDI. Yet it does not clarify what the export produces, whether files are written, what the return payload is, or any 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 dense sentence with no filler. It front-loads the action and immediately conveys the key scope distinction, making it efficient and well-structured.

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

  Completeness3/5

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

  For a one-parameter export tool, the description gives the essential semantic distinction, but it is incomplete in other respects. There is no output schema and no annotations, and the description does not state what the export returns, where it goes, or what 'separately' concretely means operationally.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not mention project_id at all. The parameter is only understandable from its name and schema pattern, so the description adds no semantic value for parameters beyond what the schema already implies.

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

  Purpose4/5

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

  The description states a specific verb and resource: it exports notation pitches while excluding keyswitch notes. It also distinguishes the export from plugin performance MIDI, which helps separate this tool from the sibling export_midi, though it does not name the sibling explicitly.

  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 'separately from plugin performance MIDI' implies this tool is for notation-only exports and not for performance MIDI, giving some usage context. However, it does not explicitly say when to prefer this tool over export_midi 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.

• sound_audition_in_contextB
  3.3/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It does disclose one key behavior: 'without changing the project', which signals a non-destructive operation. However, it omits other potentially important behaviors such as whether playback is triggered, whether the audition is synchronous, or any side effects beyond project state. This is partial transparency for a tool with no annotations.

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

  Conciseness5/5

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

  The description is a single sentence that immediately states the purpose and the key constraint (non-destructive). It is front-loaded and contains no fluff, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the complexity of the nested plugin object with many optional fields, the lack of schema descriptions, and no output schema, the description is insufficient. It does not explain how to specify the preset, what the plugin object represents, or what the tool returns. An agent would need to infer too much about the required parameters and behavior.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description is the only source of parameter meaning. The description does not explain project_id, track_id, or the plugin object structure (including preset_id, automation, parameters, etc.). It only says 'preset' and 'MIDI part', which gives no insight into the required fields. The description fails to 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 states a specific verb ('Audition'), a resource ('preset on an existing MIDI part'), and a clear scope ('in context without changing the project'). It clearly distinguishes this from sibling tools like sound_search (searching) or sound_probe (probing) by focusing on non-destructive auditioning of a preset on a MIDI part.

  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 previewing a preset in a specific context without altering the project, which gives some guidance on when to use it. However, it does not explicitly mention when not to use it or name alternative tools, leaving the agent to infer the boundary between this and similar tools like sound_probe or sound_assess.

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

• job_cancelB
  3.4/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full behavioral burden. It discloses that partial WAV files are discarded, which is a key side effect. However, it does not mention whether cancellation is idempotent, what happens to the job status, or if the operation is synchronous.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 with no filler. The core action and side effect are 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.

  Completeness3/5

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

  The tool is simple (one param, no output schema), so the description covers the primary action. However, it omits usage context (how to obtain job_id) and any mention of return behavior or error cases. Given the lack of annotations, this is a moderate 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 coverage is 0%, so the description must compensate. The only parameter, job_id, is self-explanatory, but the description does not explain its origin or format beyond the schema pattern. It lacks context such as 'the ID returned by render_start' or 'a valid job ID from job_status'.

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

  Purpose5/5

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

  The description states a specific action ('Cancel') and resource ('a render owned by this MCP service'), clearly distinguishing it from sibling tools like render_start (create) and job_status (query). The side-effect note about partial WAV files further clarifies its scope.

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

  Usage 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, or when not to use it. It does not mention that job_id should come from render_start or job_status, nor any prerequisites (e.g., job must be running).

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

• massive_x_preset_importB
  3.4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses validation, state capture, a runtime requirement, and a limitation (no content bundling). This is useful but does not cover side effects, failure modes, or whether the operation is destructive, which would be expected for a no-annotation tool.

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

  Conciseness4/5

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

  The description is a single, well-structured sentence that front-loads the core action and key qualifiers. It avoids unnecessary fluff and is appropriately brief, though it omits parameter details that would add length.

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

  Completeness2/5

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

  Given the complex schema with nested objects, no output schema, and no annotations, the description is insufficient. It does not describe the expected return value, the purpose of each parameter, or the structure of the plugin object. An agent would need to inspect the schema thoroughly and may still be uncertain about calling conventions.

  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%, so the description must compensate. However, it does not explain any of the four parameters (name, path, tags, plugin) beyond hinting that 'local NKS preset' relates to path. The nested plugin object and its required fields (kind, plugin_id) are not mentioned, leaving the agent to infer parameter meaning from the schema alone.

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

  Purpose5/5

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

  The description clearly states the action ('Import'), the specific resource ('a local NKS preset for Massive X VST3 1.7.1 (R0)'), and adds two distinctive behaviors ('validating its product ID' and 'capturing plugin state'). This distinguishes it from siblings like modo_bass_preset_import and plugin_preset_save without 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?

  It provides a key prerequisite ('Requires an installed and initialized plugin') and an exclusion ('does not bundle its content'), but it does not explicitly mention when to use this tool versus alternatives. The tool name and description imply Massive X is the target, but no direct comparison or condition for selecting it over other preset import tools is given.

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

• queue_statusB
  3.4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry behavioral context. It adds one useful trait: 'Connections and job reads stay responsive', implying this is a non-blocking, low-impact read. However, it does not explicitly state read-only, side-effect-free, or any permissions or limits. Some transparency is present but incomplete.

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

  Conciseness5/5

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

  The description is two concise sentences, front-loading the core purpose and adding a behavioral note. Every word adds value, 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?

  For a simple status tool with no parameters and no output schema, the description covers the main behavior and a key operational trait. However, it does not describe what the response will contain (e.g., fields or format), which could leave an agent uncertain about the return value. It is adequate but not fully 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 is empty (0 parameters), so there are no parameter details to explain. The description does not need to add parameter semantics since none exist. Baseline for 0 parameters is 4, and nothing is missing.

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

  Purpose4/5

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

  The description states a specific action ('Show') and resource ('single server processing lane and FIFO waiting operations'), which is clear and distinct. It does not explicitly contrast with siblings like job_status, but the specific focus on server lane and FIFO queue is unique enough to infer its purpose.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives. It does not mention when to prefer queue_status over job_status or other status-related tools, nor any exclusions or prerequisites. The usage context is only implied by 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.

• catalog_portable_exportA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that the export is sanitized and omits local paths, plugin state, binaries, and licenses. However, it does not explain whether the operation writes a file, returns data, is asynchronous, or has any side effects or prerequisites.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler; every word earns its place. It conveys the core operation and key constraints in the most economical way possible.

  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 no annotations, no output schema, and a completely undocumented parameter, the description is insufficient for confident invocation. The content exclusions are helpful, but the missing job_id semantics and lack of operational context such as output format or side effects leave important gaps.

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

  Parameters1/5

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

  The only parameter, job_id, is completely absent from the description, and the schema description coverage is 0%. The schema only provides a string pattern with no semantic meaning, so an agent cannot determine whether job_id is needed, what it refers to, or how it affects the export.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Export') and resource ('sanitized metadata catalog'), and explicitly defines scope by excluding installation paths, plugin state, binaries, and licenses. This clearly distinguishes it from generic export or catalog siblings such as export_project, bundle_export, or catalog_inventory.

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

  Usage Guidelines4/5

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

  The phrase 'portable' and the exclusion list convey a clear use case: creating a shareable, sanitized metadata catalog without machine-specific artifacts. However, it never names an alternative tool or states when not to use this tool, so the guidance is contextual but not explicit.

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

• content_bind_presetA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full behavioral disclosure burden. It does disclose a meaningful limitation—no independent proof of patch identity—but it omits side effects, overwrite/idempotency behavior, required preconditions, and whether existing associations are changed.

  Agents need to know what a tool does to the world before 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 efficient sentences with no wasted words. The primary action and resources are front-loaded, and the important caveat is stated in a separate short sentence.

  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 semantics and the key caveat, but with no annotations and no output schema, it leaves gaps around return behavior, error conditions, and side effects. For a simple linking operation this is acceptable but not 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 description coverage is 0%, but the description compensates by explaining the semantic roles of content_id, preset_id, and probe_id as caller-identified patch, exact saved preset, and actual probe audio respectively. The required 'description' parameter is not explained, and no parameter-specific details are mapped explicitly.

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

  Purpose5/5

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

  The description uses a specific verb ('Link') and clearly identifies the resources: a caller-identified library patch, an exact saved preset, and actual probe audio. The phrase 'Does not claim independent proof' distinguishes it from verification/probing tools in the sibling list.

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

  Usage Guidelines3/5

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

  The description implies this tool is for cases where the caller has already identified the patch, and the disclaimer implies it is not for verification use cases. However, it does not explicitly state when to use it vs. alternatives, nor does it name any sibling verification tool or exclusion condition.

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

• delivery_publishA
  3.5/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden. It discloses that updates are journaled for rollback and explicitly states it does not certify listening quality. However, it does not mention side effects such as overwriting existing deliveries, required permissions, or the exact nature of the validation 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 two concise sentences, front-loaded with the action and deliverables. No redundant phrasing or filler.

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

  Completeness2/5

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

  With five parameters, a nested tags object, no output schema, and no annotations, the description is insufficient. It doesn't explain parameter semantics, return values, or failure modes. The agent would need to rely heavily on schema constraints without understanding the business logic behind each field.

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

  Parameters1/5

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

  Schema description coverage is 0%, meaning the description adds no meaning beyond the raw schema. It mentions 'optional tagged MP3' but does not explain the tags object fields (title, album, genre, etc.) or the purpose of project_id, job_id, artwork_asset_id, or mp3. An agent cannot determine how to fill these parameters correctly from the description 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 action (validate and publish) on a specific resource (current render) and enumerates the deliverables (stems, optional tagged MP3, MIDI, report, delivery ZIP). It distinguishes itself from batch_delivery_publish by focusing on a single render, even though it doesn't explicitly name the alternative.

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

  Usage Guidelines3/5

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

  The description provides a caveat about not certifying listening quality but offers no explicit guidance on when to use this tool versus alternatives like batch_delivery_publish or delivery_recover. The usage context is implied from the name and the single-delivery nature, but the agent must infer selection criteria.

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

• export_midiA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavior. It states the tool writes a file and clarifies what is excluded, but it does not mention side effects, whether the file is saved or returned, or any other operational details. This is a partial disclosure, sufficient for a simple export 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?

  Two sentences with no redundancy. The core action is stated first, followed by a critical exclusion. Every word earns its place, and the structure is front-loaded 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?

  Given the tool's simplicity (one parameter, no output schema), the description is still incomplete. It does not mention how the file is delivered (download, saved path), whether it exports the entire project or a selection, or any limitations of the MIDI type 1 format. Sibling tools like export_notation_midi and midi_inspect suggest more context is needed for an agent to choose 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 0%, so the description must compensate. The only parameter, project_id, is not explained beyond its name. The description does not explicitly state that project_id identifies the project to export, leaving the agent to infer it. This is a gap given the schema provides no descriptive help.

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

  Purpose5/5

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

  The description clearly states the tool writes a Standard MIDI File type 1, specifying the content (notes, tempo, meter) and explicitly excluding plugin sounds/effects. This is a specific verb-resource pairing that differentiates it from export_project (which would include audio/effects) and export_notation_midi (which focuses on notation).

  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 usage by stating plugin sounds/effects are not included, implying this is for MIDI data only. However, it does not name alternatives like export_project or export_notation_midi, nor does it give explicit conditions for when to prefer this tool over them. 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.

• parameter_annotateA
  3.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral burden. It does disclose an important behavioral constraint—'never infer a linear normalized-to-unit mapping'—and implies that evidence is required. However, it does not describe what happens on write, whether the operation is idempotent, or what the response/result looks like.

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

  Conciseness5/5

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

  The description is a single sentence, front-loaded with the core action, and contains no filler. The critical behavioral warning is placed after the main action without unnecessary elaboration, 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?

  For a tool with four required parameters and no output schema or annotations, the description is too thin. It lacks guidance on how to identify a valid snapshot, what evidence should include, whether the operation creates or replaces an annotation, and what happens after invocation. The description is useful but not complete enough for reliable autonomous 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 0%, and the description does not explain the relationship between snapshot_id and parameter_id, the expected format of evidence, or what 'meaning' should contain. The parameter names are suggestive, but the description adds little beyond them and does not compensate for the complete 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 uses a specific verb and object: 'Attach evidenced meaning to a known parameter snapshot'. It clearly identifies both the action and the resource being acted upon, and the added caution about not inferring a linear mapping distinguishes the intent from other parameter-related 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 use case is implied: annotate a known parameter snapshot with meaning and evidence. However, there is no explicit guidance about when to choose this tool over alternatives, no exclusions, and no mention of prerequisites such as whether the snapshot must already exist or whether annotations can be updated.

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

• project_applyA
  3.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers meaningful traits: atomicity, idempotent retries via request_id, and pre-commit plugin state capture. These go well beyond what an agent would assume about a generic 'apply' tool. It falls short of a 5 because it doesn't disclose what happens on a base_revision conflict or whether the operation is reversibile, which are material for a concurrency-aware write 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?

  Three sentences, roughly 30 words, with purpose front-loaded and each sentence earning its place: atomic apply semantics, idempotency guidance, and state-capture behavior. There is no filler, no restatement of schema fields, and no redundant qualification. Appropriately sized for the information it conveys.

  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?

  This is a high-complexity tool — 4 required parameters, 16 operation variants in a oneOf, no output schema, and no annotations — so the description has a large job. It covers the critical invocation semantics (atomicity, unique request_id, retry safety) that an agent needs to call it correctly. Clear gaps remain: the behavior on base_revision mismatch, the response/return value, and how to discover the current revision to pass. Adequate but visibly incomplete 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 0%, so the description must compensate, and it partially does: request_id gains real meaning ('identical retries are safe') and base_revision gains context ('apply at base_revision'). However, operations is only glossed as 'concrete musical edits' despite being the tool's core payload, and project_id receives no semantic support. The description meaningfully explains the two non-obvious params but leaves the most complex one underserved.

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

  Purpose4/5

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

  The description states a specific verb and resource: 'Atomically apply concrete musical edits at base_revision.' The term 'musical edits' plus the tool name clearly distances it from read/probe siblings like project_inspect, and from create/import/restore tools that build or replace projects rather than editing. It loses the fifth point because it doesn't explicitly name or exclude any sibling, so an agent must infer the boundary against related mutation tools like project_restore or project_import.

  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 select this tool versus alternatives such as project_create, project_import, or project_validate. The unique-request_id advice and retry-safety note are invocation hygiene, not selection criteria. There is no mention of when not to use it, no stated prerequisites (e.g., an existing project, a known base_revision), and no named alternative tool.

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

• project_listA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It only says 'List local projects' without disclosing what is returned (names, paths, IDs), whether it scans the filesystem, if there is pagination, or any side effects. The read-only nature is implied but not stated.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose without redundancy, making it highly scannable for an agent.

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

  Completeness3/5

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

  While the operation is simple, the lack of an output schema and annotations means the description is the sole source of return-format information. It does not specify what a 'project' looks like in the output (e.g., name, path, ID), which could leave an agent unsure of how to use the result. A note on the return structure 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?

  The tool has zero parameters, so the description does not need to add meaning beyond the empty schema. The baseline for no parameters is 4, and the description adequately conveys the operation without 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 states a specific verb (list) and resource (local projects), clearly distinguishing it from sibling tools like project_import (imports), project_create (creates), and project_inspect (inspects a specific project). The qualifier 'local' adds meaningful context beyond the name.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus the many project-related siblings (e.g., project_validate, project_restore). It does not mention alternatives or exclusions, leaving the agent to infer the appropriate context from the name alone.

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

• audio_analyzeA
  3.6/5.0
  Behavior3/5

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

  Annotations are absent, so the description must carry the behavioral burden. It clarifies the measurement scope and explicitly excludes LUFS/true peak, which is valuable. However, it does not state whether the operation is read-only, error conditions, or return format. The read-only nature is implied but not explicit.

  Agents need to know what a tool does to the world before 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 purpose and a clear exclusion. 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.

  Completeness3/5

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

  The description covers what the tool measures and what it doesn't, but it does not describe the output/return format, which is absent from the schema. For a measurement tool, the agent might need to know how results are returned (e.g., numeric values, report structure), which is a notable 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?

  Schema coverage is 0%, so the description must explain the 'path' parameter. It specifies that the file must be a local mono/stereo WAV, adding file-type and location constraints not present in the schema. This is essential for correct invocation, though it does not cover path format details.

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

  Purpose4/5

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

  The description states a specific verb 'Measure' and resource 'local mono/stereo WAV', enumerating the metrics (sample peak, RMS, silence, clipping) and explicitly excluding LUFS/true peak. It is clear but does not explicitly differentiate from the sibling 'audio_measure', so it falls short of full sibling 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 provides a clear when-not condition ('This does not measure LUFS or true peak'), telling the agent when not to use it, but it does not name an alternative tool to use for those measurements. It implies usage context but lacks explicit alternatives.

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

• asset_relinkA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the original hash must match exactly and that source/reference role is preserved, which are useful. However, it does not explain whether the existing asset record is overwritten, whether the file is moved or copied, what happens on hash mismatch, or what side effects occur beyond restoring the asset.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 leads with the action and purpose and adds a key behavioral constraint at the end. Every phrase earns its place, and there is no redundant or filler language.

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

  Completeness2/5

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

  For a mutation-like recovery operation with no annotations, no output schema, and 0% parameter coverage, the description leaves important invocation details unexplained: exact meaning of path, how the hash constraint is enforced, whether the original file is consumed, expected failure modes, and what the caller receives on success. It is adequate for tool selection but not 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 0%, so the description is the only source of parameter meaning. It implies that 'path' is the recovery file but gives no explanation of 'asset_id' or 'project_id', no file path semantics, and no detail on how the exact original hash is provided or verified. The description does not compensate for the missing schema documentation.

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

  Purpose5/5

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

  The description states a specific action ('Restore'), a resource ('missing/corrupt collected asset'), and the recovery method ('from a file with the exact original hash'). It also adds a distinguishing invariant, 'Keeps source/reference role unchanged,' which clearly separates it from general import or relink 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 clearly identifies the target scenario: a missing or corrupt collected asset that must be restored from a file. It does not explicitly name alternatives or state when not to use this tool, but the scenario is specific enough that an agent can infer appropriate use.

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

• bundle_exportA
  3.7/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the behavioral disclosure burden. It provides useful scoping detail (included items and exclusions) and a prerequisite (successful render), but does not disclose side effects, whether it creates or overwrites a file, permissions needed, or failure behavior.

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

  Conciseness5/5

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

  The description is compact, front-loaded with the core action and content, and follows with concise exclusions. Every clause adds information and there is no 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?

  For a tool with no annotations and no output schema, the description establishes what is collected and the precondition but omits output format, return behavior, and side-effect visibility. It is usable but leaves several operational questions unanswered.

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

  Parameters3/5

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

  Schema description coverage is 0%, so parameter meaning must come from the description. The phrases 'current project' and 'successful current-revision render' loosely map to project_id and job_id, but the description never explicitly explains the role of each required parameter or their relationship.

  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 ('Collect') and identifies the resources involved: current project, hashed assets, and frozen audio from a render. It also states exclusions (jobs, temp, existing ZIPs), making the tool's boundary clearer. It does not explicitly contrast with sibling tools, though the render-centric scope differentiates it from generic export/import tools.

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

  Usage Guidelines4/5

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

  It clearly states the precondition: the tool is used after a successful current-revision render. The exclusions also communicate what will and will not be included. However, it does not explicitly mention when to prefer this over alternatives such as export_project or bundle_import.

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

• catalog_indexA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the incremental nature and the lack of render compatibility declaration, which are key behavioral traits. However, it omits details about side effects, persistence, errors, or return behavior, so it is only partially transparent.

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

  Conciseness5/5

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

  The description is a single, tightly worded sentence that front-loads the core action and its distinguishing constraint. Every word earns its place with no filler or redundancy.

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

  Completeness4/5

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

  For a zero-parameter tool with no output schema, the description provides sufficient context for an agent to understand the purpose and the primary constraint. It could elaborate on the meaning of 'record' (e.g., persistence, scope) but given the simplicity, it is reasonably complete.

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

  Parameters4/5

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

  The tool has zero parameters and the schema is empty (100% coverage), so there are no parameters to explain. The baseline for zero-parameter tools is 4, and the description adds no irrelevant parameter information, so this score 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 states a specific verb ('record') and resource ('local plugin/preset metadata') with a distinguishing qualifier ('incrementally' and 'without declaring render compatibility'). It is clear about the core action, though it doesn't explicitly name sibling tools for contrast. The unique aspect helps differentiate it from other catalog 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 'incrementally record' and 'without declaring render compatibility' implies when it is appropriate (for incremental metadata capture) and what it avoids (render compatibility declaration). However, it does not explicitly state when not to use it or mention alternatives, leaving the agent to infer context.

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

• project_inspectA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description must disclose behavioral traits. 'Read' implies a non-destructive operation, and the statement about notes being omitted by default discloses a default behavior. However, it does not explicitly state that the tool has no side effects, or mention any prerequisites or error behaviors. The disclosure 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, well-structured sentence that front-loads the primary purpose and then adds the important note about notes. Every word earns its place; there is no redundancy or fluff. It is concise and 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?

  For a simple read tool with two parameters and no output schema, the description covers what is read (revision, sections, harmony, tracks) and the optional notes behavior. It does not detail the return format or error cases, but given the tool's simplicity and the fact that the schema defines the parameters, the description is sufficiently complete 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?

  Schema description coverage is 0%, so the description must add meaning. It does so for include_notes by explaining the default and the rationale for requesting notes. It doesn't explicitly mention project_id, but that is self-explanatory from the schema and the tool's purpose. The description adds value for at least one parameter, which is significant given zero 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 reads 'current revision, sections, harmony and tracks,' giving a specific verb and resource. It distinguishes from editing or import tools by using 'read,' and mentions the default omission of notes, which is a distinct behavior. It doesn't explicitly name siblings but the purpose is clear 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 inspecting project state, and the note about 'request them for precise edits' gives some context on when to include notes. However, it does not explicitly state when to use this tool versus alternatives like project_validate or project_list, nor does it provide exclusion criteria. Guidance is inferred rather than explicit.

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

• batch_delivery_publishA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries full weight for behavioral disclosure. It reveals the formats produced and mentions a 'recoverable release manifest', which hints at recovery semantics. However, it does not mention permissions, idempotency, or how recovery ties into sibling tools like delivery_recover.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 the core action front-loaded and every clause adds a distinct fact: scope, output formats, and recoverability. There is no filler or unnecessary 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 high-level behavior is covered well: completed batch songs, output formats, and recoverability via a manifest. However, the nested tags parameter is not described at all, and without an output schema or annotations, the agent is left without guidance on return semantics or the recovery workflow details.

  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%, so the description needs to compensate. It only hints at 'optional tagged MP3', which relates to the mp3 parameter, but it never names or explains the tags object or its many nested fields. Required identifiers project_id and job_id are left entirely to the schema.

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

  Purpose5/5

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

  The description clearly states a specific verb ('publish'), resource ('all completed batch songs'), and deliverable formats ('WAV/optional tagged MP3/report/ZIP'), which distinguishes it from siblings like batch_render or delivery_publish. The action and scope are 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 conveys the clear precondition that batch songs must be completed and that the operation covers all of them together. It does not explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to recognize this as the batch publishing step.

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

• delivery_inspectA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates a read-only operation ('Read') and clarifies it does not render or convert, but it does not mention potential side effects, permissions, or error behavior (e.g., what happens if called before publishing). This leaves some ambiguity for a mutation-free 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, tightly worded sentence with no filler. It front-loads the core action and qualifiers, 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.

  Completeness3/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 no output schema, the description tells what it does but not what the output looks like, how errors are handled, or what 'server file paths' implies. It is minimally complete but leaves room for an agent to need clarification on return structure and edge cases.

  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 only parameter, project_id, has no description in the schema and is not mentioned in the tool description. Schema description coverage is 0%, so the description should compensate, but it provides no meaning or context for the parameter. The agent must infer that project_id identifies the delivery, which is not explicitly stated.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value 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 ('Read'), the resource ('delivery manifest and server file paths'), and the qualifier 'already published' which distinguishes it from publishing tools like delivery_publish. The phrase 'without rendering or conversion' explicitly differentiates it from rendering tools like render_start, 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?

  It implies usage after publishing ('already published') and contrasts with rendering/conversion tools, but does not explicitly name alternative tools or state when not to use it. The context is clear enough for an agent to infer it is for inspection, but lacks an explicit exclusion or alternative mention.

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

• content_discover_rootsA
  3.9/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly signals a non-destructive read ('Read') and explicitly discloses what it does NOT do ('Does not load instruments or infer licensing'), which is meaningful behavioral context beyond the raw purpose.

  Agents need to know what a tool does to the world before 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 tight sentences with zero filler. The primary purpose is front-loaded, and the scope qualifier (Mac/Windows + user/shared dirs) plus the non-behavior negation each earn their 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 low complexity (no parameters, no output schema, simple read operation), the description covers what the tool does, where it operates, and what it explicitly avoids. It could optionally mention the return format, but for a discovery read this 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?

  The tool has zero parameters and the input schema is empty, so there is nothing for the description to document. Per baseline, 0 params warrants a 4; the description appropriately focuses on behavior rather than parameter details.

  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?

  States a specific verb ('Read') and a precise resource ('NI registered content locations on Mac/Windows and known user/shared directories'). The negation 'Does not load instruments or infer licensing' differentiates it from instrument/plugin siblings. It doesn't explicitly name sibling tools, so it stops short of a 5, but the purpose is unambiguous.

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

  Usage Guidelines3/5

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

  Usage is implied rather than stated: an agent can infer it should call this when it needs the registered content root locations, and not when it wants to index or search content. However, no explicit when-to-use vs when-not-to-use guidance or named alternatives (e.g., content_register_root, content_index) is provided.

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

• audio_measureA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does well by explicitly stating the tool is non-destructive and does not impose a loudness target. It could go further by describing the return format or failure behavior, but the key safety-relevant traits 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.

  Conciseness5/5

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

  The description is compact, front-loaded with the core measurement purpose, and every sentence earns its place. It spends no words on filler and adds a valuable clarification in the second sentence.

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

  Completeness3/5

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

  For a single-parameter, read-only measurement tool, the description covers purpose and safety well. However, there is no output schema and no mention of what the tool returns or how measurements are reported, so an agent cannot fully anticipate the invocation result.

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

  Parameters2/5

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

  The schema has 0% description coverage and the tool description never directly explains the 'path' parameter. The word 'source' weakly implies that the path points to the audio file being measured, but the description does not add meaningful detail about accepted formats, path types, or accessibility.

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

  Purpose5/5

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

  The description uses the specific verb 'Measure' and names precise resources: integrated LUFS, true peak, and loudness range. It also clarifies what the tool does not do, making it easy to distinguish from sibling tools like audio_analyze or sound_assess.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 conveys that this is for measurement only: it does not normalize, edit, or prescribe -14 LUFS. This gives the agent useful exclusion criteria for selecting the tool, though it does not explicitly name alternative tools for normalization or editing.

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

• catalog_reference_searchA
  4/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explicitly states that results do not prove installation, which is a key behavioral limitation. It also describes the catalog as 'source-controlled' and 'observed', indicating data provenance and potential staleness. It does not explicitly state read-only behavior, but the verb 'Search' implies it. The caveat adds significant behavioral context beyond the tool name.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 short, focused sentences. The first sentence front-loads the action and resource; the second adds a concise caveat. There is zero waste or redundancy, making it highly 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 gives the purpose and a key caveat, but it lacks parameter semantics and does not describe the return format. Given there is no output schema and no annotations, the description should provide more detail about what a result looks like and how the parameters affect the search. For a simple search tool with two optional parameters, it is minimally adequate but not fully complete.

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

  Parameters2/5

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

  The schema has 0% description coverage, and the description provides no explanation of the parameters 'query' or 'limit'. The tool name and the word 'Search' imply that query is the search term, but the description does not explicitly map parameters to their meaning or explain how 'limit' controls results. This is a significant gap given 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 action (Search) and the specific resource (source-controlled observed metadata catalog). It further specifies the subject matter (plugin parameters/programs) and includes a critical caveat about installation proof, which distinguishes it from other catalog search tools. This is a specific verb+resource with added nuance.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 results describe metadata and do not prove installation, implying the tool is for reference lookups rather than installation checks. However, it does not explicitly name alternative tools (e.g., plugin_verify) or provide explicit when/when-not guidance, so it stops short of a full exclusion.

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

• modo_bass_preset_importA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the transparency burden. It discloses meaningful behavior: the import is version-checked, state readback verification occurs, and a reusable preset ID is returned. This is more than a minimal description, though it does not cover failure modes or file-handling side effects.

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

  Conciseness5/5

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

  The description is two sentences with no filler. It front-loads the action and resource, then provides the key return behavior. Every word adds value.

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

  Completeness3/5

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

  The description gives a good high-level picture and mentions the output (preset ID), which is useful given there is no output schema. However, the tool has a nested required plugin object and no parameter descriptions, and the description does not explain how to construct that object or what fields like plugin_version and plugin_id mean in this 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 0%, and the description does not explain the parameters beyond implying that 'path' refers to the local .mb2 file. The required nested 'plugin' object, 'name', and 'tags' receive no semantic guidance, so the description fails to compensate for the missing schema descriptions.

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

  Purpose5/5

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

  The description clearly identifies the action (import), the resource (local .mb2 musical preset), and the specific adapter (MODO BASS 2 VST3 2.0.5). This distinguishes it from sibling tools like massive_x_preset_import and plugin_preset_save without needing further context.

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

  Usage Guidelines4/5

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

  The description gives clear context: use this tool when importing a local .mb2 MODO BASS preset. It does not explicitly name alternatives or exclusion conditions, but the file format and plugin-specific adapter make the intended use obvious.

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

• system_capabilitiesA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. 'Report' clearly signals a read-only operation, and the second sentence adds meaningful platform-specific behavior. It does not describe output formatting, but for a zero-parameter informational tool, this is adequate.

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

  Conciseness5/5

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

  The description is two tight sentences with no wasted words. The primary purpose is front-loaded, and the key platform caveat about AU and VST3 is included succinctly.

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

  Completeness5/5

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

  For a zero-parameter tool with no output schema, the description sufficiently explains what it returns: native engine platform and supported features. It even provides a concrete example of platform-specific support. No additional operational detail appears necessary 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 tool has zero parameters, so the baseline is 4. There is no parameter semantic gap, and no parameter documentation is needed.

  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 ('Report') and clearly names the resource: the native engine platform and supported features. It focuses on engine-level capabilities, which distinguishes it from the content and audio sibling tools, but 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 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 discovering engine platform capabilities, but it does not explicitly state when to use it or when not to use it. The AU/VST3 note adds platform context but does not provide alternative routing or exclusions.

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

• project_cleanupA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the safety burden and does so by stating the tool can remove files and by enumerating protected categories. It would be stronger if it explicitly tied removal to dry_run=false, but the behavior of removing only completed job work files is transparent.

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

  Conciseness5/5

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

  Two short sentences; the primary action and scope are front-loaded and the second sentence adds a valuable safety exclusion without 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?

  It is sufficient for selecting the tool but not fully complete for invoking it correctly: the dry_run=false removal path and any result/return behavior are left implicit. Given the destructive potential and absence of annotations, a sentence on dry-run semantics would make it 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 0%, so the description must compensate. 'List or remove' hints at dry_run's role and 'completed job work files' gives domain meaning to project_id, but it does not explicitly map dry_run values to list-vs-remove or describe the project_id scope.

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

  Purpose5/5

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

  The description names a specific verb+resource: list/remove only completed job work files. It disambiguates from the many sibling tools by narrowing the scope to cleanup of completed job work files and explicitly excluding artifacts, source assets, frozen audio, and failed jobs.

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

  Usage Guidelines4/5

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

  It gives clear context: use when the target is completed job work files. The 'Never removes...' sentence provides a when-not boundary, though it does not name alternative sibling tools for artifact or source cleanup.

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

• export_projectA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers the most important trait for an export tool: the precise scope of the output (what is and isn't included). The boundary between portable JSON and full bundles (binaries/libraries) is explicitly drawn, which prevents the agent from assuming the export is a complete project backup. It could add detail on the delivery mechanism or side effects, but the core behavioral characteristic is transparent.

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

  Conciseness5/5

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

  Two tight sentences with zero wasted words. The primary purpose is front-loaded first, and the clarifying exclusion is delivered second. Every clause earns its place — the description states the action, the output format, the included contents, and the excluded contents in under 25 words.

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

  Completeness4/5

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

  For a simple one-parameter tool with no output schema and no annotations, the description covers the essential ground: action, output format, contents, and exclusions. The only notable gap is how the export is delivered (returned inline as JSON vs. written to a path), which is not stated. Overall it is nearly 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 0%, so the description should compensate, but it adds nothing about project_id beyond the schema's pattern constraint. That said, the single parameter is largely self-explanatory — 'project_id' clearly refers to the project to export, and the regex pattern fully documents its format. The compensation gap is minor because the parameter name and schema together convey sufficient meaning; a richer description would add little value here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Export a portable project JSON') and goes further to enumerate exactly what's included (concrete notes and saved plugin states) and excluded (plugin binaries, sample libraries). This clearly distinguishes it from siblings like bundle_export (which would bundle binaries/libraries) and export_midi/export_notation_midi (which export MIDI data, not project JSON). An agent can immediately tell what this tool produces and how it differs from its neighbors.

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

  Usage Guidelines4/5

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

  The 'Does not bundle plugin binaries or sample libraries' sentence conveys the intended use case: this is the tool for a portable, JSON-based project exchange, not for a full asset bundle. This is implicit guidance that helps an agent choose between export_project and bundle_export, though it stops short of explicitly naming the alternative or stating when NOT to use this tool. The context is clear, but exclusions are 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.

• midi_inspectA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It honestly discloses important constraints: only SMF 0/1 are supported, variable tempo is rejected, and unsupported controllers/program changes are reported. It does not explicitly declare side-effect-free behavior, but 'parse' and 'report' strongly imply a read-only inspection.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 short sentences with no filler. Every phrase adds value: the input format scope, what is parsed, what is reported, and a clear rejection condition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 a single obvious parameter, no output schema, and no annotations, the description covers the essential operational behavior: accepted input format, main data extracted, unsupported-event reporting, and a key rejection case. It does not detail output structure or error handling, but for a low-complexity inspection tool this 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?

  The schema only defines 'path' as a string with minLength 1, and schema description coverage is 0%. The description does not explicitly define the path parameter, but 'Parse SMF 0/1' implies that 'path' should point to a Standard MIDI File. This adds some meaning beyond the bare schema, but it does not fully compensate for the lack of any parameter-level 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 uses a specific verb ('Parse') and a concrete resource ('SMF 0/1 notes and timing'), making the tool's function immediately clear. It further distinguishes itself from sibling tools like midi_import and export_midi by emphasizing inspection and reporting of unsupported events.

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

  Usage Guidelines4/5

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

  The description gives clear context: use this tool to parse and inspect Standard MIDI File 0/1 note and timing data, and to detect unsupported controllers/program changes. It does not explicitly name alternatives or exclusions, but the inspection-oriented phrasing sufficiently implies when it is appropriate compared to import/export siblings.

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