Server Quality Checklist

Tool Scores

• add_object_instanceC
  2.8/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false, implying a write operation, but the description adds no further behavioral context. It does not disclose potential side effects, permissions, or behavior regarding existing instances, which is particularly important for a mutation tool.

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

  Conciseness5/5

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

  The description is a single sentence with no filler words, front-loading the core action and resource. Every word adds meaning, making it appropriately concise.

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

  Completeness2/5

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

  The tool has 10 parameters and no output schema, yet the description is minimal and provides no information about return values, prerequisites, or side effects. Given the complexity, this is insufficient for an agent to fully understand the tool's behavior.

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

  Parameters2/5

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

  With 0% schema description coverage, the description is expected to compensate for parameter meaning, but it only mentions 'optional instance variables,' leaving the other nine parameters purely self-explanatory from their names. It fails to clarify relationships, constraints (e.g., exclusiveMinimum for width/height), or the structure of nested variables.

  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 specifies the action ('Place') and resource ('initial instance of a scene object'), and mentions optional instance variables, which differentiates it from sibling tools like add_scene_object. However, it could be more explicit about the distinction between placing an instance and adding an object definition.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives, and no prerequisites are mentioned (e.g., whether the object must already exist in the scene). The description simply states what it does without contextual usage advice.

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

• set_scene_eventsB
  3/5.0
  Behavior1/5

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

  The description states the tool can 'Replace' events, which implies destructive overwriting of existing content. However, the annotation destructiveHint is false, creating a direct contradiction between the described behavior and the tool's declared destructiveness.

  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 or redundant information. It is concise, though it sacrifices detail that could have been included without much added length.

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

  Completeness2/5

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

  Given the complexity of the nested events schema and the lack of an output schema, the description is incomplete. It omits usage context, side effects of replacing events, parameter details, and any return value information, leaving the agent with insufficient guidance for correct invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not name or explain parameters like projectId, sceneName, events, or mode. It only vaguely maps 'Replace or append' to the mode parameter and lists event types without explaining the structured events schema.

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

  Purpose5/5

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

  The description uses specific verbs 'Replace or append' and identifies the resource as 'native GDevelop comments, groups, and standard events.' This clearly distinguishes it from sibling tools like set_scene_javascript, which handles JavaScript instead of native events.

  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 modifying scene events but provides no explicit guidance on when to choose this tool over alternatives. The word 'native' hints at a distinction from JavaScript-based tools, but no direct when-to-use or exclusion guidance is given.

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

• set_scene_javascriptB
  3.1/5.0
  Behavior1/5

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

  Annotation contradiction: the description says 'replace', which implies destructive overwriting of existing code, while destructiveHint is false. This could mislead the agent into thinking no data loss is possible. Additionally, the description does not clarify what 'MCP-managed' entails or what happens to non-MCP code.

  Agents need to know what a tool does to the world before 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, focused sentence that front-loads the verb and resource. There is no wasted wording, and the structure is clean.

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

  Completeness2/5

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

  The description is too sparse for a tool with 4 parameters and no output schema. It lacks details about the mode's behavior (append vs replace), what happens to existing code, and any prerequisites or side effects. The annotation contradiction further reduces reliability.

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

  Parameters2/5

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

  The input schema has zero description coverage, so the description must compensate. It only hints that 'code' is JavaScript code for a scene event but does not explain 'projectId', 'sceneName', or 'mode' semantics beyond the schema's enum and default. This is insufficient for reliable parameter selection.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid 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 ('Add or replace') and the specific resource ('MCP-managed inline JavaScript event on a GDevelop scene'). This distinguishes it from sibling tools like set_scene_events, which deal with broader event editing.

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

  Usage Guidelines3/5

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

  The description implies usage for setting scene JavaScript but does not explicitly state when to use this over alternatives like set_scene_events. The 'MCP-managed' qualifier hints at a specific use case but is not elaborated.

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

• add_scene_objectB
  3.2/5.0
  Behavior3/5

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

  Annotations already indicate a write operation (readOnlyHint false) and no destructive behavior. The description adds useful context about optional Sprite, Text, or Spine configuration and behaviors, but it does not disclose potential side effects like object overwriting, required resource existence, permission needs, or failure modes. It adds some value beyond annotations but remains incomplete for a create operation.

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

  Conciseness4/5

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

  The description is a single sentence with no wasted words. It is front-loaded with the action and resource, and efficiently conveys the key optional configuration aspects. It could be slightly more structured (e.g., listing required inputs) but remains appropriately concise.

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

  Completeness2/5

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

  This is a complex tool with 16 parameters, nested objects, and no output schema. The description provides only a high-level overview, omitting required parameters, type-specific requirements, error conditions, and return behavior. It is insufficient for an agent to safely invoke the tool without further schema inspection, which is especially problematic given the schema has zero property descriptions.

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

  Parameters2/5

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

  With 0% schema description coverage, the description must compensate for the 16 parameters. It mentions categories like Sprite, Text, Spine, variables, and behaviors, but it does not clarify the crucial 'type' parameter, required fields (projectId, sceneName, name, type), or how nested configurations map to specific types. The high-level mention adds some meaning but is far from adequate given the schema's complexity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Create' and clearly identifies the resource as 'an editable scene object.' It further distinguishes this from sibling tools by detailing optional Sprite, Text, or Spine configurations, object variables, and behaviors, making the tool's purpose immediately clear and distinct from tools like add_object_instance or add_object_group.

  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 compared to alternatives such as add_object_instance or add_object_group. It does not state prerequisites, typical use cases, or exclusions, leaving the agent to infer usage solely from the tool name and schema.

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

• export_projectB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds the useful context that the export produces a persistent build and writes to a caller-selected directory, but it does not disclose what destruction might occur (e.g., overwriting existing files). This is acceptable but not very rich.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence with no filler. It is front-loaded with the verb and object, and every word contributes meaning.

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

  Completeness2/5

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

  Given three parameters, a destructive annotation, and no output schema, the description is too sparse. It does not explain prerequisites, what happens to existing files, what sceneName controls, or how export relates to the project lifecycle.

  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 clarifies that outputDirectory is the local destination, but projectId and especially sceneName are left to inference. sceneName is not mentioned at all, leaving its role ambiguous.

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

  Purpose5/5

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

  The description uses a specific verb ('Export') and clearly identifies the resource ('persistent GDJS web build') and destination ('caller-selected local directory'). The word 'persistent' helps distinguish this from the sibling tool 'build_preview', though it does not explicitly name the alternative.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives like build_preview or save_project. The description simply states what it does without specifying prerequisites (e.g., a prior build) or exclusions.

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

• import_resourceB
  3.3/5.0
  Behavior2/5

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

  Annotations indicate readOnlyHint=false, so this is a write operation, and the description's 'Register' matches that. However, the description does not disclose additional behavioral traits such as whether the file is copied or referenced, overwrite behavior, failure modes, or required permissions. With minimal annotation coverage, the description carries the burden and fails to provide meaningful transparency.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that immediately states the action ('Register') and lists supported resource types. It is concise, front-loaded, and wastes no words.

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

  Completeness2/5

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

  Given the tool's complexity (5 parameters, nested metadata object, enum, no output schema, and minimal annotations), the description is insufficient. It does not explain return values, side effects, prerequisites beyond 'open project', or parameter relationships, leaving significant gaps for an agent to use the tool correctly.

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

  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 maps some parameters implicitly (sourceFile as local file, kind as one of the listed file types, projectId as an open project), but does not explain metadata, the meaning of resourceName, or the default/auto behavior of kind. This is only partial compensation for a 5-parameter schema.

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

  Purpose5/5

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

  The description uses the specific verb 'Register' and enumerates exactly which file types are handled (image, model, audio, video, font, JSON, Spine, JavaScript) and the scope ('in an open project'). This clearly distinguishes it from sibling tools like create_project or export_project, which have different purposes.

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

  Usage 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 add an existing local file to an open project, but it does not explicitly state when to use this tool versus alternatives such as create_project or set_scene_javascript. No exclusions or alternative names are given, though the 'open project' constraint provides some context.

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

• add_object_groupA
  3.5/5.0
  Behavior2/5

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

  Annotations only state readOnlyHint=false and destructiveHint=false; the description adds 'editable' but fails to disclose whether an existing group with the same name is overwritten, whether objectNames must reference existing scene objects, or any error/failure behavior. It communicates that this is a mutation but not its side effects.

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

  Conciseness5/5

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

  The description is a single focused sentence, front-loaded with the action and resource, with no unnecessary words or repetition.

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

  Completeness2/5

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

  With 4 required parameters, no output schema, and no parameter documentation, the description provides only usage intent. It omits prerequisites, duplicate behavior, and the relationship between the group and scene objects, so an agent lacks complete information for reliable invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain any parameter. While names like projectId and sceneName are self-explanatory, the meaning of objectNames (must they refer to existing objects? are duplicates allowed?) and behavior on name conflicts are unaddressed, leaving a meaningful gap.

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

  Purpose5/5

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

  The description uses a specific verb ('Create') and names the resource ('editable scene object group'), and it clarifies the purpose: authoring shared enemy, pickup, or platform events. This clearly distinguishes it from sibling tools like add_scene_object and add_object_instance.

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

  Usage Guidelines4/5

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

  The description gives clear contexts for use (shared enemy, pickup, platform events) and implies grouping common objects for event authoring. However, it does not explicitly state when not to use this tool or name alternatives, stopping short of a 5.

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

• build_previewA
  3.6/5.0
  Behavior4/5

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

  With annotations showing only false values (readOnlyHint, openWorldHint, destructiveHint), the description carries the burden. It explicitly discloses that it starts a loopback HTTP server and returns the URL, revealing a persistent side effect. It does not mention server lifetime or resource usage, but the core behavior is transparent.

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

  Conciseness5/5

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

  The description is a single sentence that immediately states the action, method, and output. It is front-loaded and contains no redundant information, earning a perfect score for conciseness.

  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 steps (compile, serve, return URL) and gives an adequate overview. However, it lacks parameter semantics and usage guidance, and with no output schema, the return format is only described as 'preview URL'. Gaps remain for a tool that starts a persistent server, but the core context is present.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description mentions neither projectId nor sceneName. The agent must infer meaning from names alone, which is especially problematic for the optional sceneName parameter. The description provides no additional value for parameter understanding.

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

  Purpose5/5

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

  The description clearly states the tool compiles a project, starts a loopback HTTP server, and returns a preview URL. This specific verb+resource combination distinguishes it from siblings like export_project (which exports without serving) and get_preview_status (which only checks status).

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

  Usage Guidelines3/5

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

  The description implies the tool is for building and serving a preview, but does not explicitly mention when to use it versus alternatives like export_project or get_preview_status. No exclusions or alternative tool names are provided, so the guidance is limited to context rather than explicit directions.

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

• set_scene_variableA
  3.6/5.0
  Behavior2/5

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

  Annotations already mark it as not read-only. The description adds only that the variable is 'editable' and accepts certain value types, which is largely redundant with schema. It does not disclose overwrite behavior, scene existence requirements, or side effects.

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

  Conciseness5/5

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

  Single sentence, concise, front-loaded with action. No filler.

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

  Completeness4/5

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

  For a simple setter, the description covers the main purpose and value type limitations. It leaves out overwrite/merge semantics but overall is sufficient given the straightforward nature of the tool.

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

  Parameters3/5

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

  With 0% schema description coverage, the description explains the 'value' parameter can be primitive, structure, or array, aiding interpretation of the recursive schema. However, projectId, sceneName, and name are not elaborated beyond their self-explanatory names.

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

  Purpose5/5

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

  The description uses specific verb 'Create or update' with resource 'editable scene variable' and enumerates value types, clearly distinguishing from sibling set_global_variable. It is specific and unambiguous.

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

  Usage Guidelines3/5

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

  The description implies use for scene variables but provides no explicit guidance on when to choose this over set_global_variable or other sibling tools. No alternatives are named.

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

• describe_native_projectA
  3.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description's 'Inspect' aligns. It adds value by enumerating the exact components inspected, which informs the agent of the tool's scope. No mention of error behavior or edge cases, but annotations cover the safety profile.

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

  Conciseness5/5

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

  The description is a single 11-word sentence, highly front-loaded and free of fluff. It efficiently communicates the tool's core function.

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

  Completeness2/5

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

  With no output schema, the description should clarify the return format. It mentions 'event counts' but doesn't specify whether other items are returned as full objects or counts, nor any prerequisites like the project being open.

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

  Parameters2/5

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

  The single parameter projectId is only defined by schema type/format. The description provides no explanation of what projectId refers to or how to obtain it, despite low schema description coverage (0%), so the agent must infer meaning from the name alone.

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

  Purpose5/5

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

  The description uses the specific verb 'Inspect' and lists concrete resources (scenes, editable objects, behaviors, instances, variables, event counts), clearly distinguishing it from sibling tools that create, modify, or preview projects.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or alternative guidance is provided. The read-only nature is implied by the verb 'Inspect' and the sibling set, but the description does not state when to choose this over get_preview_status or other read tools.

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

• update_projectA
  3.7/5.0
  Behavior4/5

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

  The description adds 'in memory', a key behavioral trait not captured by annotations, indicating changes are temporary until saved. Annotations already indicate readOnly=false and destructive=false, so the description's addition of scope and persistence context is valuable.

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

  Conciseness5/5

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

  The description is a single, focused sentence with no filler. It front-loads the verb and resource, efficiently conveying the core purpose without redundancy.

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

  Completeness2/5

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

  The tool has 9 parameters and no output schema, yet the description provides only a high-level overview. It lacks details on return behavior, error handling, preconditions (e.g., project must be open), and does not compensate for the sparse schema, making it incomplete for safe 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?

  With 0% schema description coverage, the description must substitute for missing parameter details, but it only groups parameters into 'metadata, resolution, and frame-rate settings'. It does not explain individual parameters like name, width, author, or constraints, leaving the agent to infer semantics.

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

  Purpose5/5

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

  The description clearly states the tool updates project metadata, resolution, and frame-rate settings, with the important scope qualifier 'in memory'. This distinguishes it from siblings like save_project (persisting changes) and create_project (creating a new project).

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

  Usage Guidelines3/5

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

  Usage is implied: the tool is for updating in-memory project settings, but there is no explicit guidance on when to choose this over alternatives (e.g., save_project for persistence). No exclusions or alternative tool references are provided.

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

• add_scene_layerA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds the 'editable' qualifier and an example, but does not disclose potential naming conflicts, required permissions, or effects on existing layers. Since annotations cover the basic safety profile, this is acceptable but not enriched.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that directly states the operation and provides a helpful example. Every word earns its place with no redundancy or fluff.

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

  Completeness3/5

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

  The tool is simple with 3 well-named parameters, and the description gives a clear purpose and example. However, it does not mention edge cases like duplicate layer names, whether the scene must already exist, or what the success/failure behavior looks like (no output schema). For a straightforward add operation, the description is adequate but has 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 0% and the description provides no explanation of parameters. The parameter names (projectId, sceneName, layerName) are self-explanatory, giving some implicit meaning, but the description fails to compensate for the complete lack of schema descriptions. It adds no value beyond the names already present.

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

  Purpose5/5

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

  The description clearly states the verb 'Add' and the resource 'an editable 2D layer to a scene', making the tool's purpose unambiguous. It distinguishes itself from sibling tools like add_scene_object (which adds objects) and add_object_instance, and the example 'for example a HUD layer' further clarifies typical usage.

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

  Usage Guidelines4/5

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

  The description gives a concrete example (HUD layer) that implies when the tool is useful, and the sibling tool context (add_scene_object, set_scene_events) helps differentiate it from alternatives. However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a 5.

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

• close_projectA
  3.8/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds specific behavioral context by stating that it 'stop[s] previews' and 'release[s] its C++/Wasm project handle,' which reveals the nature of the resource being cleaned up and the side effect on previews—information beyond a simple destructive flag.

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

  Conciseness5/5

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

  The description is a single concise sentence of 13 words, front-loading the primary action ('Stop previews') followed by the secondary effect ('release its C++/Wasm project handle'). Every word contributes meaning, with no wasted 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 one-parameter tool with no output schema and destructive annotations, the description gives a clear summary of the main effects. However, it omits relevant context such as whether unsaved changes are saved or discarded, what happens if the project is already closed, or whether the operation is reversible. These gaps are notable for a destructive operation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for explaining the parameter. However, the description does not mention projectId at all. Although the parameter name is self-explanatory (the UUID of the project to close), the description omits any explicit mapping of the parameter to the action, leaving the agent to rely solely on the schema's format and property name.

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

  Purpose5/5

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

  The description clearly states the tool's action: 'Stop previews for a project and release its C++/Wasm project handle.' It uses specific verbs ('stop', 'release') and identifies the resource ('a project'), distinguishing it from siblings like open_project (creates a session) and stop_preview (likely only stops previews without releasing the handle).

  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 (closing a project session when done), but does not explicitly provide when-to-use guidance or mention alternatives. It does not contrast with sibling tools like stop_preview or save_project, leaving the agent to infer the appropriate context.

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

• save_projectA
  3.8/5.0
  Behavior3/5

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

  The description reveals that it writes to a file (the JSON file) and requires an open in-memory project, adding context beyond the readOnlyHint=false annotation. However, it does not disclose overwrite behavior or error conditions, so it adds only moderate insight.

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

  Conciseness5/5

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

  The description is a single concise sentence that front-loads the core action. Every word adds value, with no redundancy.

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

  Completeness3/5

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

  For a simple save operation with one parameter, this is minimally adequate. It lacks details on return values, error handling, or whether the existing file is overwritten, but it does specify the precondition (open project) and destination (JSON file).

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not mention the projectId parameter or explain how it relates to the operation. The parameter is self-evident from the name, but the description provides no additional guidance.

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

  Purpose5/5

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

  The description uses a specific verb ('serialize') and resource ('open in-memory project') with a clear destination ('back to its JSON file'). This distinguishes it from siblings like create_project, update_project, and export_project.

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

  Usage Guidelines4/5

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

  It provides clear context: the tool saves an already-open in-memory project to its original JSON file, implying you should use it after opening or modifying a project. It does not explicitly mention alternatives like export_project, but the context is reasonably clear.

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

• create_projectA
  3.9/5.0
  Behavior4/5

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

  The description discloses that the tool creates a file and keeps it open as a session, which is behavioral information beyond the annotations (readOnlyHint=false, openWorldHint=false, destructiveHint=false). It does not mention overwrite behavior or lifecycle details, but the session disclosure adds meaningful context.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action and the session behavior without padding.

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

  Completeness2/5

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

  Given the tool's complexity (14 parameters, no output schema, and a sizable sibling list), the description is too minimal. It does not explain key behaviors like overwrite semantics, session lifecycle, or the purpose of less obvious parameters, leaving the agent under-informed for correct invocation.

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

  Parameters2/5

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

  The input schema has 14 parameters with 0% description coverage, and the description adds no meaning for any of them. Parameter names like loadingMinDuration and sizeOnStartupMode are not self-evident, and the description fails to compensate for the lack of schema documentation.

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

  Purpose5/5

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

  The description clearly states the action ('Create') and the resource ('a new editable GDevelop project JSON file'), and adds a distinctive behavioral trait ('keep it open as a session') that differentiates it from siblings like open_project and update_project. This is a specific and unambiguous purpose.

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

  Usage Guidelines4/5

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

  The description clearly implies when to use this tool: when creating a new project rather than opening or updating an existing one. It does not explicitly exclude alternatives, but the 'new' wording provides clear contextual guidance without requiring inference.

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

• stop_previewA
  3.9/5.0
  Behavior4/5

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

  Annotations declare destructiveHint=true, but the description adds specific details about what gets destroyed: the loopback HTTP server and the preview's temporary directory, scoped to 'only this preview'. This is valuable scoping context beyond the annotation.

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

  Conciseness5/5

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

  A single, focused sentence with no extraneous content. Front-loaded and easy to parse, making it highly concise.

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

  Completeness4/5

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

  For a simple stop operation, the description covers the key behaviors (stopping server, removing temp dir) and adds scoping ('only this preview'). However, it omits any mention of the previewId parameter or what happens if the preview does not exist, but given low complexity and the presence of annotations, it is adequate.

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

  Parameters2/5

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

  The description does not mention the previewId parameter or explain how to obtain/use it. With 0% schema description coverage, the description must compensate, but it doesn't add any parameter-related meaning. The parameter name itself is suggestive, but the description should clarify what identifies the preview.

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

  Purpose5/5

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

  The description states a specific action ('stop the loopback HTTP server') and identifies the exact resource ('only this preview's temporary directory'). It clearly differentiates from siblings like build_preview and get_preview_status, as this is the stopping counterpart.

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

  Usage Guidelines3/5

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

  No explicit guidance on when to choose this tool over alternatives (e.g., close_project or build_preview). The usage is implied by the tool name and title, but the description provides no direct statement of when to invoke it.

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

• open_projectA
  4/5.0
  Behavior4/5

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

  The phrase 'isolated in-memory session' adds meaningful behavioral context beyond the readOnlyHint annotation by clarifying that no persistent changes are made. However, it does not describe what happens if a project is already open or the behavior on invalid files.

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

  Conciseness5/5

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

  The description is a single, compact sentence that is immediately informative and front-loaded. Every word contributes value, with no redundant or tangential content.

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

  Completeness4/5

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

  For a simple tool with one parameter, the description is largely complete: it states what is loaded and the session context. However, it omits information about return values or whether opening a new project replaces an existing session, which could be relevant for an agent's invocation decisions.

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

  Parameters3/5

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

  Schema description coverage is 100% and the parameter 'projectFile' is clearly documented with path type and relativity. The description adds no additional parameter semantics beyond what the schema 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 clearly states the specific action ('Load') and resource ('local .json GDevelop project') with a clear target ('into an isolated in-memory session'). This distinguishes it from sibling tools like create_project, save_project, or describe_native_project.

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

  Usage Guidelines3/5

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

  The description implies usage for loading an existing project, but does not provide explicit when-to-use guidance or mention alternatives like create_project for new projects. It lacks exclusion conditions or context about the session lifecycle.

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

• set_global_variableA
  4/5.0
  Behavior3/5

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

  Annotations already indicate the operation is not read-only and not destructive. The description adds context about 'create or update' behavior and value types, but does not disclose details like overwriting existing variables or potential side effects. It covers the basics without contradicting annotations.

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

  Conciseness5/5

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

  The description is a single sentence with no redundant words. It is front-loaded with the action and resource, making it easy to scan.

  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 setter tool with clear annotations and no output schema, the description is sufficient. It covers the essential purpose and value types. Minor missing details like explicit overwrite behavior are implied by 'update', so the description is adequately complete for its complexity.

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

  Parameters3/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions 'primitive, structure, or array value' which maps to the 'value' parameter, but does not explain 'projectId' or 'name' semantics beyond what the schema types and tool name suggest. It partially compensates for the low coverage, but not fully.

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

  Purpose5/5

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

  The description clearly states the action ('Create or update') and the resource ('editable project-wide variable'), with explicit mention of supported value types ('primitive, structure, or array value'). The term 'project-wide' distinguishes it from sibling tools like set_scene_variable, which target scene variables.

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

  Usage Guidelines4/5

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

  The description implies usage for global (project-wide) variables versus scene variables through the word 'project-wide', but it does not explicitly mention alternatives or exclusions. It provides clear context but no direct comparison with sibling tools, so a score of 4 is appropriate.

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

• get_preview_statusA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds valuable behavioral context: the tool returns either a single session (when previewId is provided) or all sessions (when omitted). This conditional behavior is not captured by annotations alone. However, it does not disclose error handling (e.g., invalid ID) or response format, which are minor gaps for a read-only 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 purpose and includes the key conditional behavior. There is no redundancy or filler.

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

  Completeness4/5

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

  For a tool with one optional parameter and no output schema, this description is largely complete. It covers the core behavior (single vs. all sessions) and the read-only nature is reinforced by annotations. It does not specify the return format or edge cases, but these are not critical for a simple query tool.

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

  Parameters4/5

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

  The input schema provides no description for previewId (coverage 0%), so the description carries the burden. It explains the parameter's meaning and effect: 'when previewId is omitted' implies that previewId selects a single session, while omitting it lists all. This adds semantic meaning that the schema lacks, though it could be more explicit in naming the parameter.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Return one preview session, or list all sessions when previewId is omitted.' This uses a specific verb ('return'), defines the resource (preview session), and explains the conditional behavior. It effectively distinguishes itself from sibling tools like build_preview and stop_preview by indicating it is a read-only status query.

  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 but does not explicitly state when to use this tool versus alternatives. It says 'Return one preview session, or list all sessions when previewId is omitted,' which suggests it is for fetching status, but it does not provide context such as 'use after starting a preview' or compare to stop_preview. The usage is clear from the name and behavior but lacks explicit guidance.

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