Skip to main content
Glama

Renforge New Game

renforge_new_game

Launch a new Ren'Py game from a project path, starting at the start label and polling launch status until it is running.

Instructions

Start at the start label; poll launch status when still starting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
versionNostable
project_pathYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

C2/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not say what starting a game does, whether it is destructive to an existing session, what permissions or preconditions are needed, or what happens on success or failure. The mention of polling suggests a two-step flow but is too vague to be actionable.

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

Conciseness3/5

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

The description is short and front-loaded around the start label, but it mixes behavioral instructions ('poll launch status') with unclear terminology. It is not bloated, but its brevity comes at the cost of clarity.

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 an output schema exists, return values need not be explained, but the description omits parameter meaning, preconditions, and how this tool differs from renforge_launch/renforge_launch_status. For a game-starting tool with zero schema coverage, it is substantially incomplete.

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 says nothing about either parameter (project_path, version). With two parameters completely undocumented and no description to compensate, an agent cannot know what project_path should point to or what version accepts.

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

Purpose2/5

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

The description 'Start at the ``start`` label; poll launch status when still starting' hints at launching a game and interacting with a 'start' label, but the name renforge_new_game is not clarified beyond a snippet about labels and polling. It is unclear whether this tool starts a new game session or something else, and it overlaps confusingly with siblings like renforge_launch and renforge_launch_status.

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

Usage Guidelines2/5

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

There is no explicit when-to-use or when-not-to-use guidance; the phrase about polling launch status implies follow-up with renforge_launch_status but does not name it or give conditions. An agent would have to guess whether to call this, renforge_launch, or renforge_jump.

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