Server Quality Checklist

Tool Scores

• tex_ematB
  3.2/5.0
  Behavior3/5

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

  With no annotations (readOnlyHint=false is default, no useful info), the description must carry the behavioral burden. It discloses that the tool writes files (writes .emat), that it depends on prior .edds imports, and that it reads .edds.meta GUIDs. However, it does not disclose the overwrite behavior, error conditions (e.g., missing .edds), or what happens on failure, though the overwrite parameter exists in schema.

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

  Conciseness3/5

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

  The description is a single dense paragraph of two sentences, which is reasonably economical. However, it mixes workflow context, technical mechanics, and parameter semantics in a compact run-on structure without clear separation. It is not front-loaded with the primary action verb; 'Phase 2' precedes the actual tool function, making the intent less immediately scannable.

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

  Completeness2/5

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

  This is a file-writing (mutation) tool with no annotations and no output schema, operating within a complex multi-phase pipeline. The description should clarify prerequisites (that .edds must exist first), error states, and the overwrite behavior—none of which are covered. The 3 undocumented remaining parameters and the tool's role in a multi-step workflow leave the agent under-informed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need 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 for 5 undocumented parameters. It partially does: family is explained (determines shader template), and it implies name/sub_path relate to file generation. But overwrite and addon_dir have zero explanation, and the description doesn't map which parameters are involved beyond family. The description adds some meaning but leaves gaps for 3+ parameters.

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

  Purpose4/5

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

  The description clearly states the tool writes .emat files ('Phase 2: .emat schreiben') after PNGs are imported to .edds by the workbench, reading GUIDs from .edds.meta and wiring real .edds references. The family parameter role is explained (determines shader template). While it lacks an explicit verb+resource target contrast with siblings, the purpose is specific and technical.

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

  Usage Guidelines3/5

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

  The description implies a sequential workflow ('Phase 2', 'nachdem die Workbench...') and states the family choices (metall/stoff/foliage). However, it does not explicitly contrast with sibling tools like tex_material or tex_generate, nor does it state when NOT to use this tool. The phase-ordering context is useful but not elaborated.

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

• tex_generateB
  3.2/5.0
  Behavior3/5

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

  Annotations show readOnlyHint: false (not read-only) and no destructive/idempotent hints, so the description carries the burden. The description does disclose the key behavioral trait: it writes to a free folder rather than to addons ('kein Addon-Schreiben'), which is non-destructive behavior worth noting. However, annotations contradict in nuance - readOnlyHint:false suggests mutation, but the 'kein Addon-Schreiben' implies it doesn't modify project state. Given no annotations cover write behavior, the description provides modest transparency but lacks detail on what happens on repeated runs.

  Agents need to know what a tool does to the world before 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, compact and informative. Each sentence earns its place - one states the deliverable and scope, the second provides the pipeline context and purpose. No filler or redundancy. Slightly under-specified on params but structurally 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?

  For a tool with 0% schema coverage, no output schema, and no annotation support for behavior, the description is minimal. It captures the main purpose (generate maps + contact sheet to a free folder) and intended use (experiments/inspection). However, given 4 params are entirely undocumented, and the tool is a pipeline with potential for significant behavior, the description feels incomplete for guiding an agent through correct invocation. The reference to tex_material being 'the same pipeline' helps but assumes agent familiarity.

  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 provides NO parameter-level information. The schema itself only lists param names (source, preset, out_dir, overrides) with generic titles and no descriptions or enums. The description mentions 'Gleiche Pipeline wie tex_material' which implies presets/sources work like that sibling tool, but doesn't explain what values these parameters accept, formats, or relationships. For a 4-param tool with zero schema coverage, the description should compensate significantly but doesn't.

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

  Purpose4/5

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

  The description clearly states it generates Maps + a contact sheet into a free folder (not addon-writing). The verb 'erzeugen' (generate) plus the specific deliverable (maps + contact sheet) is specific. It references the same pipeline as tex_material, which gives some sibling differentiation context, though it could be clearer on exactly what distinguishes it from tex_material itself.

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

  Usage Guidelines3/5

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

  The description mentions it's for experiments and visual inspection ('fuer Experimente und Sichtpruefung'), which implies a use case. It also contrasts with 'kein Addon-Schreiben' which implicitly distinguishes it from writing tools. However, it doesn't explicitly state when NOT to use this vs tex_material or tex_emat, leaving the boundary somewhat implied.

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

• tex_materialA
  3.5/5.0
  Behavior3/5

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

  Annotations are minimal (readOnlyHint false, no idempotent/destructive hints), so the description carries the burden. It discloses the important behavioral trait that this step deliberately skips .emat creation, which is valuable sequencing info. However, it doesn't mention whether overwrite behavior is destructive, what happens to existing staged files, or whether the operation is reversible — gaps for a mutating tool with no annotation coverage on 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.

  Conciseness3/5

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

  The description is a single dense paragraph that packs a lot of information but is not front-loaded or scannable. It buries the overrides example (the most schema-compensating content) at the end. The German terminology mixed with English makes parsing harder. It's efficient in word count but poorly structured for quick comprehension.

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

  Completeness3/5

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

  The tool has 7 parameters with 0% schema coverage and no output schema, so completeness burden is high. The description covers the pipeline stages and the overrides format, plus the critical .emat sequencing note. But it omits return behavior (contact sheet format?), error conditions, and meaning of half the parameters. Given 7 params and no schema enrichment, this is only partially complete — adequate but with notable gaps.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meaning. The description does explain the 'overrides' parameter with a concrete example ({'roughness.base_rough': 0.5}) and dotted-path semantics, which is genuinely helpful. However, it provides no explanation for the other 6 parameters (source, preset, addon_dir, name, sub_path, overwrite), leaving the agent to infer them from 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 clearly states what the tool does: it processes a source texture end-to-end through presets (metall/stoff/foliage), packs to Enfusion formats (BCR/NMO/Opacity), and stages atomically into the addon with a channel contact sheet. However, it heavily uses German technical jargon ('Quelltextur', 'atomar ins Addon gestaged', 'Kanal-Kontaktblatt') that may reduce clarity for English-speaking agents, and it doesn't explicitly contrast with sibling tools like tex_emat or tex_generate in the purpose statement.

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

  Usage Guidelines4/5

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

  The description provides clear sequencing guidance: it explicitly states it does NOT write .emat and instructs that tex_emat should be called after workbench import creates .edds files. This gives strong when-to-use and what-to-do-next context. However, it doesn't explicitly name sibling tools like tex_generate or tex_inspect for specific exclusion scenarios, though the pipeline framing makes the flow reasonably clear.

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

• tex_inspectA
  3.6/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe-read nature is covered. The description adds meaningful context: that the tool doesn't need a viewer and that it reports neutrality hints. However, it doesn't disclose the return format, whether it prints to console or returns structured data, or behavior on missing/invalid images. With annotations covering safety, this is acceptable but not rich.

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

  Conciseness4/5

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

  The description is a single, dense sentence with a clear purpose and a parenthetical rationale. It's front-loaded with the core capability (channel statistics per RGBA) followed by the use case. No wasted words, though the German language and nested clauses make it slightly dense. Efficient for a one-parameter tool.

  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 (1 param, read-only, no output schema, no nested objects), so the description covers the essential purpose well. It explains the neutrality-hints feature and the reason viewers are misleading. The main gap is lack of detail on parameter format/expected input and output presentation, but for a read-only inspection tool these are minor. Adequate for the complexity level.

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

  Parameters3/5

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

  There's only 1 parameter (image) and schema description coverage is 0%. The description doesn't elaborate on the image parameter beyond the tool's overall purpose—no mention of supported image formats, whether it accepts file paths vs base64, or constraints. The single parameter's semantics are largely inferable from the tool's purpose, but given 0% coverage, the description should have specified the expected format.

  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+resource: inspecting image channel statistics (min/max/mean per R/G/B/A) plus neutrality hints. It clearly distinguishes itself from siblings (tex_material, tex_generate, tex_emat, tex_params) by referencing BCR/NMO/masks inspection without a viewer. It could be considered slightly verbose but purpose is distinct.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use it: to verify generated BCR/NMO/masks without a viewer, because viewers misinterpret data-alpha as transparency. This explains a specific usage scenario that distinguishes it from the sibling texture tools. It doesn't explicitly say when NOT to use it, but the context is clear and actionable.

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

• tex_paramsA
  3.9/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the agent knows this is a safe, deterministic read. The description adds the behavioral detail that field names serve as override point-paths, which explains how output maps to other tools' usage. Given annotation coverage, the description adds meaningful extra context.

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

  Conciseness5/5

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

  The description is a single, dense sentence that conveys purpose, scoping, output format, and a critical coupling detail (field names = override paths). Zero wasted words. Impactful and front-loaded.

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

  Completeness4/5

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

  For a simple reference-lookup tool with one optional parameter, strong annotations (readOnly, idempotent), and no output schema, the description covers the essential needs: what it returns, the three preset scopes, and how output connects to the override system. The one gap is that the preset parameter's accepted values are only implied, not enumerated, but this is a minor gap for such a low-complexity tool.

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

  Parameters4/5

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

  There's one parameter (preset) with a default of null, and schema description coverage is 0%. The description compensates by stating presets are metall/stoff/foliage, making it clear the preset parameter filters among these named options. This adds meaning beyond the bare schema. A brief mention that preset accepts these three values explicitly would push it to 5, but the enums are inferable from the description.

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

  Purpose4/5

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

  The description states it returns all presets (metall/stoff/foliage) with all parameters and defaults as JSON, and clarifies field names double as valid override point-paths. This clearly defines the resource (presets) and the output format. It doesn't explicitly contrast with siblings like tex_generate or tex_inspect, but the description is specific enough about what it returns.

  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 conveys that this tool provides parameter reference data for the presets and that field names serve as override paths. This implies it's for lookup/reference purposes before generating or inspecting materials, but no explicit when-to-use vs alternatives (e.g., tex_inspect, tex_emat) is given. Sibling differentiation is only implicit through the output being reference data.

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

• tex_packA
  4/5.0
  Behavior4/5

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

  With no annotations to rely on, the description discloses key behaviors: inverting smoothness to roughness, supporting two normal_y conventions, neutrally filling missing maps, and reporting warnings. It does not explicitly mention file writing or overwrite behavior, but the transformative details are substantial. It stops short of full transparency regarding filesystem 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 dense sentence with many meaningful details, but it is somewhat run-on. It is not overly long and every phrase adds value, though breaking it into structured points would improve readability. It earns a 4 for efficiency without being bloated.

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

  Completeness4/5

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

  The description covers the core behavior: input maps, output format, transformations, normal_y options, and missing-map handling with warnings. There is no output schema, so it partially explains what the tool produces. It does not mention return values or file structure, but for a packing tool, the operational context is mostly complete.

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

  Parameters2/5

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

  The input schema has 0% description coverage, so the description must compensate. It explains 'normal_y' with its directx/opengl options, but does not describe 'maps_dir', 'out_dir', or 'name'. The description implies the output format and missing-map handling, but fails to clarify three of the four parameters.

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

  Purpose5/5

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

  The description clearly states the tool's function: packing manually created Materialize single maps into Enfusion BCR/NMO format, with specific transformation details. The verb 'packen' and the resource 'Einzelmaps' make the purpose unambiguous and distinct from sibling tools that generate or inspect textures.

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

  Usage Guidelines4/5

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

  The description implies usage context: it is an ingest bridge for maps manually created in Materialize with specific suffixes. It does not explicitly name alternatives or exclusions, but the context is clear enough to infer when this tool applies. No explicit 'when not to use' is given, hence not a 5.

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