@gbs-toolkit/mcp-server

by gbs-toolkit

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., delete_custom_event vs delete_scene, create_actor vs create_trigger). Descriptions clearly differentiate overlapping operations like read_script vs patch_script, and list_scenes vs read_scene. No two tools serve the same purpose.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., list_scenes, create_variable, delete_actor). Verbs like list, read, create, delete, set, build, run, generate, convert are used predictably without mixing styles.
Tool Count5/5
23 tools cover a comprehensive range of operations for GB Studio development (scenes, actors, triggers, variables, scripts, sprites, build/run). This count is well-scoped for the toolkit's purpose—neither too few to be incomplete nor too many to be unwieldy.
Completeness4/5
The toolkit covers CRUD for scenes, actors, triggers, variables, custom events, and scripts, plus building, emulation, and sprite generation. Minor gaps include lack of dedicated list tools for variables and custom events (though scoped via read_scene and inference), and no direct background/palette management despite backgroundId references.
Average 4.3/5 across 23 of 23 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions return shape and references external skill for semantics. It does not disclose idempotency, side effects, or authorization requirements, lacking sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. Every sentence adds value: first states action, second adds shape detail and reference. No waste.
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 (no output schema, 0% schema coverage, no annotations), the description is incomplete. It lacks detail on locator construction, error cases, and return format beyond shape. The external reference partially compensates but is not sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'locator' parameter structure beyond 'given owner and key'. The complex schema with multiple shapes is left undocumented, requiring inference from the schema itself.
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 it returns ScriptEvent[] for a given owner and key, with specific detail on event shape. It distinguishes the tool from siblings like patch_script (write) and other read tools by focusing on script retrieval.
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 reading scripts but does not explicitly state when to use vs alternatives or provide exclusions. No mention of when not to use or comparison with siblings like patch_script for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the file path, trigger behavior (script/leaveScript), tile-based coordinates, and the MAX_TRIGGERS=30 limit, but does not mention permissions, error handling, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three efficient sentences with front-loaded action. Every sentence adds value: file path, trigger definition, and constraint. No 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?
Given the moderate complexity (7 params, no output schema), the description covers the core purpose and a key constraint but omits success/error expectations and the fact that script parameters are not part of this 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?
Schema coverage is 100%, so baseline is 3. The description adds general context about trigger behavior (script/leaveScript) not present in the schema, but does not elaborate on individual parameters beyond what the schema already 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?
Description states verb 'Append a new trigger file' and clearly identifies the resource (trigger in a scene). It defines what a trigger does (fires script on enter/exit), setting it apart from siblings like create_actor or create_scene.
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 adding trigger zones but does not explicitly state when to use this tool vs alternatives such as create_actor. No when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It implicitly describes a read operation by returning data, but does not explicitly state that it is safe or non-destructive. Additional context about permissions or rate limits is missing.
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 plus a follow-up pointer, with no wasted words. It is front-loaded with essential 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 tool with one parameter and no output schema, the description adequately lists the returned fields and directs to a related tool. Minor missing details like pagination or default ordering but overall sufficient.
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 parameter 'sceneId' is required but the description does not explain its format, constraints, or how to obtain it. With 0% schema coverage, the description should compensate, but only vaguely refers to 'a scene'.
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 'list', the resource 'actors', and the scope 'in a scene', while listing specific fields returned. This distinguishes it from sibling tools that perform CRUD or other operations.
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 context by suggesting 'Use read_script to fetch event bodies,' indicating a workflow. However, it does not explicitly state when not to use this tool or compare to other listing tools like list_scenes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the script body starts empty and that patch_script is needed to populate it. However, with no annotations, it fails to mention potential side effects (e.g., file creation on disk), permissions required, or reversibility, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the primary action, and provides essential context without any filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior (creation, empty body) and hints at the next step (patch_script). It lacks details on error handling (e.g., duplicate names) or return values, but given the simple nature of a create tool and the absence of an output schema, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for 'name' (seeds slug), 'symbol' (override GBVM), and 'description' (GUI display). No additional guidance is offered.
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 creates a new script resource file under project/scripts/ and specifies that custom events are reusable scripts called from scenes, actors, or triggers. The verb 'create' and resource 'custom event' are specific, and the purpose is distinct from sibling tools like delete_custom_event or patch_script.
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 context: custom events are reusable scripts, and the script body starts empty, with guidance to use patch_script to populate it. It implies the tool is for creating the initial file, but does not explicitly state when to use it over alternatives or when not to use it, missing exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It explains that the tool reads the full log from the last build and offers an optional tailLines parameter. However, it does not specify behavior when no build has occurred (e.g., returns empty or error), which is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences. The first states the core purpose, and the second adds usage guidance and parameter hint. No unnecessary words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description is largely complete: it explains what is read, when to use it, and the optional truncation. The only missing detail is the behavior when no build log exists, but given the tool's simplicity, this is a minor omission.
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% for the single tailLines parameter, and the description merely rephrases the schema's meaning ('Optionally returns only the last N lines'). It adds no new information beyond what the schema already provides, meeting the baseline but not exceeding it.
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 'Read the full stdout+stderr captured from the last build_rom invocation,' specifying the exact resource and providing a direct alternative to guessing when a build fails, which distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool 'INSTEAD of guessing when a build fails,' providing clear context for when to use it. It does not explicitly list when not to use it, but no alternatives beyond guessing are needed given the tool's focused purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses invocation of an external CLI, capture of stdout/stderr to a compile log, the return object shape, and a required environment variable. It could mention potential overwriting of output files, but overall it's transparent.
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 five sentences, each adding value: action, log capture, return format, usage emphasis, and requirements. It is front-loaded with the verb and resource, and no filler is present.
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 no output schema, the description describes the return object and links to read_compile_log via naming convention. It mentions environment requirements. For a build tool, it covers the main behavioral and usage aspects, though failure modes could be elaborated.
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 100% and both parameters have descriptions. The tool description does not add extra meaning beyond the schema; it only mentions compilation in general. Baseline 3 is appropriate since the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool invokes an upstream CLI to compile a GB Studio project to ROM. It immediately distinguishes itself from sibling editing/reading tools by being the build step, and the mention of 'ALWAYS call this after structural edits' reinforces its unique 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 gives explicit when-to-use guidance ('ALWAYS call this after structural edits before declaring work done') and prerequisite (env var). It doesn't explicitly state when not to use or list alternatives, but the context among siblings makes it clear, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions a heuristic quality check and the force parameter to bypass it, and notes 'No API key required.' However, it does not disclose whether the tool modifies project files, what permissions are needed, or what the return value is. Some behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 100 words) and front-loads the main purpose. It covers all necessary details without redundancy. Minor improvement could be structuring with bullets, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema), the description covers the main behaviors, constraints, and edge cases (quality check, input requirements). It could be more complete by stating the return value or effect on the project, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description adds significant context for animationType (sprite sheet requirements) and the quality check. It explains the behavior of each parameter beyond the schema, e.g., 'force: true' skips the check. Only animationType lacks a description in schema, but the description compensates.
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 converts a local PNG/JPG to a 4-colour DMG-quantised GB Studio sprite. It specifies the animation types and sprite sheet constraints, distinguishing it from sibling tools like generate_sprite.
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 constraints for when to use this tool (e.g., input must be a sprite sheet for multi/multi_movement). It does not explicitly mention alternatives or when not to use it, but the context is sufficient for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses hardware limits, default coordinate type, and that actor won't render without spriteSheetId. Missing error handling details but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences, front-loaded with action and location, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and hardware constraints, description covers key behaviors. Could mention return value but not critical.
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 covers all parameters, but description adds context: default coordinate type, hardware caps relevance, and empty spriteSheetId behavior, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: creating a new actor in a scene, with specific file location and hardware caps. It distinguishes from siblings like create_trigger by focusing on actors.
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?
Implies use for adding actors to scenes, mentions hardware caps and optional sprite, but does not explicitly state when to use this tool vs alternatives or prerequisites (e.g., scene must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool refuses deletion if any script references the customEventId, that force=true can override, and that the file (including its body) is deleted. It does not mention all side effects (e.g., impact on dependent scripts after forced deletion), but is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action in the first sentence, and no wasted words. Every phrase adds value.
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 no annotations or output schema, the description covers the key behaviors (refusal, force, deletion). It lacks details on return values or error handling beyond refusal, but for a delete tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds behavioral context for 'force' (override refusal) but does not significantly enhance meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'custom-event (script resource) file'. It specifies the location 'under project/scripts/' and distinguishes from sibling delete tools like delete_scene by mentioning it's a script resource. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to delete a custom event) and mentions the refusal behavior when there are references, with a force option to override. However, it does not explicitly state when not to use or provide alternatives, though the context implies it's for deletion only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains sequential operation application (indices reflect state after prior ops), atomic persistence to disk, and the dialogue width budget check with force override. Missing details on error handling or permissions, but the level of detail for a mutation tool is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding unique value: operation definition, sequential behavior, persistence and budget constraints. No redundant or unnecessary phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, nested objects, no output schema), the description covers core behaviors: operation types, sequential index interpretation, atomic writes, and budget enforcement. Missing return value info (expected since no output schema) and error handling details, but fairly complete for a patch 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?
Schema description coverage is 50%. The description adds meaning for force and widthBudget (skip budget check/override char limit) and explains operation semantics (index state after prior ops). However, the complex locator parameter is not elaborated beyond mentioning it in the context of persisting to a scene or custom event. The operations structure is partially detailed, but the locator remains abstract.
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 applies operations (insert/replace/delete) to a ScriptEvent[] array. It specifies what it does, the operation types, and contrasts with unsupported full-array replacement, distinguishing it from sibling tools like read_script or delete_custom_event.
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 context on when to use force (skip budget check) and notes that full-array replacement is unsupported (use delete+insert). However, it does not explicitly state when to prefer this tool over alternatives like delete_custom_event, though sibling names imply such distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return format (base64 PNG), default file source (latest.png), and alternative filename support. Does not address potential errors (e.g., file not found) but behavior is well-scoped and predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and return type. Every word adds value with no redundancy. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and no output schema, the description adequately explains the return value and usage. Could optionally mention error handling, but not required given the tool's straightforward nature.
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 100% with a clear parameter description. The tool description also mentions the default and alternative usage, which echoes schema info but adds no significant new semantics. Per guidelines, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an emulator screenshot as a base64 PNG image content block. It specifies the resource (emulator screenshot) and the action (return). Distinguishes from siblings by its explicit dependency on run_emulator.
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?
Explicitly instructs to call AFTER run_emulator, providing clear usage context. Also explains default behavior and how to specify a different filename. While no explicit when-not to use, the single-purpose nature makes it clear when this tool is applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavior. It discloses the exact content returned and what is omitted. For a read operation, this is sufficient. No contradictions with annotations (none provided).
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, no redundancy. The first sentence states the purpose and output, the second clarifies exclusions. Every word earns its place.
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?
Given one required parameter, no output schema, no annotations, and being a read operation, the description fully explains what the tool does and what it returns. No significant gaps remain.
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?
Only one parameter (sceneId) with 100% schema coverage. The schema already describes it as a UUID string. The description adds no further detail beyond what the schema provides, so it meets the baseline but doesn't add extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the full structured representation of one scene, listing exactly what is included (metadata, actors, triggers, scripts) and what is excluded (backgrounds, palettes, sprites). It distinguishes from sibling tools that fetch other assets.
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 guidance on when to use this tool (to get scene structure) and when not to use it (for backgrounds, palettes, sprites) by stating to fetch those separately. It implies alternative tools but doesn't name them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses auto-assignment of id, auto-derivation of symbol from name with an example, and the 16-bit signed integer range. With no annotations provided, this covers important behavioral traits, though edge cases like symbol conflicts are not discussed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no redundant words, front-loaded with the core action. Each sentence adds distinct value: purpose, auto details, and usage guidance.
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?
Covers creation, auto-assignment, symbol derivation, variable range, and linkage to set_variable. For a simple tool with no output schema or annotations, it is reasonably complete, though it could mention uniqueness or conflict behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining auto-derivation of symbol and providing a concrete example ('curQ' -> 'cur_q'). This clarifies meaning beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Append a new Variable entry to project/variables.gbsres', which clearly identifies the resource and action. Distinguishes from sibling set_variable by noting that initial value is set separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use this tool vs set_variable by explaining variable range and recommending set_variable for initial value. Does not explicitly exclude other tools but differentiates from the key sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Reveals output format, optional mid-run screenshot, and setup requirements. Does not detail error handling or stderrTail content.
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 cover launch mechanism, output, retrieval, and setup. No unnecessary words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 4 params, and no output schema, the description is largely complete. Covers output structure, retrieval, setup constraints, and parameter limits. Could add more on error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning beyond schema: explains input timeline structure, duration cap, and extra screenshot timing. Provides context for romPath absolute path.
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?
Clearly states it launches a ROM via a scripted runner with input timeline and captures screenshots. Distinguishes from sibling 'screenshot' tool by specifying retrieval method.
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?
Explains when to use (launch ROM with inputs) and provides setup instructions (build runner or set env var). Notes duration cap and suggests splitting for longer walkthroughs, but does not explicitly exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the cross-reference check runs, force skips it, and that the trigger's onEnter/onLeave scripts are removed along with the file. This provides comprehensive behavioral 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 three sentences long, front-loaded with the core purpose, and each sentence adds critical value: purpose, safety behavior, and side effects. No wasted words.
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 simple delete operation with no output schema, the description is complete. It covers what is deleted, the safety check, the force option, and the consequence of removing scripts. No gaps for an AI agent to misinterpret.
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 100% with descriptions for all three parameters. The description reinforces the 'force' parameter's purpose (skip cross-reference check) but does not add significant new meaning beyond what the schema already 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 clearly states that the tool deletes one trigger file from a scene's triggers/ directory, with a specific verb and resource. It distinguishes itself from sibling tools like delete_actor and delete_scene by focusing on triggers.
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 explains when to use the tool (to delete a trigger file) and notes that a cross-reference check runs for safety, with the option to force override. However, it does not explicitly compare to alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists scenes and returns specific fields, but does not disclose other behavioral traits (e.g., read-only nature, error conditions, or whether it depends on an active project). It 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first explains purpose and output, second provides usage guidance. No extraneous words.
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 parameterless tool with no output schema, the description fully covers purpose, output fields, and usage context. No additional information is necessary.
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 0 parameters, so baseline is 4. No parameter documentation is needed, and the description does not detract.
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 'List every scene in the active project' with a specific verb and resource, and lists the returned fields. It distinguishes itself from sibling tools like read_scene by noting it returns all scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use this for orientation before reading a specific scene,' providing clear context for when to use this tool versus alternatives like read_scene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool refuses if external scripts reference the actorId (with example path), that force skips the check, and that the actor's own scripts are deleted with the file.
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 long, front-loaded with the action, and every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description covers the core behavior, refusal condition, force option, and actor script handling. It could mention prerequisites like scene existence, but is still comprehensive for a deletion 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?
Schema coverage is 100% with descriptions for each parameter. Description adds behavioral context for 'force' (skip cross-reference check) and clarifies that actor's own scripts are not counted as external references, which adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete one actor file from a scene's actors/' directory.' This is a specific verb+resource, clearly distinguishing it from sibling tools like delete_scene or delete_trigger.
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 explains when to use (delete an actor) and when it refuses (external script references). It also mentions the force option to override. However, it does not explicitly contrast with alternatives like delete_scene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully explains behavioral traits: it performs a cross-reference check, refuses deletion if references exist unless force is true, and warns of compile errors when force is used. This covers key behavioral aspects beyond the basic delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the main action, and the second covers the exception and force option. It is front-loaded and easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, refusal condition, and force behavior. There is no output schema, and the description does not mention the return value or success indication. For a simple delete tool, this is mostly adequate, but a mention of success response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, but the description adds value by explaining the cross-reference check and the effect of the force parameter (override with potential compile errors). Coverage is 100%, so baseline is 3, but the enrichment justifies a higher score.
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 removes a Variable entry from a specific resource (project/variables.gbsres), which is a specific verb and resource. It distinguishes from sibling delete tools like delete_scene by specifying the resource type and the cross-reference checking behavior.
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 explains when the tool refuses (if references exist) and how to override with force, including the consequence of compile errors. It implies when to use the tool (to delete variables) but does not explicitly state when not to use it or mention alternatives, though the context of sibling tools provides some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It fully discloses the process: calling image-generation provider, quantisation to 4-colour DMG, file writing (sprite.png + .gbsres), return value spriteSheetId, frame size, call count per animation type, and the heuristic quality check with force flag to override. No critical behaviors are hidden.
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 detailed and front-loaded with the main action. It is structured logically but slightly longer than necessary; however, given the tool's complexity, each sentence provides value. Could be slightly more concise but remains effective.
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?
No output schema exists, so the description appropriately explains the return value (spriteSheetId) and output files. It covers input (prompt, name, animationType), process (provider, quantisation, quality check), and output. For a tool with this complexity, the description is 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?
Schema coverage is 80% (4 of 5 parameters have descriptions). The description adds meaning beyond schema: explains that animationType impacts number of calls, provider can override env default, prompt gets auto-wrapped, force skips quality check. The animationType parameter lacks schema description but is clarified in the description.
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 generates a GB Studio sprite from a text prompt, specifies the output files and returned spriteSheetId, and distinguishes itself from sibling tools like convert_image_to_sprite by focusing on text-to-sprite generation.
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 guidance on when to use this tool (text prompt to sprite) and notes animation types trigger multiple calls. While it doesnt explicitly list when not to use it, the context around provider selection and quality check is helpful. Would benefit from mentioning alternatives like convert_image_to_sprite for image input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool 'preserves every other setting field' and that the sceneId must be valid. Without annotations, the description carries the burden and does so well for a simple mutation, though it lacks details on error handling or return 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?
Two sentences with no wasted words. First sentence defines action and location; second sentence adds critical constraint. Front-loaded with key information.
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?
Fully covers the tool's behavior for a single-parameter mutation with no output schema. Includes input requirement, consequence, and scope of effect (preserves other fields). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond the schema. The schema only states 'Must exist in project/scenes/', while the description explains the consequence of invalid input ('build_rom will fail') and the exact file being patched ('project/settings.gbsres').
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?
Clearly states the action ('patch'), resource ('startSceneId in project/settings.gbsres'), and purpose ('so the game boots into the given scene'). Distinguishes from sibling tools like list_scenes or create_scene by specifying a unique mutation operation.
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?
Explicitly states that the sceneId must exist on disk and that failure to do so will cause build_rom to fail. Provides context for when to use this tool (to change start scene) but does not explicitly list alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: name slugification, collision suffixes, type change resetting config, default size, scrolling, and lack of background creation. No contradictions.
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?
Concise paragraph with no wasted words. Front-loaded with main action, each sentence adds value. Length is appropriate for the tool's complexity.
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?
Comprehensive for most aspects but does not describe return values. No output schema exists, so noting what the tool returns would improve completeness. Otherwise covers behavior well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the input schema: name slugification/collision, type uppercase requirement and consequence, default size and scrolling, backgroundId usage. Schema coverage is 100% but description enriches every 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 it creates a new scene folder and file, differentiating it from sibling tools like read_scene, delete_scene, and list_scenes. It specifies the location and naming behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on scene type selection (must be uppercase, deliberate choice due to engine config reset) and background handling (not created, must be provided or added later). Lacks explicit when-not-to-use but offers solid context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses modification of start scene's script, the value constraint (signed 16-bit), and the reason for necessity (no default-value field). Could mention if previous initialization is overwritten, but overall thorough.
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?
Front-loaded with main action, three concise sentences each adding essential information (prerequisite, limitation, alternative). No fluff or repetition.
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?
Given no output schema and only 2 params, description adequately covers all needed context: game-specific use case, prerequisite, alternative tool for different scenarios. No gaps for agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only variableId described in schema). Description adds meaning: value must fit signed 16-bit range, variable must already exist. Compensates for schema gaps with practical constraints.
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 initializes a variable at game start by inserting/updating an event, specifying the resource (variable), context (GB Studio 4.x), and distinguishing from siblings like create_variable (adding new variable) and patch_script (in-game changes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (game start initialization) and when not to (in-game changes, use patch_script). Also provides prerequisite: variable must exist, so call create_variable first. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses recursive deletion, unconditional guard for start scene, conditional reference check, and the fact that force only skips the reference check. Also warns there is no undo.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action, then conditions and recommendations. Every sentence adds value without 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?
With 2 fully described parameters and clear behavioral details, the description is complete for a delete tool. It covers prerequisites, limitations, and consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds meaning: explains sceneId is a UUID, and force skips cross-reference check but not the start-scene guard. This clarifies the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it recursively deletes a scene folder, specifying the files involved (scene.gbsres, actors/, triggers/). It distinguishes itself from sibling tools like delete_actor and delete_trigger by focusing on the scene itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states conditions for use (not start scene, no references) and provides the force flag as an override for references. Recommends using list_scenes to find target IDs and warns about no undo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/gbs-toolkit/mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/gbs-toolkit/mcp-server)

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/gbs-toolkit/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/gbs-toolkit/mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gbs-toolkit/mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server