Server Quality Checklist

Tool Scores

• set_world_modsC
  2.9/5.0
  Behavior3/5

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

  With no annotations, the description is the only source for behavioral information. It clearly states the mutation ('enable or disable') and adds a useful side-effect detail: required dependencies are kept automatically. However, it is silent on whether changes are applied immediately, whether disabled dependencies are affected, or whether the operation is reversible.

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

  Conciseness4/5

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

  The description is two sentences with no filler. The first sentence front-loads the action and resource, and the second adds a significant dependency detail. It is concise, though it sacrifices some needed context.

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

  Completeness2/5

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

  For a mutation tool with no annotations and no output schema, this description is incomplete. It fails to explain the apply boolean, how to specify the world, or what happens after enabling/disabling mods. The dependency note helps, but an agent would still have to guess at key execution semantics.

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

  Parameters2/5

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

  Schema description coverage is only 50%, with world and apply left undocumented. The description does not mention apply at all and only loosely relates 'world profile' to the world parameter, without clarifying the expected value. The enable/disable arrays are documented in the schema, but the description adds no extra meaning beyond that.

  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 specific action ('Enable or disable specific mods') and a resource ('world profile'), making the tool's function clear. It does not explicitly differentiate itself from siblings like apply_world or analyze_mods, but the phrase 'specific mods' helps distinguish this from bulk/world-level operations.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus alternatives such as apply_world, recommend_mods, or analyze_mods. The description implies the use case of toggling mods, but it never states exclusions or conditions that would help an agent choose between sibling tools.

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

• read_logB
  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 disclosure burden. It does state 'never dumps the whole huge file', which is a meaningful safety/performance guarantee, and it reveals tail/search capabilities. However, it omits default behavior when neither tail nor search is provided, how output is truncated, and any permission considerations.

  Agents need to know what a tool does to the world before calling it. Descriptions 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: the verb and resource come first, the operations are parenthesized, and the key safety behavior is included. 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 3-parameter tool with no output schema and no annotations, the description is too thin. It does not state defaults, how results are bounded when tail/search are absent, or how the path relates to sibling tool list_logs. The 'never dumps the whole huge file' hint is useful but leaves major gaps.

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

  Parameters2/5

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

  Schema description coverage is only 33%; only path has a description. The description mentions 'tail or search' but does not explain what tail counts (lines? bytes?) or how search works (substring? regex? case-sensitive?). An agent cannot confidently construct correct values for these parameters based solely on the available text.

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

  Purpose4/5

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

  The description uses the specific verb 'Read' with the resource 'log or crash report', and adds the operational modes 'tail or search'. It is clearly distinct from sibling tools like list_logs (list vs read) and read_config, though it does not explicitly name a sibling.

  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 list_logs for discovering available logs, nor does it distinguish when diagnose or read_config would be more appropriate. The usage context is only implied by the tail/search hint.

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

• analyze_modsB
  3.2/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 names the categories analyzed but does not state whether the tool is read-only, whether it writes or changes anything, or what kind of result it returns. This is a meaningful gap for a diagnostic 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, well-structured sentence that immediately states the action and the specific analysis categories. Every word contributes value, and there is no redundant or filler content.

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

  Completeness3/5

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

  For a zero-parameter tool this is reasonably complete: it tells the agent what is analyzed and at what scope. However, with no output schema and no behavioral notes, it does not explain what the tool returns or whether it is safe to invoke as a read-only operation, leaving some context missing.

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

  Parameters4/5

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

  The tool has zero parameters, so there is no parameter semantics gap for the description to fill. With 100% schema coverage and no parameters, the baseline of 4 is appropriate; there is nothing missing at the invocation level.

  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 specific verb ('Analyze') and resource ('the current instance'), and lists exactly what is checked: missing deps, duplicate jars, missing files, and incompatibilities. It is clear and informative, but it does not explicitly distinguish itself from siblings like diagnose or compare_mods, so it falls just 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 implies this is for checking the current instance for problems, but it gives no guidance on when to choose this tool over alternatives like diagnose, health_check, or list_mods. There are no explicit conditions, exclusions, or references to sibling tools.

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

• list_modsB
  3.2/5.0
  Behavior3/5

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

  There are no annotations, so the description bears the responsibility for behavioral disclosure. The verb 'List' conveys a read-only intent, but the description does not explain the meaning of 'current instance', whether anything is modified, or what happens with default settings. This is adequate but minimal.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no filler. It earns its place, but it is slightly under-specified for a tool with three parameters and no output schema.

  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 three parameters, no annotations, and no output schema, a one-sentence description is not enough. It does not state what fields are returned, how query or enabledOnly affect results, or what 'all' means for the kind parameter. The tool is understandable at a high level but not fully specified for reliable autonomous invocation.

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

  Parameters2/5

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

  Schema description coverage is only 33% since query is the only documented parameter. The description partially clarifies kind by mentioning optional resource packs, but it does not explain the enum values mod/resourcepack/all, the default behavior, or the enabledOnly parameter. Low schema coverage requires more compensation than this.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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'), a clear resource ('mods and optional resource packs'), and a scope ('current instance'). It is immediately distinguishable from siblings like list_worlds, list_instances, list_configs, and list_logs, and the verb also separates it from compare_mods, analyze_mods, and recommend_mods.

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

  Usage Guidelines2/5

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

  No guidance is given about when to use this tool versus the related analyze_mods, compare_mods, or recommend_mods tools. The phrase 'current instance' implies some prior context selection, but there is no mention of that prerequisite or any exclusion criteria.

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

• register_serverB
  3.2/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 behavioral disclosure burden. 'Remember' suggests a persistent side effect, but the description does not say whether registrations accumulate, overwrite existing entries, validate the path, or return any confirmation.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 communicates the core action and purpose efficiently.

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

  Completeness2/5

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

  For a registration action with no annotations and no output schema, the description leaves important behavior ambiguous: is the registration persistent, idempotent, overwriting, or additive? The low parameter count keeps complexity low, but the agent still needs more operational context to invoke the tool confidently.

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

  Parameters3/5

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

  The schema already fully documents 'path' as an absolute path to a server directory, so the description adds little beyond framing it as a Minecraft server folder. The baseline of 3 applies because schema coverage is 100%.

  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 specific action ('Remember') applied to a distinct resource ('dedicated Minecraft server folder') and ties it to compare/diagnose workflows. It is reasonably distinguishable from sibling tools, though it does not explicitly contrast with instance-related tools.

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

  Usage Guidelines3/5

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

  The phrase 'for compare/diagnose' implies the tool should be used before those operations, but it does not state whether registration is a prerequisite, how it relates to instances, or when not to use it. Usage context is only implied, not explicit.

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

• compare_modsB
  3.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 tells the agent what is compared and between what targets, but it does not state whether the operation is read-only, what the result format is, how comparison is performed (e.g., names, versions, hashes), or what happens on missing/ambiguous targets.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler or redundant phrasing. It efficiently communicates the action and both valid comparison target types in a compact way.

  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 only two parameters, no output schema, and no annotations, the description needs to provide more operational context. It adequately defines the inputs but omits what the comparison returns, whether there are side effects, and how success or failure is signaled. An agent could invoke the tool but would lack clear expectations for the result.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters adequately. The description adds the insight that 'mod jars' are the subject and clarifies left/right roles, but it does not provide meaningful extra semantics beyond what the schema already states.

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

  Purpose5/5

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

  The description uses a specific verb ('Compare') and resource ('mod jars'), and defines the exact scope: between two instances, or between an instance and a registered/server mods folder. This clearly distinguishes it from siblings like list_mods or analyze_mods by emphasizing a comparative operation.

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

  Usage Guidelines3/5

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

  The description clearly states the supported comparison configurations (instance-to-instance, or instance-to-folder), which implies when the tool is appropriate. However, it does not explicitly name alternatives or explain when not to use this tool, such as when plain listing or deeper analysis would be more suitable.

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

• create_worldB
  3.4/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 behavioral burden. It adds genuinely useful context: 'dep-safe subset of ~N mods' signals dependency resolution, and 'Does not generate terrain; you create/open the world in-game after apply' clarifies the post-apply side-effect. However, it never discloses the mutating, disk-writing nature of applying a profile, nor any overwrite consequences, which is a notable gap for a creation tool with an overwrite parameter.

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

  Conciseness4/5

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

  Three tight sentences with the primary purpose front-loaded, followed by only high-value additions: dependency safety, the terrain exclusion, and the in-game follow-up. The '~N' placeholder is slightly oblique, but every sentence earns its place with no filler.

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

  Completeness3/5

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

  For a mutating tool with 8 parameters, no annotations, and no output schema, the description covers the essential mental model well: profile creation, optional mod subsetting, and the post-apply workflow. But it omits return values, failure modes, and overwrite/seed behavior, so an agent would still face uncertainty on edge cases such as re-creating an existing world.

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

  Parameters3/5

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

  Schema coverage is only 50% — seed, notes, overwrite, and targetModCount lack schema descriptions. The description partially compensates by tying drop/keep/targetModCount to 'a dep-safe subset of ~N mods', though the literal '~N' placeholder is vague. It adds nothing for seed, notes, or overwrite, leaving those parameters semantically under-specified.

  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+resource+scope: 'Create a world profile inside the current instance.' The clarification 'Does not generate terrain' prevents confusion with terrain generation, which is a meaningful boundary. However, it does not explicitly distinguish from sibling tools like set_world_mods or apply_world, which overlap in the world-modification space.

  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 workflow hint 'you create/open the world in-game after apply' implies this is the first step in a create→apply→play sequence, giving the agent a sense of when to call it. But there are no explicit exclusions or named alternatives, so the agent must infer when to prefer set_world_mods or apply_world instead.

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

• list_configsB
  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 carries the burden of behavioral disclosure. It clarifies scope ('current instance' and 'world's serverconfig if named') and the word 'List' implies a read-only operation. However, it does not state the response format, whether the query parameter affects behavior, or any edge cases.

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

  Conciseness4/5

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

  The description is a single concise sentence with no wasted words. The core action and scope are front-loaded, and the parenthetical adds the optional world behavior efficiently. Slight clarity could be improved, but overall it is well-structured.

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

  Completeness2/5

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

  Given no output schema, no annotations, and zero schema description coverage, the description is not complete enough. It omits the meaning of the query parameter, does not describe the return value, and provides no guidance on expected behavior. An agent would need additional information to invoke this tool with confidence.

  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 partially explains the world parameter by referencing a world's serverconfig, but the query parameter is completely unexplained. An agent cannot determine what query should contain or how it affects the listing.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'List' with a clear resource: 'config files on the current instance', and optionally a world's serverconfig. This distinguishes it from sibling tools like read_config, edit_config, and list_worlds, so an agent knows exactly what this tool does.

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

  Usage Guidelines3/5

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

  The description implies when to use this tool — when listing config files for the current instance or a named world's serverconfig. However, it does not explicitly mention when not to use it or point to alternatives such as read_config or edit_config for viewing or modifying file contents, leaving some inference to the agent.

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

• recommend_modsA
  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 responsibility for behavior. It does convey that the tool produces recommendations and that dependency preservation is part of its logic, which suggests a non-mutating advisory operation. It does not explicitly state whether any changes are applied, but the verb 'suggest' weakly implies a read-only 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 entire description is a single focused sentence with no filler. It front-loads the core action and includes the key constraints compactly.

  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 two-parameter advisory tool, the description covers the main purpose and constraint. However, since there is no output schema and no annotations, it does not describe the shape of the returned recommendations or confirm that no modifications are made, leaving some ambiguity.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It helps by clarifying that 'world' can refer to a specific world or the whole instance, and that 'target count' maps to targetModCount. It does not name the parameters directly or add details like defaults, ranges, or the meaning of omission.

  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 ('Suggest mods') and a clear objective ('to hit a target count and keep dependencies'), which makes the tool's purpose understandable. It does not explicitly contrast with siblings like analyze_mods or compare_mods, but the recommendation-focused intent is still 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 when to use it: when the user wants to reach a target mod count while preserving dependencies, and for either a world or the whole instance. However, it provides no explicit guidance about when not to use it or which sibling alternative to prefer, so the agent must infer the boundary.

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

• diagnoseA
  3.6/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 the input files it processes and the categories of issues it looks for. However, it does not state whether the tool is read-only, what its output format is, or whether it may apply any changes, leaving some behavioral ambiguity.

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

  Conciseness5/5

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

  A single sentence with no filler. The verb, scope, files, and analysis targets are all front-loaded and each word contributes to the tool's purpose.

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

  Completeness3/5

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

  For a parameterless diagnostic tool, the description is reasonably complete: it names the sources and expected findings. Still, it does not describe the return value or output shape, and with no output schema or annotations, an agent has to infer what 'likely culprits' will look like when the call completes.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 an empty input schema, so there are no parameter semantics to add. The description correctly focuses on behavior rather than parameters, matching the baseline for parameterless tools.

  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, 'Parse', with concrete resources ('latest.log, debug.log, and recent crash reports') and a clear analytical goal ('missing mods, mixins, and likely culprits'). However, it does not explicitly differentiate from sibling tools like read_log, analyze_mods, or health_check, relying on the operational details to imply distinction.

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

  Usage Guidelines3/5

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

  The description implies when to use the tool: when you need to diagnose crashes or mod issues from logs. It does not explicitly state when not to use it, nor does it mention alternatives such as health_check or analyze_mods, so the guidance is only implicit.

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

• edit_configA
  3.7/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 behavioral disclosure burden. It clearly warns that worldgen/server config edits cause a backup and world reset by default, which is a significant side effect. It does not cover all edge cases, but it discloses the most important mutation consequence.

  Agents need to know what a tool does to the world before 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 with no filler. The core operation is front-loaded, and the important side-effect caveat is stated immediately after.

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

  Completeness3/5

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

  The description covers the main side effect and the timing of the change taking effect. However, it omits guidance about the value format, path scope, return behavior, and when to use related sibling tools, so 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.

  Parameters3/5

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

  Schema description coverage is 80%, so the schema already documents key and path semantics. The description adds meaning around the default reset behavior, which clarifies resetWorld, but it does not explain the value parameter or the world parameter beyond what the schema provides.

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

  Purpose5/5

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

  The description uses a specific verb ('Change') and a clear resource ('a key in a config file'), and the dotted-path detail in the schema reinforces the operation. This distinguishes it from read-only siblings like read_config and list_configs.

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

  Usage Guidelines2/5

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

  The description gives no explicit guidance on when to use this tool over alternatives such as read_config, list_configs, or apply_world. The reset behavior is mentioned, but there is no stated context, prerequisite, or exclusion.

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

• read_configA
  3.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 burden of signaling safety and behavior. It indicates a non-destructive read and clarifies path resolution relative to the instance root, but it does not mention error behavior, permission requirements, or what the tool returns.

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

  Conciseness5/5

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

  A single sentence with no filler. The core verb, object, and path-scoping constraint are all front-loaded and 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?

  For a one-parameter read operation, the description and schema cover the essentials for invocation. However, with no output schema it does not describe the return format, and it omits preconditions like having a current instance or when to prefer edit_config.

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

  Parameters4/5

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

  The schema already documents path at 100% coverage, so the baseline is 3. The description adds value by stating that the path is resolved 'relative to the current instance root,' which the schema's 'Relative path' alone does not specify.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 precise action ('read') and resource ('config file'), and scopes it to 'the current instance root.' This clearly separates it from sibling tools like list_configs and edit_config without needing to open their schemas.

  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 choose this tool over list_configs, edit_config, or other siblings, and no mention of prerequisites such as an active instance. The intended use is inferable from the verb 'read,' but the description does not state it.

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

• list_logsA
  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 behavioral burden. It does state that the action is a listing operation on log and crash-report files, which implies a read-only behavior, but it does not describe the return format, whether a current instance must be selected, or any error behavior. This is adequate but has gaps.

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

  Conciseness5/5

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

  The description is a single sentence with no filler. The action, object, and scope are all front-loaded, and every word contributes to meaning.

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

  Completeness4/5

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

  For a zero-parameter list tool, the description is nearly complete: it names the file categories and the scope. It does not explicitly state the return shape, but 'list' strongly implies a list of files, and there is no output schema to demand more detail.

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

  Parameters4/5

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

  There are zero parameters, so the description has no parameter burden to carry. Per the baseline for no-parameter tools, this is scored as 4.

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

  Purpose5/5

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

  The description uses a specific verb ('list') with a specific resource ('log and crash-report files') and scopes it to the current instance. This clearly distinguishes it from siblings like read_log and diagnose, so an agent can identify the operation without needing to inspect schemas.

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

  Usage Guidelines2/5

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

  No explicit guidance is given about when to use list_logs versus read_log, diagnose, or other siblings. The usage context is only implicit in the verb 'list', and no prerequisites or exclusions are stated.

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

• apply_worldA
  3.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 of disclosing behavior. It does reveal the mutation effects ('enable/disable jars and write config patches'), which is concrete and useful. But it does not say whether the operation is destructive, reversible, idempotent, or whether it overwrites existing configuration patches, leaving the agent with incomplete safety knowledge.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 zero redundancy. The core action and effects are front-loaded, and the timing instruction earns its place. Nothing extraneous or vague is present.

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

  Completeness3/5

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

  For a single-parameter mutation tool with no annotations and no output schema, the description gives the essential purpose, actions, and timing. But it omits details like prerequisites (e.g., the world profile must exist), possible side effects, and what a successful invocation returns. It is adequate but not complete for an agent operating autonomously.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It implies that the 'world' parameter is the identity of the world profile being applied, giving some meaning. However, it does not specify whether 'world' is a name, ID, or path, nor does it list valid values or how to obtain them, leaving the parameter underdocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Apply') and resource ('a world profile to the instance') and immediately clarifies the mechanism with concrete actions: 'enable/disable jars and write config patches.' This clearly distinguishes it from sibling tools like reset_world or set_world_mods, which have different scopes and effects.

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

  Usage Guidelines4/5

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

  The description provides explicit timing context with 'Do this before launching,' which tells the agent when to invoke the tool. However, it does not mention alternatives or conditions that would make another tool more appropriate, so it stops short of a full decision guide.

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

• list_worldsA
  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 carries the full behavioral burden. 'List' implies a read-only retrieval operation, but the description does not explicitly state side-effect-freeness, prerequisites like an active current instance, output format, or error behavior. This is mostly adequate for a simple zero-parameter list 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 that front-loads the action and resource. There is no filler or redundant information.

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

  Completeness4/5

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

  For a simple zero-parameter tool with no output schema, the description captures the essential what and where. It could have clarified how the 'current instance' is established, but that is likely a shared precondition set by sibling tools like use_instance.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 an empty input schema, so there is no parameter documentation burden. The baseline for zero-parameter tools is 4, and the description need not add parameter-level detail.

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

  Purpose5/5

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

  The description uses the specific verb 'List' and clearly identifies the resources ('world profiles', 'save folders') and scope ('current instance'). This makes the tool's purpose distinct from sibling list tools like list_instances, list_mods, and list_configs.

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

  Usage Guidelines3/5

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

  Usage is implied by the verb 'List' and the 'current instance' scope, so an agent can infer when to call it. However, there is no explicit guidance about when to choose this tool over siblings such as list_instances or create_world, and no exclusions or alternatives are stated.

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

• use_instanceA
  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 carries the behavioral burden. It discloses that an instance is selected and retained 'for later' tools, implying persistent state. However, it does not say whether the instance must already exist, whether a new selection replaces the previous one, or what happens on invalid names.

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

  Conciseness5/5

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

  A single, front-loaded sentence states the action and purpose with zero filler. Every word earns its place, 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.

  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 state-setting tool, the description is nearly complete: it explains what the tool does and why it is used. It omits details like return value and error behavior, but these are minor for this tool and no output schema exists to carry that burden.

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

  Parameters3/5

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

  The schema description fully covers the single 'name' parameter with an example ('ATM10'), so the schema already carries the semantic weight. The tool description adds no additional parameter detail, which is acceptable given the 100% schema coverage.

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

  Purpose5/5

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

  The description uses a specific verb ('Select') and a specific resource ('the current CurseForge instance'), and states its intended role ('for later world/mod/config tools'). This clearly distinguishes it from sibling tools like list_instances/get_instance, which retrieve or list rather than set a working 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 phrase 'for later world/mod/config tools' explicitly conveys when this tool is appropriate: before using instance-scoped operations. It gives clear usage context, though it does not explicitly name alternatives or state when not to use it, which is a minor gap.

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

• get_instanceA
  4.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 burden of behavioral disclosure. 'Get' signals a read-only retrieval, 'summary' indicates a limited return shape, and 'Defaults to the current instance' reveals the omitted-parameter behavior. It does not cover no-match errors or permissions, but those are less critical for a simple getter.

  Agents need to know what a tool does to the world before 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 with no filler. The core action and the key default behavior are front-loaded, making the description easy to parse quickly.

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

  Completeness4/5

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

  Given the low complexity—one optional parameter, no nested objects, no output schema—the description covers the essential invocation and default behavior. The return value is only described as a 'summary', but that is likely adequate for this tool. A brief pointer to list_instances or use_instance would make it 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 schema already documents the single 'name' parameter with 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by specifying the default behavior when the parameter is omitted: it uses the current instance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value 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'), the resource ('a summary of one CurseForge instance'), and adds the useful default behavior. It distinguishes itself from list_instances by focusing on a single instance rather than a collection.

  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 single-instance use case and explains the current-instance fallback, but it never explicitly mentions alternatives like list_instances or use_instance. The guidance is inferred rather than stated.

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

• reset_worldA
  4.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 behavioral disclosure burden. It discloses that the tool backs up before deleting, that the next launch regenerates the world, and that the profile is retained. It does not mention prerequisites like stopping the server, but the core side effects are clearly 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?

  Two sentences with no wasted words. The action (backup then delete) and key consequence (fresh generation) are front-loaded, and the profile retention is a useful clarifier included without padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 one-parameter tool with no output schema, the description explains what happens, what is preserved, and the end state. It omits operational details like whether a running server must be stopped, but the overall flow is sufficiently clear for an agent to invoke it correctly in most contexts.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need 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. The parameter 'world' is referenced as 'a world save,' but the description doesn't specify the expected format (e.g., world name vs path). However, with a single string parameter and the tool name, an agent can reasonably infer the meaning, so the gap is moderate.

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

  Purpose5/5

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

  The description states a clear verb-resource pair: reset a world save by backing up then deleting it, and explains the intended effect (regenerates fresh with current configs). It also distinguishes itself from siblings by noting the profile is kept, which separates it from create_world or apply_world.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 it: when you want a fresh world generated from current configs while preserving the profile. It doesn't explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it among related world-management tools.

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

• apply_fixA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the disclosure burden. It states that a backup is created before changes, that resetWorld is optional, and that this approach is safer than deleting jars. It does not disclose return values or how crash-culprit mods are determined, but the core safety-relevant behavior is clearly communicated.

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

  Conciseness5/5

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

  The description is two sentences with no filler. The action and precondition are front-loaded, and the preference instruction is separated for emphasis. Every clause contributes decision-relevant information.

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

  Completeness3/5

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

  The description is sufficient for selecting the tool and understanding its high-level behavior: backup, disable culprit mods, optionally reset. However, with no output schema and no annotations, it does not describe what the tool returns, what 'crash-culprit' detection depends on, or the exact consequences of resetWorld, leaving some post-invocation behavior to inference.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 67%, and the description compensates for the missing resetWorld semantics with 'Optionally reset the world.' It also reinforces that crash-culprit disabling is the main operation and that addonIds are extra, which helps agents understand which arguments are required versus supplemental.

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

  Purpose5/5

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

  The description identifies a specific action (disable crash-culprit mods), a specific resource (world profile), and a key precondition (after backup). It is clearly distinguishable from siblings like set_world_mods or reset_world because it targets crash-culprit mods and explicitly mentions backup. The 'Always prefer this over deleting jars' line further narrows its role.

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

  Usage Guidelines4/5

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

  The description provides clear context: use it to fix crashes by disabling culprit mods, after backup, and prefer it over deleting jar files. It does not explicitly state when not to use it or compare it against related sibling tools such as reset_world or set_world_mods, so it stops short of full routing guidance.

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

• health_checkA
  4.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 disclosing side effects. It explicitly states 'Read-only' and 'Does not change files,' which is strong transparency for this tool. It also clarifies that it only checks existence/readability of environment items, so the agent knows it is safe to run early in a workflow.

  Agents need to know what a tool does to the world before 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 deliver the purpose, scope, side-effect guarantee, and usage timing with no filler. The key term 'Read-only' is placed first, and the guidance 'Run this first' is front-loaded, giving an agent the most actionable information immediately.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 health-check tool, the description is complete enough: it names what is checked, when to run it, and that it is non-destructive. There is no output schema, but the description's list of checked items gives a reasonable expectation of what the agent will learn without needing to document return values explicitly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description coverage is 100%, so there is no parameter documentation burden. The description still adds value by explaining what the tool inspects, which compensates for the absence of a richer 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 names a specific verb ('check'), a clear resource (a new computer/system environment), and enumerates the exact items checked: Node version, CurseForge Instances folder, readable packs, and diagnose logs. It clearly differentiates itself from sibling tools like read_log or list_instances by positioning itself as an aggregate health check rather than a targeted read.

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

  Usage Guidelines4/5

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

  The description gives explicit placement guidance: 'Run this first on a new device.' This tells the agent when it is appropriate to invoke this tool before other operations. It does not spell out when not to use it or name alternative tools, but the context is clear enough for a zero-parameter read-only tool.

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

• list_instancesA
  4.5/5.0
  Behavior4/5

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

  With no annotations available, the description carries the behavioral burden. It clearly indicates a read-only listing operation and discloses the returned fields (name, version, loader, mod counts), plus the local-PC scope. It does not mention error conditions or output ordering, but the behavior of a simple list tool is well conveyed.

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

  Conciseness5/5

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

  A single sentence that contains the action, target, scope, and result contents. Every word adds value and there is no redundancy.

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

  Completeness5/5

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

  For a zero-parameter list tool with no output schema, the description is complete: it tells the agent what the tool does, what it returns, and where it operates. No critical information is missing.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description appropriately focuses on what the tool returns rather than parameter details, which are nonexistent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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'), names the exact resource ('CurseForge Minecraft instances'), and scopes it to the local PC. The parenthetical return fields further distinguish it from sibling listing tools like list_worlds and list_mods.

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

  Usage Guidelines4/5

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

  The description makes the tool's context clear: it is for enumerating Minecraft instances on this machine. Sibling tools target different resources (worlds, mods, configs, logs), so no overlap is likely; however, it does not explicitly mention when to prefer get_instance for detailed single-instance information.

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