moho-mcp-server

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
Each tool targets a distinct resource and action (e.g., animation keyframes vs. frame state, bone transform vs. bone selection). The names and descriptions clearly separate concerns, leaving little ambiguity for an agent.
Naming Consistency5/5
Tool names follow a consistent domain_verbNoun pattern (e.g., animation_getKeyframes, bone_setTransform, document_getInfo). All use snake_case with the domain prefix, and the equivalent dot notation is documented.
Tool Count2/5
At 26 tools, the count exceeds the 25-tool threshold for 'too many.' While each tool is relevant to MOHO, the set feels heavy; some groupings (e.g., layer_* and input_*) could potentially be consolidated without losing functionality.
Completeness2/5
The server covers many read and update operations (keyframes, transforms, visibility, bones) but lacks creation/deletion tools for core entities like layers, bones, or meshes. This limits the ability to perform full lifecycle workflows, making it necessary to rely on UI input simulation for certain actions.
Average 3.7/5 across 26 of 26 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on August 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It indicates a read operation but does not disclose return structure, error behavior, or permissions. The phrase 'detailed properties' is vague and does not enumerate the full set of properties returned.
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 focused sentence with no fluff, and it is front-loaded with the action and resource. The use of 'etc.' is slightly vague but does not undermine conciseness.
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 getter with no output schema, the description gives some idea of the return via examples, but lacks detail on the full property list and error cases. It is minimally adequate but not fully 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% for layerId, and the description adds no parameter-specific meaning beyond the schema. Baseline of 3 applies since the schema already documents the parameter fully.
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 'detailed properties of a specific layer', with concrete examples (type, visibility, transform) that clearly distinguish it from sibling setter tools like layer_setTransform and layer_setVisibility.
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. The read-only nature is implied by 'Get', but there are no exclusions, prerequisites, or references to sibling tools for when not to use this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action. It omits whether selection changes state, if it is reversible, or any side effects on the UI.
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, direct sentence with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selection action, the description lacks context on the purpose of selecting a layer, what the tool returns, or how it fits with sibling operations. No output schema or annotations to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter layerId is already documented in the schema with its description, and the tool description adds no additional semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Select' and identifies the resource 'a layer in the MOHO UI', which clearly distinguishes it from other layer operations like layer_setTransform or bone_selectBone.
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?
Provides no guidance on when to use this tool versus alternatives; there is no mention of prerequisites, when selection is needed, or what other tools accomplish similar goals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that it deletes a keyframe, implying destructive action, but does not state what happens if the specified frame does not exist, whether the operation is reversible, or any side effects on the animation channel. This lack of detail is a 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?
The description is a single, concise sentence with no redundant words. It immediately states the action and its target, earning its place without filler.
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 delete operation with three parameters fully described in the schema, the description is relatively adequate but lacks crucial behavioral context (e.g., error handling, irreversibility). Given no annotations and no output schema, the description should do more to set expectations, so it is only minimally 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 covers 100% of the parameters with descriptions, so the baseline is 3. The description adds minimal additional meaning by reiterating 'at a specific frame', which aligns with the 'frame' parameter. No new semantic information is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Delete), the resource (keyframe from an animation channel), and the specific qualifier (at a specific frame). This distinguishes it from sibling tools like animation_setKeyframe (which sets) and animation_getKeyframes (which gets).
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 preconditions or exclusions. It simply states what it does without contextualizing when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the action ('Get all bones') but does not describe the output format, error behavior, or any prerequisites (e.g., layer must be a bone layer). It implies read-only via the verb 'Get' but adds little else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundancy. It is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter, no output schema), the description is minimal but not fully complete. It does not specify the return value structure or error handling, which an agent would need to know for reliable invocation. However, the tool is simple enough that the gaps are moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (layerId) with a description, so schema coverage is 100%. The description adds no additional context about the parameter, 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 ('Get') and resource ('all bones in a bone layer'), clearly distinguishing it from sibling tools like bone_getProperties or layer_getProperties. It could specify the return format, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what it does. Given sibling tools for bone-specific operations, explicit context would be helpful, but none is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It only states 'Get' which implies read-only, but it does not disclose return format, behavior on empty layers, potential performance costs, or whether layerId must reference an existing layer. This is a minimal disclosure for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action and resource. There is no redundancy or filler, making it appropriately concise for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is minimally adequate: it states what it does and the resource type. However, it lacks return format details (e.g., coordinates or points as objects) and does not address edge cases, leaving some gaps 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 schema description covers 100% of the single parameter (layerId: 'The numeric ID of the vector layer'). The description adds nothing beyond the schema, merely reiterating 'in a vector layer', so it neither compensates nor detracts. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('all mesh points (vertices) in a vector layer'), which is distinct from the sibling tool mesh_getShapes. It uses a specific verb and resource combination that leaves 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like mesh_getShapes or other mesh-related tools. It does not mention any prerequisites, exclusions, or alternative tools, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. While 'Get' implies read-only, the description does not explicitly state whether there are side effects, permission requirements, or return format expectations. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the purpose. Every word earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 getter, the description is adequate but not rich. It lacks details about output structure, potential errors, or behavior under empty layers, and there are no annotations or output schema to compensate. However, given the low complexity, it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (layerId) with a clear description. The tool description adds no new semantic information beyond echoing 'vector layer', so it earns the baseline score for schema-driven 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 states a specific verb ('Get') and resource ('all shapes (filled regions) in a vector layer'), making the tool's purpose immediately clear. It distinguishes itself from siblings like mesh_getPoints by specifying shapes/filled regions rather than points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as mesh_getPoints. The context is only implied by the name and description, with no explicit exclusions or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states what the tool does ('Get child layers') without disclosing return format, whether it returns all descendants or just immediate children, error behavior for non-group layers, or any ordering. This is a minimal behavioral 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, 'Get child layers of a group layer', with no filler or repetition. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a one-parameter tool with no output schema and no annotations, the description is incomplete: it doesn't specify the returned data structure (e.g., an array of layer objects), whether it recurses into nested groups, or what happens for invalid or non-group layerId values. More context could be provided.
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 a description for layerId ('The numeric ID of the parent group layer') with 100% coverage. The tool description adds no additional parameter semantics, but per the baseline for high schema coverage, a 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 'Get' with the resource 'child layers' and the qualifier 'of a group layer', clearly differentiating it from sibling tools like layer_getProperties or layer_getBones, which target different aspects of a layer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternative tool references are given. The intended use is only implied by the description—use it to retrieve children of a group layer—but there is no context on when to prefer this over related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the action and modes but does not explain side effects, error behavior (e.g., if the keyframe does not exist), whether changes are reversible, or any permission requirements. 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?
The description is a single, front-loaded sentence that includes the resource, action, and valid modes. It is concise with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with four well-documented parameters, but the lack of annotations and output schema means the description should offer more context. It does not specify what happens if the keyframe is missing, whether the mode overwrites existing easing, or if the operation is destructive. Given the straightforward nature, it is minimally adequate but not comprehensive.
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% — all four parameters (layerId, channel, frame, mode) are described. The description adds no extra parameter semantics beyond the schema, 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 clearly states the tool sets the interpolation/easing mode on an existing keyframe, listing the specific modes. This distinguishes it from sibling tools like animation_setKeyframe, which sets keyframe values, and animation_getKeyframes, which reads keyframes.
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 on existing keyframes and provides the valid modes, but does not explicitly contrast with alternatives (e.g., animation_setKeyframe) or describe when to choose this tool over others. No exclusions or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of disclosing behavior. It only states 'Navigate' without revealing that this likely changes the current frame in the document (a mutation), nor does it mention possible side effects, frame range validation, or return values. This leaves the agent uncertain about the tool's impact and expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and target without any filler words or unnecessary details. It is appropriately concise for such a simple function.
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?
While the tool is simple with one parameter and no output schema, the description omits important contextual details: it does not clarify whether the operation modifies the document state, what happens for out-of-range frames, or if any return value is provided. These gaps make the description incomplete for a fully informed invocation, though the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the 'frame' parameter with its own description ('The frame number to navigate to'). The tool description adds no additional semantics beyond the schema, such as whether frame numbering starts at 0 or 1, valid ranges, or whether fractional frames are supported. Thus, it does not elevate understanding beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Navigate' and identifies the resource as 'a specific frame on the MOHO timeline.' This clearly distinguishes it from sibling animation tools like animation_setKeyframe or animation_getFrameState, which involve keyframes or state retrieval rather than navigation.
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 should be used to jump to a specific frame on the timeline, but it does not explicitly state when to use it over alternatives or when not to use it. Given the unique purpose among siblings, the context is sufficient to infer usage, but no explicit exclusions or alternative references 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?
The description discloses a key behavioral trait: it deselects all other bones first. However, with no annotations, it carries the full burden of behavioral disclosure and lacks details about error conditions, return values, or whether it modifies undo state. The information given is useful but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the core action and an important behavioral detail efficiently, earning top marks for 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, the description is fairly complete: it states the action and the key side effect. The lack of an output schema and high schema coverage reduce the need for more detail. It could mention that the layer must be a bone layer, but the schema already implies this, so the description is sufficient.
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 full descriptions for both parameters (boneId and layerId), covering 100% of them. The description adds no additional semantic meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool selects a bone in the MOHO UI, specifying the verb and resource. It also distinguishes itself from sibling tools like layer_selectLayer by focusing on bones and adding the 'deselects all others first' behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is for bone layers specifically, nor does it recommend using it before operations like bone_setTransform. No exclusions or alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to disclose important behavioral traits such as whether a keyframe is created/modified, interactions with existing keyframes, interpolation, or undo behavior. The value range is more parameter semantics than behavioral 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 one clear sentence, front-loaded with the verb and resource, and includes the crucial value range. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameter semantics thoroughly, there are no annotations and no output schema. The description does not explain the operation's effect on animation, whether it creates keyframes, or any side effects. This leaves the tool under-described for an agent to use it correctly in an animation 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 coverage is 100%, with each parameter already described in the input schema. The description repeats the opacity range (0.0 to 1.0), adding minimal value beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and resource (opacity of a layer) with a specific context (at a specific frame), including the valid value range. It distinguishes from siblings like layer_setVisibility and layer_setTransform by focusing on opacity/transparency.
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 purpose is clear enough to imply when to use it (when you need to animate opacity at a frame). The frame specificity hints at keyframing, providing context. However, it does not explicitly mention alternatives or exclusions, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states the core effect (show or hide) but does not disclose potential side effects, such as impact on child layers, return values, or error handling. The basic mutating behavior is clear, though some additional context would improve 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, direct sentence that immediately communicates the tool's function. It contains no redundant information or filler, making it optimally concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two scalar parameters and no output schema, the description adequately covers the tool's purpose. It doesn't explain return values or failure scenarios, but these are not critical for such an operation. A note on usage context relative to sibling tools would improve completeness, but the current description is sufficient for selection and 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 input schema provides full descriptions for both parameters (layerId and visible), achieving 100% coverage. The description itself adds no extra meaning to the parameters, so the baseline score of 3 for full schema coverage 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 'Show or hide' and identifies the resource as 'a layer in the MOHO scene'. This clearly distinguishes it from sibling layer tools like layer_setOpacity, layer_setName, and layer_setTransform, making the tool's unique purpose obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives such as layer_selectLayer or layer_setTransform. There is no mention of prerequisites or context in which hiding/showing is appropriate, leaving the agent to infer usage from the name alone.
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 disclosing behavior. The verb 'Get' implies a read-only operation, and 'full animation state' gives some sense of scope. However, it doesn't detail the return format, potential edge cases, or whether any side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that includes the key elements: action, target, and temporal scope. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, and the schema covers them well. However, there is no output schema, and the description does not clarify what 'full animation state' includes or what the response looks like, leaving some contextual ambiguity.
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 both parameters (frame and layerId) with clear descriptions, so the schema already provides full parameter semantics. The description adds no additional meaning beyond what the schema states, warranting 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 clearly states the action ('Get') and the resource ('full animation state of a layer at a specific frame'). It distinguishes itself from the sibling tool animation_getKeyframes by focusing on the state at a specific frame rather than keyframes themselves.
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 usage context is implied by the wording 'at a specific frame', suggesting this is for inspecting the resulting state at one frame. However, it doesn't explicitly state when to prefer this over animation_getKeyframes or provide any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states the action 'Get keyframe data' but does not mention what the returned data looks like, whether the tool is read-only, what happens if no keyframes exist, or any error conditions. This is a significant gap for a read 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 sentence that is precise and front-loaded. No filler or redundancy. It earns its place and leaves the schema to handle parameter details.
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 read tool with fully documented parameters, the description is minimally adequate. However, without an output schema, it does not explain what 'keyframe data' includes (e.g., times, values, interpolation), leaving some ambiguity about the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; it merely restates 'channel' and 'layer' without detailing parameter formats, defaults, or relationship to the return 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 verb ('Get'), the resource ('keyframe data'), and the scope ('for a specific animation channel on a layer'). This distinguishes it from sibling tools like animation_setKeyframe, animation_deleteKeyframe, and animation_getFrameState, which are either mutations or different reads.
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 the use case: when you need keyframe data for a specific channel and layer. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to choose it over the sibling set/delete tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the mutation action and scene context ('MOHO scene'), but does not disclose return values, side effects, or potential errors. 'Rename' does imply a write operation, which is useful.
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, front-loaded with the action, and contains no redundant words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with full schema coverage, the description plus schema provide adequate context. It lacks return value information, but given the simplicity of a rename operation, this is not a significant gap. The absence of output schema and annotations slightly reduces 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 both parameters (name and layerId) with descriptions. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Rename a layer in the MOHO scene'. It uses a specific verb ('Rename') and resource ('layer'), and is easily distinguished from sibling tools like layer_setTransform or layer_setVisibility.
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 want to rename a layer) but provides no explicit guidance on alternatives or exclusions. It is clear but does not elaborate on when not to use it or mention related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose side effects or return behaviors. It only describes the input format (vec2 vs scalar) and does not mention overwriting existing keyframes, error conditions, or whether the tool mutates state persistently. This leaves the agent without information about potential consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema and no annotations, the description is somewhat minimal. It covers the critical value shape nuance but omits potential behavioral details like overwrite semantics or failure modes, making it adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all four parameters with 100% coverage. The description builds on this by explicitly listing which channel types (translation, scale) use vec2 values and which (rotation, opacity, shear) use scalar numbers, adding clarity beyond the schema's anyOf definition.
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 starts with 'Set a keyframe value on an animation channel,' clearly stating the verb and resource. It distinguishes from sibling tools like animation_getKeyframes, animation_deleteKeyframe, and animation_setInterpolation by specifying the setting action.
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: whenever you need to set a keyframe value. It also gives channel-specific value format guidance, which helps the agent avoid errors. However, it does not explicitly mention alternatives or prerequisites, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions supported modifiers and provides examples, but it does not disclose prerequisites such as whether the MOHO window must be focused, nor what happens if the shortcut is invalid or unhandled. This leaves important behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a list of examples. It is concise, front-loaded with the core purpose, and every word earns its place. The examples are directly relevant and aid understanding without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the basic purpose and examples. However, it omits critical operational context such as whether the window must be active/focused, how errors are reported, or if there is any return value. These gaps make it incomplete for an agent needing to execute reliably.
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 describes the 'keys' parameter with examples, achieving 100% coverage. The description adds examples of shortcut-to-action mappings (e.g., ctrl+z = undo), which is useful context but primarily reinforces usage rather than adding new 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 clearly states 'Send a keyboard shortcut to the MOHO window', which is a specific verb and resource. It also provides examples that distinguish this tool from sibling mouse input tools (input_mouseClick, input_mouseDrag), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples give concrete use cases (undo, redo, play/pause, save), implying when the tool is appropriate. However, it does not explicitly mention alternatives like mouse clicks or state when not to use it. Still, the context is clear enough for an agent to select it correctly.
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. 'Get' implies a read-only operation, but it doesn't explicitly state that there are no side effects, nor does it describe the return format, potential errors, or any prerequisites. The mention of 'detailed properties' gives 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, front-loaded sentence that efficiently communicates the tool's function. The parenthetical list of example properties adds value without unnecessary verbosity.
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 getter with two well-documented parameters and no output schema, the description provides sufficient context. It lists the types of properties returned, which compensates for the lack of an output schema. The examples help the agent understand the nature of the returned data.
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 both parameters (boneId and layerId) with clear descriptions. The tool description adds no additional parameter meaning beyond 'specific bone', which aligns with the params. Since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting detailed properties of a specific bone, with explicit examples (position, angle, scale, parent). This distinguishes it from sibling tools like bone_setTransform (which sets properties) and bone_selectBone (which selects a bone).
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 clear when to use this tool: when you need detailed properties of a specific bone. It doesn't explicitly mention alternatives or exclusions, but the context is evident from the sibling list (e.g., layer_getProperties for layer-level info, mesh_getPoints for mesh points).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only operation ('Get') and operates on the current MOHO document. However, it does not disclose return format, behavior with empty documents, or any side effects. For a simple get, this is acceptable but sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action, and zero wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is sufficient. It clearly states what is returned (a list of all top-level layers) and the scope (current MOHO document). It could mention the return structure, but for a simple list tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema is trivially complete. The description naturally needs to explain nothing about parameters. Baseline for zero parameters is 4.
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 gets a list of all top-level layers in the current MOHO document. The verb 'Get' is specific, the resource is precise, and 'top-level' distinguishes it from sibling tools like layer_getChildren which retrieve nested layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: use this when you need top-level layers. However, it does not explicitly mention when not to use it or name alternatives like layer_getChildren for nested layers. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. It discloses that 'full' uses 'native screen capture' and that scene mode produces a 'clean rendered frame.' However, it does not mention whether the operation is read-only, whether it pauses rendering, or any side effects (e.g., whether it modifies the document). The description is not misleading but lacks depth on behavioral traits.
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 core action, and each sentence earns its place. It wastes no words and clearly conveys the main purpose and the key mode distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with four optional parameters and no output schema. The description covers the critical mode distinction and the presence of width/height constraints is in the schema. There is no need to explain return values in detail. It is reasonably complete for a screenshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as all four parameters have descriptions. The description adds context for the 'mode' parameter (default and difference between values), but the schema already covers the semantics of frame, width, and height. The description's value over schema is marginal but not absent.
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: 'Render the MOHO scene or capture the full application window and return as an image.' It uses specific verbs (render/capture) and identifies the resource (MOHO scene/application window). This clearly distinguishes it from sibling tools like animation or input 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 provides explicit guidance on mode selection: 'Use mode "scene" (default) for a clean rendered frame, or "full" for the entire MOHO UI including timeline, layers panel, etc.' This tells the agent exactly when to use each mode. It does not name alternative tools, but no sibling serves a similar purpose, so this is adequate 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 does specify the coordinate frame (relative to MOHO window top-left), which is important. However, it does not mention potential side effects like window focus requirements, cursor movement, or behavior when coordinates are invalid. The basic behavior of a click is implicit, so 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 two sentences, each earning its place. It front-loads the core function ('Click at (x, y)...') and then adds the key usage workflow. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple click tool, the description covers the main workflow with document_screenshot and notes coordinate relativity. It does not cover edge cases like right/double-click (though those are in the schema enums) or window focus, but given the presence of schema-enumerated options and the tool's simplicity, the description 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 the schema already documents all parameters including enums and defaults. The description adds no additional parameter semantics beyond what the schema provides, though it reinforces the coordinate system for x and y. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Click' and clearly identifies the resource (coordinates relative to the MOHO window top-left). This distinguishes the tool from siblings like input_mouseDrag and input_sendKeys, and the mention of document_screenshot indicates a concrete use case.
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 explicitly recommends using document_screenshot(mode='full') to identify UI element positions before clicking, providing a clear workflow. It does not explicitly mention alternatives or exclusions, but the suggested integration with a sibling tool gives practical usage 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 full behavioral disclosure burden. It discloses the coordinate system (relative to MOHO window) but does not mention simulation details such as step interpolation, button behavior, or the need for window focus. The description is adequate but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and provides only relevant information. Every sentence earns its place with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description covers purpose and typical use cases. It lacks explicit guidance on prerequisites or side effects, but for a drag operation this is somewhat self-evident. No output schema means no return value explanation is needed.
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% parameter coverage, including descriptions for startX/startY/endX/endY and enums for button. The description adds minimal semantic value beyond what the schema states, merely restating the coordinate variables. Thus baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Drag from (startX, startY) to (endX, endY)') and specifies it is relative to the MOHO window. It distinguishes itself from sibling input_mouseClick by focusing on drag operations, and lists specific use cases.
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 concrete use cases ('dragging timeline playhead, sliders, or drawing operations'), giving clear context for when to use the tool. It does not explicitly exclude alternatives like input_mouseClick, but the drag-specific language implicitly differentiates it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It does disclose a key behavior: all transform params are optional and only supplied values are changed. However, it fails to mention whether a new keyframe is created or an existing one overwritten, what happens to other transform properties, or the return value. This leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose and immediately adds the critical behavioral note. 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?
The description is adequate for a basic understanding but lacks details about keyframe behavior, return values, and interaction with existing animation data. Given 7 parameters and no annotations/output schema, a bit more context would be valuable.
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%, so the baseline is 3. The description adds the note 'only supplied values are changed', which clarifies partial-update semantics beyond what the schema's required list implies. This enriches parameter understanding.
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 specifies the action (set transform), the resource (layer), and the context (at a specific frame). It distinguishes from siblings like bone_setTransform by targeting layers, and from animation_setKeyframe by focusing specifically on transform properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for setting a layer's translation/rotation/scale at a given frame. While it doesn't explicitly mention alternatives or exclusions, the sibling naming makes the distinction obvious (layer vs bone, transform vs other properties).
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 signals a read-only operation via 'Get' and enumerates the returned fields, making the main behavior transparent. However, it does not disclose what happens if no document is open or the exact return format (e.g., units for dimensions).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It efficiently lists the relevant document attributes, making it easy to parse and understand.
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 getter with no output schema, the description covers the essential context: what object it operates on and what information it returns. Minor gaps such as error behavior when no document is open and precise data types are noted, but they do not detract significantly from overall 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 there is no parameter detail to add. Per the rubric, a zero-parameter tool gets a baseline score of 4, and the description adequately focuses on the return value instead.
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 specifies the verb 'Get' and the resource 'currently open MOHO document', with a concrete list of data fields (name, path, dimensions, frame range, FPS). This clearly distinguishes it from sibling tools targeting layers, bones, or 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 usage when document-level metadata is needed, but it does not explicitly state when not to use it or name alternative tools. The phrase 'currently open' suggests a prerequisite, but no explicit when-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses two critical behaviors: it automatically creates keyframes and only changes supplied transform parameters (partial update). This goes beyond the schema's optional flags, although it doesn't address overwrite semantics or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences without redundancy. It front-loads the purpose, then introduces keyframing and the partial-update behavior, making every sentence valuable.
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?
Considering the lack of annotations and output schema, the description covers purpose, keyframing, and partial updates, which is sufficient for core usage. Some gaps remain (e.g., overwriting existing keyframes, error conditions), but the schema documents all parameters completely, and the description compensates well.
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%, so the baseline is 3. The description adds meaning by clarifying that all transform params are optional and that omitted ones remain unchanged—a partial-update semantic not fully explicit in the schema. This helps the agent avoid resetting unspecified parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the transform (angle, position, scale) of a bone at a specific frame and automatically creates keyframes. This distinguishes it from sibling tools like bone_selectBone (selection) and layer_setTransform (layer-level transform).
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 its usage via the formulation 'Set the transform of a bone at a specific frame' and the auto-keyframing note. It does not explicitly mention alternatives or when not to use, but the specificity of bone keyframing provides clear context among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It explains performance characteristics, unsupported methods, sequential execution implied by stopOnError guidance, and the exact return structure including per-operation success/error results.
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 well-structured with a clear opening, bulleted patterns, and a closing return-format summary. Every sentence contributes essential information, and the content is organized for quick scanning.
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 complexity (batching arbitrary operations) and lack of output schema, the description is complete: it covers input format, limitations, return structure, and error handling. The examples cover common use cases sufficiently for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters well (100% coverage). The description adds meaningful value by clarifying dot-notation format for method names, stating that params match each tool's schema exactly, and providing example usage patterns that aid parameter construction.
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: executing multiple MOHO operations in a single IPC round-trip. It distinguishes itself from sibling tools by explicitly mentioning 'PREFER THIS over individual calls' and listing supported method types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('whenever you have 2+ operations'), exclusions (document.screenshot, batch.execute), and common usage patterns with concrete examples. Also advises using stopOnError when operations are dependent, which is actionable guidance.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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