Galgame MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
Many tools have overlapping purposes, such as multiple list/probe/extract tools (e.g., re_strings vs xp3_re_tpm_inspect, archive_list vs gal_list_dir). Despite detailed descriptions, the sheer number and similar names make it hard for an agent to pick the correct tool without reading every description.
Naming Consistency2/5
Tool names use various inconsistent prefixes (re_, xp3_re_, kirikiri_, vnt_, vntextpatch_, native_, etc.) and mix verb-first and noun-first patterns. While subsets are internally consistent, the overall naming lacks a unified scheme, making it difficult to predict tool names.
Tool Count1/5
With 99 tools, this server is extreme in size. Even for a broad domain like Galgame reverse engineering and translation, this number overwhelms an agent's selection process and suggests insufficient consolidation.
Completeness4/5
The tool set covers an impressively wide range of operations: archive manipulation, reverse engineering, script/text extraction, translation workflows, and native sidecar management. Minor gaps exist (e.g., some niche formats or automation steps), but overall it is a comprehensive surface for the domain.
Average 3.2/5 across 99 of 99 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'Create an archive' without mentioning side effects, permissions, format handling, or error conditions. This is insufficient for a tool that likely creates files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise in length. However, it is under-specified and adds little beyond the tool name, so while structure is acceptable, the content is too minimal to be highly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With six parameters, no annotations, and no output schema, this description is completely inadequate. It does not explain the archive format, the role of the 'native writer', or the constraints on parameters, leaving the agent without essential context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions none of the six parameters. It does not explain what 'input', 'output', 'format', 'version', 'compress_index', or 'compress_contents' mean, nor does it add any usage hints beyond the schema's raw names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Create an archive') but the qualifier 'using a native writer' is vague and does not specify what kind of archive or what differentiates it from sibling tools like xp3_pack or archive_unpack. It provides a basic verb+resource but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. Among numerous sibling tools for archiving and packing, there is no mention of preferred contexts, prerequisites, or exclusions.
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 present, so the description must disclose side effects and behavior. It only supplies an implementation hint ('implemented_via_native_sidecar') and ambiguous terms like 'DLL deploy' that could imply deployment, but does not clarify whether the tool reads, installs, or modifies anything. No return behavior or side effect is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is very short, but brevity is achieved by omitting necessary functional information rather than by efficient explanation. It is a fragment without a clear sentence structure, and 'implemented_via_native_sidecar' is redundant within the fragment.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the cryptic description, empty schema, and no output schema, the agent lacks essential information about what this tool returns and how to use it. The existence of many capability/utility siblings makes the missing context particularly harmful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the baseline for parameter semantics is high. The description adds no parameter syntax or semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides no action verb; it reads as a subsystem label ('VNTextProxy: SjisTunnel / SRT·ASS + native sidecar DLL deploy') rather than explaining what invoking `vnt_proxy_capabilities` does. It restates the tool name's domain without distinguishing whether this lists, queries, or configures capabilities. Sibling tools like `vnt_proxy_sjis_encode` are not differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no mention of when to use this tool or when to prefer alternatives. It neither lists context, exclusions, nor sibling relationships. The sibling list includes many proxy-related tools, but no guidance is given.
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 fully disclose behavior. It implies a read-only suggestion operation but does not state whether it scans the game directory, how existing patch files are handled, or what output is produced. Side effects and edge cases are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is compact and front-loaded. However, the brevity hurts clarity, and the use of jargon ('stem') makes it less effective than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more context about inputs, outputs, and behavior. It lacks details about the return value, the algorithm for finding the next patch, and how this tool fits into the broader patch workflow. An agent would be uncertain how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage. The description partially explains the 'base' parameter via the example 'patch_cn' but leaves 'game_dir' unexplained and does not clarify how base is used in the suggestion logic. It does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Suggest next patch / patch2 / … or custom base (patch_cn) stem' but does not clearly define what a 'stem' is or how the 'next' patch is determined. It uses domain jargon and fails to distinguish itself from sibling tools like kirikiri_list_patch_archives or kirikiri_pack_patch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention workflow context, prerequisites, or why an agent should choose this over related patch tools.
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, but it only states a high-level action and a negative clarification. It does not mention whether the operation extracts all entries by default, writes files to disk, overwrites anything, requires specific permissions, or what the output looks like. This is a significant gap for a potentially mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is very short, it is under-specification rather than genuine conciseness. It is a single fragment with no structured organization, and the cryptic parenthetical does little to clarify the tool's behavior. It lacks essential details that the schema and usage require, so it fails to be an efficient, useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, 2 required, nested objects, and no output schema or annotations, this description is severely incomplete. It does not explain return values, side effects, error conditions, or the meaning of key parameters like 'scheme'. The description leaves the agent with almost no contextual understanding beyond the bare action of unpacking an archive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only 'entries' has a description), and the tool description adds almost no meaning to the parameters. It does not explain 'path', 'format', 'output', 'scheme', or 'scheme_params', nor how they interact. The single sentence does not compensate for the low schema coverage, leaving most parameters effectively undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Unpack') and resource ('natively supported archive'), which gives a clear sense of purpose. The parenthetical '(NOT script→JSON)' helps distinguish it from script-processing tools, but it doesn't differentiate it from other archive-related siblings like xp3_unpack or archive_pack, so it's not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only a negative hint ('NOT script→JSON') about when not to use it, but gives no positive guidance on when to use it versus alternatives such as archive_pack, xp3_unpack, or archive_list. There is no explicit context, prerequisite, or exclusion beyond the one negative clarification.
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 full responsibility for disclosing side effects. It states 'Update' but does not reveal whether files are overwritten, what happens to existing values, required permissions, or any other behavioral traits, leaving significant ambiguity 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, but it sacrifices needed detail. The vague term 'highlights' and lack of parameter context make it under-specified; however, there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 params, nested objects, no output schema, no annotations), this description is far from complete. It omits return behavior, side effects, and any meaningful parameter structure, leaving an agent with insufficient context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 14 parameters with zero description coverage, and the description adds no parameter-level meaning. Nested objects like config_updates and appconfig_updates are completely unexplained, so an agent cannot know what structure or values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Update) and the resource (Config.tjs / AppConfig.tjs) on a KAGeXpress project, which helps distinguish it from init/locate siblings. However, the term 'highlights' is vague and doesn't precisely specify what gets updated, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions 'on an existing KAGeXpress project,' which implies a prerequisite but gives no explicit when-to-use or when-not-to-use guidance. It also fails to mention alternatives like kagconfig_set or other config-related sibling tools.
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 says 'Load' but does not disclose whether the operation is read-only, what side effects occur, whether encoding is handled, or what the return format is. This is insufficient for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no fluff. However, it is under-specified and lacks any structural breakdown of parameters or behavior, which reduces its usefulness despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, no output schema, and no annotations. The description only offers a minimal statement of action; it does not explain return values, encoding defaults, or how this relates to sibling scenario tools. This is far from complete for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either parameter (path or encoding). It provides no additional meaning beyond the raw parameter names, leaving the agent to guess what 'path' refers to and how 'encoding' behaves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb (Load) and specific resource (KAGeXpress multilingual scenario .txt lines), which distinguishes it from sibling tools like kirikiri_write_scenario_text. It lacks an explicit differentiator, but the action and target are 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention related tools (e.g., kirikiri_write_scenario_text, kirikiri_list_text_refs) or any prerequisites, making it hard to know if this is the right tool for a given task.
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 convey behavioral traits, but it only states the high-level outcome. It does not disclose whether existing files are overwritten, whether game_dir is modified, what 'staging' entails (e.g., copying, linking, or packing), or any side effects. This is a minimal disclosure that leaves the agent guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence with no wasted words. However, the brevity comes at the cost of substance, omitting parameter details and behavioral context. It is appropriately short but not sufficiently informative to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (2 required), no output schema, and no annotations. The description provides only a single-line overview, which is insufficient for correct invocation. It does not explain valid mode values ('xp3', 'loose', 'both'), the meaning of the 'pack' boolean, or expected directory structures. This is incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the parameters. The terms 'game_dir', 'source_dir', 'mode', and 'pack' are not explained in the prose. The description does not compensate for the schema's lack of descriptions, so the agent has no semantic understanding of how to set the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('Stage files') and target resources ('unencrypted.xp3 and/or loose unencrypted/ folder'), clearly distinguishing it from sibling tools like kirikiri_stage_patch and kirikiri_pack_unencrypted. It lacks an explicit verb+resource phrasing like 'Create' or 'Pack', but 'Stage' is meaningful in this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention scenarios such as preferring 'loose' for debugging or 'xp3' for release, nor does it compare with kirikiri_stage_patch or other pack tools. The description only states what it does, not when to choose it.
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 fails to mention whether the tool is read-only, the format of the output, or any side effects. It only gives a minimal functional statement without elaborating on behavior, assumptions, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise in length, but it is a fragment without a main verb and lacks clear sentence structure. It conveys minimal information without being poorly organized. It is neither overly verbose nor effectively structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description should at least explain what statistics are computed, what the output looks like, and any constraints. It does none of these. 'Same line statistics' remains undefined, and the tool's behavior is barely specified, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'path' with no description (0% coverage). The description implies the path should point to a Google Docs CSV/TSV export, which is some added meaning, but it does not explicitly state that the path is to a file, nor does it specify expected file extensions, encoding, or structure. The hint is indirect and insufficient for reliable parameter handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates the tool computes line statistics for a Google Docs CSV/TSV export, which distinguishes it from sibling tools like vnt_excel_line_stats. However, 'Same line statistics' is ambiguous and lacks a clear verb (e.g., 'calculate' or 'report'), making the exact purpose unclear. It is more of a title than a descriptive statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like vnt_excel_line_stats or vnt_stats. It does not mention any prerequisites, workflow position, or exclusions. The only hint is the file format reference.
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 only states the basic resolution action without disclosing side effects, return behavior, or error handling. There is no contradiction, but also no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, efficient and front-loaded with the key action. However, it is too brief to be fully useful; conciseness crosses into underspecification. The structure is clean but content lacking.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, a nested object, and no output schema, the description is severely incomplete. It gives no parameter explanations, no return value details, no usage context, and no interaction with sibling tools. This is far below the minimum viable level for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 13% (1 of 8 parameters described). The description adds meaning for title and name_key+order_hex, but leaves query, scheme, title_id, scheme_params, and title_id_name unexplained. It does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resolve) and the target (NPA game title or name_key+order_hex) and output (scheme params). It distinguishes from sibling tools by explicitly targeting NPA, though it doesn't contrast with xp3_resolve_scheme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as xp3_resolve_scheme or npa_list_schemes. The description implies usage when you have a title or name_key+order_hex, but provides no exclusions or alternative references.
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 mentions 'using the native XP3 writer', which hints at the output format but does not disclose effects like overwriting, compression defaults, version handling, or required permissions. The schema properties (compress_index, compress_contents) imply compression behavior, but the description adds no context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), which is efficient and front-loaded. However, it is under-specified even for a simple tool; it lacks any structural breakdown or additional context that would help the agent. It is not verbose, but the brevity borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema) and the existence of sibling tools with overlapping functionality, the description is incomplete. It does not cover return values, error conditions, or when to select this tool over alternatives. The rich sibling list emphasizes the need for more contextual detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It does not explicitly explain any parameters. At best, 'Pack a folder into XP3' implies that 'input' is the folder and 'output' is the XP3 file, but the version, compress_index, and compress_contents parameters are entirely unaddressed. This is well below the baseline expected for a tool with 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action ('Pack a folder into XP3') and the method ('using the native XP3 writer'), which is specific and understandable. However, it does not distinguish this tool from sibling tools like 'xp3_pack' or 'archive_pack', which likely have overlapping 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or exclusions. Given the availability of similar pack tools (e.g., xp3_pack, kirikiri_pack_patch), the lack of usage context is a significant gap.
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 disclosing behavior. It only says 'Write' but does not reveal whether it overwrites existing files, requires a directory, what encoding defaults apply, or any side effects. This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and free of unnecessary words. It communicates the core action efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with no annotations, no output schema, and minimal schema descriptions, the description is drastically under-specified. It lacks details on file format, line structure, encoding behavior, and side effects, making it inadequate for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not clarify the meaning of 'path', 'lines', or 'encoding'. It mentions 'scenario .txt lines' but does not explain the structure of the 'lines' array or how to specify the path. The description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'Write' and resource 'KAGeXpress multilingual scenario .txt lines', clearly indicating a write operation for scenario text. It distinguishes from the sibling 'kirikiri_load_scenario_text' which reads scenario text. However, it doesn't mention the file path or encoding, relying on the schema for those details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, relationships to read tools, or when not to use it. The description simply states the action without contextual usage instructions.
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?
Without annotations, the description carries the full burden. It only discloses the JDK requirement, but not whether the tool modifies the binary, creates temporary project files, or what side effects may occur. This is minimal disclosure for a tool that invokes an external program.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that contains no wasted words. However, it omits important information, though that is more relevant to completeness than conciseness. It is efficiently written for what it says.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, this description is grossly insufficient. It doesn't explain what sample output looks like, how scripts are passed, or what 'import_only' does. A user/agent would be left guessing on most operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only 'script' has a description). The description adds no detail about the six other parameters (timeout, import_only, project_dir, script_args, project_name) beyond the binary path implication. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run Ghidra analyzeHeadless') and the target ('a binary'), making the tool's purpose unambiguous. It doesn't explicitly compare to sibling tools like re_rizin, but the specific reference to Ghidra distinguishes it sufficiently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (JDK) but provides no guidance on when to choose this over re_rizin, re_disasm, or other reverse-engineering tools. No context is given for selecting this tool.
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 carry the full behavioral burden, but it only states 'search', implying read-only behavior without explicitly confirming it. It does not disclose whether the operation is safe, what it returns, or any side effects, which is a gap for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is under-specified. It earns its place as a summary but lacks essential details, making it merely adequate rather than comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no output schema, the description is too sparse. It fails to convey required path details, pattern encoding, max_hits limitations, or expected return value, so it is incomplete for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at pattern_hex and pattern_ascii without explaining their formats or relationships. It does not clarify path semantics or max_hits behavior, leaving most parameters under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a search operation on binary content using byte/ASCII patterns. It uses a specific verb and resource, though it does not explicitly distinguish itself from other re_* tools like re_strings or re_disasm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as re_strings or re_disasm. There are no exclusions or prerequisites mentioned, leaving the agent without 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only calculation of stats but does not explicitly state whether the tool reads a file, has side effects, requires specific file formats, or returns a structure. It gives no information about permissions, resource access, or error behavior, leaving the agent to guess.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the tool's context and includes a helpful parenthetical enumerating the stat categories. It is efficiently written with no wasted words, though it is terse and functions more as a label than a full description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and no output schema, the description is too minimal. It does not explain the expected input (path format or file type) or the structure of the returned statistics, nor does it define key terms like 'checked' or 'edited'. The agent lacks essential context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the 'path' parameter. The parameter is simply named 'path' with no type or format details, and the description does not state that it should point to an Excel file. The agent must infer this from the tool name, which is insufficient given the complete absence of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('VNTextPatch Excel') and the output type ('line statistics'), listing specific categories (total/translated/checked/edited). It distinguishes from the sibling tool 'vnt_google_docs_line_stats' by specifying Excel rather than Google Docs. However, it lacks an explicit verb like 'get' or 'calculate', making it a noun phrase rather than a full action description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to choose Excel line stats over 'vnt_google_docs_line_stats' or 'vnt_stats', nor does it state any prerequisites or contexts where this tool is preferred. There is no exclusion or alternative 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?
With no annotations, the description must disclose side effects. It only says 'Load' but doesn't explain whether this is idempotent, overwrites existing mappings, or requires prior setup. The lack of behavioral detail is a concern for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, front-loading the core action. However, its brevity sacrifices necessary context, making it efficient but somewhat under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and cryptic parameters, this tool requires more context. Missing information about the tunnel encoder, the file format, and expected usage makes the description incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'path' parameter beyond its existence or the meaning/effect of 'sync_util'. The boolean parameter's role is entirely unexplained, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Load') and the resource ('sjis_ext.bin' into the 'tunnel encoder'). It distinguishes from sibling encode/decode tools by being a load operation, but 'tunnel encoder' is undefined, leaving some ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the encode/decode or ext_save siblings. There are no prerequisites, contextual triggers, or exclusions 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?
With no annotations provided, the description carries the full burden. It discloses that the tool returns statistics but does not mention whether it is read-only, any prerequisites (e.g., file must exist), or potential side effects. The safety profile is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, front-loading the resource and action. However, it is so terse that it omits essential detail, making it feel incomplete rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and no output schema, the description is insufficiently complete. It fails to clarify the 'work' parameter or the nature of the returned statistics, making it difficult for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists a single required 'work' string parameter with no description. The tool description does not explain what 'work' refers to or how it should be formatted, leaving a significant gap at 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns translation completion statistics for AI bundle.jsonl, using a specific verb and resource. It distinguishes from other vnt_* stats tools by referencing this particular file/format, though it could more explicitly contrast with Excel/Google Docs stats tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like vnt_excel_line_stats or vnt_google_docs_line_stats. The description simply states what it does without any contextual cues.
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 mentions 'unencrypted' and 'natively' but does not explain side effects, overwrite behavior, required input formats, or any limitations. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, making it concise and well-structured. However, it is under-specified, so it loses a point for being too terse to convey essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no annotations, and no output schema, the one-line description is minimal. It provides only the core purpose, but lacks information on parameter roles, expected behavior, and edge cases, making it inadequate for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the five parameters. It does not mention input, output, version, or compression options at all. Even though parameter names are somewhat self-explanatory, the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create') and resource ('XP3 archive'), with qualifiers 'unencrypted' and 'natively' that add some specificity. However, it does not explicitly differentiate from sibling tools like archive_pack or kirikiri_pack_unencrypted, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or exclusions, leaving the agent without context for choosing among the many archive/pack tools in the sibling list.
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 fully disclose behavioral traits, but it only states the transformation action (re-scramble) and references Scrambler.cs. It does not mention whether the tool reads/writes files, overwrites output, requires existing files, or any side effects. This is a significant gap for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the action is front-loaded. The phrase 'Kirikiri FE FE' contains a redundant 'FE', which is slightly sloppy, but overall it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description must provide complete context for safe invocation. It does not explain return values, file handling, or how this tool fits into the broader workflow with its many siblings, making it inadequate for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the 'mode' parameter by listing modes 0/1/2, and 'plain text' hints that 'input' is text. However, it does not explain whether 'input' and 'output' are file paths or inline content, nor the effect of different modes beyond the numeric range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 're-scramble' and identifies the resource 'plain text' to 'Kirikiri FE FE modes 0/1/2', which clearly indicates the operation and distinguishes it from the sibling 'kirikiri_descramble' by action direction. However, it does not explicitly contrast with other related tools like 'kirikiri_scramble_tree', so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'kirikiri_descramble' or 'kirikiri_scramble_tree'. It does not state prerequisites, exclusions, or preferred contexts, leaving the agent to infer usage solely from the tool name.
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 carry the behavioral disclosure burden. It only says 'List', which implies a read-only operation, but does not disclose what the output looks like, whether the path should be a file or directory, any restrictions, or side effects. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is under-specified rather than appropriately concise. It lacks essential context about the path parameter and the nature of the listing, making it only minimally useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema), the description still fails to provide complete context. It does not explain what 'sectors' are, what 'KrKrZ Split metadata' means, or what information the listing returns. The absence of an output schema makes this omission more critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single `path` parameter with no description, and schema coverage is 0%. The description does not compensate: it never explains what `path` should refer to (e.g., a file, directory, or archive path). Parameter semantics are completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List TJS2100 DATA/Other/TJS2 sectors' and adds '(KrKrZ Split metadata)' for context. This clearly distinguishes it from sibling TJS2100 tools like kirikiri_tjs2100_import, export, split, and merge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any preconditions, use cases, or exclusions, leaving the agent without any direction for 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, the description must carry the burden of behavioral disclosure. It mentions signing modes but does not state whether embedded signing modifies the file in place, whether a new .sig file is created, whether a private key is required, or what happens if the key is missing. This is insufficient for a potentially destructive signing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Sign a file') and packs in the key modes. There is no fluff or repetition, making it extremely concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no output schema, no annotations, and low schema coverage, a one-sentence description is wholly inadequate. It leaves critical questions unanswered: what do the various private key options mean, how are offsets interpreted, what is returned on success, and what are the failure modes? The description needs substantially more detail to be usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (2 of 10 parameters have descriptions), and the tool description only mentions 'auto_krkr' by name. It does not explain the private key parameter variants, offset semantics, or ignore ranges, so it fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (sign) and resource (a file), and specifies two modes (detached .sig or embedded) plus an optional flag (auto_krkr). This distinguishes it from sibling tools like krdevui_sig_check and krdevui_sig_inspect, though the reference 'like krdevui SignUnit' is somewhat cryptic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that verification or inspection tools should be used for checking signatures, nor any prerequisites like needing a private key or when to choose detached vs embedded mode.
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 mentions the underlying library (pefile) but does not disclose whether the operation is read-only, what the output looks like, or any side effects. This is insufficient for a tool that inspects file structures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact phrase with no filler words. It is front-loaded and efficient, but it is so terse that it sacrifices necessary detail for brevity, earning a high but not perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the tool returns (e.g., parsed header data, sections list, etc.) and any operational context. It does neither. The tool is simple (one param) but still lacks critical details about the result format and the exact type of input expected, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'path' parameter with no description, and the tool description provides no additional explanation. The param name is somewhat self-explanatory in context, but with 0% schema coverage, the description should explicitly state that 'path' refers to the path of a PE file to analyze. This inference is left to the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (PE files) and the aspects covered (headers, sections, imports, exports), which distinguishes it from sibling RE tools like re_strings or re_disasm. However, it lacks a verb such as 'parse' or 'extract', making it a noun phrase rather than an explicit 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention when to prefer re_pe_info over re_rizin, re_ghidra_headless, or other RE tools, nor does it state any 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 behavioral disclosure. It only says it 'assist[s]' and mentions a 'playbook', but does not clarify what the tool actually does (e.g., returns text, runs a workflow), whether it has side effects, or how it interacts with other tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, but it is under-specified and fails to convey key details. It lacks a clear structure that would help an agent anticipate what the tool returns or how it should be used.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is an informational tool likely returning a guide, the description does not specify the output format, content details, or how the playbook is organized. With no output schema, the description alone is insufficient for a complete understanding of the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema imposes no burden. Baseline for 0 parameters is 4; the description adds no parameter-specific info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the domain (XP3 reverse-engineering) and content (capabilities/playbook), but uses the vague verb 'assist' rather than a specific action like 'provides' or 'displays'. It does not clearly distinguish itself from sibling tool 're_workflow', which may have a similar 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling RE tools. The description does not state prerequisites, whether it should be called before other RE tools, or what kind of scenario recommends it.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states that unpacking occurs with an explicit scheme; it does not warn that files are written to output, how errors are handled, or whether this can overwrite existing files. The mutation aspect is only implicit in 'Unpack'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the action, and wastes no words. However, at eight words for a six-parameter tool, it is under-specified; brevity is achieved at the cost of necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, no output schema, and no annotations, yet the description is minimal. It omits required parameters, default behavior of scheme, optional entries filtering, and the relationship to scheme-list/resolve tools, leaving an agent without enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters with descriptions, and the text adds context only for 'scheme' by stressing it must be explicit. It does not help with the required path/output, the meaning of entries/omit-to-extract-all beyond schema, or game_title/scheme_params usage. Since the schema already documents entries and game_title, the marginal value from the description is low.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Unpack' and resource 'XP3', with the qualifier 'explicitly selected scheme' which distinguishes it from generic archive_unpack and xp3_pack. It doesn't mention related scheme-resolution tools, so sibling differentiation is partial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with an explicitly selected scheme' implies the tool is used when a scheme is already known, suggesting you should first obtain a scheme via xp3_list_schemes or xp3_resolve_scheme. However, it never states this explicitly or mentions alternatives for other archive formats, so guidance is only implied.
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 behavioral disclosure. It does not state whether the tool is read-only, what it returns (e.g., JSON structure), or what 'decode container hint' means. This is a significant gap for a probe tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the purpose statement, making it highly concise and structurally sound.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple interface (1 parameter, no output schema, no annotations), the description is too sparse. It omits return values, what a 'container hint' is, and any error or edge-case behavior. This leaves the agent with insufficient context to confidently invoke the tool and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists only a 'path' string parameter with no description, and schema coverage is 0%. The description does not explain the path parameter or its expected format beyond implying a file path. This adds minimal value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Detect native audio format and decode container hint.' The verb 'detect' plus 'native audio format' gives clear purpose, and it distinguishes from siblings like audio_decode and audio_list_formats. However, 'decode container hint' is ambiguous, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. It does not mention audio_decode, audio_list_formats, or any prerequisites. The usage is only implied by the name and description (e.g., probe an audio file before decoding), but no when-to-use or when-not-to-use is 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?
With no annotations, the description must disclose side effects, but it only mentions copying and writing operations without details on overwrite behavior, file system modifications, or dependencies. The explicit 'no EXE/DLL' is useful but minimal. It does not warn about potential data loss or the need for template_dir, leaving behavioral transparency insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with a clear verb-object structure. It is front-loaded with the main action and includes a parenthetical clarification about EXE/DLL. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter tool with no output schema and no annotations, the description is too sparse. It fails to explain the project initialization workflow, return values, or critical behaviors like overwriting and scenario peeking. Users are left without enough context to use the tool safely or effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only 50% of parameters, and the description adds no parameter-level detail. It does not compensate for undocumented params like maker, game_id, or template_dir. The high-level mention of 'text assets' and 'Config/AppConfig' loosely maps to some params but lacks specificity, providing little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies KAGeXpress Template text assets and writes Config/AppConfig highlights, with a notable exclusion of EXE/DLL files. It distinguishes from sibling tools like locate_template or apply_config, though the term 'highlights' is somewhat vague. Overall, the purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., locating the template first) or contrast with sibling tools like kirikiri_kagex_apply_config. The description only states what it does, not when to choose it.
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 disclosing behavioral traits. It only says 'Write ... file', which is generic and adds no detail about overwriting behavior, file path resolution (wave path vs .sli path), or the need for prior loop_read data. The WaveLoopManager mention gives a slight hint but doesn't explain side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the core action and resource. There is no redundancy or extraneous information, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects (links with condition fields, labels) and no output schema, the description is far too sparse. It doesn't explain the relationship between 'info', 'links', and 'labels', nor the alternative path semantics (wave path writes FileName.sli). An agent would need to fully inspect the schema and possibly sibling tools to understand correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (path and info have descriptions, links and labels have nested property descriptions but no array-level description). The description adds no parameter semantics beyond the phrase 'loop/link/label', which loosely maps to links and labels but doesn't explain the 'info' parameter or the path nuances. It does not compensate for the partially covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Write' and the resource '.sli loop/link/label file', identifying the tool as a writer for Kirikiri WaveLoopManager data. It implicitly distinguishes from the sibling 'loop_read' by being the write counterpart, though it doesn't explicitly reference it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. There is no mention of pairing with loop_read, prerequisites like having prior loop data, or scenarios where this tool is preferred over other write/pack tools. The context must be inferred entirely from the name and schema.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention whether the tool is read-only, whether it modifies files, how long it might take, whether it requires specific permissions, or what the output looks like. The term 'playbook' suggests orchestrating multiple operations, but no details about side effects or dependencies are given, making this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single sentence and no filler. The 'Playbook:' prefix is a bit cryptic but does not waste words. It is appropriately sized for a tool with no parameters, though it might benefit from slightly more detail to be more useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (a multi-tool orchestration workflow), the description is quite incomplete. It does not explain the sequence of steps, expected outputs, or how it integrates with sibling re_* and xp3_* tools. There is no output schema and no further documentation, so the agent cannot accurately predict what this tool will do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the parameter semantics baseline is 4. The description adds nothing about parameters, but there is nothing to explain. Schema coverage is trivially 100% and no parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific goal: 'drive Ghidra/Rizin/x64dbg/IDA for EXE crypto → XP3 scheme.' This clearly identifies the tool as a playbook/workflow for reverse engineering EXE encryption to derive an XP3 scheme, distinguishing it from single-tool siblings like re_rizin or xp3_re_xor_recover. However, it does not explicitly define the scope of actions or how it orchestrates the listed tools, leaving some ambiguity about what the playbook actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. It does not mention any exclusions or recommend it for specific scenarios beyond the implied purpose of analyzing EXE crypto to identify an XP3 scheme. Sibling tools exist for more focused operations, but the description does not address when to choose this playbook over them.
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 available, the description carries the full burden for behavioral disclosure. It only states that the tool loads a file into a map, but does not mention error handling, whether the file must exist, read-only nature, or side effects. The KAGConfigEX2 semantics are referenced but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence. The verb and resource are front-loaded, and every word provides necessary information without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description gives the output type but not the exact return structure or path semantics. It also lacks usage context relative to sibling kagconfig tools, making it incomplete for an agent that needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not clarify the 'path' parameter at all. It is unclear whether path should point directly to Config.tjs or to a directory containing it. The description adds no meaning beyond the schema's bare type and name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads Config.tjs into a flat key→value map, using KAGConfigEX2 semantics. This is a specific verb+resource, and it distinguishes from siblings like kagconfig_summarize or kagconfig_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as kagconfig_list_keys or kagconfig_summarize. The description does not mention any exclusions or contextual use cases.
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 convey behavioral traits on its own. It says 'static probe,' which hints at a read-only analysis, but does not disclose side effects, return values, prerequisites, or limitations beyond the parameter names. This is minimal information for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line, front-loaded with the tool category and using a slash-separated list to enumerate functions. It has no wasted words, but the structure is cryptic and mixes concepts without proper punctuation, which slightly hurts readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description carries the full burden of explaining the tool. It lists three modes but does not explain what the probe returns, how params interact, or which mode to choose. For a 4-parameter tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all four parameters (url, path, folder, game_dir) at 100% coverage, so the baseline is 3. The description adds a light mapping to capabilities like 'archive:// URL map' and 'game scan,' but does not explicitly connect these to the parameters. It adds some value but does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'CxdecHelper static probe' and lists three specific capabilities (IsCxdecArchive, archive:// URL map, game scan), which points to a clear resource (cxdec archives) and action (probing). It distinguishes from siblings like archive_probe by focusing on cxdec, but lacks a strong verb and uses domain jargon, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives like xp3_re_analyze or archive_probe. The three listed functions imply some use cases, but there are no conditions, exclusions, or references to other tools.
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 reveals the 'override' and 'zero adlr' aspects, but does not state side effects such as whether an existing output file is overwritten, whether directories are created, or what happens with the input folder. For a mutation-style tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence with no wasted words. It front-loads the primary action and output format, then appends the technical overrides. It is efficient, though the jargon may be opaque to some agents, it earns high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no output schema, and no annotations, the description is too minimal to fully orient an agent. It omits important behavioral context, parameter semantics for half the inputs, and does not clarify how this fits among the many sibling Kirikiri packing tools. The provided schema descriptions help partially but leave gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40% (two of five parameters have descriptions), so the description must compensate. It does not: 'input' is left unexplained beyond the implied folder reference, and the compress flags are not clarified. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pack') and resource ('folder to unencrypted.xp3'), clearly indicating the tool creates an unencrypted Kirikiri archive. The technical qualifiers ('KirikiriUnencryptedArchive override; zero adlr') add precision and separate it from sibling pack tools like xp3_pack or kirikiri_pack_patch, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Pack folder to unencrypted.xp3' implies the intended use case: producing an unencrypted archive. However, there is no explicit guidance on when to choose this tool over other pack tools (e.g., for encrypted packs or patch archives), nor any mention of exclusions or prerequisites.
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 behavioral disclosure. It states the function and internal method name but does not disclose side effects (e.g., overwriting files), required resource directory semantics, the effect of the 'compress' and 'fix_offsets' parameters, or any safety or permission considerations. The behavior is only minimally implied by the word 'Repack'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without excessive words. However, it is so terse that it omits needed details, slightly reducing its effectiveness as a complete description, though it remains highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no parameter descriptions, no annotations, and no output schema, yet the description is only 12 words. It does not cover prerequisites, return values, error conditions, or the relationship to sibling tools like 'kirikiri_pimg_unpack'. This is far from complete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at the purpose of 'input', 'output', and 'resource_dir' via 'Repack N.res into .pimg/PSB'. It does not explain the meanings or allowed values of 'compress' or 'fix_offsets', nor does it clarify the exact format expected for 'input' or 'resource_dir'. This is insufficient for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Repack N.res into .pimg/PSB', using a specific verb ('Repack'), a specific resource ('N.res'), and a specific output format ('.pimg/PSB'). This clearly distinguishes it from sibling tools like 'kirikiri_pimg_unpack' and 'kirikiri_psb_analyze_export'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It implies a repacking workflow through the verb 'Repack' and the mention of 'KrKrZ PSBResManager.Export', but does not explain when a user should choose it over similar pack/repack siblings.
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. It implies a read-only analysis by saying 'bytecode/strings for RE', but it does not disclose side effects, output format, or whether the operation is safe. The negative clarification about translation JSON is helpful but not sufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: it states what the tool is, which platform, what it deals with, and what it is not. Every word adds value, making it an effective one-liner without wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and only one parameter. The description provides bare-bones context about purpose but omits critical details like the exact output structure, prerequisites, limitations, or any safety notes. This is insufficient for an agent to confidently invoke the tool in a complex reverse-engineering workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter 'path' with no description, and the tool description does not elaborate on it at all. With schema description coverage at 0%, the description should compensate, but it fails to explain what kind of path is expected or any constraints, leaving meaning to inference from the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a PSB analyzer for KrKrZ, focusing on bytecode and strings for reverse engineering. It explicitly excludes translation JSON, which helps distinguish it from related tasks and sibling tools, though it lacks a full imperative sentence like 'Analyzes...'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an implicit use case (reverse engineering) and an explicit exclusion ('NOT translation JSON'), which provides some guidance on when to use it. However, it does not explicitly name alternative tools or describe conditions that would favor another sibling like kirikiri_psb_analyze_export.
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 'replace' and 'rebuild blob' which imply mutation, but does not state side effects, safety, reversibility, or whether the operation is in-place or produces a new file (output parameter exists but is not described).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is compact and front-loaded. Every word contributes meaning (the action, target, and the engine context), with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that modifies game data, the description is minimal. It gives one contextual clue (KrKrZSceneManager) but omits important information like prerequisites, side effects, return values, and how the input/output arguments relate to the operation. The presence of an optional 'output' parameter adds ambiguity that is not clarified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning beyond the bare schema by identifying that the 'strings' array replaces the TJS2100 DATA string table and that the result is a rebuilt blob. However, it does not explicitly map each parameter (e.g., 'input' vs 'output') and lacks detail on format expectations, so it partially compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Replace TJS2100 DATA string table and rebuild blob') with a clear resource and technical context (KrKrZSceneManager). It is not a tautology and conveys the core intent, though it does not explicitly differentiate from sibling tools like kirikiri_tjs2100_import or split/merge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description only names the operation, leaving the agent to infer when it is appropriate relative to sibling tools.
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 positive condition (true if mark exists) and does not mention error behavior, file access implications, what happens when the file is missing, or the return value for the negative case. The mention of 'sigchecker CheckExeHasSignature' adds no meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with the key condition. No unnecessary words or details are present, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean predicate with one parameter and no annotations, the description provides the core information. However, it lacks context about the XRELEASE_SIG____ mark, the return format beyond 'True', and how it relates to sibling signature tools. Given the tool's simplicity, this is borderline adequate but leaves room for clearer usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies that 'path' refers to an EXE file but does not explicitly define the parameter, its expected format, or constraints. The single parameter remains minimally described, leaving the agent to infer that the path points to a file to be checked.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it returns true if an EXE has the XRELEASE_SIG____ mark. This is specific and distinguishes it from siblings like krdevui_sig_check or krdevui_sig_sign by referencing a particular mark and underlying function. However, it lacks an explicit verb like 'checks' or 'returns', relying on 'True if' to convey 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The sibling tools krdevui_sig_inspect, krdevui_sig_check, and krdevui_sig_sign likely overlap in purpose, but the description does not clarify what makes this tool the right choice for specific scenarios.
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 carry the full burden of behavioral disclosure, but it only says 'Locate' without explaining whether this is a read-only scan, what the output format is, or if it modifies the file. The lack of detail about behavior beyond the basic action leaves significant opacity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, densely packed sentence that lists the specific marks to locate. No unnecessary words, and it is front-loaded with the action and target. It earns its place despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain what 'locate' returns (e.g., offsets, presence). It does not, leaving a critical gap. The simplicity of the tool reduces the burden but does not eliminate the need to specify return value or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the sole parameter 'path' at all. It fails to clarify that the path should point to a Kirikiri EXE file, leaving the parameter semantics entirely to inference from the tool name and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: locating specific Kirikiri EXE marks (OPT_EMBED / CORE_SIG / RELEASE_SIG / XP3). The verb 'Locate' is specific and the resource is well-defined, distinguishing it from siblings like krdevui_sig_has_signature (which checks existence) and krdevui_sig_sign (which creates signatures).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It neither states the typical scenario nor mentions any exclusions or prerequisites. Without this context, an agent cannot decide between krdevui_sig_inspect and related signature tools.
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 burden of behavioral disclosure. It mentions 'optional backup,' which hints at file overwriting, but it does not explicitly state that existing files may be overwritten, what happens without backup, or any permission/risk implications. The schema's backup description adds detail but is not part of the tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It conveys the core action and the optional backup behavior in ten words, matching the standard of high-concision examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is too sparse. It does not mention that the sidecar kit must already exist or be listed, what 'native sidecar' means, or the relationship to sibling deployment tools. The lack of behavioral and usage context leaves the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it only restates the backup option in general terms. The schema already documents all parameter purposes thoroughly, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Copy'), the resource ('a native sidecar kit'), and the destination ('into a game directory'), making it a specific verb+resource pair. It is distinguishable from sibling tools like native_undeploy and native_run by the nature of the action, though it does not explicitly name 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that native_undeploy should be used for removal or that native_run is for execution after deployment. There is no context about prerequisites or conditions for use.
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 carries the full burden. It mentions headless mode and default analysis commands, but does not disclose whether the tool is read-only, what output it returns, or any side effects. This is a significant gap for a tool that executes external commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the tool's name and default behavior, containing no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should at least indicate what the tool returns or achieves. It does not mention output format, and the phrase 'crypto/Cx string hunt' is opaque without domain knowledge. For a complex tool with 3 parameters, the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 3 parameters (path, timeout, commands), so the baseline is 3. The description adds no new parameter semantics beyond the schema, though it aligns with the 'commands' omission default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as headless Rizin analysis and specifies the default command set (aaa + crypto/Cx string hunt). It is distinct from siblings like re_ghidra_headless, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like re_ghidra_headless or re_disasm. The mention of 'default' implies custom commands are possible, but there are no explicit context cues 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It fails to mention whether the file is overwritten, if directories are created, or what happens if no mapping table exists. The side effects of the 'sync_util' merge are not described in the tool description, only in the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that gets straight to the point. It is well-structured and front-loaded, though it omits useful contextual details that would improve clarity without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters and no output schema, and the description is minimal. It does not explain the purpose of the mapping table, how the sync_util option behaves, or what the tool returns. Given the context and existence of a related load tool, this description is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the 'path' parameter, and it is unclear whether 'path' is a directory or a full file path given the fixed name 'sjis_ext.bin'. Schema coverage is only 50%, with no description for 'path', and the tool description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Write') and resource ('current tunnel mapping table'), naming the output file 'sjis_ext.bin'. It effectively distinguishes itself from the sibling 'vnt_proxy_sjis_ext_load' by indicating a save operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool or how it compares to alternatives. While the name implies saving after a mapping table has been built, it does not state prerequisites or exclusion conditions, leaving usage ambiguous.
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 bears the full burden of disclosing side effects. It only says 'Update', which implies mutation, but does not state whether existing translations are overwritten, what happens if an ID is missing, or if any permissions are required. No error behavior or return value is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, action-first, with no fluff. It is appropriately concise and front-loaded, though it could arguably include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, only 2 params, and no annotations, so the description must provide essential operational context. It fails to explain return values, error handling, prerequisites for calling it, or the relationship between the 'work' parameter and 'bundle.jsonl'. This is a significant gap for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints that 'id' is a stable entry ID and 'translation' is the new value, but it does not explain what 'work' refers to (e.g., a file path, workspace, or bundle identifier) and leaves the structure of 'items' ambiguous beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update', the resource 'translations', and the locator 'by stable entry ID in bundle.jsonl'. It differentiates from sibling tools like vnt_insert (insert) and vnt_query (query) by specifying the update action and the ID-based targeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus vnt_insert, vnt_extract, or other translation-related tools. There are no prerequisites (e.g., the entry must already exist) or exclusions mentioned, leaving the agent to infer usage solely from the tool name.
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 disclosure burden. It only mentions 'without extracting', hinting at a non-destructive behavior, but it does not explicitly state that it is read-only, what information is returned, or any side effects. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 6-word sentence with no wasted words, front-loading the core action. However, it is perhaps too terse for a tool with four parameters, as it lacks any structured detail, but it is still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, and no annotations, the description is incomplete. It does not mention pagination behavior (limit/offset), the meaning of the format parameter, or the return value shape. The simplicity of the tool's action helps, but substantial gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides absolutely no explanation of the parameters (path, limit, format, offset). It does not compensate for the schema's lack of descriptions, leaving the agent without guidance on how to use the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('archive entries'), and explicitly distinguishes from extraction tools by adding 'without extracting'. It is specific and unambiguous, differentiating it from siblings like archive_unpack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without extracting' implies the tool is used when the user wants to see archive contents without decompressing, but there is no explicit contrast with other listing-related siblings (e.g., archive_list_formats, archive_probe). No when-not-to-use 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, the description must convey safety and behavior, but it only says 'analyze' and 'recommend'; it does not state read-only status, side effects, limitations, or what 'symptoms' detection entails. This leaves important behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundant wording. Every clause contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema or annotations, the description does not explain the optional parameter, return format, or prerequisites for meaningful use. It is minimally viable for selection but not for correct invocation beyond the required path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description only indirectly covers 'path' via 'one XP3'; 'sample_entries' is completely unexplained. The agent cannot infer what sample_entries controls or its acceptable values from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Analyze' with a clear resource and goal ('one XP3', 'cxdec/encryption symptoms', 'recommend next RE steps'). It differentiates from raw extraction tools but does not explicitly name sibling alternatives, so it stops 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use when analyzing a single XP3 to decide next RE work, but provides no explicit when-to-use/when-not-to-use or alternative tool guidance. The 'one XP3' scoping is the only 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?
No annotations are provided, and the description only states the action without disclosing potential side effects, failure behavior, or operational constraints. It does not mention whether output files are overwritten or what happens with unsupported formats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of fluff, making it easy to parse and fully aligned with the tool's core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks output schema and annotations, and the description provides only a minimal action statement. It does not explain return values, error conditions, or any context for usage, making it insufficient for an agent to fully invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines only 'input' and 'output' with no descriptions. The description implies input is the source audio and output is the decoded file, but it does not clarify path conventions, format encoding, or other details, leaving the two required parameters under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Decode' with a clear resource 'supported game audio' and output targets 'WAV/OGG/MP3', which distinguishes it from sibling audio tools like audio_probe and audio_list_formats that 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any mention of prerequisites, exclusions, or usage scenarios, leaving the agent without 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 only states the conversion action and supported formats, but does not disclose potential side effects, whether it overwrites existing files, error conditions, or the output structure. The mention of 'other supported image formats' is vague and provides no additional behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose efficiently. Every word earns its place, with no superfluous details or padding. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description is too minimal to be complete. It lacks critical context such as return behavior, file overwrite semantics, supported format lists, or error scenarios. Compared to more thorough descriptions for similarly scoped tools, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 33% coverage (only 'format' has a description), yet the description does not compensate by explaining the 'input' or 'output' parameters. It implies these are image files but does not clarify that they are file paths, the role of 'output' as destination, or how 'format' relates to file extensions. The description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Convert') and resource (image formats), listing explicit formats like PNG, TLG5, and TLG6. This distinguishes it from sibling tools such as image_probe (which inspects images) and image_pack_xp3 (which packs images into archives). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention image_probe for inspecting images or image_pack_xp3 for packaging, nor does it state any prerequisites or exclusions. There is no explicit 'when to use' or 'when not to use' 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 only says 'natively' and 'decode', but does not explain side effects, whether input/output are file paths or raw data, what happens on error, or what the return value is. The behavior beyond the basic operation is entirely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively communicates the core purpose with no fluff. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (two required strings) and no output schema, the description is insufficient for an agent to invoke the tool correctly. It fails to explain what input and output represent, how the mode is determined, or what the tool returns. More detail is needed, especially since there is no annotation or output schema to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two required string parameters (input, output) with 0% description coverage. The description adds only that it decodes modes 0-2, which implies input is scrambled and output is decoded, but it does not clarify the format or meaning of these string parameters. The mention of modes is also disconnected from the schema, which has no mode parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool decodes Kirikiri scrambling modes 0, 1, or 2, using a specific verb ('Decode') and resource. It distinguishes itself from siblings like kirikiri_scramble (encode) and kirikiri_descramble_tree (tree decoding).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. The description only states what the tool does, not when to prefer it over related tools.
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 carries the full burden of behavioral disclosure. It only states that the tool lists existing archives, but it does not clarify the numeric pattern (e.g., patch1.xp3, patch2.xp3), recursive behavior, handling of missing directories, or output format. The single sentence provides minimal insight into the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, has no filler, and front-loads the action ('List'). Every word is necessary it achieves maximum conciseness without irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too brief to fully equip an agent for correct usage. It fails to explain what 'unencrypted.xp3' means, how the base parameter alters the listing, or what the return data looks like. The tool is simple, but the description leaves too many details for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description's reference to 'custom base' gives a slight hint about the 'base' parameter but does not explain the default 'patch' or expected format. 'game_dir' is not described at all, leaving the agent to infer its purpose from the name. The description adds only marginal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly specifies the resource: 'patchN.xp3 (or custom base) and unencrypted.xp3.' This distinguishes it from sibling tools like archive_list, xp3_unpack, and other listing utilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as archive_list or xp3_list_schemes. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent without sufficient 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only names the action and optional packing, omitting what 'next patch folder' means, whether existing folders are overwritten, or any process details like file modifications or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is tightly worded and front-loaded with the core action, but it is almost too sparse for a tool with six parameters, sacrificing necessary context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is severely underspecified: six parameters, no annotations, no output schema, and only 17% parameter coverage. It fails to explain required inputs, the meaning of 'next patch folder,' or the behavior of pack_patch, making confident invocation impossible.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only 'base' is described). The description hints at 'pack' via 'optional pack_patch' but does not explain required game_dir, source_dir, stem, or descramble, leaving parameter meanings largely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (descramble a tree) and the destination (next patch folder), distinguishing this tool from siblings like kirikiri_descramble_tree by adding staging and optional packing context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case—staging a descrambled tree into the next patch folder—and mentions optional pack_patch, but it does not explicitly state when to choose this over alternatives like kirikiri_descramble_tree or kirikiri_pack_patch.
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 disclose side effects and safety. It mentions dumping files but does not state whether it overwrites existing files, creates directories, or has any destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes meaningful information about the tool's operation and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a write tool with no annotations or output schema, the description is too sparse. It omits critical details like whether the output directory must pre-exist, how the manifest is structured, and what the input path refers to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the parameters. It only hints at 'path' and 'output_dir' through the verb phrase, without defining formats, constraints, or required behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Dump'), names the exact resource ('TJS2100 sectors'), and specifies the output ('folder' with 'manifest.json + NNNN_TAG.bin'). This clearly distinguishes it from sibling tools like import/export/merge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives such as export, import, or merge. The description lacks any contextual hints 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?
With no annotations present, the description carries the full burden of disclosing behavioral traits. It gives a hint about the sources checked (PATH / env / native/re_tools bundling), which is useful, but does not state whether the operation is read-only, what the return format is, or any side effects. The word 'Discover' implies non-mutating behavior, but this is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value, and the parenthetical note clarifies the scope. It is a model of concise writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is minimally viable: it states what the tool does and the sources it checks. However, it does not mention what the return value looks like or how the 'ids' filter behaves in practice, leaving some ambiguity. This is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single optional parameter 'ids' with a clear description ('Subset of tool ids; omit for all'), providing 100% schema coverage. The tool description itself adds no parameter-specific information, so the baseline score of 3 is appropriate; it neither helps nor hinders beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Discover') and resource ('RE tool paths'), and adds scope details (PATH / env / native/re_tools bundling) that differentiate it from sibling tools like re_install or re_launch. It is concise but effective, though it could be slightly more explicit about what 'paths' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. The intended use is implied by the name and context, but the description does not state scenarios where discovery is needed before invoking other tools.
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 for behavioral disclosure. It implies a read-only operation via 'Show,' but doesn't disclose potential scanning overhead, output format, or whether it checks local filesystem, registry, etc. This is a significant gap for a tool that could have side effects or require environment inspection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb 'Show.' It's efficient and easy to scan. However, the trailing 'and MCP ops' is vague and somewhat wastes words without adding clarity, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), and the description gives a basic sense of purpose. But it's incomplete regarding what 'MCP ops' refers to and what the output looks like. It's adequate for a minimal status tool but leaves gaps for an agent deciding whether to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (empty). Per rubric, this is a baseline 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows installed/high-end RE tools, identifying a specific verb (show) and resource (tools like Ghidra/IDA/Rizin). It distinguishes from sibling tools like re_install or re_launch. However, 'and MCP ops' is vague and not fully explained, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the many sibling RE tools. It doesn't say 'check before installing' or mention alternatives. The implied usage is to view status, but without clear context or exclusions, the user/agent cannot determine when this is the right choice.
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?
Without annotations, the description carries the full burden of behavioral disclosure. It states the core operation ('Extract') and hints at an extra output (control-block signature offset), but it does not explain the output format, how 'interesting' is determined, or any side effects or prerequisites. This is minimal coverage for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the main purpose with no redundant words. It is an efficient and well-structured summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having five parameters and no output schema or annotations, the description provides only a one-line overview. It omits return behavior, parameter details, and the meaning of 'interesting' or the offset, leaving significant gaps for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the five parameters (path, utf16, min_len, keywords, max_hits). The vague term 'interesting' might loosely relate to keywords, but it does not convey parameter semantics or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Extract' and the resource 'crypto/Kirikiri strings', making the tool's purpose specific and unambiguous. It also distinguishes itself from sibling tools by focusing on string extraction and mentioning the unique output of 'control-block signature offset'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives such as re_search or re_disasm. The mention of 'crypto/Kirikiri' implies a reverse-engineering context, but there are no named alternatives or exclusion criteria, so usage is only implied.
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 states the core read/download action and output format, but does not disclose whether local files are overwritten, what authentication is required, or whether any side effects occur. This is insufficient for a tool that creates local files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. It is concise and free of filler, achieving maximum clarity with minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and no output schema, this sparse description is incomplete. It lacks details about authentication, multi-sheet handling, file naming, and error cases. The schema covers some output naming rules, but the description does not provide enough context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, and the description does not compensate. It adds no meaning about parameters beyond the schema's existing descriptions. For instance, spreadsheet_id, api_key, service_account, and sheet_names remain undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('Google Spreadsheet') with a clear output format ('local CSV/TSV'). It distinguishes itself from sibling tools like vnt_google_docs_list_sheets (which lists sheet names) and vnt_google_docs_line_stats (which provides stats) by indicating this tool downloads spreadsheet data to local files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for google_docs extract/insert' implies the tool is a preparatory step for subsequent extract/insert operations, giving some sense of when to use it. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or prerequisite steps.
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 disclose behavioral traits itself. It states the action and a default location but does not mention whether existing drafts are overwritten, side effects, permissions, or the nature of the generated draft. As a mutation tool, this leaves significant ambiguity about its runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and essential context. Every word earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, no output schema), the description is incomplete. It omits critical information about parameter semantics and behavioral side effects, leaving an agent uncertain about how to invoke it correctly and what to expect. A more detailed description is needed for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'name' is described). The description does not add meaning for the other three parameters (notes, output_dir, archive_hint) and does not compensate for the low coverage. It only mentions a fixed directory, which partially relates to output_dir but is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Write' and names the resource ('draft Python XP3 scheme') plus the target location ('xp3_schemes/user_drafts/'), clearly distinguishing it from sibling RE tools. The purpose for further RE is stated, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to create a new scaffolded XP3 scheme for reverse engineering, but it provides no explicit guidance on when to choose this tool over alternatives like xp3_re_analyze or xp3_re_workflow. No exclusions or alternative references are given, landing at the 'implied usage' level.
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?
Without annotations, the description carries the full burden of behavioral disclosure. The verb 'Summarize' implies a read-only operation, but the description does not explicitly state that the file is not modified, nor does it describe error behavior, path handling, or output format. The added detail about extracting title, resolution, and keys is helpful but not sufficient for a tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the key extracted fields. There is no redundancy or unnecessary detail; every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and only a minimal parameter schema. The description does not describe the return value structure, error scenarios, or when to prefer this tool over siblings. While the tool is simple, the lack of output information and usage context leaves the description incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'path' with 0% description coverage. The description mentions the target file type (Config.tjs), which partially clarifies what the path should point to, but it does not explicitly describe the parameter's format, whether it is a file or directory, or any constraints. The tool name and context add some meaning, but the parameter remains under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Summarize' with a clear resource 'KAG/Kirikiri Config.tjs' and lists the extracted fields (title, resolution, keys), distinguishing it from sibling tools like kagconfig_load and kagconfig_list_keys. This makes the tool's 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., kagconfig_load for full config access, kagconfig_list_keys for key enumeration). No exclusions, prerequisites, or recommended contexts 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?
With no annotations, the description must carry the behavioral disclosure burden. It only states the action and file types, without mentioning side effects such as in-place rewriting (which is only hinted at in the output param schema), prerequisites, or failure behavior. The description adds little beyond what the name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and scope. It contains no redundant words and is easy to parse. However, the brevity comes at the cost of omitting useful context, so it is efficient but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch operation that processes multiple file types across a folder, the description is notably thin. It lacks details on input/output behavior, directory recursion, error handling, and whether files are overwritten. There is no output schema or annotations to compensate, leaving the agent with insufficient context to anticipate the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (only 'output' has a description), and the tool description does not explain the input parameter or add any parameter-level semantics. The description mentions 'a folder' but does not map it to the input parameter, nor does it elaborate on how 'output' interacts with the operation. The description fails to compensate for the missing input parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Descramble') and resource ('all .ks/.tjs/.txt/.csv/.ini under a folder'), specifying both the file types and the folder scope. The 'tree' suffix and the mention of 'under a folder' effectively distinguish it from the sibling kirikiri_descramble, making 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch/folder usage via 'all ... under a folder' and the 'tree' suffix, but it does not explicitly state when to use this tool versus the singular kirikiri_descramble or other siblings. There is no direct alternative or exclusion mentioned, so usage is only implied rather than clearly guided.
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 repair action and the algorithm, but it does not disclose whether the input file is modified in place, what the optional 'output' parameter does, or whether the operation is reversible. This is a significant gap for a repair/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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the key action and resource. It is concise and scannable, though it is somewhat cryptic and could benefit from a brief expansion. Every token earns its place, so it merits a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a recovery operation) and the absence of annotations and output schema, the description is under-specified. It does not explain what the tool returns, how it interacts with files, or why MDF-awareness matters. An expert might infer much, but the description alone is incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate by explaining parameter roles. It does not explain 'path' or 'output'; while 'path' might be inferred as the file to repair, 'output' is completely ambiguous. The description adds no meaningful information about either parameter beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Repair') and resource ('empty chunk-table header offsets'), and it distinguishes this tool from siblings by referencing the KrKrZ PSBStrMan.TryRecovery algorithm and MDF-awareness. This clearly states what the tool does for someone familiar with the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a usage context: it is for repairing empty chunk-table header offsets, and the MDF-aware note hints at a specific file variant. However, it does not explicitly state when to use it versus other PSB or recovery tools, nor does it mention any exclusions or prerequisites.
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 only states that the tool lists certain items, but gives no details about output format, side effects, or any special behaviors. It is a minimal, non-destructive-sounding description but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action 'List' and enumerates the specific content. Every word is informative, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and is simple in scope, but the description only lists three categories without explaining what they mean or what the output looks like. It is adequate for a high-level capabilities overview but lacks detail on return structure or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the baseline is 4. The description adds context about the tool's content (ports, patch naming, example), which compensates for having no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and specific resources: KirikiriTools / KAGeXpress ports, patch naming, and a descramble→patch example. It is specific and distinguishable from sibling tools by its capabilities-focused scope, though it doesn't explicitly compare to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it lists, leaving the user to infer that this is an overview tool. There are no usage scenarios, preconditions, or alternatives 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only mentions the disassembly engine and addressing modes, but omits output format, side effects (e.g., read-only), and limitations, which is insufficient for a complex disassembly tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the key action and resource. Every word earns its place, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of annotations and output schema, the description should cover return format, error cases, and parameter details. It only states the basic purpose, leaving critical aspects unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 17% (only arch is described). The description clarifies that offset, rva, and va are addressing modes, adding meaningful context. However, it does not explain count or path semantics, so it only partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs Capstone disassembly and specifies the addressing modes (file offset, RVA, VA). This distinguishes it from sibling disassemblers like re_rizin, which likely use different engines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives like re_rizin or re_ghidra_headless. The description does not mention prerequisites, preferred scenarios, 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 full burden. It only says 'Search/page' without disclosing that this is a read-only operation, how results are ordered, whether pagination is required, or any side effects. This is a significant transparency gap for a tool with no schema descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It earns its place, though it is too terse to be excellent—being concise is not the same as being complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, 0% schema coverage, no annotations, and no output schema, this one-sentence description is inadequate. It doesn't explain pagination, filtering behavior, or return format, so an agent cannot confidently invoke the tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it adds no explanation for any of the five parameters (q, work, limit, offset, untranslated_only). The agent gets no semantic guidance beyond the raw schema, making this dimension critically deficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search/page' and a clear resource 'extracted AI bundle.jsonl', and it explicitly ties usage to 'after vnt_extract', distinguishing it from sibling tools like vnt_extract, vnt_insert, and vnt_update. It clearly states the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context ('after vnt_extract'), telling the agent when the tool is applicable. However, it does not include exclusions or alternative tool suggestions, so it falls short of a full 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 responsibility. It lacks disclosure about side effects (none indicated), requirements (e.g., file existence or permissions), or return behavior. It states only the action, not the behavioral context around it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action and an exclusion. Every word earns its place; no verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description must explain return values or expected outputs, but it does not. The tool is simple, but given the lack of structured context, more information about the detection result would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention the 'path' parameter, leaving the agent to infer that a file path is expected. It adds no semantic detail about path type, constraints, or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Detect') and a clear resource ('archive format'), and the parenthetical clarifies it is not a conversion tool, distinguishing it from conversion-related siblings. This makes the primary 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'Detect archive format' but offers no explicit guidance on when to use it over alternatives like archive_list_formats or archive_unpack. The 'not for script/JSON conversion' provides a minimal exclusion but names no sibling alternatives.
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 burden for behavioral disclosure. It only says 'Rebuild TJS2100' without revealing whether the output file is overwritten, what happens to existing files in the output path, whether the source dump folder is modified, or any side effects or failure modes. This is a significant gap for a file-writing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. Every term contributes to understanding the tool's core purpose, and it is front-loaded with the action 'Rebuild'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, no output schema, and 0% parameter coverage, the description is insufficiently complete. It lacks critical context such as usage workflow, expected input format, output behavior, and any edge cases or prerequisites, making it only barely adequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides a clue that dump_dir points to a 'sector dump folder', but it does not explain the output parameter or clarify the expected structure of dump_dir. Parameter names are somewhat self-explanatory but the description adds only minimal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Rebuild' and identifies the resource 'TJS2100 from a sector dump folder', making it clear this tool reconstructs a TJS2100 file from split sector dumps. The parenthetical '(KrKrZ Merge)' reinforces its role as a merge operation, distinguishing it from sibling tools like kirikiri_tjs2100_split, kirikiri_tjs2100_import, and kirikiri_tjs2100_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it should be used when you have a sector dump folder and want to rebuild the original TJS2100 file. However, it does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites like having previously split a file or the relationship to kirikiri_tjs2100_split.
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 behavioral disclosure. It does not mention whether the operation is read-only, what happens on signature failure, or any side effects. The only behavioral nuance is the embedded vs. detached distinction, which is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose and input modes, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations) and current low schema documentation coverage, the description is far from complete. It leaves critical ambiguities about parameter usage and expected return values, making it marginally usable but insufficient for a fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (only public_key has a description), and the tool description adds no clarification for the five parameters. The difference between pubkey, public_key, pubkey_file, and public_key_file is unexplained, and the phrase 'embedded EXE or detached .sig' provides only a vague hint about the path parameter. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verify a Kirikiri RSA-PSS signature, with specific detail about embedded EXE or detached .sig sources. This distinguishes it from sibling tools like krdevui_sig_sign (signing) and krdevui_sig_inspect (inspecting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (for verification, not signing or inspection) and mentions two input forms (embedded or detached). However, it does not explicitly name alternatives 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?
With no annotations, the description must carry the burden of behavioral disclosure. It mentions the destructive action ('remove') and optional restore, but does not describe side effects, irreversibility, permissions, or what happens to existing backups or game_dir contents. This is insufficient for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the primary action and concise to the point of zero waste. It efficiently conveys both the core function and an optional behavior without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, 2 required, no output schema, and no annotations. The description provides minimal context: it does not explain what sidecar files are, how to specify them, what the restore_backup option entails, or what the tool returns. This is inadequate for an operation of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at the restore_backup parameter ('optionally restore newest backup'). The other four parameters (kit, game_dir, proxy_name, dest_subdir) are not explained, leaving key semantics to the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Remove deployed sidecar files; optionally restore newest backup.' It uses a specific verb and resource, and the phrase 'remove deployed sidecar files' distinguishes it from siblings like native_deploy and native_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as the inverse of native_deploy, but it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. The stated action makes the use case fairly evident, but no explicit 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 of behavioral disclosure. It mentions the at_ms filter but does not explain input selection (path vs text), return format, error handling, or the effects of encoding and strip_overrides. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. It is front-loaded with the verb and includes the most important qualifier (at_ms filter), making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters and no output schema or annotations, the description is too brief. It omits critical operational details such as how to provide input (path vs text), the output structure, encoding behavior, and override stripping, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description must compensate. It clarifies the format enum (SRT/ASS/SSA) and at_ms filter, but fails to explain the relationship between path and text, the encoding parameter, or strip_overrides. Several parameters remain ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Parse') and resource ('SRT (VNTextProxy) or ASS/SSA Dialogue cues'), with an optional timestamp filter (at_ms). This distinguishes it from other vnt_* tools, as no sibling tool performs subtitle parsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for parsing subtitle files but does not explicitly state when to use it over alternatives or any exclusions. The purpose is clear from the context, but there is no explicit when/when-not guidance.
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 bears full responsibility for disclosing behavior. It reveals that the tool ranks results by file-magic score, but does not disclose whether it modifies files, requires specific permissions, or how the brute force operates. It also fails to mention failure modes or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and key options, with no wasted words. It is well-structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters, no output schema, and no annotations, making the short description insufficient. It lacks details on the meaning of file-magic score, how schemes are ranked, prerequisites, and expected output. Context from sibling tools suggests this is part of a larger workflow, but the description does not situate it within that workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'built-in XP3 schemes' and 'XOR brute', which map to the schemes and xor_brute parameters, but it provides no details on the required path parameter or how the parameters interact. With only 50% schema coverage, the description fails to compensate for the undocumented required property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Try built-in XP3 schemes'), an optional enhancement ('XOR brute'), and a ranking output ('rank by file-magic score'). It distinguishes from siblings like xp3_list_schemes, which only list schemes, and xp3_resolve_scheme, which resolves a single scheme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when attempting to identify or decrypt XP3 archives with built-in schemes and optional XOR brute-forcing, but it does not explicitly state when to prefer this over alternatives like xp3_re_xor_recover or xp3_list_schemes. No exclusions or alternative tool names are given, leaving usage context inferred.
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?
There are no annotations, so the description must disclose behavior. It only states what the tool detects, not whether it is read-only, what it returns, or any limitations. No details on side effects, errors, or performance characteristics are provided, leaving the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core function. Every word is purposeful, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter probe tool with no output schema, the description gives the essential purpose but omits any information about return values, invocation context, or relationship to sibling probes (e.g., audio_probe, archive_probe). It is minimally complete but lacks the context an agent needs to confidently invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'path' parameter at all. While 'path' is superficially self-explanatory, the tool description provides no guidance on expected input (e.g., file vs. directory, supported extensions, handling of non-existent paths). The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Detect PNG/TLG and other native image formats' with a specific verb ('Detect') and resource ('image formats'). It also distinguishes from siblings like image_convert and image_pack_xp3 by explicitly noting 'without vision/AI', making the tool's niche clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without vision/AI' implies a lightweight, pure-signature-based detection use case, but no explicit alternatives or when-not-to-use scenarios are mentioned. Usage is implied rather than stated, which is a clear gap compared to tools that name alternative 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?
The description discloses beyond the basic mutation operation that the tool works in UTF-16 encoding and preserves comments when possible, which is useful behavioral context. However, it omits other important behavioral traits such as error handling, file access requirements, or side effects on keys not included in the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. The parenthetical note on encoding and comment preservation is concise and provides meaningful information without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse. It does not cover return values, failure modes, backup behavior, or the effect on existing keys not listed in the update. The encoding and comment-preservation notes are helpful but insufficient for a complete operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by interpreting the `values`/`updates` parameters as 'keys' in Config.tjs, which clarifies their purpose. The schema already provides descriptions for two of the three parameters, but the required `path` parameter remains undescribed, and the structure of the update objects is not detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Update') and resource ('Config.tjs keys') with the specific qualifier 'in place'. This directly differentiates it from sibling kagconfig tools like load, list, and summarize, which are read-only operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or scenarios where a different tool would be preferable. The usage context is left entirely to inference.
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 burden. It only states that a mapping table is used, but does not disclose whether the operation is read-only, what the return format is, or what sync_util does. This is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the mechanism without any filler. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too brief. It does not specify the return value, error conditions, or the role of sync_util, leaving the agent without essential execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 67% of parameters with descriptions for hex and bytes_hex, and the description adds the context of using a loaded mapping table. However, sync_util remains unexplained, and the description does not clarify parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Decode' with the resource 'SJIS+tunnel bytes', clearly indicating the operation. It also mentions 'using the current / loaded mapping table', which distinguishes it from encoding or extension load/save siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for decoding SJIS/tunnel bytes, but provides no explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives like the encode sibling.
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 states the tool scans for an encryption control block, but does not disclose whether the operation is read-only, what output or side effects occur, or any permissions or prerequisites. The name 'inspect' hints at non-destructive behavior, but the description does not confirm it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the verb and resource, with no redundant filler. Every word contributes to the purpose. It is highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description must explain return values and operational context. It does not describe what the scan produces (e.g., whether it reports success, returns the control block, or outputs a report), nor how this step fits into a larger RE workflow. The mention of 'GARbro-style' gives some context but leaves critical gaps for an agent deciding to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'path' with the description 'Path to game .exe', covering 100% of parameters. The tool description adds the modifier 'official' and specifies the target as 'game EXE', which slightly enhances the schema but does not significantly add meaning beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scan') and resource ('official game EXE') to state exactly what the tool does: look for embedded Cx 'Encryption control block'. The mention of 'GARbro-style RE assist' provides useful context that distinguishes it from sibling tools like xp3_re_xor_recover or xp3_re_tpm_inspect, which target different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for reverse engineering assistance via 'GARbro-style RE assist', but it does not explicitly state when to use this tool versus alternatives, nor does it mention any conditions or exclusions. The context signal of sibling tools suggests it is one of several RE options, but the description gives no comparative guidance.
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 full burden for behavioral disclosure. It only states the recovery action and hints at two input modes, but fails to disclose any side effects, input format requirements (e.g., hex vs raw), limitations on key length, or what the output looks like. This is insufficient for a tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds meaning, and it is appropriately concise for a tool whose purpose is clear at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no output schema, and no annotations, this one-sentence description is under-specified. It does not cover return values, how to choose between plaintext vs archive entry, or key length constraints. The brevity leaves significant gaps for an agent attempting to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some semantic grouping by mentioning 'plaintext' and 'cipher' and 'archive entry', which helps map to parameters like cipher, plaintext_hex, and archive. However, with only 17% schema coverage and six parameters, the description only partially compensates; parameters like max_key_len and plaintext_path remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Recover') and the target resource ('repeating XOR key'), and specifies the method ('from known plaintext vs cipher or archive entry'). This is distinct from sibling tools like xp3_re_try_schemes or kirikiri_descramble, which target broader or different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied use case is recovering an XOR key when plaintext-cipher pairs or an archive entry are known. However, it does not explicitly state when to prefer this over alternatives, nor does it mention exclusions or prerequisites beyond the phrase 'or archive entry'.
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. The verb 'Show' implies a read-only operation, but the description does not explicitly state side effects, prerequisites, or error conditions. It does add value by listing the exact output categories.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a clear front-loaded verb. Every word earns its place, and there is no irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema), the description is largely sufficient. It enumerates the categories shown, though it could be more complete with a brief explanation of terms like 'native runtime' or 'task_routing_hint' for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (trivially). The description adds meaning by explaining what the tool reports (native runtime, workspace, formats, task_routing_hint), which is useful for understanding the tool's output without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Show') and names four resources it reports: native runtime, workspace, formats, and task_routing_hint. However, it does not differentiate from the sibling tool 're_status', which likely has overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like re_status. The description only states what it does, without mentioning exclusions or preferred contexts.
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 states the core action (collect indices) and implies a read-only operation, but does not mention what happens if the file is malformed, whether the file is modified, or any side effects. This is adequate for a simple list operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, filler, or repetition. It is perfectly sized for the tool's simplicity and is front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description conveys the essential purpose but misses some context an agent might need, such as what the returned indices look like, whether they are sorted, or how errors are reported. The description is sufficient for basic invocation but not fully complete without additional guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' has no schema description, but the description clarifies that the path points to a KAG .ks file. This adds meaningful context to the parameter. However, it doesn't explain format expectations (e.g., relative vs absolute, encoding) or how the path relates to the collected indices beyond being the source file. With 0% schema coverage, the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Collect' and identifies the exact resource ('[text num=N] indices from a KAG .ks file'), clearly distinguishing it from sibling tools that handle scenario text, archives, or other KAG operations. Even though the KAG tag syntax may be domain-specific, it precisely communicates what is extracted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or sibling tools like kirikiri_load_scenario_text that could be confused with this one. The usage context is only implicit from the tool name and description.
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 only says 'Export' without disclosing any side effects, output format, or requirements. This is insufficient for a tool with potential write behavior via the output 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core action and includes a necessary disambiguation. Every word earns its place, with zero fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 4 parameters, the description is too sparse. It does not explain what 'analyzer strings' are, the output format, or how this tool relates to neighboring PSB tools like kirikiri_psb_analyze or kirikiri_psb_try_recovery. Only one sibling is addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'compress' has a description), and the tool description adds no information about the parameters. The parameter names are somewhat self-explanatory, but the description fails to compensate for the low coverage, leaving 'input' and 'strings' under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports PSB analyzer strings for debugging/reverse engineering, using a specific verb and resource. It also explicitly distinguishes itself from vntextpatch_extractlocal for scn-to-json conversion, preventing confusion with a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance (NOT scn转json) and names the correct alternative (vntextpatch_extractlocal). The scope 'debug/RE' implies when to use it, making the usage context clear enough.
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 carries full responsibility for disclosing side effects. It only states file types and symmetry, but fails to mention that scrambling modifies files in place by default (unless output is provided), that files become 'FE FE' when scrambled (per force parameter description), or any prerequisites/reversibility. This leaves the agent without critical safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one concise sentence with little fluff and a clear front-loaded verb. It includes only essential information and references a sibling without verbose explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is too sparse to be a complete tool guide. It omits behavioral details, mode semantics, and any warning about the destructive nature of scrambling, meaning an agent would likely need external information before invoking the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes force and output, but input and mode lack descriptions. The phrase 'under a folder' helps clarify that input is the root folder, but the purpose of the mode parameter (0-2) remains completely unexplained. Thus the description adds only marginal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Scramble') and resource (all .ks/.tjs/.txt/.csv/.ini under a folder). The parenthetical 'symmetric to descramble_tree' clearly distinguishes it from the related sibling, indicating it is the inverse tree-level operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by naming descramble_tree as the symmetric counterpart, implying the tool is used when you need to scramble an entire directory tree. However, it does not explicitly mention when to use this over the single-file kirikiri_scramble or detail exclusions, 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 must disclose behavioral consequences. It only says 'Download' but does not mention whether existing installations are overwritten, network requirements, side effects on the filesystem, or that omitting 'tool' lists available options. This lack of detail undercuts transparency for a 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the tool's core function. It wastes no words and avoids redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has no annotations or output schema, so the description must carry the full load. It fails to explain return values, error behavior, side effects, or the 'omit to list' behavior implied by the schema. For a tool that installs software, critical operational details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'tool' has a description). The description adds value by enumerating valid values for 'tool' (rizin/x64dbg/ghidra/cutter/capstone/pefile), but it does not explain the semantics of 'force' or 'refresh_url'. With such low coverage, the description should compensate but fails to address two of three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Download open-source RE kits) and the specific targets (native/re_tools and pip packages), distinguishing it from sibling tools like re_rizin or re_status. The verb 'Download' and resource list make the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies clear usage: when you need to install these specific RE kits. However, it does not explicitly state when not to use it or contrast with alternatives like re_rizin or re_deploy. The context is clear enough for basic selection but lacks explicit 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 disclose behavior. It only states 'Launch', without explaining side effects, whether the process blocks, requires a display, or returns any output. This leaves the agent without key operational expectations for a process-launching tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action verb 'Launch' and contains no filler. It efficiently conveys the essential purpose and options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description captures its core function, but it omits operational details like process behavior and return value. Given no annotations or output schema, the description is not fully complete for an agent to predict what happens after invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents 'path' and 'tool' with descriptions, and the description reinforces that opening a PE is optional. However, the 'args' parameter remains undefined in both schema and description, and the description adds little for tool beyond what the schema's enum-style string already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Launch' and identifies the resource (GUI RE tool) with explicit tool names (ghidra/ida/x64dbg/cutter/binary_ninja). This clearly distinguishes it from sibling tools like re_rizin or re_ghidra_headless, which are likely CLI/headless variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for interactive GUI analysis by listing GUI tools and the optional PE, but does not explicitly state when to choose this over alternatives such as re_rizin or re_ghidra_headless. No exclusions or alternative recommendations are 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 full burden. It discloses a side effect (slots allocation) but does not explain reversibility, state changes, error conditions, or what happens to the input text. The mention of slot allocation is useful but incomplete for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that starts with the action and includes a parenthetical side effect. No filler, no redundancy, and all words carry meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, but the description does not mention the return value or outcome beyond slot allocation. It is unclear whether the encoded text is returned, stored, or only used for slot registration. The sync_util parameter and the overall workflow implications are left unexplained, making the description incomplete for a tool with side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (sync_util has a description, text does not). The description adds no parameter-specific meaning; it only mentions the allocation side effect, which is not tied to either parameter. For a low-coverage schema, the description should compensate but fails to explain the text parameter or how sync_util affects behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ("Encode") and the resource ("Unicode via SjisTunnelEncoding"), with an explicit side effect ("allocates sjis_ext slots"). This distinguishes it from the sibling decode tool and other vnt_proxy utilities, making 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when Unicode text needs to be encoded into SJIS, but it does not explicitly state when to use it over alternatives like vnt_proxy_sjis_decode or ext_load. No when-not-to-use or alternative references are provided, so usage guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of disclosing behavior. It reveals that only 'native' decoders are listed (a useful qualifier), but does not state read-only behavior, output format, or any potential side effects. For a list operation, this is minimal 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is immediately clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool, the description is adequate. It does not describe the return value, but the low complexity and clear scope make the description sufficient for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter details because there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('implemented native audio decoders'), clearly distinguishing this tool from siblings like archive_list_formats or vnt_list_formats. It immediately conveys the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like audio_probe or audio_decode. The description gives no context for selecting this tool in a workflow.
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 burden of behavioral disclosure. It does reveal a key safe behavior ('without opening or modifying them'), which is valuable. However, it omits other relevant traits like recursion behavior, hidden file handling, or output format, so it only partially discloses the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It directly states the action and a crucial safety qualifier, making it highly concise and appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is nearly complete. It communicates the core purpose and safety, while the schema covers the path semantics. The only minor gap is the lack of explicit indication that this is a filesystem/directory listing as opposed to an archive listing, though the schema's 'directory' reference partially covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not mention the 'path' parameter at all, but the schema already fully documents it with a default and a clear description. Thus the description adds no extra semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('files'), clearly stating the tool's core function. The additional phrase 'without opening or modifying them' reinforces its read-only nature, which distinguishes it from siblings like archive_list or format-specific tools. Despite not naming alternatives, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as archive_list or image_probe. There is no mention of appropriate contexts, exclusions, or fallback tools, leaving the agent without decision support for tool selection.
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 adds behavioral context by stating 'no binaries' and indicating the search location and environment variable fallback in the parameter description. However, it does not disclose what the tool returns (e.g., a path) or behavior when the template is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short clauses front-loaded with the verb 'Locate'. Every word contributes meaning, including the path and the 'no binaries' clarification. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple locate tool with one optional parameter and no output schema, the description covers the essential aspects: what it locates, where, and what it excludes. It could be more complete by explicitly stating the return value (e.g., the resolved path), but overall it provides enough context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (template_dir) with a description, achieving 100% schema coverage. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Locate KAGeXpress Template', with a specific path (源码/kagexpress/Template) and an explicit scope exclusion ('no binaries'). This distinguishes it from sibling tools like kirikiri_kagex_init_project or apply_config, which perform different actions on templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The name and description imply it is for locating the template directory, but there is no mention of prerequisites, related workflows, or when to prefer this over other tools that might also reference templates.
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 transparency burden. It adds a valuable behavioral detail (zero adlr checksums) and references the underlying tool (KirikoriTools Xp3Pack). However, it does not disclose potential side effects like overwriting output, permissions needed, or error behavior, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action, output, and key detail. The parenthetical with the tool name adds specificity without bloat. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pack operation, the description gives the core purpose and a key differentiator, but lacks guidance on compression parameters and when to use this over sibling tools. It is adequate as a minimum viable description but leaves clear gaps for an agent needing full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints that 'input' is a folder and 'output' is an XP3 file, but leaves compress_index and compress_contents entirely unexplained. The parameter names are somewhat self-explanatory, but the description adds minimal semantic value beyond them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Pack'), resource ('folder into patch XP3'), and key modifier ('zero adlr checksums'). It distinguishes itself from sibling pack tools like xp3_pack and kirikiri_pack_unencrypted by emphasizing the zero adlr checksum behavior and the KirikiriTools Xp3Pack implementation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating patch XP3 archives without adlr checksums, but does not explicitly name alternatives, exclusions, or when to choose this over other pack tools. The zero adlr checksums hint gives context, but no direct comparison or 'use when' statement 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 must carry the full burden. It states the action and output but does not disclose side effects (e.g., whether files are overwritten), prerequisites, permissions, or error behavior. The reference to PSBResManager.Import adds a hint of internal behavior but is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant phrases. Every word contributes to the meaning. It is appropriately concise for a tool with only two parameters and a straightforward purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and target format, but it lacks details about the output (e.g., whether N.res is a file or directory), potential pitfalls, or the relationship to other operations. Given the simple parameter set, the minimal description is adequate but not rich enough to be fully complete in the context of many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the parameters. The parameter names 'path' and 'output_dir' are somewhat self-explanatory, but the description does not confirm their roles (e.g., path as input file, output_dir as target folder) or any constraints. Since coverage is low and description fails to compensate, this warrants a below-average score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unpack .pimg/PSB chunk resources to N.res' uses a specific verb ('unpack') and explicitly names the input (.pimg/PSB) and output (N.res) formats. It also references the underlying function (KrKrZ PSBResManager.Import), which adds precision and distinguishes it from the sibling tool 'kirikiri_pimg_pack' (the inverse operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when to use the tool: to unpack .pimg/PSB chunk resources to N.res. While it doesn't explicitly mention alternatives or when-not-to-use scenarios, the specific input/output formats provide clear context for an expert agent. The inverse sibling 'kirikiri_pimg_pack' is implicitly excluded by the direction of the operation.
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 action and format, but does not disclose side effects, whether it writes data, prerequisites, error behavior, or return values. The term 'import' is ambiguous regarding what actually happens to the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two sentences: one for the core purpose and one for clarification. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the description covers the essential purpose and includes a helpful sibling distinction. However, it lacks behavioral details (what 'import' does), output expectations, and prerequisites. With no annotations or output schema, these omissions leave gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's single parameter 'path' has no description (0% coverage), so the description must compensate. The phrase 'from compiled TJS2100' suggests the path points to a compiled TJS2100 file, but it doesn't clarify expected file extensions or format specifics. This is minimal but usable context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Import UTF-16 string table from compiled TJS2100 (KrKrZ)', specifying the verb, resource, and format. It also explicitly distinguishes itself from VNTextPatch's scn→json conversion by naming the alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit exclusion ('NOT VNTextPatch「scn→json」') and names the correct alternative ('use vntextpatch_extractlocal'). This is useful guidance, though it doesn't discuss other related TJS2100 siblings (export, list_sectors, split/merge), so it's not a comprehensive usage guide.
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 must carry the behavioral burden. It clearly states 'Read', implying a non-destructive operation, and adds 'no playback' to clarify scope. However, it does not mention output format, permissions, or potential edge cases, leaving some transparency gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource with zero redundant words. Every word adds value, earning a top score for structure and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description states the core function but does not describe the shape of the returned data or any additional behavior beyond 'no playback'. This is adequate for a simple read, but it leaves the user guessing about the output, making it neither complete nor severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'path', describing it as '.sli path, or wave path (uses FileName.sli)'. The description adds no additional parameter semantics, so the baseline of 3 is appropriate, as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('Kirikiri WaveLoopManager .sli links/labels'), clearly distinguishing it from sibling tools like loop_write and other kirikiri readers. The parenthetical 'no playback' prevents confusion with audio playback tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to inspect .sli loop labels, and 'no playback' provides a negative constraint. However, it stops short of explicitly stating when to use this tool versus alternatives like loop_write or other kirikiri analysis tools, leaving the guidance implicit.
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. It adds the behavioral detail that output goes to an independent output, implying non-destructive behavior. However, it doesn't disclose error handling, encoding specifics, or file/folder handling nuances beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a disambiguation note. It is concise, front-loaded with a clear 'JSON→脚本' label, and every word adds value. No wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description provides the core purpose and a selection hint, but lacks edge-case behavior, usage context, or return value expectations. The schema fills most parameter meaning, but the description could mention file/folder handling or prerequisites for a more complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, so the baseline is 3. The description restates the schema's role mapping (translated .json to script) without adding new parameter details. It doesn't explain format, timeout, or optional sjis_ext beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: writing translated .json back into script files with an independent output, using 'classic VNTextPatch insertlocal'. It also explicitly distinguishes from sibling vnt_insert, satisfying sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a negative exclusion ('不是 vnt_insert') but no explicit when-to-use or alternative guidance. It implies usage via the JSON→script direction and the 'local' in the name, but lacks explicit scenarios or comparison to alternatives like extractlocal.
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 transparency burden. It discloses the important read-only nature, but lacks detail on authentication requirements, error behavior, or return format. As a simple read operation, the gap is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the main verb and resource, and includes useful context (Sheets API, read-only). Zero fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and read-only, but there is no output schema or description of the return value. The description does not specify whether the output is an array, a formatted list, or includes any metadata. It is adequate but leaves some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so most parameters are documented. The description adds little beyond what the schema provides; it does not elaborate on spreadsheet_id format or the relationship between api_key and service_account. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('sheet titles in a Google Spreadsheet'), and notes it uses the Sheets API in a read-only capacity. This distinguishes it from sibling tools like vnt_google_docs_fetch or line stats tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering sheet titles but does not explicitly state when to prefer this tool over alternatives or provide exclusions. There is no mention of use cases like 'before fetching specific cells' or comparisons to vnt_google_docs_fetch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It conveys a read-only scanning action and an emitted playbook, but does not explain whether the playbook is written to disk or returned, or any side effects. The verb 'scan' implies non-destructive behavior, covering the most important trait, but deeper behavior is left ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word contributes to understanding the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description gives the essential action and target file types, making the tool invocable. However, 'RE playbook' is domain jargon and is not defined, and there is no mention of return values or whether any files are produced, leaving a moderate ambiguity gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes game_dir as 'Game directory' with 100% coverage, so the baseline is 3. The description adds a little contextual value by clarifying this is the folder scanned for XP3/TPM/EXE, but it does not add format, path, or constraint details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('scan'), a clear resource ('game folder'), and explicit file extensions (XP3/TPM/EXE), while also stating the output ('emit an RE playbook'). This clearly differentiates it from sibling tools that focus on specific inspection, unpacking, or workflow execution steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to scan a game folder for XP3/TPM/EXE files and generate an RE playbook, but it does not explicitly state when to choose this over alternatives like xp3_re_analyze or re_discover. No exclusionary 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only listing operation via 'List', and adds the source file 'Formats.dat', but does not describe output format, ordering, or any side effects. This is minimal but sufficient for a trivial read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that is clear and free of unnecessary words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool, the description provides the core information needed. It lacks details like where Formats.dat is found or how results are presented, but these are not critical for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description need not explain inputs. It adds useful context by mentioning the source file (Formats.dat), which is the only relevant operational detail. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('Nitroplus NPA EncryptionScheme titles from Formats.dat'). It distinguishes this tool from similar sibling tools like xp3_list_schemes by specifying NPA and the source file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as npa_resolve_scheme or xp3_list_schemes. The description simply states what it does without contextualizing its role in a workflow.
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 behavioral traits. The verb 'List' implies a read-only operation, and the output fields are specified, but there is no explicit statement about safety, side effects, or whether the list is exhaustive or filtered. The meaning of 'status=ready' is ambiguous—whether all entries have status 'ready' or only ready schemes are shown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and key output details. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description covers the essential return value (list of schemes with name, params schema, status). However, the ambiguity around 'status=ready' and the lack of any caveats or limitations prevent a perfect score. The presence of sibling resolver tools suggests a broader workflow that this description does not hint at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing the description needs to add beyond what the empty schema already shows. The baseline for 0 params is 4, and the description does not introduce any confusion about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('List XP3 decryption schemes') and specifies the output fields (name, params schema, status=ready), making it clear what the tool does. It is distinguishable from sibling tools like xp3_resolve_scheme or npa_list_schemes due to the XP3 scope and 'list' 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It merely states the function without context, so an agent would have to infer when listing schemes is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the write-back mutation and the 'separate output' behavior, which signals non-destructive output targeting. However, it omits overwrite behavior, permissions, and failure modes, leaving gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler; the first sentence states the action and output, the second gives alternatives. It earns every word but uses shorthand [AI bundle] that may require context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters with zero schema descriptions and no annotations/output schema, the description leaves important gaps. It provides workflow context and differentiation but doesn't explain what each parameter should contain or what the tool returns. This is insufficient for confident invocation without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and no parameter descriptions exist. The description mentions bundle.jsonl and script output but doesn't map these to the three parameters (input, work, output), so parameter usage remains ambiguous. It only hints that 'output' is the separate destination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: writing back bundle.jsonl translations into script files in a separate output. It explicitly differentiates itself from vntextpatch_insertlocal for classic JSON→scn and names its counterpart vnt_extract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool versus alternatives: use it for 'AI bundle' workflow, and use vntextpatch_insertlocal instead for classic JSON→scn. The mention of corresponding vnt_extract clarifies the pairing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The word 'Inspect' implies a read-only operation, and the description adds specific behavioral details (Cx control block + interesting strings). However, it doesn't explicitly state safety, side effects, or output format, 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 14 words. Every word contributes to conveying purpose and scope, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core purpose and parameter type. However, it omits any mention of the output format or return value, and lacks usage guidance relative to sibling tools, which are significant gaps given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes 'path' simply as 'Path to .tpm / PE'. The description adds meaning by clarifying that the path can point to a Kirikiri .tpm file or any PE executable, and that the tool will focus on Cx control block and strings, enriching the schema's semantic coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Inspect a Kirikiri .tpm (or any PE): Cx control block + interesting strings.' It uses a specific verb (Inspect), identifies the resource (.tpm/PE), and details the specific focus (Cx control block + strings), distinguishing it from siblings like re_pe_info and re_strings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool by mentioning the specific .tpm/Cx control block focus, which differentiates it from generic PE inspection or string extraction. However, it lacks explicit guidance on when not to use it or which sibling tools to prefer for alternative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly indicates a read-only enumeration action via 'List all,' but it does not disclose any additional behavioral traits such as whether it reflects runtime-discovered plugins or requires initialization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb 'List' and contains zero filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-annotation, no-output-schema tool, the description clearly states what is listed and even specifies 'pack support' as an additional dimension. It is slightly terse but sufficient for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already reflects that with 100% coverage. Baseline 4 applies because there is no parameter ambiguity for the description to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'List' and identifies the resource as 'all native archive format plugins and pack support.' It clearly distinguishes from sibling tools like archive_list (which likely lists archive contents) and archive_probe (which likely probes a specific archive).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this to see which archive formats are natively supported and whether packing is supported. However, it does not explicitly mention when not to use it or compare it with alternatives like audio_list_formats or vnt_list_formats.
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. The verb 'List' conveys read-only behavior, and the parenthetical adds detail about what content is returned. However, it does not explicitly state that there are no side effects or permissions needed, though these are generally inferred for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. The parenthetical efficiently conveys the content scope without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description provides adequate completeness by naming the location (native/) and the categories of items listed. It does not explain potential error conditions or the exact return format, but these are less critical for a straightforward listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is effectively 100% and no parameter documentation is needed. The baseline of 4 applies, and the description adds no parameter information since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'native DLL/EXE kits under native/', with a parenthetical enumerating content categories (paths, files, proxies, tools, tool_guide). This distinguishes it from sibling listing tools like gal_list_dir, which targets a different directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to list native sidecars) but provides no explicit or-when-not guidance or alternatives. It does not mention exclusions or compare with sibling tools like native_deploy or native_run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the local bundled Formats.dat map as the source and the output shape, but does not mention what happens when no match is found or whether lookup is strictly read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the action, input, output, and data source with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup with no output schema, the description covers purpose, input, source, and output shape. It leaves out failure behavior, but the tool is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single 'title' parameter already has a clear description ('Game title substring (case-insensitive)'). The tool description adds context about the map source but no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Resolve' with clear resource: a game title maps to XP3 scheme and params via a bundled Formats.dat map. This distinguishes it from sibling tools like xp3_list_schemes and npa_resolve_scheme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for obtaining a scheme+params for a given game title, which is a distinct use case. However, it does not explicitly name 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.
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 states 'Run a catalogued native EXE with raw args' but does not mention any safety concerns, side effects, output capture, or what happens to the process. The reference to 'raw args' is a hint but insufficient for a potentially arbitrary command execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose and immediately provides actionable alternatives and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description provides useful examples and usage guidance but omits behavioral details like output capture, return format, and safety implications of running arbitrary EXEs. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), so the baseline is 3. The description adds value by giving concrete examples for the 'tool' parameter (vntextpatch, krkrtpc, kagconfig) and for 'args' (extractlocal/insertlocal), enriching what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's function: running a catalogued native EXE with raw arguments. It distinguishes itself from wrappers like vntextpatch_extractlocal/insertlocal by noting the preferred alternatives, making its specific role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises preferring vntextpatch_extractlocal and vntextpatch_insertlocal wrappers for the common cases, and lists other supported tools (krkrtpc, kagconfig). This gives concrete when-to-use and when-not-to-use guidance relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool's read-only nature ('List') and specifies the scope (keys from Form1/Form2) and the kind of output (types, quote modes, r/w coverage). It does not describe potential side effects, but for a listing tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and object. Every word adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with no output schema, the description adequately explains what the tool lists and what aspects are included. It could go a step further by mentioning the output format, but the given details cover the essential purpose and scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description needs no parameter details. The description adds meaning by clarifying the domain (KAGConfigEX2) and the output contents, which is useful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List'), the resource ('known Config.tjs keys from KAGConfigEX2 Form1/Form2'), and the specific aspects covered ('types, quote modes, Form1 r/w coverage'). It distinguishes itself from siblings like kagconfig_load or kagconfig_set by indicating a read-only enumeration of known keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool to list known Config.tjs keys. However, there is no explicit when-to-use vs alternatives or any mention of conditions like needing a loaded config. The sibling names (kagconfig_summarize, kagconfig_load) suggest alternatives, but the description does not address them.
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 burden for behavioral disclosure. It states the conversion direction (script to per-file JSON) and implies writing output, but does not mention side effects, prerequisites (e.g., VNTextPatch installed), overwrite behavior, or error handling. This is a baseline level of transparency for an extraction tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with front-loaded purpose. Every clause earns its place, and the exclusions are packed efficiently without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (4 params, no output schema) and the description covers its core mapping, user-trigger phrases, and sibling exclusions. It does not mention the inverse tool vntextpatch_insertlocal or potential dependencies, but these are not necessary for basic invocation. Slight gap around what 'classic' implies, but overall sufficient for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters succinctly. The description adds some semantic context by mentioning 'scn/ks/…' and 'per-file .json', which aligns with the input and script parameters, but does not go beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Classic VNTextPatch extractlocal: script → per-file .json'. It explicitly names the resource (scn/ks scripts) and the output format, and distinguishes itself from sibling tools vnt_extract and kirikiri_psb_* with concrete examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use signals: 'When user says "scn to json" / "export script json", use this'. It also provides clear exclusions: 'Not vnt_extract(bundle.jsonl), not kirikiri_psb_*', which directly addresses alternative selection.
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. The verb 'list' implies a read-only operation, but the description does not explicitly state safety, side effects, or return behavior. It adds scope information but no additional behavioral traits such as 'no side effects' or 'returns a list of format names'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter listing tool, the description is largely complete. It names the exact resource and scope. The lack of output schema means it could mention the return format, but 'list script formats' sufficiently implies a list of format identifiers. Minor gap: no mention of error conditions or whether the list is static/dynamic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is vacuously 100%. Per guidelines, a 0-parameter tool receives a baseline of 4; the description does not need to explain parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('script formats'), with a specific scope ('pure-Python vnt_* bundle layer') and an explicit exclusion ('not VNTextPatch CLI'). This distinguishes it from sibling list tools like audio_list_formats and archive_list_formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about the tool's scope and an exclusion ('not VNTextPatch CLI'), which helps the agent know when to use it. However, it does not explicitly name alternative tools or give 'when to use' guidance beyond the scope statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is a mapping table and mentions its focus areas, but it does not describe what the tool actually returns, how the agent should use the mapping, or whether it is a static reference or an interactive prompt. With no annotations provided, the description carries the full transparency burden, but for a read-only guidance tool, the disclosed nature is reasonably clear, though missing behavioral output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each with a distinct purpose: definition, usage trigger, and specific coverage. It is front-loaded with the core purpose and contains zero filler. Every sentence earns its place, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no annotations, no output schema), the description provides sufficient context for an agent to know when to call it and what it covers. It lacks a description of the exact output format, but for a simple meta-tool, this is a minor gap. The description is complete enough for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds context by implying the tool is a static guide the agent consults based on the user's wording, even though it requires no explicit input. This clarifies the tool's role beyond the empty schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a '对照表' (comparison table) mapping user wording to correct MCP tools, with a specific verb (选工具) and resource (correct MCP tool). It is distinct from sibling tools because it is a meta-tool for tool selection, not an actual operation. It also names specific disambiguation cases (scn→json, bundle.jsonl, PSB/TJS2100), further clarifying its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says '不确定用哪个时先调这个' ('call this first when unsure which to use'), providing a direct usage trigger. It also explains that it specifically distinguishes between ambiguous tool choices, guiding the agent on what kind of uncertainty this tool resolves. This is strong, actionable guidance without needing alternatives.
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 full behavioral disclosure. It specifies the input (a directory) and output (work/bundle.jsonl), and indicates the processing logic ('按条目 ID 翻译' - translate by entry ID). It also explicitly disclaims a behavior it doesn't perform. However, it does not mention side effects like overwriting existing files, permissions, or detailed prerequisites, which prevents a perfect 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two compact sentences. It front-loads the core purpose ('【AI bundle】目录→work/bundle.jsonl'), then adds a crucial negative clarification and an alternative. Every sentence serves a purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity (2 params, no output schema, no annotations), the description covers the essential transformation, output path, and sibling differentiation. Some ambiguity remains around 'AI bundle' and the exact meaning of 'translate by entry ID', but overall it provides enough context for an agent to select and use the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. The phrase '目录→work/bundle.jsonl' implies that 'input' is the source directory and 'work' is the base directory for the output file, providing meaningful roles for both parameters. It does not explicitly define formats or types beyond this, but it adds substantial semantic value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: converting a directory to 'work/bundle.jsonl' with entry-ID-based translation. It also distinguishes itself from another sibling tool by explicitly saying it is not 'scn转json' and pointing to vntextpatch_extractlocal for per-file JSON output, demonstrating a specific verb+resource+scope and sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it states what the tool is not for ('不是「scn转json」') and gives a direct alternative ('用户要经典每文件 .json 时用 vntextpatch_extractlocal' - use vntextpatch_extractlocal when classic per-file .json is needed). This clearly communicates when to use this tool versus the identified sibling.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/YeXuanHs/Galgame-mcp'

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