Blender Pose 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
Each tool has a clearly distinct function: health check, rig structure read, pose read, single/batch edits, SMPL-X import, reset, undo, viewport, and save. The only nearby pairs are separated by scope or output, so an agent should not misselect.
Naming Consistency4/5
Tool names uniformly use lowercase snake_case and mostly follow a verb-first pattern like get_*, set_*, reset_pose, and save_blend. The single-word ping and undo are minor deviations from the verb_noun convention, so the set is consistent but not perfectly patterned.
Tool Count5/5
With 10 tools, the set is well-scoped for a pose-editing assistant: read, edit, batch, apply/reset, undo, view, and save operations are each represented exactly once. No tool feels redundant or unnecessary.
Completeness4/5
The core pose workflow is well covered: query state, mutate individual bones, batch changes, apply a full SMPL-X pose, reset, undo, render viewport, and save. The main gaps are generic custom pose import/export and rig constraint editing, but these are not necessarily required for the server's stated posing purpose.
Average 3.8/5 across 10 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose a key behavioral trait: the tool resets the current state before importing, and it references 'verified main.py rules' as a source of truth. However, it does not explain side effects, reversibility, permissions, or how partial/null pose inputs behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the reset behavior front-loaded. There is no redundant wording, but the vague reference to 'verified main.py rules' is not fully self-contained.
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?
Even though an output schema exists, the tool has four undocumented optional parameters and no annotations. The description does not explain when to use this tool, what happens when parameters are null, or how it differs from set_pose_batch and reset_pose, leaving important context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain how body_pose, lhand_pose, rhand_pose, or body_root_pose relate to the 'full SMPL-X pose' claim. The phrase 'full pose' hints that all parts are involved but provides no concrete parameter guidance, leaving the schema's bare names to carry the 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 a specific verb ('import'), a resource ('one full SMPL-X pose'), and an initial action ('Reset'). It is more informative than the tool name and implicitly distinguishes from reset-only or single-bone siblings, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus siblings like set_pose_batch, set_bone_pose, or reset_pose. 'Reset then import' implies a use case, but there is no 'use when' or 'instead of' direction.
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 usefully indicates that the tool returns structured data plus fixed PNG views, implying a read-only, deterministic operation, but it does not explicitly state that the tool has no side effects or clarify what the structured Pose data contains.
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. It is front-loaded with the action ('Return') and every clause adds specific, useful detail about the output contents.
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 parameterless getter with no output schema, the description is nearly complete: it names the two output categories and specifies the fixed camera directions. A more detailed pose schema would improve it, but the zero-parameter interface keeps the risk of incorrect invocation low.
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 there is no parameter-semantic burden on the description. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('viewport'), and clearly enumerates two concrete outputs: structured Pose data and fixed front/left/right/back PNG views. This distinguishes it from pose-only or rig-related siblings, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use get_viewport versus related sibling tools such as get_pose or get_rig. The agent must infer the intended use case from the tool name and output description, with no when-to-use or when-not-to-use guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. The verb 'Read' and the word 'existing' clearly signal a non-destructive, read-only operation, and the description enumerates exactly which rig aspects are returned. This provides meaningful behavioral context beyond the bare tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, listing the resource components 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?
The tool has no parameters and an output schema, so the description doesn't need to explain return values. However, it leaves unclear which armature is being read (e.g., selected object, current scene, or a default rig), which could matter for correct invocation. A bit more context about the implicit target would make it fully 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 tool has zero parameters and 100% schema description coverage, so there is nothing to document. The baseline for zero-parameter tools is 4, and the description appropriately avoids fabricating parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and names a specific resource ('existing Armature hierarchy, rest basis, constraints, and roles'). This clearly distinguishes it from pose-related siblings like get_pose and set_bone_pose, though it does not explicitly mention those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to choose this tool over sibling tools such as get_pose or get_viewport. There is no mention of typical scenarios, prerequisites, or exclusions, so the agent is left to infer usage from the description 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 exist, so the description carries the disclosure burden. It discloses that the tool reports file, version, and Armature, implying a read-only status operation, but it does not explicitly confirm that no mutations occur or describe failure behavior. This is adequate for a diagnostic tool but not especially 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 sentence that front-loads the testing behavior and then lists the reported outputs. Every word earns its place, and there is no filler or repetition of the tool name.
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 parameterless diagnostic tool with an output schema available, the description is complete: it states what the tool does and what it reports. The output schema covers the return details, so the description does not need to enumerate response fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to add beyond the schema. The no-parameter baseline of 4 applies, and the description introduces no confusing or misleading parameter expectations.
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 verb 'Test' and the chain 'Codex -> MCP -> Blender' clearly identify this as a connectivity/diagnostic tool, which separates it from the action-oriented siblings like get_pose or reset_pose. It also names what is reported (file, version, and Armature), making the purpose concrete and operational.
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 verify that Codex can reach MCP and Blender. However, it does not explicitly contrast it with alternative tools or state when not to use it, though for a ping-style tool the intended trigger is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates that this is a mutating operation that resets the Armature, and it limits scope to 'all'. However, it does not mention undo behavior, preconditions, or side effects, which would be useful for a 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 two short sentences with no filler. The action is front-loaded and the critical constraint on the parameter follows immediately. Every word 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?
This is a very simple tool with one constrained parameter and an output schema present. The description covers the operation and the only valid scope, which is likely enough for an agent to invoke it correctly. It could still benefit from a note on when to choose reset_pose over the set_* siblings.
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 0%, so the description must compensate. It does state that only scope='all' is valid, which matches the schema's const: 'all'. However, it adds no further meaning about what scope represents beyond that single constraint.
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 names a specific verb ('Reset'), a specific resource ('Armature'), and the target state ('base pose'). This clearly distinguishes it from sibling tools like set_bone_pose, get_pose, or apply_smplx_pose, which all do different things.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the existing Armature should be returned to its base pose. It also states a hard constraint, 'Only scope='all' is valid,' but it does not explicitly name alternatives or explain when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose an important side-effect boundary: other bones are not reset, and it hints at local-space delta behavior. However, it does not explain whether the change is undoable, how absolute vs delta mode affects the existing pose, or what prerequisites exist, leaving the behavioral picture 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 front-loaded sentence with no filler. Every phrase contributes either the action, the target resource, the scope, or a safety guarantee.
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 output schema covers return values, and the description covers the core purpose and a key behavioral guarantee. Still, for a mutating tool with no annotations and 0% parameter-documentation coverage, the description does not fully explain mode semantics, prerequisites, or when another sibling should be preferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to clarify bone addressing, the 3-number rotation_degrees format, and the absolute/delta distinction. It only weakly implies delta mode via 'delta-rotate' and adds no real meaning beyond what the schema's property names and enum already provide.
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 names a specific verb and resource ('Set or locally delta-rotate one Pose Bone') and adds a scope constraint ('without resetting other bones') that distinguishes it from reset_pose and set_pose_batch. An agent can tell what this tool does and roughly what it is not for without opening the schema.
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?
'One Pose Bone' and 'without resetting other bones' give clear contextual signals about when to choose this tool over batch or reset operations. It does not explicitly name sibling tools or state when-not-to-use rules, 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.
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 usefully discloses that edits are 'local' (bone-local space) and that the entire batch is grouped into one undo step, which is meaningful behavioral context. It does not mention error handling or exactly what happens on invalid input, but the key mutation and undo semantics are present.
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. It front-loads the action and resource, then adds the key atomicity detail. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves a nested BoneChange object with a mode enum, so more semantic context would help. The description gives the core purpose and undo behavior, and an output schema exists, but it omits the absolute/delta distinction and does not guide the agent on when to choose this over set_bone_pose. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needs to compensate for parameter meaning. While 'local Pose Bone edits' hints at the coordinate space, it does not explain the 'changes' array structure, the 'absolute' vs 'delta' modes, or how 'rotation_degrees' is applied. The schema's names and enums help, but the description adds little semantic value beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Apply'), a specific resource ('multiple local Pose Bone edits'), and a distinguishing behavior ('as one Blender undo step'). This clearly separates it from siblings like set_bone_pose, which implies a single-bone operation, and reset_pose, which clears poses rather than applying edits.
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 word 'multiple' implies the batch tool is for applying several pose edits at once, but the description never explicitly says to prefer set_bone_pose for single edits or mentions any alternatives. Usage context is implied rather than stated, and no when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only states the obvious action. It does not mention what happens when the undo stack is empty, whether undo reverts only the most recent operation or can be called repeatedly to step back further, or how errors are reported. The phrase 'most recent operation' gives a hint of scope, but many behavioral details are left undocumented.
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 with zero filler. It front-loads the system context ('Blender's undo system') and immediately states the action. No unnecessary information is included, making it an appropriately sized definition.
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 trivial complexity (no parameters, clear action, output schema present), the description is nearly sufficient for an agent to invoke it correctly. The only missing context is edge-case behavior (e.g., empty undo stack), but these are minor and unlikely to cause incorrect invocation. The presence of an output schema relieves the description from explaining return values.
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 no parameters, and the input schema shows an empty object (100% schema coverage, trivially). The description therefore has no parameter meanings to clarify, and the baseline score of 4 applies. There is nothing missing on the parameter front.
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 ('undo') and a clear resource ('Blender's undo system'), making the tool's function unmistakable. It also distinguishes the tool from its siblings, which are pose, rig, and viewport operations, since 'undo' is a general state-reversal action rather than a domain-specific edit.
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 obvious use case (call after a previous operation to reverse it) but gives no explicit guidance on when not to use it or how it compares to alternatives like reset_pose or set_pose_batch. The usage context is inferable from the name and description, but the tool does not articulate edge cases such as multiple undo steps or interactions with other Blender operations.
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 behavioral disclosure burden. It clearly states this is a read operation, that it returns current data, that the data is local, and that both degrees and quaternions are involved. It does not discuss return structure, but the presence of an output schema helps cover that.
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, information-dense sentence with no filler. The action, scope, frame of reference, and units are all front-loaded, making it immediately scannable for an agent deciding whether to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with an output schema available, the description covers the essential operational details. It could be slightly more explicit about whether the returned data includes both degrees and quaternions simultaneously, but the output schema likely resolves that; overall the definition is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this, so there is nothing for the description to elaborate on parameter semantics. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on the operation and output rather than adding nonexistent parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a clear resource ('all current local Pose Bone rotations'), and it specifies units ('degrees and quaternions'). This cleanly distinguishes it from write-oriented siblings like set_bone_pose and set_pose_batch, and from get_rig, which likely targets rig structure rather than pose rotations.
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: whenever you need the complete current local pose rotation data. However, it gives no explicit guidance about when not to use it or which sibling alternative might be better for a more specific need, such as reading a single bone or retrieving rig-level transforms.
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?
There are no annotations, so the description must carry the behavioral burden. It discloses that this is a save operation and adds a guardrail against unsolicited saves, but it does not explicitly state that the current file is overwritten on disk or note any irreversibility. The behavior is mostly inferable, but the side effect is not fully spelled out.
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 front-loads the action and then states the usage constraint, with no filler or redundancy. It is concise while conveying both what and when.
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 operation, the action and invocation condition are covered, and an output schema exists to document the return value. The only minor gap is the lack of explicit overwrite/destructive warning, which the absence of annotations makes more relevant.
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 is complete and no parameter documentation could be expected. The description adds no parameter-specific meaning, but none is required; per baseline, a zero-parameter tool earns a 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 uses the specific verb 'save' with a concrete resource, 'the current .blend', which exactly and unambiguously identifies the operation. It also distinguishes this tool from the sibling tools, none of which perform a file save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit call condition: 'call only after an explicit user save request.' This tells the agent when to invoke the tool and implicitly when not to, and no alternative save tool exists among the siblings, so no further routing is needed.
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:

[![pose-mcp MCP server](https://glama.ai/mcp/servers/nar-oah/pose-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nar-oah/pose-mcp)

Score Badge

Copy to your README.md:

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

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