BlenderMCP

by wenyen-hsu

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between 'download_polyhaven_asset' and 'set_texture' (both involve Polyhaven textures) and between 'generate_hyper3d_model_via_images' and 'generate_hyper3d_model_via_text' (both generate Hyper3D models). However, their descriptions clarify the differences (download vs. apply, image vs. text input), so confusion is minimal.
Naming Consistency4/5
The naming is mostly consistent with a verb_noun pattern (e.g., 'download_polyhaven_asset', 'get_scene_info'), but there are minor deviations like 'execute_blender_code' (verb_noun_noun) and 'poll_rodin_job_status' (verb_noun_noun). Overall, the pattern is readable and predictable across the set.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for a Blender integration server that covers asset downloading, 3D generation, scene management, and status checks. Each tool appears to serve a specific function, though some could potentially be consolidated (e.g., multiple status checks).
Completeness4/5
The toolset covers key areas: asset sourcing (Polyhaven, Sketchfab, Hyper3D), scene inspection, and basic operations. However, there are minor gaps, such as no tools for editing or deleting objects in Blender, and limited texture management beyond applying downloaded ones. Core workflows are supported, but advanced editing is missing.
Average 3.4/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Execute arbitrary Python code' but fails to cover critical traits like safety implications (e.g., potential for destructive changes, permissions required), performance aspects (e.g., execution time limits, error handling), or output behavior. This leaves significant gaps for a tool that executes code.
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 appropriately sized with two sentences and uses a bullet point for the parameter, making it front-loaded and efficient. However, the second sentence ('Make sure to do it step-by-step...') could be more precise, slightly reducing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing arbitrary code, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks essential details like what the tool returns, error conditions, or safety warnings, making it inadequate for such a potentially powerful tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics by stating 'code: The Python code to execute', which matches the single parameter in the schema. With 0% schema description coverage, this provides some value, but it doesn't compensate fully (e.g., no details on code format, constraints, or examples). The baseline is 3 due to the single parameter, but it's not enhanced significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Execute' and the resource 'arbitrary Python code in Blender', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from its siblings (like other execution or modeling tools), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Make sure to do it step-by-step by breaking it into smaller chunks', which is vague and doesn't specify when to use this tool versus alternatives (e.g., other execution or import tools in the sibling list). No explicit when/when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a message about feature availability, which is basic behavioral info. However, it lacks details on error handling, performance, or side effects. The cryptic note about 'Don't emphasize the key type...' adds confusion rather than clarity, slightly undermining transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but includes an unnecessary and confusing sentence: 'Don't emphasize the key type in the returned message, but sliently remember it.' This detracts from clarity without adding value. The core purpose is stated upfront, but the extra text reduces overall conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It explains what the tool does and what it returns, which covers the basics. However, it lacks context on integration details or how the output might be used, leaving some gaps for a status-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, which is efficient. However, it doesn't add any semantic context beyond the schema (since there are no parameters), so it meets but doesn't exceed baseline 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 description clearly states the tool's purpose: 'Check if Hyper3D Rodin integration is enabled in Blender.' This specifies the verb ('Check'), resource ('Hyper3D Rodin integration'), and context ('in Blender'). However, it doesn't explicitly differentiate from siblings like 'get_polyhaven_status' or 'get_sketchfab_status' beyond the specific integration name, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, related tools (e.g., 'poll_rodin_job_status'), or scenarios where this check is necessary. The only implicit context is checking integration status, but no explicit usage rules 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 provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get detailed information'), but doesn't describe what information is returned, format of the response, error conditions, or any constraints (like whether the object must exist in the current scene). The description is minimal and lacks 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address purpose and parameters. The parameter documentation is clearly formatted. No unnecessary information is included, though it could be slightly more front-loaded with usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and multiple sibling tools in a complex domain (3D modeling), the description is insufficient. It doesn't explain what 'detailed information' includes, how results are structured, or how this differs from related tools like 'get_scene_info'. The agent would lack critical context for proper tool selection and result interpretation.
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 has 0% description coverage, but the description explicitly documents the single parameter ('object_name: The name of the object to get information about'), adding meaningful context beyond the schema's basic type information. Since there's only one parameter and it's fully documented in the description, this compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get detailed information') and resource ('about a specific object in the Blender scene'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_scene_info', which might provide broader scene information rather than object-specific details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_scene_info' (which might provide broader scene context) or clarify whether this is for retrieving metadata, properties, or other object details. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('Get a list of categories') without mentioning any behavioral traits such as rate limits, authentication needs, response format, or potential errors. For a tool with zero annotation coverage, this is inadequate, as it leaves critical operational details unspecified.
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 appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. Both sentences earn their place by clarifying the tool's function and parameter options. It avoids unnecessary fluff, making it efficient, though minor improvements in structure (e.g., bullet points for parameters) could enhance readability.
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 low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter semantics but lacks details on behavioral traits, usage context, and output format. Without annotations or output schema, the description should do more to compensate, but it meets the bare minimum for a simple read operation, hence a score of 3.
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 description adds meaningful context for the single parameter 'asset_type' by listing possible values (hdris, textures, models, all), which is not covered in the input schema (0% schema description coverage). This compensates well for the schema gap, providing clear semantics beyond the schema's basic type and title. However, it doesn't explain the implications of choosing 'all' or other nuances, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a list of categories for a specific asset type on Polyhaven.' This specifies the verb ('Get'), resource ('list of categories'), and context ('on Polyhaven'). However, it doesn't explicitly differentiate from sibling tools like 'search_polyhaven_assets' or 'get_polyhaven_status', which is why it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the asset_type parameter but doesn't explain scenarios for using this tool over other Polyhaven-related tools like 'search_polyhaven_assets' or general context for category retrieval. This lack of explicit when/when-not or alternative references results in a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] detailed information' but doesn't specify what 'detailed information' includes, whether it's read-only, if it requires specific Blender state, or any error conditions. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's purpose without any fluff or redundancy. It's efficiently front-loaded and appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails, the format of the return value, or any dependencies on Blender's state. For a tool that presumably returns structured scene data, more context is needed to be fully helpful.
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 0 parameters with 100% schema description coverage, so no parameter information is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary 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 clearly states the verb 'Get' and the resource 'detailed information about the current Blender scene', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_object_info' or 'get_viewport_screenshot', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_object_info' and 'get_viewport_screenshot' that might retrieve related information, there's no indication of context, prerequisites, or exclusions for this tool's usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns a formatted list of matching models,' which gives some output information, but it lacks critical behavioral details: authentication requirements, rate limits, pagination behavior, error handling, or what 'formatted list' entails. For a search tool with no annotation coverage, this is insufficient.
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 appropriately sized and well-structured. It starts with a clear purpose statement, followed by a bulleted list of parameters with explanations and defaults. There's no wasted text, and information is front-loaded. It could be slightly more concise by integrating defaults into the initial sentence, but overall it's efficient.
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 moderate complexity (4 parameters, no annotations, no output schema), the description is partially complete. It covers parameters well but lacks behavioral context (e.g., authentication, rate limits) and output details beyond 'formatted list.' Without an output schema, the description should ideally explain the return structure more thoroughly. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% schema description coverage. It explains all four parameters: 'query' (text to search for), 'categories' (optional comma-separated list), 'count' (maximum results with default 20), and 'downloadable' (filter with default True). This compensates well for the schema's lack of descriptions, though it could provide more detail on category options or query syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for models on Sketchfab with optional filtering.' It specifies the verb ('search'), resource ('models on Sketchfab'), and scope ('with optional filtering'). However, it doesn't explicitly distinguish this search tool from the sibling 'search_polyhaven_assets' tool, which searches a different platform. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'search_polyhaven_assets' tool for searching a different asset library, nor does it provide context about when Sketchfab models are preferred over other sources. There's no information about prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Returns a message indicating whether PolyHaven features are available,' which implies a read-only, non-destructive operation, but doesn't specify details like response format, error handling, or performance characteristics. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences that directly state the tool's purpose and return value. Every word earns its place with no redundancy or fluff, making it easy for an agent to parse quickly.
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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and what it returns, but lacks details like the message format or integration specifics. With no output schema, the agent might need more context about return values, but the simplicity of the tool keeps it from being incomplete.
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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately focuses on the tool's function. A baseline of 4 is applied since no parameters are present, and the description doesn't add unnecessary param 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 clearly states the tool's purpose: 'Check if PolyHaven integration is enabled in Blender.' This specifies the verb ('Check') and resource ('PolyHaven integration in Blender'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_hyper3d_status' or 'get_sketchfab_status' beyond the resource name, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., if Blender must be running), exclusions, or comparisons to similar tools like 'get_hyper3d_status' or 'get_sketchfab_status'. The agent must infer usage from context alone, which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a message indicating availability, which is helpful, but lacks details on error handling, performance, or side effects. For a status-checking tool, this is minimal but not entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences that directly state the purpose and return value with zero wasted words. Every sentence earns its place by providing essential information 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?
Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose and return type, but for a status-checking tool, it could benefit from more context on what 'enabled' entails or example outputs.
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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, but this is appropriate given the lack of parameters, earning a baseline score of 4 for not requiring compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if Sketchfab integration is enabled in Blender' specifies the verb (check) and resource (Sketchfab integration in Blender). It distinguishes from siblings like 'get_hyper3d_status' by naming the specific integration, though it doesn't explicitly contrast with similar status-checking tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the purpose implies it's for checking Sketchfab status, there's no mention of prerequisites, timing (e.g., before using Sketchfab features), or comparison to other status tools like 'get_hyper3d_status' or 'get_polyhaven_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions access rights and downloadability as constraints, which is helpful, but fails to detail critical aspects like whether this is a read/write operation, potential side effects (e.g., file system changes), error handling, or performance implications, making it insufficient for safe use.
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 front-loaded with the core purpose, followed by parameter and return details in a structured format. It avoids redundancy and is appropriately sized for the tool's complexity, though the second sentence about access rights could be integrated more smoothly for better flow.
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 moderate complexity (download/import operation), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and basic constraints but lacks details on return values (beyond success/failure message), error cases, or integration with sibling tools, leaving room for improvement in 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 description adds meaningful context for the single parameter 'uid' by specifying it as 'the unique identifier of the Sketchfab model', which clarifies its role beyond the schema's basic type. With 0% schema description coverage and only one parameter, this compensation is adequate, though it could benefit from format examples or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'download and import' and the resource 'Sketchfab model by its UID', making the purpose specific and understandable. It distinguishes from siblings like 'search_sketchfab_models' by focusing on retrieval rather than discovery, though it doesn't explicitly contrast with them.
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 by specifying that the model must be downloadable and accessible, providing some context for when it's applicable. However, it lacks explicit guidance on when to use this tool versus alternatives like 'import_generated_asset' or prerequisites beyond access rights, leaving gaps in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that the tool 'returns a list of matching assets with basic information', which gives some behavioral context about the output. However, it doesn't disclose important traits like whether this is a read-only operation, potential rate limits, authentication needs, pagination behavior, or what 'basic information' entails. For a search tool with zero annotation coverage, this leaves significant gaps.
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 appropriately sized with three sentences: a purpose statement, parameter explanations, and return information. It's front-loaded with the core functionality. While efficient, the parameter section could be slightly more structured, but overall there's minimal waste.
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 2 parameters with 0% schema coverage and no output schema, the description provides adequate but incomplete coverage. It explains parameter purposes and mentions the return type, but doesn't detail the structure of returned assets, error conditions, or search behavior limitations. For a search tool with no annotations, it meets minimum viable standards but has clear gaps in behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for both parameters: 'asset_type' is explained as 'Type of assets to search for (hdris, textures, models, all)' and 'categories' as 'Optional comma-separated list of categories to filter by'. This adds crucial context beyond the bare schema, though it doesn't specify format details or provide examples for the categories parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for assets on Polyhaven with filtering, which is a specific verb (search) and resource (assets on Polyhaven). It distinguishes from siblings like 'download_polyhaven_asset' (which retrieves specific assets) and 'search_sketchfab_models' (which searches a different platform), though it doesn't explicitly mention these distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching assets with optional filtering, but provides no explicit guidance on when to use this tool versus alternatives like 'search_sketchfab_models' or 'get_polyhaven_categories'. It mentions filtering capabilities, which gives some context, but lacks clear when/when-not instructions or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool imports an asset and returns success status, but lacks details on behavioral traits such as required permissions, error handling, rate limits, or what 'import' entails (e.g., file format, storage location). For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear opening sentence stating the purpose, followed by parameter details and usage rules. Every sentence adds value, such as explaining parameter dependencies and the return statement. It could be slightly more concise by integrating the return information into the first sentence, but overall it's efficient.
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 complexity (3 parameters, no annotations, no output schema), the description covers the basics: purpose, parameters, and return indication. However, it lacks details on what 'import' involves (e.g., asset format, integration into a scene), error conditions, or output specifics beyond success status. This makes it adequate but incomplete for a tool with no structured support.
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?
With 0% schema description coverage, the description must compensate, and it does so effectively. It explains the purpose of all three parameters: 'name' as the object name in scene, 'task_uuid' for MAIN_SITE mode, and 'request_id' for FAL_AI mode. It also clarifies the exclusive choice between task_uuid and request_id, adding crucial semantic context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import') and resource ('asset generated by Hyper3D Rodin after the generation task is completed'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'download_polyhaven_asset' or 'download_sketchfab_model', which also import assets but from different sources.
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 on when to use this tool: after a Hyper3D Rodin generation task is completed. It also specifies that parameters depend on the Hyper3D Rodin mode (MAIN_SITE vs. FAL_AI), offering guidance on parameter selection. However, it doesn't mention when not to use it or explicitly compare it to alternatives like other asset import tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool captures a screenshot and returns it as an Image, but lacks critical details such as whether this operation is read-only or has side effects, permission requirements, performance impact, error conditions, or format specifics (e.g., PNG, JPEG). The description is minimal and misses key 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 highly concise and well-structured: a clear purpose statement followed by a bullet point for parameters and a note on returns. Every sentence earns its place with no wasted words, and key information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (capturing a screenshot in a 3D application), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavioral aspects like side effects, error handling, and output format specifics, leaving gaps for an AI agent to understand full usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'max_size' by explaining it's the 'Maximum size in pixels for the largest dimension' with a default of 800, which goes beyond the schema's basic title and type. With 0% schema description coverage and only one parameter, this compensates adequately, though it could specify units or constraints more explicitly.
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 specific action ('Capture a screenshot') and target resource ('current Blender 3D viewport'), distinguishing it from all sibling tools which involve downloading assets, executing code, getting statuses, or modifying scenes. The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a screenshot of the Blender viewport is needed, but provides no explicit guidance on when to use this tool versus alternatives (e.g., other screenshot methods or tools for different outputs). There's no mention of prerequisites, limitations, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the action ('Download and import') and return type ('message indicating success or failure'), but lacks critical behavioral details: required permissions, network/rate limits, whether it overwrites existing files, import settings in Blender, or error handling specifics.
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 efficiently structured with a clear purpose statement followed by a bulleted parameter breakdown. Every sentence adds value: the first states the action, and the parameter explanations provide essential context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description covers parameters well but lacks behavioral context (permissions, side effects, error details). It's adequate for basic use but incomplete for reliable agent operation without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic meaning for all 4 parameters: asset_id (ID to download), asset_type (category with examples), resolution (quality with examples), and file_format (optional format with type-specific examples). This fully explains what each parameter controls.
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 specific action ('Download and import'), target resource ('Polyhaven asset'), and destination ('into Blender'). It distinguishes itself from sibling tools like 'search_polyhaven_assets' (which finds assets) and 'import_generated_asset' (which imports from other sources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to obtain a Polyhaven asset for Blender, but provides no explicit guidance on when to use this vs. alternatives like 'download_sketchfab_model' or 'import_generated_asset'. It doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the generated asset has built-in materials, has a normalized size (requiring re-scaling), and returns a success/failure message. However, it lacks details on permissions, rate limits, error conditions, or what 'import into Blender' entails (e.g., file location, overwrite behavior). For a tool with no annotations, this is a moderate disclosure but misses critical operational context.
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 well-structured and appropriately sized. It starts with the core purpose, adds behavioral details, then lists parameters with clear explanations. Every sentence adds value, but it could be slightly more front-loaded by integrating parameter constraints earlier. No wasted words, but minor structural improvements are possible.
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 complexity (3 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose, key behaviors, and parameter semantics well, but lacks output details beyond a generic success/failure message, and doesn't address error handling or integration specifics with Blender. For a tool with no structured support, it should provide more operational context to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It provides detailed semantics for all three parameters: explains that 'input_image_paths' requires absolute paths and is for MAIN_SITE mode, 'input_image_urls' is for FAL_AI mode, 'bbox_condition' controls length/width/height ratio as a list of 3 ints, and clarifies that only one of the image parameters should be used based on mode. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate 3D asset using Hyper3D by giving images of the wanted asset, and import the generated asset into Blender.' It specifies the verb (generate), resource (3D asset), and method (via images), and distinguishes it from its sibling 'generate_hyper3d_model_via_text' by mentioning images. However, it doesn't explicitly differentiate from other 3D-related tools like 'download_polyhaven_asset' or 'download_sketchfab_model' beyond the generation method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you have images of a wanted asset and want to generate a 3D model with Hyper3D, importing it into Blender. It mentions the sibling 'generate_hyper3d_model_via_text' implicitly by specifying 'via images,' but doesn't explicitly state when to choose this over text-based generation or other 3D download tools. No explicit exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool 'Returns a message indicating success or failure', which adds some behavioral context about output. However, it lacks details on permissions needed, whether the operation is destructive (e.g., overwrites existing textures), error conditions, or rate limits, which are important 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 front-loaded with the core purpose in the first sentence, followed by a bulleted list of parameters and a note on returns. Every sentence earns its place without redundancy, making it efficient and well-structured for quick understanding.
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 2 parameters with no schema descriptions, no annotations, and no output schema, the description is adequate but has gaps. It covers the basic purpose and parameters but lacks details on behavioral traits like destructiveness or error handling. For a mutation tool in a 3D context, more context on effects and limitations would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining both parameters: 'object_name' as the 'Name of the object to apply the texture to' and 'texture_id' as the 'ID of the Polyhaven texture to apply (must be downloaded first)'. This adds meaning beyond the bare schema, clarifying usage and constraints, though it could specify format or examples.
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 specific action ('Apply'), the resource ('a previously downloaded Polyhaven texture to an object'), and distinguishes it from siblings like 'download_polyhaven_asset' by focusing on application rather than acquisition. It directly addresses what the tool does without being vague or tautological.
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 by specifying that the texture must be 'downloaded first', implying a prerequisite and distinguishing it from download tools. However, it does not explicitly state when not to use this tool or name alternatives, such as whether it applies only to certain object types or if other texture-application tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the 3D asset has built-in materials, the model has normalized size (suggesting rescaling may be needed), and it returns a success/failure message. However, it lacks details on permissions, rate limits, whether the import is automatic or requires confirmation, or what happens on failure. This provides moderate but incomplete 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core action. Each sentence adds value: the first states the purpose, the second and third provide behavioral details (materials, size), and the parameter section explains inputs clearly. There is minimal waste, though the structure could be slightly more streamlined by integrating parameter details into the flow.
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 no annotations, 0% schema coverage, and no output schema, the description does a fair job: it covers the purpose, key behaviors, and parameter meanings. However, for a tool that generates and imports 3D assets (a potentially complex operation), it lacks details on error handling, output format beyond success/failure, or integration specifics with Blender. This leaves gaps in contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'text_prompt' is described as 'A short description of the desired model in **English**', and 'bbox_condition' as 'Optional. If given, it has to be a list of floats of length 3. Controls the ratio between [Length, Width, Height] of the model.' This clarifies usage beyond the bare schema, though it could specify units or constraints for bbox_condition values.
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 specific action ('Generate 3D asset using Hyper3D by giving description of the desired asset, and import the asset into Blender'), identifies the resource (3D asset/model), and distinguishes it from siblings like 'generate_hyper3d_model_via_images' by specifying it works via text input rather than images. The purpose is unambiguous and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you want to generate a 3D asset from a text description and import it into Blender. It implies usage vs. 'generate_hyper3d_model_via_images' by specifying text-based generation, but does not explicitly state when not to use it or name alternatives for similar tasks like downloading models from other sources (e.g., 'download_polyhaven_asset').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a polling API, specifies completion criteria ('Done' or 'COMPLETED'), failure indicators ('Failed' or other states), and advises to proceed only when status is final. This covers essential operational behavior, though it could add more on rate limits 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but could be more front-loaded. It starts with a clear purpose, then details modes in separate sections, which is structured but slightly verbose. Some sentences, like repeating 'This is a polling API,' could be consolidated for better flow without losing clarity.
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 complexity (two operational modes, no annotations, no output schema), the description is largely complete. It explains purpose, parameters, usage context, and behavioral expectations. However, it lacks details on return values beyond status lists, and doesn't cover potential errors or response formats, which could be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully. It does so by clearly explaining the two parameters: 'subscription_key' for MAIN_SITE mode and 'request_id' for FAL_AI mode, linking them to previous steps. This adds crucial meaning beyond the bare schema, ensuring the agent understands when and how to use each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if the Hyper3D Rodin generation task is completed.' It specifies the verb ('check') and resource ('Hyper3D Rodin generation task'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_hyper3d_status', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: after a generation step, to poll for completion status. It distinguishes between two modes (MAIN_SITE and FAL_AI) with specific parameter requirements. However, it doesn't explicitly mention when not to use it or name alternatives among siblings, such as 'get_hyper3d_status'.
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:

[![blender-mcp MCP server](https://glama.ai/mcp/servers/wenyen-hsu/blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/wenyen-hsu/blender-mcp)

Score Badge

Copy to your README.md:

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

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