RenForge MCP
Server Quality Checklist
Latest release: v0.7.1
- Disambiguation3/5
The tool set covers many distinct capabilities, but several tools overlap: renforge_info and renforge_context both report active project details, renforge_advance is a subset of renforge_control, and renforge_game_state vs renforge_game_state_compact are near-duplicates. Additionally, renforge_screenshot and renforge_capture_screenshot have fuzzy boundaries, and renforge_inspect_project/renforge_parse_lint have no descriptions.
Naming Consistency4/5Most tools follow the consistent renforge_verb_noun pattern (set_var, get_var, click_element, position_element), but a few are bare nouns (renforge_info, renforge_context, renforge_assets) and there are minor deviations like renforge_screenshot vs renforge_capture_screenshot. The prefix anchors the naming well.
Tool Count1/5With 54 tools, this is at the extreme end of the scale. Even for a broad Ren'Py automation domain, the number is excessive and many tools could be consolidated (docs tools, translation tools, screenshot variants). The calibration explicitly marks 50+ as extreme mismatch.
Completeness5/5The tool surface is remarkably comprehensive, covering the full lifecycle: project discovery, launching, live control, scene observation, input simulation, save/load, scenario running, error diagnostics, asset management, translation, building, and documentation lookup. There are no obvious dead ends for the intended use cases.
Average 3.3/5 across 54 of 54 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 198 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is a single sentence with no details about side effects, return behavior, permissions, or operational constraints. It does not disclose any behavioral traits beyond the basic 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it is under-specified for the tool's complexity, which slightly reduces the score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no parameter documentation, and no behavioral details. The presence of an output schema does not compensate for the complete lack of input and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 8 parameters and 0% schema description coverage, the description adds no meaning to parameter names. It only implies 'saved frames' (before_path and after_path) but leaves region_x, max_shift, threshold, etc., unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'estimate' and resource 'stable visual translation between two saved frames.' It is distinct but does not explicitly differentiate from sibling tools like renforge_diff_screenshots, so it earns a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. The description provides no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the tool blocks, modifies game state, requires specific conditions (e.g., active dialogue), or what happens if no dialogue exists. This leaves significant uncertainty for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, which is structurally concise. However, it is under-specified to the point of being vague, so the brevity is not an asset here. The structure does not add clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present but not described, and a sparse input schema, the description is insufficient. It does not explain return values, side effects, or the broader interaction flow, leaving the context incomplete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (project_path) with no description, and schema description coverage is 0%. The tool description does not mention the parameter at all, so the agent receives no semantic guidance about what project_path should contain (e.g., path format, scope).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Advance') and resource ('current dialogue'), making the core action clear. It distinguishes somewhat from siblings like select_choice (which selects options) and send_input (which sends arbitrary input), but lacks detail on what 'advance' entails (e.g., next line, confirm, skip).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There are no exclusions, prerequisites, or mentions of related tools, leaving the agent without context for choosing this over select_choice or control.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'persist a screenshot,' leaving out side effects such as file overwriting, naming conventions, or whether it captures the current screen or processes an input. This is a significant gap for a write 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words, front-loading the action 'Persist' and specifying a location. While efficient, it is arguably too terse given the tool's complexity, but it earns a 4 for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 undocumented parameters, no annotations, and a one-sentence description, the tool definition is severely incomplete. It fails to explain any parameter, usage context, or behavioral detail, making it inadequate for an agent to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 13 parameters with zero description coverage, and the description mentions none of them. It does not clarify the required project_path or the meaning of crop, scale, grid, or other fields, leaving the agent completely without guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Persist' to clearly indicate a save/write operation, and identifies the resource as a screenshot destined for a 'controlled capture directory.' This distinguishes it from a simple screenshot tool, though it does not explicitly name sibling alternatives like renforge_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or appropriate contexts. It is a bare statement without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, what side effects exist, or what 'bounded' means. The ambiguous 'or' between 'bridge exceptions' and 'crash-file diagnostics' adds confusion about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient, but the over-terseness creates ambiguity. The word 'bounded' seems meaningful but is left unexplained, so the structure is not as clear as it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks essential operational context. It does not clarify the meaning of the required 'project_path' or the 'since' parameter, nor does it describe the nature of the returned diagnostics. The agent is left guessing about prerequisites and result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate for the parameters, but it doesn't. It fails to explain what 'project_path' refers to or how the integer 'since' parameter works, despite the hint from 'recent'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'recent bridge exceptions or bounded crash-file diagnostics', which is a specific resource and distinguishes it from sibling tools like renforge_parse_lint. However, the term 'bounded' is vague and the 'or' is ambiguous, so it doesn't fully reach a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions. It simply states what it does without contextualizing when to invoke it, such as after a crash or during debugging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It implies a read-only operation via 'Report' but does not mention failure modes, side effects, or any special behavior. The description is too minimal to be transparent about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant details. It is appropriately concise, though it sacrifices essential information for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, 1 required, 0% schema description coverage, no annotations), the description is entirely inadequate. It provides no parameter semantics, usage context, or behavioral detail. Even with an output schema present, the agent cannot correctly invoke this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 0% description coverage. The description does not explain the meaning or purpose of any parameter, nor does it clarify how the UI element is identified (e.g., via text, element_id, screen, expected_frame_id). The agent is left without guidance for filling in fields correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Report') and resource ('focus bounds and rendered painted bounds for a UI element'). While it distinguishes itself from some siblings by mentioning 'focus bounds', it does not explicitly differentiate from renforge_get_displayable_bounds, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or exclude conditions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. It indicates a read-only operation via 'inspect' and mentions 'active screen' as a precondition, but it does not explain side effects, error behavior, or what happens if no screen is active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, making it efficient. However, its brevity omits important context, though that is more a completeness issue than a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two undocumented parameters, many sibling tools), the description is too sparse. It does not explain what 'JSON-safe scope' means, how it differs from other inspect tools, or provide enough context for correct invocation. The presence of an output schema does not compensate for the lack of input parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters (name, project_path) with no descriptions; the description adds no parameter semantics. Since schema description coverage is 0%, the description should clarify what these parameters refer to, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Inspect' with a clear resource ('an active screen's layer, JSON-safe scope, and arguments'), making the primary function clear. It does not explicitly contrast with sibling inspect tools, but the name and resource disambiguate it from 'inspect_image' and 'inspect_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It only states what the tool does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action but does not clarify whether the export writes to a file, returns a string, or has side effects. The format 'plain text' is mentioned but not the actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is appropriately sized for a simple tool, though it is somewhat under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description need not explain return values, but it still lacks context about the optional language parameter and the intended use case. The tool is simple, but the description could be more helpful with a sentence about when to use it or what the output represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 the 'language' or 'project_path' parameters. While 'project_path' is self-explanatory, 'language' is ambiguous and could require clarification about accepted values or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (export) and resource (the game's dialogue), with a specific output format (plain text). It is distinct from sibling tools like renforge_list_choices or renforge_generate_translations, though it does not explicitly mention those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of context, prerequisites, or when to prefer other tools such as renforge_scan_project or renforge_inspect_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions the possible return values but does not explain error conditions, what happens if no launch exists, whether the call is read-only, or if there are side effects. Minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It is concise and to the point, though it omits useful context that could be added without much bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, a terse description, and no annotations, the description is under-specified. It conveys the return values but lacks parameter explanation, usage context, and any relationship to sibling tools. The presence of an output schema does not mitigate the need for parameter and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, project_path, is a bare string with no schema description. The tool description does not mention the parameter at all, so the agent has no information about what project_path should be or how it relates to the status query. Schema coverage is 0% and the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and clearly identifies the resource: the status of a background launch, listing the exact possible values. It distinguishes itself from sibling tools like renforge_launch by focusing on status rather than initiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites (e.g., having a launched background process), no mention of polling patterns, and no contrast with alternatives such as renforge_poll_events or renforge_launch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the return ('bounds') but does not explain failure behavior, side effects, or how parameters like threshold and region affect the search. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of redundant information. Every word contributes to conveying the tool's core purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With eight parameters and no annotations, the description is insufficient for an agent to invoke the tool correctly. The existence of an output schema does not compensate for missing parameter guidance, and the description omits important behavioral details like matching logic and failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 of the eight parameters. Terms like 'threshold', 'max_matches', and region coordinates are left undefined, requiring the agent to guess or rely on defaults without understanding their impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('find'), a resource ('template image'), scope ('current frame'), and result ('return its bounds'). This distinguishes it from sibling tools like renforge_inspect_image or renforge_get_displayable_bounds, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools such as renforge_find_references or renforge_hit_test exist, but no comparison or contrasting context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the exclusion of screenshot payloads, which is a useful behavioral note, but it does not disclose side effects, permissions, or state changes beyond the basic save/load/list actions. This is insufficient for a tool that likely mutates save data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the core function. It is efficient and avoids unnecessary words, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no schema descriptions, and the description omits any parameter guidance. While an output schema exists, the description is still incomplete for a tool with multiple actions and parameters. It provides only a minimal overview and leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description does not explain any of them. The concepts of 'named save slots' imply the 'slot' parameter, and 'save, load, or list' imply the 'action' parameter, but no explicit mapping or guidance is provided for 'regexp', 'extra_info', or 'project_path'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: saving, loading, and listing named save slots. It also adds a distinguishing detail ('without screenshot payloads') that differentiates it from potential alternatives. However, the multiple actions are not explicitly tied to the 'action' parameter, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without screenshot payloads' implies a use case where screenshots are not needed, but the description does not explicitly state when to use this tool instead of others, nor does it mention any alternatives. Usage context is present but not fully developed.
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?
With no annotations, the description carries the behavioral burden. It does disclose the default summary-only behavior, the opt-in nature of sections, and pagination support, which are useful. However, it does not explicitly state whether the operation is read-only, safe, or has side effects, nor does it clarify what 'sections' entail. This partial disclosure gives some context but leaves gaps for a tool that has no annotation safety indicators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, terse sentence that front-loads the purpose and then packs in key behavioral details. Every word earns its place—there is no fluff or repetition. This is an example of efficient, well-structured writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, no annotations, and sits among a large family of sibling tools, yet the description is minimal. It does not explain what 'sections' are, what a typical summary includes, or how `symbol` and `file_glob` affect the scan. While an output schema exists, the description still needs enough context to guide selection and invocation, which is lacking here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 adds meaning for `sections` (opt-in) and `limit`/`offset` (pagination), but it leaves `project_path`, `symbol`, and `file_glob` unexplained. This partial coverage is not enough for a tool with six parameters; a more thorough description should at least hint at the role of `symbol` and `file_glob`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Scan scripts') and a specific resource ('scripts'), which is a verb+resource pattern. It also notes key behaviors (summary-only default, opt-in sections, pagination), which adds clarity. However, it doesn't distinguish this tool from siblings like `renforge_inspect_project` or `renforge_find_references`, so it misses the opportunity to differentiate within the tool family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description purely states what the tool does without mentioning typical use cases, prerequisites, or exclusions. It does not say 'use this when you need a summary of scripts' or 'for other analysis, see X', so it fails to aid selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It fails to state whether the operation is read-only, how 'orphaned' or 'missing' is determined, whether it modifies files, or what output to expect. This lack of context leaves the agent uncertain about side effects and analysis semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that efficiently communicates the core purpose without filler. It earns its place by being front-loaded and actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema may define return values, the description is too minimal for effective tool selection. It lacks usage context, parameter details, and behavioral notes, making it incomplete for an agent comparing many sibling tools. For a complex analysis task, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, project_path, has no schema description, and the tool description doesn't explain its format, required type, or acceptable values beyond implying it points to the project. The description adds minimal meaning over the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' and identifies the resource as 'orphaned and missing image/audio assets in the project.' This clearly distinguishes it from sibling tools like 'renforge_find_references' and 'renforge_scan_project' by targeting asset health specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives. It does not mention prerequisites, typical scenarios, or exclusions. The use case is only implied by the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions 'optional frame/state safety guards' which hints at conditional behavior, but it does not explain what happens when a guard fails, whether the click is suppressed or errors, or any side effects. This is insufficient for an action 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the primary action. Every word contributes value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no annotations, this description is too sparse. It doesn't explain the coordinate_space semantics, the behavior of safety guards, or how the tool integrates with the rest of the workflow. The output schema exists but is not referenced, and the description alone does not enable a confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 only adds meaning through the phrase 'screen coordinates' for x/y and 'frame/state safety guards' for expected_frame_id/expected_state. It does not explain coordinate_space, project_path, or any other parameter. The compensation is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clicks screen coordinates, which is a specific action on a specific resource. It distinguishes itself from sibling tools like renforge_click_element by emphasizing raw screen coordinates, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where coordinate-based clicking is preferred over element-based tools, nor does it indicate when the safety guards are necessary. No exclusions or alternatives are named.
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?
With no annotations, the description carries the behavioral burden. It does disclose that matching is 'exact' and that text interpolations are included, but it omits other important traits such as search scope, case sensitivity, or pagination behavior. Still, it is more transparent than a bare 'find'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb and object, and every phrase adds value. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the tool has five parameters, no annotations, and no parameter descriptions. The description covers only the core purpose and leaves out operational context, making it insufficient for confident usage beyond guessing from parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 of the five parameters. Only 'symbol' is implied, while project_path, file_glob, limit, and offset lack any semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific: it names the action ('Find'), the resource ('exact Ren'Py definitions/usages'), and adds a distinctive scope ('including text interpolations'). This clearly distinguishes it from sibling tools like renforge_search_docs or renforge_scan_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor are there any prerequisites, exclusions, or typical scenarios described. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states the action itself but does not mention whether hovering triggers UI state changes, whether it requires the element to be visible on screen, what happens if the element is not found, or whether it is a safe read-like operation. The lack of such disclosure is a significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise, front-loaded with the action, and contains no unnecessary words or repetition. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no annotations, the description is far from complete. It does not explain selection strategies, how the tool locates the element, whether it scrolls or waits, or what the output schema contains. The description is minimally adequate for a simple action but severely under-specified for an agent to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with 0% description coverage, so the description must compensate by explaining how to identify the target control. However, the description only says 'a visible control' and provides no guidance on using text, element_id, screen, exact, expected_frame_id, or project_path. This leaves the agent with almost no help in selecting correct parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move the pointer') and the target ('a visible control'), and explicitly distinguishes it from clicking ('without clicking it'). This differentiates it from sibling tools like renforge_click_element and renforge_click_at.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for hovering over UI elements, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It provides only minimal context for when this action is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description responsible for conveying side effects and behavioral context. The description introduces the term 'frame guard' without explanation and does not clarify whether the operation is read-only, requires a running game, or has other side effects. This is a significant gap for an automation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core action and resource. It contains no filler and communicates the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 4 parameters, 0% schema description coverage, and no annotations. The description fails to explain key parameters or usage context, making it insufficient for an agent to invoke correctly without additional guesswork. The 'frame guard' phrase adds ambiguity rather than clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions none of the parameters (text, screen, element_type, project_path). The description adds no meaning beyond the schema, leaving the agent to guess parameter semantics. This is a critical shortfall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List'), a clear resource ('visible focusable Ren'Py controls'), and additional details ('with bounds and frame guard'). This clearly distinguishes it from sibling tools like renforge_get_ui_element_bounds or renforge_list_choices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting UI elements but does not explicitly state when to use this tool over alternatives or mention any exclusions. Sibling tools exist for related but distinct purposes, yet no comparison or 'use this instead' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic operation and omits important traits like persistence, overwriting behavior, whether the game must be running, or error conditions. This is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words or repetition. It is optimally concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description is incomplete given zero annotations and 0% parameter coverage. It lacks context about side effects, execution requirements, return values, or error behavior, which an agent needs to invoke it correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning about the parameters (project_path, name, value). The names are somewhat self-explanatory, but the description does not compensate for the lack of schema documentation, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' and names the resource 'a variable in the running game's store namespace', clearly distinguishing it from siblings like get_var. It is unambiguous and immediately conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description and tool name: if you need to set a variable, use this tool. However, there is no explicit guidance on when to use it vs alternatives such as eval or game_state, nor any exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It mentions 'clean up' as a side effect, but does not explain what cleanup involves, whether the action is destructive, whether it affects saves, or what happens if no game is running. This omits critical details for a stopping 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise, and front-loaded with the primary action. Every word contributes to the core message without extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (one parameter, no nested objects), the description lacks essential context: it does not explain the project_path parameter, the cleanup process, or any preconditions. The presence of an output schema is noted but not described, and the description is insufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, project_path, with 0% description coverage. The description does not mention or explain this parameter at all, leaving the user to guess what path is expected (project directory vs. game executable). This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Stop a running game or cancel its in-progress launch, then clean up.' This uses specific verbs ('stop', 'cancel') and identifies the resource ('game'/'launch'), distinguishing it from 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a game is running or a launch is in progress), but it does not explicitly mention alternatives or circumstances to avoid. It does not reference related tools like renforge_launch_status or renforge_advance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden. It discloses the web DLC requirement but does not mention side effects, whether existing files are overwritten, or the nature of the build output. This is insufficient for a build 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loaded with the action and the key requirement. It is appropriately concise and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no annotations, and an output schema, the description is thin. It does not explain the destination parameter, potential side effects, or when this tool should be chosen over alternatives. The existence of an output schema mitigates some need to explain returns, but not the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description refers to 'the project' (implying project_path) but provides no explanation of the 'destination' parameter, leaving it ambiguous. With no schema descriptions, the description fails to compensate for the missing parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Package' and the outcome 'browser-playable build', and adds the prerequisite 'needs the web DLC'. This distinguishes it from sibling tools like renforge_distribute which may handle other distribution formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a browser-playable build is desired, and mentions a prerequisite (web DLC) but does not provide alternatives or exclusions, such as when to use renforge_distribute instead. No explicit 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?
With no annotations, the description carries the burden of behavioral disclosure. It adds value by revealing that the tool emits correlated business events and that wait_for_effect blocks until the matching event appears. However, it does not disclose potential side effects of disruptive actions like quit, reload_script, or quick_save/quick_load, nor does it mention permissions or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—three sentences that front-load the action list and provide only essential usage details. Every sentence contributes unique information without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 0% schema description coverage, no annotations), the description is insufficiently complete. It covers the core action list and wait_for_effect, but omits meaning for effect_timeout and interaction_id, and lacks caveats for the more disruptive actions, leaving the agent with important gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It explains 'action' by listing valid values and 'wait_for_effect' through blocking semantics, but it leaves 'effect_timeout', 'interaction_id', and 'project_path' completely unexplained, relying only on schema defaults and parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does with a specific verb ('Run') and resource ('runtime action'), and enumerates all supported actions, making the scope unambiguous. However, it does not explicitly differentiate from sibling tools like renforge_advance or renforge_jump that may overlap with specific listed actions, so it stops short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for use: execute this tool when you need to perform one of the listed runtime actions, and it gives explicit guidance on wait_for_effect. However, it does not discuss when to prefer a more specific sibling tool (e.g., renforge_advance) or mention any exclusions, leaving alternative selection implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, prerequisites, or execution behavior beyond the generic 'build'; important details like whether existing distributions are overwritten 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action verb, and no unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A build tool with no annotations and minimal description leaves important context (e.g., build duration, required environment, potential overwrites) unaddressed; though an output schema exists, the description still under-specifies the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema property descriptions are entirely absent, the description adds illustrative values for 'package' and implies project/destination context, but it does not explicitly define the other two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action 'Build' and resource 'desktop distributions', with clarifying examples of package values ('pc', 'mac', 'linux'), distinguishing it from sibling tool renforge_web_build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; it neither states conditions for use nor mentions the web build sibling.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal an important asynchronous behavior (the need to poll launch status), but it omits other key traits such as whether it requires a running game, whether it resets all game state, and what it returns. The description adds some value but is far from complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is action-first and free of fluff. Every word contributes meaning: it states the core action and a critical conditional behavior. It is appropriately concise for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description remains too sparse for a mutation tool with no annotations. It does not explain when to use it, what happens to the current game session, whether it blocks, or how parameters affect the launch. The presence of sibling launcher/status tools makes the missing differentiation more problematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 project_path or version at all. The parameter names are somewhat self-explanatory (project_path is likely the filesystem path), but the description provides no additional meaning, leaving the agent to guess about the version parameter and how it affects behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Start at the start label' clearly conveys the action of starting a new game from the beginning, and the sibling context (renforge_launch, renforge_jump) helps distinguish it. However, it does not explicitly state whether this resets the current game or launches a new process, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a conditional usage hint ('poll launch status when still starting'), which implies a follow-up action using renforge_launch_status. But it does not provide explicit guidance on when to choose this tool over renforge_launch or renforge_jump, nor does it mention exclusions or prerequisites.
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?
With no annotations, the description carries the full burden for behavioral disclosure. It usefully discloses automatic screenshot capture and compact diagnostics on failure, but it omits other important behavior such as state mutation, side effects, or how failures affect execution beyond the stop_on_failure parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the core purpose in the first sentence. The additional sentences about failure behavior and supported actions earn their place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step orchestration, seven parameters, zero schema descriptions, no annotations), the description is too thin. It lacks step object structure, parameter meanings, and operational context, even though an output schema exists and reduces the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 provides a list of supported step actions, which partially clarifies the 'steps' parameter, but it does not explain project_path, timeout, state_profile, stop_on_failure, or capture_on_failure. The supported actions list is helpful but insufficient for seven parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a multi-step live scenario in one call, with a specific verb and resource. It lists supported actions, but it does not explicitly distinguish itself from sibling tools like renforge_autopilot or the individual step tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in one call' implies this is for batching multiple steps, and listing supported actions hints at use cases. However, it never explicitly states when to prefer this over renforge_autopilot or individual step tools, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It does not disclose that evaluating arbitrary Python may have side effects, modify game state, or require the game to be running. It only states the basic 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no filler or redundancy. It communicates the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and a side-effect-capable operation, the description lacks essential context about safety and prerequisites. The output schema may document return values, but the description does not mention potential mutation or the need for a running game.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description should compensate. It implies 'expr' is the expression to evaluate and 'project_path' identifies the project, but neither parameter is explicitly defined. This is insufficient for a 2-param tool with no other documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'evaluate' and a clear resource (Python expression in the running game's store namespace), distinguishing it from variable-specific tools like renforge_set_var and renforge_get_var.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an arbitrary expression needs evaluation, but does not explicitly state when to use this instead of renforge_get_var/set_var or other alternatives. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral transparency burden. It only states a read-like operation without disclosing potential side effects, data size implications (especially with audio), or any performance/rate considerations. The vagueness of 'complete live state' leaves behavioral traits opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose and hints at an optional parameter. It has no wasted words, though it could include more essential details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, which can cover return values, but the description lacks guidance on how to choose between this and the compact variant, and what values 'include' accepts. For a tool with a simple two-parameter schema, the description is adequate but leaves significant contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage in the description, it must compensate for the undocumented parameters. The mention of optionally including 'compact metrics or audio' hints at the 'include' parameter but does not name it or explain its structure (array of strings). The required 'project_path' is not mentioned at all, leaving the parameter meanings largely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the complete live state, which is a specific resource. It distinguishes itself from the sibling renforge_game_state_compact by emphasizing 'complete' and mentioning optional compact metrics or audio, making the scope evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for full state access via 'complete live state' and hints at the compact alternative indirectly, but it does not explicitly state when to use this tool versus renforge_game_state_compact or other siblings. No clear exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool reads from the running game's store, but does not disclose behavior when a variable is missing, whether errors are thrown, or any side effects. The read-only nature is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb+object, no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple two-parameter read tool with output schema present; the description covers the core operation. However, it omits prerequisites such as needing a launched game or behavior when the variable is absent, so not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero description coverage, and the description does not explain 'project_path' or 'name.' Although parameter names are intuitive, the description adds no semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Read' and names resource 'a variable from the running game's store,' clearly distinguishing it from sibling renforge_set_var and other tools. This is direct 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this over alternatives like renforge_eval or renforge_game_state, nor any exclusions or prerequisites. Usage is only implied by the word 'Read'.
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?
With no annotations, the description carries the burden of disclosing behavior. It implies a read-only operation ('List') and describes the output, but does not explicitly state that it does not modify state, whether it requires a running game, or what happens when no menu is present. This is adequate for a simple listing tool but leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part adds value, and it is immediately clear what the tool does and what it returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks crucial context: the meaning of project_path, when to use this over sibling tools, and any error/edge-case behavior. For a simple tool with one parameter and 0% schema coverage, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, project_path, has no schema description and is not mentioned in the tool description. The name suggests it is a path to a Ren'Py project, but this is not explicit. With 0% schema coverage, the description should clarify the parameter's role, and it fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and a specific resource ('on-screen menu choices'), and specifies the output content ('text + index'). It differentiates from siblings like renforge_select_choice (which selects) and renforge_list_ui_elements (which lists UI elements generally). This is a concise 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 Guidelines2/5Does 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. It does not mention that it is a precursor to renforge_select_choice, nor does it clarify when on-screen menu choices are available. The description leaves usage context entirely implied.
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?
With no annotations provided, the description must fully disclose behavioral traits, but it only mentions that the image tag must be 'shown' (implying a prerequisite) and that coordinates are 'logical.' It does not explain failure modes (e.g., what happens if the tag isn't shown), coordinate origin, or relationship to screen coordinates. This leaves meaningful gaps but does add some context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's purpose without redundancy. It is appropriately sized for a simple query tool, and every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, which likely explains the return format, so the description does not need to detail return values. However, it lacks crucial usage context such as when the tag must be currently displayed, how to specify the project path, and how logical coordinates map to the screen. Given the absence of annotations, these omissions make the description only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only clarifies that 'tag' refers to a shown image tag. Project_path and layer remain entirely unexplained. Given three parameters and two required, the description adds minimal semantic value for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Report where a shown image tag was rendered, in logical coordinates.' It uses a specific verb ('Report') and resource ('shown image tag'), and distinguishes it from sibling tools like get_ui_element_bounds by focusing on image tags rather than UI elements. The phrase 'logical coordinates' adds precision about the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Sibling tools such as get_ui_element_bounds or find_image_on_screen exist, but there is no explicit instruction on which tool to choose for which scenario.
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?
With no annotations, the description carries the full burden of disclosure. It explains the behavior of grid, rulers, crosshair_x/y, and the effect of width/height. It is missing details about side effects, return format, or whether the frame is saved/returned, but the core action is clearly scoped.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: the first states the core capability, the second details the measurement guides, and the third offers a practical resolution/aspect-ratio tip. There is no filler or redundancy; the structure is front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no annotations, and no output schema, the description is insufficiently complete. It explains the main purpose and some param semantics, but omits return behavior, side effects, and full parameter coverage for crop/scale, making autonomous correct invocation challenging.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for any of the 12 parameters, so the description provides the only semantic layer. It explains grid, rulers, crosshair_x/y, width/height, and the aspect-ratio behavior, while grouping crop and scale only generically. It leaves many parameter details implicit and says nothing about project_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Capture') and resource ('game frame'), and clearly outlines optional transformations (resizing, cropping, zooming) and measurement overlays. It conveys a distinct purpose, though it does not explicitly differentiate itself from the similarly named sibling renforge_capture_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful context such as capturing at logical resolution and preserving aspect ratio when only one dimension is passed. However, it does not explicitly state when to prefer this tool over alternatives like renforge_capture_screenshot or renforge_diff_screenshots, nor does it give exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, what the return format is, or any limitations. The only extra context is 'offline', which implies no network needs but nothing else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is highly concise and directly communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description does not need to explain return values. It sufficiently states the purpose. Minor gap: it doesn't hint at how results are presented (e.g., snippets vs. doc names), but this is not critical given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'query' string parameter with no description. The description refers to 'keyword', clarifying that the query is a search term. This adds basic meaning but does not provide format details, case sensitivity, or wildcard support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search Ren'Py's offline documentation for a keyword' – a specific verb ('search'), resource ('offline documentation'), and scope ('keyword'). This clearly distinguishes it from sibling tools like get_doc and list_docs based on the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_doc or list_docs. The description only states what the tool does, without mentioning use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only states 'Report', which suggests a read-only action, but does not explicitly confirm no side effects, mention permissions, or clarify what happens with the provided parameters. There is no context on return format or potential costs, making this a significant gap for a tool that likely accesses project 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no superfluous words. It is front-loaded with the action and immediately conveys the core function, exemplifying conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is minimally viable but has clear gaps: it does not explain the project_path parameter, lacks usage guidance, and provides no behavioral context beyond 'Report'. The output schema exists, so return values need not be described, but the description still feels incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 'for a language' which hints at the 'language' parameter, but it does not name or explain the 'project_path' parameter at all. There is no guidance on expected formats, required values, or how the two parameters relate, leaving the agent to infer too much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Report' and the specific resource 'missing dialogue/string translation counts' for a language. It distinguishes itself from siblings like renforge_generate_translations or renforge_estimate_translation by focusing on missing counts, making its purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking translation coverage but provides no explicit context, exclusions, or mention of alternatives. It does not compare with sibling tools like renforge_estimate_translation or renforge_generate_translations, leaving the 'when to use' guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool auto-plays and reports coverage/crashes, but it doesn't disclose side effects on game state, whether it requires a running game or restarts it, or how long it might take. It also doesn't mention whether it modifies save files or has destructive consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loading the core action. Every word contributes to understanding the tool's purpose and outputs; there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with three parameters and no annotations, the description is too sparse. It doesn't explain how max_runs/max_steps influence behavior, what constitutes 'label coverage,' or what 'crashes' means in this context. While the output schema may cover return values, the tool's operational context and parameter semantics are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the parameters, but it doesn't mention max_runs, max_steps, or project_path at all. The names are somewhat self-explanatory, but there's no info on defaults, constraints, or how they affect the auto-play process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('auto-play') and identifies the resource ('the game') and the scope ('across all branches'), clearly distinguishing it from more targeted tools like renforge_run_scenario or renforge_advance. It also specifies the outputs (label coverage, crashes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: when you want comprehensive playthrough coverage of all branches. However, it doesn't explicitly name alternatives or state when not to use it, though the 'across all branches' phrase implies it's for exhaustive exploration rather than targeted testing.
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?
With no annotations provided, the description carries the full burden. It discloses key behaviors: the exclusivity of input modes, the character-by-character posting for text, and the optional submit behavior for pressing Enter. It also notes the requirement of a focused Ren'Py Input, but it does not address potential errors, consequences of sending invalid input, or the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the main rule, then breaks down each mode in clear, separate lines. It uses formatting for readability and avoids unnecessary fluff, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality well but omits the required 'project_path' parameter, which might leave an agent unsure how to supply it. It also lacks details about error handling or return behavior, though an output schema exists to cover return values. Overall, it is sufficient for the simple act of sending input but misses a few contextual pieces.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the raw schema by specifying the allowed formats for 'key' (readable names), 'scroll' (object with x, y, direction, and optional amount), and the interaction of 'submit' with 'text'. The only parameter not mentioned is 'project_path', but it is likely a standard context path required by many sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sends exactly one input mode (text, named key, or scroll) to a Ren'Py input, which is a specific verb+resource. It differentiates the modes, making the purpose clear, but does not explicitly compare with 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the use cases for each input mode (e.g., text posts TEXTINPUT events, key accepts readable names), which implies when to use the tool. However, it does not explicitly state when not to use it or suggest alternatives, making the guidance implied rather than explicit.
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?
With no annotations, the description carries the burden of behavioral disclosure. It explains the default state profile and cautions against full state, but it omits critical behavior such as timeout handling, error behavior on unmet conditions, and whether the operation is read-only. It offers partial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and the second sentence adds essential parameter guidance without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no annotations, and an output schema, the description only covers the core wait condition and return profile. It does not explain timeout semantics, polling interval meaning, depth/item limits, or the required project_path, leaving the agent without enough context to invoke the tool correctly in non-default scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the 11 parameters. It explains the condition selectors (label, screen, expr), include, and state_profile, but leaves timeout, interval, max_depth, max_items, max_output_bytes, and project_path undocumented. This is inadequate for the parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Wait for exactly one label, screen, or expression condition.' This precisely distinguishes the tool from siblings like poll_events or game_state by emphasizing the 'wait for condition' purpose and the 'exactly one' constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives guidance on parameter usage ('Pass include for extra fields/variables; use state_profile='full' only when the complete store is required') but does not explicitly state when to choose this tool over alternatives like poll_events or game_state. The use case is implied but not contrasted with siblings.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently indicates a read-only operation ('Open' and 'return') and describes the main transformation (cropping/zooming), but it does not explain what happens with default values, invalid paths, or whether the original file is ever modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that is front-loaded with the key action. It is concise and free of filler, though the brevity comes at the cost of omitting necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, no output schema, and zero parameter description coverage, this description is not complete enough for reliable invocation. It lacks guidance on coordinate systems, default behavior, output format specifics, and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the 6 parameters. It only hints at 'cropped/zoomed' behavior, but never explains scale units, crop coordinate origin, or how zero values for crop dimensions are interpreted. Agents would need to guess or infer parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open'), the resource ('a local image'), and the output ('an optional cropped/zoomed PNG for inspection'). This differentiates it from sibling tools like renforge_inspect_screen or renforge_screenshot, which deal with the live screen rather than local image files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for inspection' gives a clear intended use case, and 'local image' provides context that distinguishes it from screen-oriented tools. However, it does not explicitly mention when not to use this tool or name alternative tools for related tasks.
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 burden of behavioral disclosure. It provides valuable details: returns 'received_by' when another control owns the hit point, and the 'wait_for_effect' behavior waits for correlated business events like 'quick_save.completed'. This goes beyond a generic click description, though it could mention failure modes or visibility checks more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first sentence front-loads the primary action and key constraint (stale frame). The second adds return behavior and the wait_for_effect option. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is complex with 9 parameters and no annotation support. The description covers core behavior but omits explanations for several parameters (exact, screen, expected_frame_id, interaction_id) and does not address output schema semantics or error handling. This is incomplete for an agent to fully use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It only clarifies 'text'/'element_id' (by text/id) and 'wait_for_effect' (with correlated event). Parameters like 'exact', 'screen', 'expected_frame_id', 'interaction_id', and 'effect_timeout' are left unexplained, leaving the agent to guess their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Click a visible control by text/id'. This distinguishes it from sibling tools like renforge_click_at (which likely clicks coordinates) and renforge_hover_element. The mention of 'guarded against a stale frame' adds specificity to the tool's behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to click by text or id, and when you need stale-frame guarding, but it does not explicitly state when not to use this tool or reference alternatives. It gives context ('By text/id', 'wait_for_effect') but lacks direct comparison with sibling tools.
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?
With no annotations provided, the description carries the full burden. It does disclose an important behavioral trait: that the restart may be asynchronous and the agent should poll launch status if still starting. However, it does not mention side effects such as stopping the current game, whether the project must be running, or any potential destructive impact on game state, leaving a significant transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with a semicolon separating the core action from the follow-up guidance. Every word earns its place, there is no redundancy, and the most important information (restart at a label/file:line) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool lacks parameter descriptions and annotations, and the description itself is too terse. It does not explain the required parameters, any prerequisites (e.g., game must be running), the meaning of 'version', or what happens to the current game state upon restart. Given the complexity and the 0% schema coverage, this is not adequate for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no parameter descriptions. The phrase 'label or file:line' partially explains the 'target' parameter, but 'project_path' and 'version' remain completely unexplained. The description does not sufficiently compensate for the absence of schema-level documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Restart' and clearly identifies the resource ('a label or file:line'), making it obvious what the tool does. It also distinguishes itself from sibling tools like renforge_launch or renforge_launch_status by noting it restarts at a specific point and may require polling 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Restart at a label or file:line' gives a clear use case for the tool. The second clause 'poll launch status when still starting' provides an actionable follow-up step, but it does not explicitly name alternative tools or state when not to use this tool, 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.
- 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 states 'select' without disclosing side effects (e.g., does it confirm? trigger the choice?), error handling (e.g., what if text/index not found?), or dependencies (e.g., menu must be visible). This is a significant gap for a state-changing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the action, and contains no filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and primary parameters but omits context about return values, error behavior, and prerequisites. Since an output schema exists (per context signals), some return info may be covered elsewhere, but the lack of behavioral context makes this only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning to 'text' and 'index' by explaining they are ways to select and that text is preferred. However, it does not explain the required 'project_path' parameter or the default values, leaving part of the schema undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool selects a menu choice, using a specific verb ('Select') and resource ('menu choice'). It distinguishes from siblings like 'renforge_list_choices' (which lists) and 'renforge_click_element' (which clicks UI elements) by focusing on selection from a menu.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use this tool when you need to select a menu choice, and choose 'visible text' (preferred) or 'index'. It doesn't explicitly exclude alternatives or mention prerequisites like listing choices first, but the narrow scope makes it clear when to use.
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 burden of disclosing behavior. It clarifies that the tool returns a specific set of event types and filters by timestamp, indicating a read-only operation. However, it does not disclose whether events are consumed/cleared after polling or any other side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, with no filler or redundancy. It earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is straightforward and an output schema exists, but the description leaves the required `project_path` parameter unexplained. This is a notable gap for agents selecting and invoking the tool, though the timestamp filtering is clear. The overall context is sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives meaning to `since` as a timestamp cutoff but provides no explanation for the required `project_path` parameter. With 0% schema description coverage, the description fails to compensate for the missing parameter documentation, especially since `project_path` is required and unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns pushed events (dialogue, labels, exceptions) filtered by a timestamp, which is a distinct operation from siblings like game_state or get_errors. The verb 'Return' and the resource 'pushed events' make the purpose 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for polling new events after a given time, but it does not explicitly mention when to use this tool over alternatives like get_errors or game_state. The context 'newer than since' signals the intended polling pattern, but no exclusions or alternative tools are named.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the tool writes to game/tl/<language>/, which implies a side effect, but it does not disclose whether existing files are overwritten, whether the operation is reversible, or any other behavioral details. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action (Generate/update), and contains no unnecessary words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic function and output location, but lacks guidance on usage prerequisites, behavior on existing files, and when to use this tool versus alternatives. Since an output schema exists, return values are covered, but this is still a minimal description for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 gives meaning to the 'language' parameter via the path template, but it does not explain 'project_path' at all. This is only partial compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (generate/update) and resource (translation files), and specifies the output location (game/tl/<language>/). This distinguishes it from sibling tools like renforge_languages and renforge_translation_stats, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to generate or update translation files for a language. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select this tool over siblings.
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 provided, the description carries the behavioral burden. 'List' clearly implies a read-only operation with no side effects, and the path 'game/tl/' adds specificity. It does not mention error conditions or return details, but these are likely covered by the output schema, and the operation is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the main action. No unnecessary words or repetition, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the description is mostly adequate. However, it lacks usage context and explicit parameter semantics, which could be important for an agent deciding between this and related translation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single required parameter 'project_path' with no description, and schema coverage is 0%. The tool description mentions 'game/tl/' which implies project_path is the project root, adding some meaning. However, it does not explicitly define the parameter format or expected values, so the compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List translation languages present under game/tl/.' It uses a specific verb ('List') and resource ('translation languages') with a precise location, distinguishing it from sibling tools like translation_stats or generate_translations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is self-evident, but no explicit guidance is given on when to use this tool versus alternatives like translation_stats. The context implies listing available languages, but there is no stated when-not-to-use or comparison with sibling tools.
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?
With no annotations provided, the description carries the responsibility for behavioral disclosure. It adds value by listing the three sources considered (dashboard, serve default, cwd), giving insight into its discovery process. However, it does not describe possible failure modes, return format (though an output schema exists), or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It begins with the core action and resource immediately, and the parenthetical source list adds essential detail without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description adequately covers the core purpose and the inputs it checks. It is slightly thin on broader context such as when one might need this information, but given the simplicity of the tool, it is sufficiently complete. The lack of usage guidance is the main gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to explain. The input schema is empty and schema coverage is 100%, making this a straightforward baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Discover' followed by the resource 'active Ren'Py project' and enumerates the sources (dashboard, serve default, or cwd). This clearly distinguishes it from siblings like inspect_project or scan_project, which focus on inspection/scanning rather than active-context discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to know which project is active, but it does not provide explicit guidance on when to use it versus alternatives such as renforge_inspect_project or renforge_info. No comparable alternatives or exclusions are mentioned.
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 of behavioral disclosure. It explains the input behavior (saved PNGs, empty after_path) and the output (bounding box). However, it does not disclose the behavior of the threshold parameter or whether the tool has side effects, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with purpose, parameter explanation, and use cases. It is compact, front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values don't need explanation, but the description omits project_path and threshold semantics, which are essential for correct invocation. The main diffing behavior is clear, but the parameter gaps prevent full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains before_path and after_path, but ignores project_path (a required string) and threshold (an integer with default). Since schema coverage is 0%, the description fails to compensate for half the parameters, especially the required project_path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool diffs two frames and returns the bounding box of what changed, using specific verbs and resources. This distinguishes it from sibling tools like screenshot capture or image search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ("measure how far an element moved or to confirm a tweak left everything else untouched") and explains how to use the after_path parameter (empty to diff against current live frame). It does not explicitly exclude alternatives, but the contexts are clear enough.
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?
With no annotations provided, the description must carry the behavioral disclosure burden. It states that the tool reads a documentation page as plain text, which is a non-mutating read operation, but it does not mention error behavior for invalid topics, pagination, or other behavioral details. It adds some context but not enough for a high score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. The example is integrated efficiently, making the description both concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and an output schema (not shown but noted), the description is largely complete. It explains the input, the output format, and the resource. It does not need to explain return values due to the output schema. The only missing context is how to discover valid topics, but sibling tools (list_docs) cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one string parameter 'topic' with 0% coverage in the schema description. The description compensates by providing a concrete example ('topic=cli'), which clarifies that the parameter is a documentation topic name. While it doesn't enumerate all possible topics, it gives clear context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and clearly identifies the resource ('Ren'Py documentation page') and output format ('as plain text'). It distinguishes the tool from sibling tools like renforge_search_docs (search) and renforge_list_docs (list) by emphasizing reading a specific page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you know a specific topic (via the example 'topic=cli') but does not explicitly state when to use this tool versus alternatives like search_docs or list_docs. No exclusions or alternative recommendations are provided.
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 key behavior of returning a stack of focusable layers and the intended use of detecting overlay interception. However, it doesn't explicitly state that it's read-only or describe side effects, but 'Inspect' implies a non-mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short paragraphs with front-loaded intent. Every sentence contributes to understanding the tool's purpose and returned data. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema existence and moderate complexity, the description is largely complete. It explains the tool's purpose, return behavior, and motivating use case. Minor gaps remain around coordinate spaces, but these are partially captured in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meanings. It mentions 'at a coordinate' but never clarifies x/y units, coordinate_space semantics, or the role of project_path. This leaves the four parameters under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Inspect the interactive focus stack at a coordinate.' It also distinguishes itself from siblings like 'click_at' by emphasizing returning layered focus information for overlay detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining that the tool returns topmost and underneath controls for detecting transparent overlays that intercept clicks. It does not explicitly name alternatives or when-not-to-use, but the use case is clear enough to guide an agent.
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?
With no annotations, the description carries the full burden. 'List' clearly indicates a read-only operation with no side effects, which is sufficient for a simple tool. But it adds no additional context like sorting, pagination, or return format, though these are likely covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool whose output schema exists, the description is complete. It fully describes the tool's purpose without needing to explain return values or parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description cannot add parameter detail. Per the baseline for zero-parameter tools, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource 'available Ren'Py documentation topics', clearly distinguishing it from related tools like renforge_search_docs and renforge_get_doc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this to see what documentation topics are available before using search or get. However, it does not explicitly state when to use it instead of siblings or mention any exclusions.
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 transparency burden. It discloses that the tag keeps its current attributes, explains Ren'Py's integer-vs-float coordinate rule, and implicitly indicates changes are live and not persisted to script by telling users to write final values into the .rpy script.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loading the core purpose and adding only necessary usage details. Every sentence earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters and no annotations, so the description needs to cover a lot. It addresses the core placement workflow and coordinate semantics, but omits details on layer, zoom, rotate, align, and offset parameters, which may be necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the integer vs float semantics with concrete examples and the requirement of at least one placement field. However, it does not explain the meaning of individual parameters like zoom, rotate, xalign, or offsets, leaving significant gaps for a 13-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Reposition a shown image tag live and return its new logical bounds,' clearly stating the action (reposition) and target (shown image tag). It differentiates from sibling tools like get_displayable_bounds or click_element by focusing on live repositioning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Provide at least one placement field' and instructs to 'Use this to converge on coordinates interactively, then write the final values into the .rpy script.' This gives clear context for when to use it, though it does not explicitly mention 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the full store is never returned unless explicitly requested, which is a key behavioral safeguard. It also indicates the output is bounded by default, providing useful context on payload limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the core function and the second provides the critical default behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are documented. The description covers the essential behavior and differentiator, but with 7 params and no parameter descriptions, more guidance on the bounding parameters would improve completeness. Still, the core function is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for parameter meaning. It adds clarity for state_profile by explaining default behavior, and 'selected variables' hints at variable_names. However, parameters like max_depth, max_items, variable_prefix, and max_output_bytes are not explained, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Return' plus resource 'bounded live state' clearly describes the tool's function. The mention of default state_profile='interaction' and the full store never being returned distinguishes it from sibling renforge_game_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that the default profile is 'interaction', meaning bounded output, and that the full store is only returned when state_profile='full' is requested. This gives implicit guidance on when to use this tool versus a full-state tool, though it doesn't explicitly name sibling alternatives or exclusions.
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 carries full burden, and it delivers: it discloses the async behavior (waits 20s then returns status='starting'), the need to poll for 'ready'/'failed', editor default and override, savedir isolation, and timeout semantics. It does not contradict any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then moves to parameter instructions and the workflow. It is dense but every sentence adds relevant information, with minimal redundancy and a useful docs pointer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter launch tool with async startup, the description covers the main workflow, defaults, and error/polling states well. It is incomplete on a few parameters (version, persistent, cleanup_on_stop) and relies on docs/LIVE_EDITOR.md for further detail, but the output schema reduces the need to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate, and it explains the meaning of editor, warp, display/audio defaults, savedir, and timeout. However, it leaves version, persistent, and cleanup_on_stop unexplained, and project_path is only implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Launch or reuse a game with the Live Editor enabled by default,' giving a specific verb and resource. It is clear about the core action, though it doesn't explicitly contrast itself with sibling tools like renforge_new_game or 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete post-launch workflow: poll renforge_launch_status until ready, observe with renforge_screenshot/renforge_scene_tree, use frame_id-guarded clicks, and stop with renforge_stop. This is clear context, but there are no explicit when-not-to-use or alternative-tool exclusions.
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 are present, so the description carries the full burden. It discloses that the tool returns 'actionable deltas in logical pixels', adds a 'pass' verdict when tolerance is given, samples the live frame for contrast, and resolves node IDs live. This is highly transparent about behavior and edge cases (one vs two targets for contrast).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The supporting details about actions and target formats are dense but well-organized, with every sentence adding necessary value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 6+ actions, special contrast behavior), the description covers the critical aspects: action meanings, target resolution, tolerance semantics, and contrast's live-frame WCAG ratio. It does not explain 'project_path', but that is a standard parameter across sibling tools. The output schema exists, so return structure details are not required in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates. It explains the 'action' enum values, defines 'targets' and 'within' as either node IDs or bounds objects, and clarifies that 'tolerance' produces a pass verdict. This goes well beyond the bare schema, which only lists names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('measure') and clear resource ('pixel relationships between scene nodes'), and lists the exact actions supported (align, gap, distribute, center, overlap, fit, contrast). This distinguishes it from sibling tools like renforge_get_displayable_bounds or renforge_position_element, which focus on single-element bounds or positioning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: whenever you need to measure alignment, gaps, distribution, centering, overlap, fit, or contrast between scene nodes. It explains the target format and tolerance behavior, but does not explicitly mention alternatives or exclusions, so it lacks the direct 'use X instead' guidance seen in the highest-caliber descriptions.
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 key behaviors: reports every layer displayable, focusable control, and text block; includes an 'omitted' completeness hint; supports detail levels (semantic/layout/raw); and explains side effects like committing snapshots (save_as) and diffing (diff_against). This is rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized paragraph that front-loads the primary purpose, then efficiently enumerates options using backticks and semicolons. No sentence is wasted, and it packs substantial detail into a compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, no annotations, but an output schema exists), the description covers most major aspects, including output hints and options. Still, it omits explanations of the three limiting parameters, which could be important for large scenes. Overall it is nearly complete but has that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions (0% coverage), so the description must compensate. It explains detail, layers/types/screen/ids, include, format, save_as, and diff_against. However, it does not explain max_items, max_output_bytes, or max_output_depth, which are important output-limiting parameters, leaving a gap for those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool perceives the whole scene as structured data, listing exactly what it reports (every layer displayable, focusable control, text block) and the fields included. It explicitly distinguishes itself from the sibling tool renforge_list_ui_elements, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly contrasts with renforge_list_ui_elements ('Unlike ... this reports every...'), providing an explicit alternative. It also describes how to scope results using layers/types/screen/ids and offers options like include, format, save_as, and diff_against, giving clear context for when and how to use the tool.
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 of behavioral disclosure. It thoroughly explains the fallback logic for active_project (dashboard → serve default → current directory detection) and clarifies that a null active_project only means auto-discovery found nothing, preventing misinterpretation. This goes beyond simple output listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the core purpose, and subsequent sentences provide essential fallback and null-handling details. Every sentence contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description fully covers the necessary context: when to call it, how active_project is resolved, what null means, and how to proceed. It leaves no ambiguity for the agent, making it a complete and actionable tool definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, but it adds semantic value by interpreting the output fields active_project and project_source, which helps the agent act on the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Call first: report RenForge version and the active project,' clearly stating the tool's purpose with a specific verb and resource. It distinguishes this tool from siblings by framing it as an initialization/info call, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Call first,' establishing when to use the tool. It explains the fallback chain for active_project and directs the agent to ask for the game's path if null, providing concrete guidance on how to handle the null case. It also notes that every tool accepts project_path directly, aiding in subsequent tool usage.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/alex-jordan547/renforge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server