Inochi Creator MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Tools are grouped by clear domains (parameters, animations, nodes, project, import), and each tool has a distinct action-target pair. Even similar tools like import_folder vs import_images are differentiated by whether they replace the project or add under a node.
Naming Consistency5/5
All tools use the 'creator_' prefix with a consistent verb_noun pattern (set_parameter, list_nodes, import_psd). Actions and targets are uniformly ordered, and variations like set_node_enabled vs set_node_transform follow the same convention.
Tool Count2/5
With 40 tools, the surface is large and exceeds the 25-tool threshold for 'too many'. While the tools cover many facets of the application, the count is heavy and may overwhelm agents; some consolidation (e.g., generic import tool) could reduce redundancy.
Completeness4/5
The tool set covers the core domains of Inochi Creator: parameter lifecycle, node tree manipulation, animation control, project import/export, and viewport interaction. Minor gaps exist such as no explicit texture/material editing tools, but the primary workflows are well represented.
Average 3.8/5 across 40 of 40 tools scored. Lowest: 2.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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It mentions opening in a running Inochi Creator but does not disclose that opening a project likely replaces the current one, discards unsaved changes, or requires specific permissions. This is a significant gap for a tool that mutates the application state.
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 gets straight to the point with no filler or redundant information. It is well-structured and front-loaded with the 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?
For a simple tool with one parameter and no output schema or annotations, the description is under-specified. It does not explain what happens to the current project, error handling, return values, or the distinction from import operations. This leaves the agent with an incomplete picture for a state-changing operation.
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 already documents the 'path' parameter with 'Absolute path to the .inx project' at 100% coverage. The description adds a minor nuance by stating 'or compatible INP', which slightly extends the schema's documentation. Since the schema covers the parameter well, the description adds minimal additional meaning.
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 opens an .inx or INP project in the running Inochi Creator, using the specific verb 'Open' and identifying the resource. It is distinct from sibling tools like creator_new_project, though it does not explicitly differentiate from creator_import_inp, which may cause slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 creator_new_project or creator_import_inp. It does not mention scenarios, exclusions, or preferred contexts, so the agent is left without enough information to select it confidently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'Stop all animations' but does not explain side effects, reversibility, or what happens to the animation timeline or keyframes. The parameter 'immediate' hints at lead-out behavior, but the description itself adds no detail.
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, direct sentence with no waste. However, it is slightly under-specified for a tool that has relevant sibling tools and a parameter that affects behavior, so it does not earn a 5.
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 presence of sibling tools with overlapping functionality (pause, seek, play), the description is too minimal for an agent to confidently select this tool. It lacks details about the 'stop' semantics, consequences, and difference from pause, making it incomplete in 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?
Schema description coverage is 100% (the 'immediate' parameter is described as 'Skip lead-out (default true)'). The description text adds nothing beyond the schema, so the baseline score of 3 applies—schema does the heavy lifting.
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 'Stop all animations.' specifies the verb (stop), resource (animations), and scope (all), making the core purpose clear. It does not explicitly distinguish from sibling tools like pause_animation, but the scope is evident.
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., pause_animation, seek_animation). It lacks any context about appropriate scenarios or exclusions, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action 'rename a node' without mentioning side effects, persistence, potential errors, or any impact on references to the node. This is insufficient for an agent to understand the operation's implications.
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 only three words, making it extremely concise and free of fluff. It contains one clear, purpose-defining sentence, but it is possibly too minimal, sacrificing necessary context for a fully helpful definition.
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 a terse description, the tool definition is incomplete. The schema covers parameters, but the description omits crucial behavioral details such as whether renaming is reversible, what happens to node references, and what errors might occur. Given the many sibling node operations, more context is needed to fully understand the tool's role.
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 both parameters (uuid and name) are already well-documented in the input schema. The description 'Rename a node' adds no extra meaning beyond what the schema already provides; it merely implies that uuid selects the node and name is the new name, which is already stated.
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 'Rename a node' clearly identifies the specific action (rename) and the resource (node) in a way that distinguishes it from all sibling operations like create, duplicate, delete, and reparent. There is no ambiguity about what the tool 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?
The description offers no guidance on when to use this tool compared to alternatives. It does not mention any prerequisites, conditions, or related tools, 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 is the only source of behavioral info. It does not disclose whether pause preserves the current playhead position, whether it is reversible, or any side effects. Lacks 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?
One concise sentence clearly states the tool's function with 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?
The description is minimal but adequate for a simple no-parameter command. However, it does not clarify the relationship to stop_animation or any state changes, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the empty schema fully covers parameter semantics. Baseline 4 applies.
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 ('Pause') and the target ('current animation'), making its purpose evident. It does not explicitly distinguish from sibling tools like stop_animation, but the term 'pause' implies a distinct 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?
No guidance is provided about when to use this tool over play_animation, stop_animation, or seek_animation. The description only states the action without any 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 provided, the description carries the full burden of behavioral disclosure. It indicates deletion ('Remove') but does not mention reversibility, side effects, permissions, or failure modes, which is a significant gap for a destructive 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 is concise and front-loaded, with no wasted words. It efficiently conveys the core action 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?
Given the destructive nature of the operation and the fact that both parameters are optional, the description lacks important context such as consequences of removal, behavior when no parameters are provided, and any return value expectations. It is overly sparse for a complete understanding.
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 both parameters with descriptions (name and uuid), achieving 100% schema description coverage. The tool description adds no additional parameter semantics, so the 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 verb 'Remove' and the resource 'parameter' with context 'from the puppet', making the tool's function unambiguous. It differentiates from sibling tools like set, add, arm, and disarm by indicating a removal 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 guidance on when to use this tool versus alternatives, no exclusions, and no contextual prerequisites. It simply states the action without discussing scenarios or conditions, leaving the agent to infer usage.
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, but it only states the basic mutation. It does not mention potential side effects, failure conditions (e.g., duplicate names), reversibility, or return values, leaving the agent without critical 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, focused sentence that directly states the tool's purpose without any unnecessary words. Every word earns its place, making it appropriately sized for the simple operation.
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 schema fully documents parameters, but the description lacks behavioral context, usage guidelines, and any note on side effects or prerequisites. It meets the minimum viability for a basic add operation but has clear gaps in surrounding 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 input schema covers 100% of the parameters with descriptions ('name' and 'is_vec2'), so the description does not need to add clarity. The description adds no extra meaning beyond the schema, but the high schema coverage warrants a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the target ('a new parameter to the puppet'), which is specific and unambiguous. It distinguishes the tool from sibling operations like set, arm, disarm, and remove by using the verb 'add'.
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 when to add a new parameter versus setting an existing one. No conditional context or exclusions are 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 present, so the description carries the full burden. It only states the action without disclosing any side effects, such as whether the camera animates, whether the node needs to exist, or whether the viewport selection changes.
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, straightforward sentence that efficiently conveys the tool's purpose with no wasted 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 simple one-parameter tool, the description is minimally adequate, but it omits any mention of return values, error conditions, or preconditions. Given the lack of annotations and output schema, slightly more detail would improve completeness.
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 'uuid' parameter with a description ('Node UUID'). The description adds no additional meaning beyond the schema, so baseline 3 applies.
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 ('Focus') and the resource ('viewport camera on a node'). It is specific and distinguishes itself from sibling tools, as no other tool mentions camera focus.
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 context about prerequisites (e.g., node existence) or exclusions (e.g., if this also selects the node).
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 of seeking a frame, without explaining side effects (e.g., does it stop playback?), error conditions (e.g., invalid frame out of range), or whether the operation is reversible. This minimal disclosure is insufficient 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 compact sentence that directly states the tool's purpose with no redundant wording. It is appropriately sized for the simplicity of the operation.
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 (one parameter, no output schema), and the description covers the basic action. However, it lacks context about prerequisites (e.g., a current animation must exist) and potential error behavior, which would be valuable given the number of sibling tools. It is minimally adequate but has gaps.
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 already fully describes the only parameter 'frame' with a description and minimum value, so the baseline is 3. The description's phrase 'to a frame' adds no additional semantic meaning 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 the specific verb 'seek' with the resource 'current animation' and target 'a frame', clearly conveying the action. It distinguishes itself from sibling tools like 'creator_play_animation' or 'creator_set_animation', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 (e.g., an animation must be loaded) or exclusion scenarios. Users are left to infer the appropriate context from the tool name and 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?
No annotations are present, so the description carries the full burden. It adds only the word 'visibility' beyond the tool name, but does not disclose side effects, persistence behavior, impact on child nodes, or whether this affects rendering/viewport 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?
The description is a single concise sentence, front-loaded with the action and resource. Every word earns its place and there is no filler or redundant restatement.
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 low-complexity boolean setter with fully documented parameters, the description captures the core purpose. However, it lacks usage context and behavioral details, making it adequate but with clear gaps in when and how to use 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?
Input schema coverage is 100% (both uuid and enabled are described). 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 uses the specific verb 'Enable or disable' with the resource 'node' and clarifies the exact meaning with '(visibility)'. This clearly distinguishes it from other creator node tools like transform, parameter, or import 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?
No guidance is provided on when to use this tool versus alternatives, such as creator_set_parameter or other node operations. There are no exclusions, prerequisites, or alternative tool 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, the description carries full behavioral burden. It discloses that the tool can add or update, implying idempotent behavior at a given frame, but omits prerequisites (active animation, parameter existence), side effects, and error behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no wasted words. It front-loads the core operation and context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks important context: what a keyframe means in this workflow, whether to use name or uuid, what happens if a keyframe already exists, and any prerequisites. Without an output schema or annotations, the agent has limited information for reliable 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?
The schema provides descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds no further parameter details beyond what the schema already includes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add or update a keyframe') and its scope ('on the current animation at the current frame'). This distinguishes it from sibling tools like creator_remove_keyframe.
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 gives context (current animation, current frame) but does not explicitly compare to alternatives or state when not to use it. There is no reference to sibling tools like creator_set_parameter or creator_remove_keyframe.
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 discloses the basic action but lacks details about consequences (e.g., what happens if no keyframe exists at the current frame), reversibility, or required prerequisites. For a destructive operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb 'Remove', and zero wasted words. It communicates the core function efficiently.
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 3 parameters, no required fields, no output schema, and no annotations. The description does not explain how parameters interact (e.g., axis vs. name/uuid) or what happens in edge cases. The 'current frame' context is mentioned but not elaborated. This leaves significant gaps for the agent to invoke the tool 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?
Schema description coverage is 100%, so the schema already documents all parameters (axis, name, uuid). The description adds no extra meaning about how parameters select the keyframe, such as whether name and uuid are alternatives or both required. Baseline 3 is appropriate given full 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 a specific action ('Remove a keyframe') on a specific resource ('from the current animation at the current frame'). It distinguishes from siblings like creator_add_keyframe and creator_remove_parameter by specifying the keyframe removal 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 usage (when you want to remove a keyframe at the current frame) but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention exclusions or alternative tools like creator_add_keyframe or creator_set_parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the core behavior of switching modes and lists allowed values, but it does not mention potential side effects, prerequisites like a loaded project, or whether undo state is affected. This is a notable gap for a tool with no safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that names the action, target, and valid values with no filler or redundancy. It is appropriately sized for the tool's simplicity.
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 enum parameter and no output schema, the description is mechanically sufficient: it tells the agent what the tool does and what values are allowed. However, it lacks usage context and behavioral caveats, making it less than fully complete for confident autonomous 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 coverage is 100% with a self-describing enum for 'mode'. The description's 'Use model, vertex, anim, or test' simply restates the schema values without adding meaning about what each mode does or when to choose one. It meets the baseline but adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Switch' and the resource 'Inochi Creator edit mode', and it explicitly enumerates the four valid mode values. This clearly distinguishes it from sibling tools that set parameters or control animation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for changing the edit mode, but it does not explicitly state when to use it versus alternatives or provide exclusions. The instruction 'Use model, vertex, anim, or test' refers to parameter values, not tool-selection guidance.
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 behavioral disclosure. 'List the puppet node tree' clearly implies a read-only operation, and the parenthetical field list adds useful context. However, it does not mention hidden nodes, tree traversal order, or the behavioral impact of the 'detail' flag 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 that front-loads the core action and includes a compact parenthetical list of returned fields. There is no wasted text or 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 a simple list operation with one optional parameter and no output schema. The description communicates the key output fields and the tree structure, which is sufficient for most use. It could be enhanced by explicitly stating whether children are nested recursively, but this is not a major 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 provides 100% coverage for the single 'detail' parameter ('Include local transform on every node'), so the description does not need to repeat it. The tool description adds no further parameter semantics, justifying the baseline score of 3.
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'), identifies the resource ('puppet node tree'), and enumerates the returned fields (uuid, name, type, enabled, children). This clearly distinguishes it from sibling tools like creator_get_node and creator_list_parameters.
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 creator_get_node or creator_list_parameters. The description implies browsing the node tree but gives no exclusions, prerequisites, or alternative 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 provided, the description carries the full burden of behavioral disclosure. It only states that it undoes the last action, but does not explain behavior when there is no undo history, whether undo is destructive, or what the return value indicates. This is important for a state-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.
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 ('Undo') and the object ('last Inochi Creator action'). No wasted words or redundant information.
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 is simple (0 params, no output schema), but it mutates state and has no annotations. The description does not address failure modes (e.g., no undo history) or return values, leaving a significant gap for an agent to predict the tool's behavior. It is minimally complete for invocation but not for consequence understanding.
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 zero parameters, so the description need not explain parameter semantics. Baseline for 0 params is 4, and the description does not need to add anything beyond what the schema already conveys (which is nothing).
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: 'Undo the last Inochi Creator action.' It uses a specific verb (undo) and unique resource (the last Inochi Creator action), which distinguishes it from sibling tools like creator_redo.
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 context (after an unwanted action) but does not explicitly mention alternatives or when not to use it. The sibling creator_redo exists, but the description does not reference it or any other exclusion conditions.
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 full burden. It discloses a key limitation (cameras cannot be duplicated) and the recursive scope (children), but does not mention return value, parameter copying behavior, or undo interactions with sibling tools like creator_undo. Some context is added, but significant gaps remain.
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 wasted words. The action, scope, and a critical exception are all conveyed efficiently.
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 1-param mutation tool with no annotations, the description gives the core action and one limitation but omits details about return values, effects on the duplicated node's properties, or relation to undo/redo. It is adequate but leaves gaps.
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 provides 100% coverage with 'Node UUID'. The description's 'Duplicate a node' adds minimal new meaning beyond confirming that the uuid identifies the node to duplicate, so the 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 and resource: 'Duplicate a node and its children', clearly distinguishing it from sibling tools like creator_create_node or creator_delete_node. The camera exclusion adds further specificity.
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 use case (copy an existing node with its children) but provides no explicit guidance on when to use this tool over alternatives such as creator_create_node or creator_reparent_node. It only notes that cameras cannot be duplicated, not a usage condition.
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 must disclose behavior itself. It prominently warns that the tool replaces the current project, a critical destructive side effect. However, it doesn't mention whether unsaved changes are lost or if confirmation is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with minimal waste. The all-caps warning is front-loaded and impactful, earning its place.
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 (2 params), and the description covers the core purpose and replacement warning. However, it lacks details about import behavior (e.g., how layers are handled, whether it resets other settings) and there is no output schema to compensate.
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 covers 100% of parameters with descriptions for 'path' and 'keep_structure'. The description adds no additional parameter context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Import a Photoshop .psd file as a new project', with a specific verb, resource, and result. The all-caps warning 'THIS REPLACES THE CURRENT PROJECT' further distinguishes its behavior from sibling import 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 explicit guidance on when to use this tool vs alternatives like creator_import_kra or creator_import_folder. The warning implies caution but does not state scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It correctly suggests a non-destructive reachability probe, but it does not specify return values, error handling, or what 'reachable' means concretely (e.g., HTTP response, process alive). The note about 'patched' is contextually useful but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 14-word sentence that front-loads the action and target. Every word earns its place, with no redundant or filler content. Ideal conciseness.
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 (no params, no output schema), the description covers the core purpose effectively. However, it omits return value/result semantics, which the agent would need to interpret the outcome. Since there is no output schema to rely on, this is a minor completeness gap for an otherwise trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema is fully descriptive. The description adds useful context by specifying 'localhost' and the 'patched' nature of the target, which provides meaning beyond the empty schema. This meets the baseline for no-parameter tools.
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: 'Check that a patched Inochi Creator instance is reachable on localhost.' It uses a specific verb ('check') and resource ('patched Inochi Creator instance'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like creator_get_status, which could also serve as a connectivity/status check.
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 this tool is used as a preliminary connectivity check before engaging with the patched Inochi Creator instance, but it does not provide explicit when-to-use or alternative guidance. Sibling tools are not referenced, leaving the agent to infer when to rely on this over other status-related operations.
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 of behavioral disclosure. It only states that the tool selects the clip, but omits what happens if the name is invalid, whether it replaces the current selection, or whether it affects ongoing playback, leaving the operation's behavior largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the key action and purpose. Every word earns its place.
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 single-parameter selection tool with no output schema, the description is functional but thin: it omits error behavior, return value, and how the selection affects subsequent animation operations. Given the low complexity, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'name' parameter as 'Animation name', and the description's phrase 'the animation clip' largely restates this. With 100% schema coverage, the description adds minimal semantic value beyond the schema, but the baseline of 3 applies.
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 ('Select') with a clear resource ('the animation clip') and scope ('to edit or play'), distinguishing it from sibling tools like play_animation or seek_animation. It unambiguously indicates this is a state-setting operation for the current animation clip.
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 phrase 'to edit or play' implies when this tool is used: before editing or playing an animation. It does not explicitly name alternatives or when-not-to-use scenarios, but the purpose is clear enough given the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals one important nuance: omitting the name plays the current clip. However, it does not indicate whether playback is asynchronous, what happens on error, or whether it affects ongoing playback, leaving gaps in 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 of 11 words. It states the action and the key conditional behavior without any extraneous information, exemplifying conciseness and clear structure.
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 two optional parameters and no output schema, the description covers the core purpose and a key behavioral detail. However, it does not address potential errors, playback state, or the workflow with creator_set_animation, leaving the description minimally complete but not comprehensive.
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 schema already provides descriptions for both parameters (100% coverage), so the baseline is 3. The description adds value beyond the schema by explaining the semantic meaning of omitting the name parameter, connecting it to the 'current clip' concept. This enriches parameter understanding without redundancy.
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 the specific verb 'play' and resource 'animation', and it distinguishes itself from sibling tools like pause/stop/seek by describing the optional name parameter and fallback to the current clip. This makes the purpose explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to start playback) but does not explicitly mention alternatives or provide exclusion criteria. It hints at the relationship between the name parameter and the current clip, offering some usage context, but lacks direct guidance on when to use this instead of set_animation or pause.
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 nuances. It only states the core action and does not mention side effects such as whether child nodes are reparented, whether the operation is reversible, or constraints like preventing cycles. This leaves the agent with incomplete information 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 exceptionally concise, consisting of two short sentences that convey the core purpose and the key parameter nuance. There is no redundant information, and the most important content is front-loaded.
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 relatively simple, but the description omits important edge-case constraints, such as the inability to move a node to its own descendant or the behavior regarding child nodes. With no annotations or output schema to fall back on, the description should provide more guidance to prevent erroneous usage.
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 schema already covers all three parameters with full descriptions, so the baseline is 3. The description additionally clarifies that the 'index' parameter is zero-based ('0 = first'), which is not evident from the schema description 'Sibling insertion index'. This adds meaningful value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Move a node to a new parent') with a specific verb and resource. It is distinct from all sibling tools, none of which handle reparenting, so there is no ambiguity.
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 makes the usage context clear: use this tool when you need to change a node's parent. It does not explicitly mention alternatives or exclusions, but no sibling tool serves a similar purpose, so the context is sufficient.
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 full burden. It discloses useful behavioral traits (unspecified axes are left unchanged, rotation units) but omits the zsort property and provides no details about return values, errors, or side effects. This is partially transparent but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary repetition or fluff. It is front-loaded with the action and resource, making it 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 setter tool with no output schema and no annotations, the description is adequate but not fully complete. It does not mention the zsort parameter, which is part of the input schema, and omits any information about return values or failure modes. Still, the core functionality is clear and the schema covers parameter details.
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 schema already describes each parameter with 100% coverage, but the description adds value by explaining the partial-update semantics (unspecified axes unchanged), which is not evident from the schema alone. This clarifies how the arrays behave when partially provided.
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 with a specific verb ('Set') and resource ('a node's local translation, rotation, and/or scale'), distinguishing it from sibling tools like creator_set_parameter or creator_set_node_enabled. It also clarifies units (radians) and partial-update behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting transform properties but does not explicitly state when to use this tool vs alternatives or what conditions apply. There is no mention of prerequisites or exclusions, so an agent must infer the appropriate context 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.
Behavior4/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 explicitly discloses the significant behavioral effect that drivers are disabled while armed, which goes beyond the schema. It does not mention reversibility, but for a simple state-change tool, this is a meaningful 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 that immediately states the action and key effect. No unnecessary words or 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 low complexity with two optional parameters and no output schema. The description covers the purpose and the main behavioral nuance (disabling drivers), while the schema handles parameter details. It is adequately complete, though it does not clarify that one parameter (name or uuid) is expected.
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 100% coverage, with descriptions for both 'name' and 'uuid'. The description adds no parameter-specific semantics, so it meets the baseline of 3 when the schema covers 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 uses the specific verb 'Arm' with a clear resource ('a parameter') and context ('for deformation editing'). It also notes a key side effect (disables drivers), which distinguishes it from sibling tools like 'set_parameter' and the inverse 'disarm_parameter'.
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 during deformation editing to prepare a parameter, but it does not explicitly state when to use this vs alternatives like 'set_parameter' or 'disarm_parameter'. No exclusions or alternative references are provided, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the create operation and adds a useful constraint (parts must be imported), but does not mention permissions, reversibility, or what happens on failure. This is acceptable for a simple create tool 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 two sentences, front-loaded with the main action, and every sentence provides essential information. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 params, one enum, and no output schema, the description covers the key contextual aspects: what it does, the allowed types, and the critical exception about parts. It is sufficiently complete for an agent to invoke the tool correctly without needing additional documentation.
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 parameter semantics beyond what the schema already provides; it merely echoes the enum values and the parent/root context already present in 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 action ('Create a node') and the resource ('under a parent'), and explicitly lists the valid node types. It also distinguishes from siblings by noting that parts must be created via creator_import_images, preventing confusion with import tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for when to use the tool (to create nodes of the listed types) and explicitly excludes parts by redirecting to creator_import_images. It does not explicitly name alternative tools for other operations, but the usage context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It explains the main effect (disarming and re-enabling drivers), but does not mention edge cases such as what happens if no parameter is armed or whether the operation is destructive. This is adequate but not detailed.
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. Every part contributes meaning: 'Disarm' (action), 'currently armed parameter' (target), and 're-enable drivers' (additional outcome). It is concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description provides the core functional context. It explains the action and its effect, which is sufficient for a simple state-change tool. However, it could mention that it is the inverse of 'creator_arm_parameter' or what 'armed' means in this context, but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema description coverage is 100% vacuously. As per the baseline for zero-parameter tools, the description does not need to add parameter semantics. The baseline of 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 clearly states the tool's function: 'Disarm the currently armed parameter and re-enable drivers.' It uses a specific verb 'disarm' and a resource 'parameter', and it is easily distinguished from the sibling tool 'creator_arm_parameter' which performs the opposite action.
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 a parameter is currently armed and drivers need to be re-enabled, but it does not explicitly state when to use this tool versus alternatives like 'creator_arm_parameter' or mention any prerequisites. This is implied usage rather than explicit guidance.
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 transparency burden. It discloses two behavioral traits: using default atlas settings and not opening the export UI. However, it does not mention side effects like file overwriting, prerequisites (e.g., a loaded puppet), or error behavior, leaving the behavioral profile incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences deliver the core purpose and a key behavioral caveat. No redundant wording, and the most important information (export action) is 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 one-parameter tool with no output schema, the description adequately covers purpose, settings, and UI behavior. Missing return values and error conditions are minor gaps given the tool's simplicity, so it is nearly 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 coverage is 100% with a clear description of the 'path' parameter ('Absolute destination path for the .inp file'). The tool description adds context about the current puppet but does not provide additional parameter-level meaning beyond the schema, hence baseline 3.
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 ('Export'), resource ('current puppet'), output format ('.inp file'), and key conditions ('using default atlas settings', 'Does not open the export UI'). This clearly distinguishes it from sibling import and save tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly conveys when to use this tool (when you need to export a puppet as a packed .inp) by specifying the action and output. However, it does not explicitly contrast with alternatives or state when not to use it, so it lacks explicit exclusion criteria.
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 the full burden. It clearly indicates this is a read operation ('Get') and discloses the return content (transform and type-specific fields). It does not mention error behavior (e.g., if UUID is not found), but for a simple getter this is sufficient additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It precisely states the operation, the target, and what is included.
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 low-complexity tool with one parameter and no output schema, this description is nearly complete: it names the input (UUID) and the output content (transform and type-specific fields). It omits potential error cases, but given the simple nature, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the schema already describes the 'uuid' parameter as 'Node UUID'. The description only repeats 'by UUID' without adding further meaning about format, constraints, or behavior, so it does not go beyond the structured field information.
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 ('Get') and resource ('one node by UUID'), and explicitly mentions the included fields ('transform and type-specific fields'). This clearly distinguishes it from siblings like creator_list_nodes (which lists nodes) and creator_select_node (which selects).
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 a single node's UUID is known and full details are needed, but it does not explicitly state when to use this instead of alternatives like creator_list_nodes or creator_select_node. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates that this is a read operation returning a status snapshot and lists the categories of state included, but it does not explicitly state that it has no side effects, nor does it describe failure modes or return structure. For a non-mutating getter this is adequate, though not deeply informative.
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 repetition. Every word contributes meaning, efficiently covering the tool's action and the specific status fields it returns.
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 zero parameters, no output schema, and no annotations, the description does a good job by explicitly listing the six status categories, giving an agent a clear picture of what the tool reports. It could additionally mention whether the result is a single combined object or separate fields, but for a simple status getter this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%, so parameter documentation is irrelevant. The description correctly does not attempt to explain parameters, which is the expected baseline for a no-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 uses the specific verb 'Get' and clearly identifies the resource: the current Inochi Creator project status, enumerating path, edit mode, selection, armed parameter, and undo state. This distinguishes it from sibling tools like creator_get_node or creator_list_parameters, which target specific nodes or parameter lists rather than a global status snapshot.
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 purpose strongly implies this tool is for checking current project state before acting, but there is no explicit guidance on when to use it versus alternative getters, nor any 'when not to use' conditions. It does not name alternatives or exclusions, so the 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.
Behavior4/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 clearly discloses the critical destructive behavior: 'THIS REPLACES THE CURRENT PROJECT.' This is a strong warning, though it does not mention undoability or confirmation 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 two sentences with a prominent, well-placed warning. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple import tool with no output schema, the description covers the essential behavior and the key risk. It could mention more about what happens to the current project or require confirmation, but the core context is sufficiently 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 description coverage is 100%, so both parameters (path, keep_structure) are already documented in the schema. The description adds no extra parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Import') with a specific resource ('Krita .kra file') and clearly states the effect ('as a new project' and 'REPLACES THE CURRENT PROJECT'). It distinguishes from sibling import tools (PSD, INP, folder, images) by naming the format.
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 (when you have a .kra file to import) but does not explicitly contrast it with alternatives like import_psd or import_folder. The destructive warning adds context but no explicit 'do not use when...' guidance.
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 full burden. It discloses the core behavior (listing names and playback state) but adds no extra context such as output format, ordering, or whether playback state is per-clip or global. It is truthful and not misleading, but lacks depth typically expected 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 concise sentence, front-loaded with the action verb 'List,' and contains no unnecessary words. Every word earns its place, making it highly efficient and scannable.
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 (no parameters, no output schema), the description adequately conveys the return value: animation clip names and playback state. However, it could be slightly more explicit about what 'playback state' entails (e.g., playing, paused, stopped), so a small gap remains.
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 does not need to explain parameter semantics since there are none. It simply states what the tool does with no parameter ambiguity.
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 specifies the resource: 'animation clip names and the current playback state.' This clearly distinguishes it from sibling tools that set, play, pause, or stop animations, making 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to inspect animation clips and their playback state, but it does not explicitly state when to use this over alternatives or provide exclusions. Sibling tools like creator_play_animation or creator_stop_animation suggest this is a query tool, but the description does not articulate that context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states 'List' which suggests a read-only operation, but it doesn't explicitly confirm non-destructiveness or describe the output format, pagination, or any side effects. The inclusion of 'current values and ranges' adds some context but not 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 sentence that is tight and information-dense: 'List puppet parameters (including groups) with current values and ranges.' Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list operation, the description covers the essential purpose and scope (including groups, current values, ranges). However, it doesn't specify the return format or whether it returns all parameters at once, which could be useful given there is no output schema. Still, it's largely complete for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (input schema is empty), so schema description coverage is 100%. The description doesn't need to explain parameter semantics; per the guidelines, 0 params yields a baseline of 4. No additional parameter information is required.
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 action 'List' and the resource 'puppet parameters', including groups, with current values and ranges. This distinguishes it from sibling tools like creator_set_parameter or creator_arm_parameter, which imply modification.
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 inspection but gives no explicit guidance on when to use this tool versus alternatives like creator_set_parameter. There is no mention of exclusions or contextual scenarios, leaving the agent to infer the intended use.
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 of behavioral disclosure. It indicates the tool restores a previously undone action but does not disclose edge cases or side effects, such as whether it is a no-op when there is no undone action. For a simple operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word contributes to conveying the operation.
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, no-output-schema tool, the description provides the essential operation. However, it lacks explicit mention of conditions like requiring a prior undo or behavior when there is nothing to redo. Despite this, the context is largely complete for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, which sets a baseline of 4. The description correctly adds no parameter information, as none is needed. The schema coverage is 100% by virtue of having no properties.
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 'Redo' and the resource 'the last undone Inochi Creator action', making its purpose unambiguous. It also differentiates from the sibling tool creator_undo, which is 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by the name and the pairing with creator_undo, but the description does not explicitly state when to use it (e.g., after an undo) or what happens if there is nothing to redo. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description prominently warns 'THIS REPLACES THE CURRENT PROJECT.' with all-caps emphasis, disclosing the destructive/replacing behavior that is critical for an agent to know. With no annotations provided, this covers the most important behavioral trait. It could add details about unsaved changes or undo history, but the core danger is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary purpose, and uses all-caps only for the critical warning. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is complete: it states the input format, the import source, the project-replacing side effect, and the target. No additional return-value or error-handling details are necessary.
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 fully describes the single parameter 'path' as 'Absolute folder path' (100% coverage). The description reinforces that it is a folder of images, but adds no additional semantic detail beyond the schema. Baseline 3 is appropriate as the schema carries the burden.
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: 'Import PNG/TGA/JPEG images from a folder as a new project.' It names the resource (folder of images), the target (new project), and the supported formats. This distinguishes it from sibling tools like creator_import_psd or creator_import_images by specifying folder-based batch import of raster formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for importing image folders when creating a new project, but it gives no explicit guidance on when to choose this over alternatives like creator_import_images or creator_import_psd. No exclusions or conditions are 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?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the core behavior (select by UUID) and the special case (omit to clear), which is beyond the schema. However, it does not disclose edge cases such as invalid UUID handling, whether the selection replaces any existing selection, or any side effects beyond changing the selection state.
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, direct sentences with no filler. It front-loads the primary action and immediately covers the exception case, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—one optional parameter, no output schema, no annotations—the description is fully sufficient. It explains the main function and the clearing behavior, leaving no critical gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the uuid parameter ('Node UUID; omit to clear'), and the tool description essentially repeats this. Since the schema covers 100% of the parameter semantics, the description adds little new meaning, keeping it at the baseline of 3.
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 'select' with the resource 'node' and clearly defines the behavior of omitting the UUID to clear selection. It distinguishes from sibling tools like creator_get_node (retrieval), creator_create_node (creation), and creator_list_nodes (listing), 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 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: selecting a node by UUID or clearing the selection by omitting the UUID. However, it does not explicitly state when not to use it or name alternative tools, leaving room for implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds valuable context that for 1D parameters only x is used, and for 2D parameters both x and y are needed, which goes beyond the schema. However, it does not mention what happens if y is provided for 1D, or identifier requirements, though these are partly covered by 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 concise and to the point, with two short sentences that front-load the main purpose and then provide necessary dimension-specific guidance. No redundant or irrelevant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 4 parameters, all documented in the schema. The description covers the core operation and key behavioral nuance (1D vs 2D). Since there is no output schema and the complexity is low, the description is sufficiently complete for an agent to invoke the tool 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 schema already provides 100% coverage with descriptions for all four parameters, including 'Y value for vec2 parameters' and 'used if uuid is omitted'. The description adds minimal extra meaning beyond the schema, mainly restating the 1D/2D usage in a more explicit way. Thus, the baseline of 3 applies.
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 'Set a parameter value' with a specific verb and resource, and further clarifies behavior for 1D and 2D parameters. This clearly distinguishes it from sibling tools like creator_add_parameter or creator_remove_parameter, which use different verbs and 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 description provides guidance on how to use the tool (for 1D vs 2D params) but does not explicitly state when to use it over alternatives or when not to use it. It implies usage for setting parameter values but lacks explicit exclusions or references 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the output format (PNG), that the image is visible to the model, and the default scaling behavior (long side to 1024), adding useful context. It does not mention error conditions or side effects, but capture is inherently read-only and the description is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the purpose and provide key default behavior with no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-option capture tool with no annotations and no output schema, the description is adequately complete: it states the action, output format, model-visible return, and default scaling. Minor omissions (e.g., behavior when saving to an invalid path) are acceptable given the low complexity.
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 already describes both parameters fully (full boolean, path string), covering 100% of the schema semantics. The description supplements this by revealing the default scaling behavior (long side to 1024), which clarifies the effect of the 'full' parameter and adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Capture the current Inochi Creator viewport as a PNG') and notes the returned image is visible to the model. No sibling tool captures the viewport, so it is well-differentiated.
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 no explicit when-to-use guidance or contrast with alternatives. The intended use is implied (visual inspection), but without exclusions or alternative mentions, it remains generic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that deletion includes children and that the action is undoable. This goes beyond the tool name and provides useful behavioral context, though it does not mention error conditions or permission requirements.
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 contains no fluff. It communicates the key aspects (delete, children, undo) efficiently.
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 simple one-parameter tool with no output schema and no annotations, the description covers the essential behavioral traits: destructive scope (children) and reversibility (undo). It is sufficiently complete for an agent to understand what will happen.
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%: the 'uuid' parameter is already described as 'Node UUID'. The tool description adds no additional parameter information, so the baseline of 3 applies.
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 'Delete' with the resource 'node', clearly states it also deletes children, and mentions undo history. This distinguishes it from sibling tools like creator_duplicate_node or creator_set_node_enabled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need to delete a node and its children. It provides context about the recursive nature and undoability, but does not explicitly mention alternatives or exclusions. However, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It prominently discloses the destructive nature ('THIS REPLACES THE CURRENT PROJECT'), which is the most important behavioral trait for an import tool. It could also mention undo behavior or error handling, but the key risk is clearly communicated.
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 core action, specifies the format, and highlights the destructive consequence with a caps-lock warning. Every word earns its place, and the structure is efficient and easy to parse.
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 tool with no output schema, the description covers the essential facts: what is imported, the target format, and the side effect on the current project. It does not explain post-import behavior (e.g., project state or undo), but given the simplicity and the clear warning, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'path', including its type and meaning. The description adds no additional parameter information beyond what the schema specifies, 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 uses a specific verb ('Import') with a specific resource ('Inochi2D .inp puppet') and outcome ('as a new project'), clearly distinguishing it from sibling import tools like creator_import_psd or creator_import_kra. The format and target are explicit, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 this tool (importing a .inp file) and adds a critical warning that it replaces the current project. It does not explicitly list alternative tools for other formats, which would make it a 5, but the naming and context make the usage scenario evident.
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 full burden of behavioral disclosure. It reveals the file format and default path behavior, but does not mention that saving overwrites existing files or what happens if no project is currently open. For a mutation tool, this is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. Every word adds value: it states the action, the file format, and the default behavior when path is omitted. This is a model of conciseness.
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 simplicity of the tool (one optional parameter, no output schema, no nested objects), the description covers the essential information: the operation, the output format, and the parameter default. It is slightly lacking in not explicitly stating that saving overwrites the existing file, but this is reasonably inferred from 'save.'
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 schema describes the path parameter as 'Absolute save path; .inx is appended if missing' (100% coverage). The description adds critical semantic context beyond the schema, stating that omitting the path saves to the current project path. This resolves ambiguity about the optional nature of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Save the current project as .inx.' This is a specific verb+resource construction that distinguishes it from sibling tools like creator_new_project, creator_open_project, and creator_export_inp, which cover different lifecycle operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear conditional usage guidance: 'If path is omitted, saves to the current project path.' This clarifies the optional parameter behavior and implies the tool is used to persist the current project. While it doesn't explicitly name alternatives, the sibling set makes the appropriate use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it clearly states the tool imports into the project as Parts and explicitly notes it does not replace the project, addressing a common destructive side-effect concern. It could further disclose undo behavior or duplicate handling, but for an import 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?
Two concise sentences, front-loaded with the main purpose. The first sentence covers what and where; the second adds a critical non-destructive clarification. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two simple parameters and no output schema, the description is fully self-contained. It explains the core behavior, the target location, accepted formats, and a key non-destructive property. Sibling tools provide sufficient context for differentiation, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds meaning by specifying the exact file types (PNG/TGA/JPEG) that the 'paths' parameter accepts, which is not in the schema. The parent_uuid behavior is summarized as 'selected (or specified) node', reinforcing the schema's default note.
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 ('Import') with a clear resource ('PNG/TGA/JPEG files') and outcome ('as Parts under the selected (or specified) node'). It distinguishes itself from sibling import tools by enumerating raster formats and the 'Parts' result, making it easy to pick from creator_import_psd, creator_import_kra, etc.
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 context is implied through the supported file formats and the 'Does not replace the project' note, but there is no explicit guidance on when to use this tool versus alternatives like creator_import_folder, creator_import_psd, or creator_import_kra. The description does not say 'use this when...' or 'for PSD files use...'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key destructive behavior—discarding the unsaved current project—which is essential for a user to know. It does not address confirmation prompts or undoability, but the most critical behavioral trait is transparently stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose and immediately follows with the crucial warning. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, destructive tool, the description is sufficiently complete. It explains what the tool does and the main side effect, and there is no output schema or nested objects to further document. The description fully covers the necessary context for an agent to decide and invoke correctly.
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 correctly focuses on the action and its consequence, and there are no parameter details to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('new empty Inochi Creator project'), clearly distinguishing it from sibling tools like 'open_project' or 'save_project'. The additional note about discarding the current project further clarifies its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for starting a fresh project and warns about discarding unsaved work, providing clear context. It does not explicitly name alternatives, but the discard warning serves as an implicit exclusion for times when preserving the current project is desired.
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:

[![inochi-creator-mcp MCP server](https://glama.ai/mcp/servers/ozekimasaki/inochi-creator-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ozekimasaki/inochi-creator-mcp)

Score Badge

Copy to your README.md:

[![inochi-creator-mcp MCP server](https://glama.ai/mcp/servers/ozekimasaki/inochi-creator-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ozekimasaki/inochi-creator-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/ozekimasaki/inochi-creator-mcp'

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