Server Quality Checklist

Tool Scores

• utmt-decompile-codeA
  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. It discloses that the tool returns decompiled GML text and is unavailable for YYC-compiled games, which is useful. However, it omits behavioral details such as prerequisites (cliPath), potential failure modes, and whether the data file is modified (though 'decompile' implies read-only). This adds some value but not rich transparency.

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

  Conciseness5/5

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

  The description is two sentences: the first states the core action and output, the second adds a key limitation. Every word earns its place, and the most critical information is front-loaded.

  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 return value and a major limitation, which is helpful given the absence of an output schema and annotations. However, it lacks guidance on when to select this tool over sibling tools and does not mention the optional cliPath context, making it only partially complete for an agent deciding how to invoke it.

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

  Parameters3/5

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

  Schema description coverage is 100%, as all three parameters (cliPath, codeName, dataFilePath) have descriptions. The tool description itself does not add parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description uses a specific verb ('Decompile') and identifies the exact resource ('a code entry from a GameMaker data file') and output ('GML source'). This clearly distinguishes it from sibling tools like utmt-list-entities or utmt-get-entity, which serve different purposes.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool over alternatives. It does not mention 'use when you need GML code' or exclude other cases, and the YYC limitation is the only contextual hint. This leaves the agent to infer usage solely from the tool name.

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

• utmt-searchA
  3.6/5.0
  Behavior4/5

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

  The description discloses key behavioral traits: case-insensitive substring matching and the return format (JSON array with type, index, name). Since no annotations are provided, this is the sole source of behavior. However, it does not mention edge cases like empty results or potential errors, so it is not fully 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 two sentences, front-loaded with the action, and contains no redundant information. It efficiently conveys the core functionality and output format.

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

  Completeness4/5

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

  The description covers the essential aspects of the tool: what it searches, how it matches, and what it returns. Given that there is no output schema, the return format is explicitly stated. However, it does not mention the optional entityTypes filter or behavior on empty results, which are covered in the schema but not in the description. Overall, it is adequate but not exhaustive.

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

  Parameters3/5

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

  The input schema has 100% coverage for parameter descriptions, so the baseline is 3. The tool description does not add any parameter-specific semantics beyond what the schema already provides; it mentions case-insensitive matching which duplicates the query parameter description.

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

  Purpose4/5

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

  The description clearly states the tool's function with a specific verb ('Search'), resource ('entities in a GameMaker data file'), and scope ('by name pattern'). However, it does not explicitly distinguish this tool from sibling tools like utmt-list-entities or utmt-get-entity.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios where a user should choose this over the sibling tools, such as when needing to filter by name rather than list all entities.

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

• utmt-export-entityA
  3.8/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 transparency burden. It discloses important behavioral output details (PNG frames for sprites, ogg/wav for sounds, decompiled .gml for code, PNG for textures). However, it does not mention side effects such as file overwriting, directory creation, or the need for cliPath, leaving some behaviors undisclosed.

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

  Conciseness5/5

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

  The description is three sentences, each contributing necessary information: first states the core action, second lists supported types, third specifies output formats. It is compact, front-loaded, and free of redundant wording.

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

  Completeness4/5

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

  Given the tool's moderate complexity, the description covers essential operational context: supported entity types and their export formats. Minor gaps exist, such as not explaining the role of cliPath or what happens at the output path, but these are documented in the schema, and the description is sufficient for an agent to understand the tool's function.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all five parameters are already documented in the input schema. The description adds no additional parameter-specific semantics beyond what the schema provides, such as the nuance that 'name' can be an index for embeddedtexture (which is already in the schema). Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool's verb ('Export') and resource ('a single entity from a GameMaker data file to disk'). It lists supported entity types and their output formats, distinguishing it from sibling tools like 'utmt-list-entities' or 'utmt-get-entity' by its explicit export-to-disk action.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool (whenever you need to export a single entity to disk) but does not explicitly compare it with alternatives or state when not to use it. Sibling tools like 'utmt-get-entity' or 'utmt-decompile-code' are not referenced, leaving the agent to infer differentiation 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.

• utmt-list-entitiesA
  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 the transparency burden. It discloses the return format ('JSON array with index, name, and brief properties') and supported types, but it omits behavioral details such as CLI dependency, read-only nature, error handling, or pagination limits (which are only in the schema).

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core action and resource. The list of supported types is useful but not excessive; every sentence contributes value without redundant filler.

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

  Completeness4/5

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

  For a simple listing tool with fully documented parameters and no output schema, the description provides sufficient top-level behavior: what it lists, from what, and the general return shape. It does not explain filter/pagination behavior, but the schema already fully covers those parameters, so the description is adequately complete.

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

  Parameters3/5

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

  Schema description coverage is 100%, and each parameter already has a clear description and defaults. The tool description adds little beyond restating the supported entity types, so it does not rise above the baseline expected when the schema is fully self-explanatory.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('List') and resource ('entities of a given type from a GameMaker data file'), making the tool's purpose immediately clear. It also enumerates supported entity types, which distinguishes it from siblings like get-entity, export-entity, and search.

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

  Usage Guidelines3/5

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

  The description implies usage when you need to list multiple entities, but it does not explicitly state when to prefer this tool over alternatives like get-entity or search. No when-not or exclusion criteria are provided.

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

• utmt-get-room-assetsA
  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 of behavioral disclosure. It clearly describes the output content (sprites, objects, code, layers) but does not mention that this is a read-only operation, return format, potential error conditions, or performance implications. It adds some value beyond the schema but lacks rich behavioral context.

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

  Conciseness5/5

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

  The description is concise, with two sentences that front-load the purpose ('Get all assets used in a room') and enumerate key output categories. The second sentence adds practical value about efficiency ('One call replaces multiple round-trips') without redundancy. Every phrase earns its place.

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

  Completeness4/5

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

  For a compound tool returning multiple asset types, the description does a solid job of enumerating the contents and even includes details like dimensions and object associations. It does not describe the exact output structure (e.g., JSON fields), but the absence of an output schema makes this a minor gap. The tool's complexity is high, yet the description is reasonably complete for an agent to know what to expect.

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

  Parameters3/5

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

  The schema describes all 3 parameters (cliPath, roomName, dataFilePath) with 100% coverage, so the baseline is 3. The description does not add any additional meaning about the parameters beyond what is already in the schema; it neither clarifies their usage nor provides examples, so no extra credit is warranted.

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

  Purpose5/5

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

  The description clearly states the tool's purpose with a specific verb ('Get') and resource ('all assets used in a room'). It enumerates the returned asset categories (sprites, objects, code entries, layer summary), distinguishing it from sibling tools like utmt-get-entity or utmt-list-entities by focusing on a room-wide aggregation.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool by stating 'One call replaces multiple round-trips,' which suggests using it when needing a comprehensive asset view without multiple requests. However, it does not explicitly mention when not to use it or name alternative tools for narrower queries, so it misses the 'explicit exclusions' level.

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

• utmt-infoA
  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. It clearly indicates this is a read-only info operation by stating it 'gets' and 'returns' JSON, and explicitly lists the returned fields. However, it does not mention potential error conditions or reliance on the UndertaleModCli executable, though these are inferable from the schema.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the action verb, and contains no redundant words. It efficiently conveys the purpose and output format without any fluff.

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

  Completeness4/5

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

  For a simple info retrieval tool with no output schema, the description provides sufficient detail about the return payload and the tool's scope. It does not enumerate every entity type or explain potential edge cases, but given the tool's simplicity and the presence of sibling tools for deeper operations, this level of completeness is adequate.

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

  Parameters3/5

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

  The schema already provides full descriptions for both parameters (cliPath and dataFilePath) with 100% coverage. The description adds no additional parameter semantics, so it meets the baseline for schema-heavy tools without adding extra value.

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

  Purpose5/5

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

  The description clearly states the tool's function with a specific verb ('Get'), a defined resource ('GameMaker data file'), and a precise output ('JSON with project name, GM version, isYYC flag, and resource counts'). It distinguishes itself from sibling tools like utmt-list-entities and utmt-get-entity by focusing on an overview summary rather than listing or retrieving specific entities.

  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 getting a high-level overview of a data file but does not explicitly state when to prefer this tool over its siblings or mention prerequisites (e.g., valid CLI path). No exclusions or alternative guidance is provided, leaving the usage context mostly implied.

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

• utmt-get-entityA
  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 burden of disclosure. It appropriately states the return format (JSON), and highlights special behaviors for string and generalinfo types. It does not detail error handling or explicitly confirm read-only status, but the 'get' verb and JSON return imply a non-destructive operation, which is reasonably 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 compact and to the point: three sentences cover purpose, return format, and special cases without any fluff or redundant repetition of schema details.

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

  Completeness4/5

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

  For a simple retrieval tool with no output schema, the description sufficiently explains the return type and handles type-specific quirks. It could be improved by mentioning behavior when an entity is not found or if the CLI path is missing, but overall it provides the essential context needed to use the tool correctly.

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

  Parameters3/5

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

  The input schema already covers all parameters with descriptions (100% coverage), including the note about using index for string type. The description adds minimal extra nuance beyond the schema, such as that 'generalinfo' ignores the name parameter, but this is a small addition on top of the structured fields.

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

  Purpose5/5

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

  The description clearly states the action (Get detailed info), the target (single entity), and the source (GameMaker data file), effectively distinguishing it from sibling tools like list-entities and export-entity. The supported types further clarify scope.

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

  Usage Guidelines4/5

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

  Provides useful context for when to use this tool (single entity retrieval) and includes type-specific usage instructions for 'string' and 'generalinfo'. However, it does not explicitly mention alternatives or when not to use it, though the 'single entity' phrasing implies differentiation.

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