BlenderMCP

by spranjal3301

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 Hyper3D generation tools (generate_hyper3d_model_via_images and generate_hyper3d_model_via_text) and their related import/polling tools, which could cause confusion about workflow steps. However, descriptions clarify their roles, and other tools like download_polyhaven_asset and set_texture are clearly differentiated.
Naming Consistency4/5
Tool names follow a consistent snake_case verb_noun pattern throughout (e.g., download_polyhaven_asset, get_scene_info), with minor deviations like poll_rodin_job_status using 'poll' instead of 'get' or 'check'. The naming is predictable and readable, supporting easy identification of actions and targets.
Tool Count5/5
With 13 tools, the set is well-scoped for Blender integration, covering asset downloading (Polyhaven), 3D model generation (Hyper3D), scene management, and status checks. Each tool serves a clear purpose without bloat, aligning with the server's domain of enhancing Blender workflows with external resources and automation.
Completeness4/5
The toolset provides comprehensive coverage for Polyhaven and Hyper3D integrations, including download, search, application, generation, and status checks. Minor gaps exist, such as no direct tools for modifying or deleting imported assets in Blender, but core workflows are well-supported, allowing agents to perform key tasks without dead ends.
Average 3.4/5 across 13 of 13 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions executing 'arbitrary Python code' and suggests a step-by-step approach, it lacks critical details: it doesn't specify security implications, whether the code runs in a sandbox, what permissions are required, how errors are handled, or what the execution environment entails (e.g., Blender version, available modules). For a tool that executes arbitrary code with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a usage tip and parameter list. There's no wasted text, and it's structured for clarity. However, the parameter section could be more integrated, and the step-by-step advice, while useful, slightly detracts from pure 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 (executing arbitrary code is high-risk), no annotations, no output schema, and low schema coverage (0%), the description is incomplete. It misses critical context: safety warnings, execution limits, error handling, and output details. For such a powerful tool, the description should provide more comprehensive guidance to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists one parameter ('code: The Python code to execute'), which adds basic meaning beyond the schema's title 'Code.' However, it doesn't provide any details on code format, constraints (e.g., length, imports), examples, or expected behavior (e.g., return values, output capture). With one parameter and low coverage, the description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute arbitrary Python code in Blender' - this is a specific verb ('Execute') + resource ('Python code in Blender'). It distinguishes from siblings like 'download_polyhaven_asset' or 'get_scene_info' by focusing on code execution rather than asset management or information retrieval. However, it doesn't explicitly differentiate from potential code-related siblings that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance with 'Make sure to do it step-by-step by breaking it into smaller chunks,' which suggests best practices for using this tool. However, it doesn't explicitly state when to use this tool versus alternatives (like whether to use this for simple operations vs. complex scripts), nor does it mention any prerequisites or exclusions. The guidance is helpful but incomplete.
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 'optional filtering' and 'returns a list of matching assets with basic information,' which gives some context about output format. However, it lacks details on rate limits, authentication needs, pagination, error handling, or what 'basic information' entails, leaving significant gaps for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a bulleted list of parameters and a note on returns. There's no wasted text, and the structure aids readability. A perfect score would require even tighter phrasing or more strategic emphasis.
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 (a search tool with filtering), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return structure (e.g., what fields are in 'basic information'), error cases, or how results are ordered/limited. For a tool with 2 parameters and no structured output, more context is needed to guide the agent effectively.
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 beyond the input schema. It explains that 'asset_type' filters by type (e.g., hdris, textures) and 'categories' is an optional comma-separated list for filtering, which clarifies usage. However, with 0% schema description coverage, it doesn't fully compensate—e.g., it doesn't specify valid categories or format details. The baseline is 3 due to some added value, but it's incomplete.
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 assets on Polyhaven with optional filtering.' It specifies the verb ('search'), resource ('assets on Polyhaven'), and scope ('with optional filtering'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_polyhaven_categories' or 'download_polyhaven_asset', which would be needed for 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 sibling tools like 'get_polyhaven_categories' (which might provide metadata) or 'download_polyhaven_asset' (which retrieves specific assets), nor does it specify prerequisites or exclusions. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it 'Get[s] a list of categories', implying a read-only operation, but doesn't clarify aspects like rate limits, authentication needs, or what the returned list format might be (e.g., JSON structure, pagination). This leaves significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 purpose followed by parameter details. Both sentences earn their place by clarifying the tool's function and its single parameter, with no redundant or verbose language.
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 purpose and parameter semantics but lacks behavioral details and usage guidelines, making it incomplete for optimal agent understanding despite the simple 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 beyond the input schema, which has 0% description coverage. It explains that 'asset_type' specifies 'the type of asset to get categories for' and lists possible values (hdris, textures, models, all), providing essential semantic information not present in the schema's bare title 'Asset Type' and default 'hdris'.
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 resource ('list of categories for a specific asset type on Polyhaven'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from its siblings like 'search_polyhaven_assets' or 'get_polyhaven_status', which could have overlapping or related functions.
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 where fetching categories is necessary or how it relates to sibling tools like 'search_polyhaven_assets', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about what 'detailed information' includes, whether this is a read-only operation, potential performance characteristics, or error conditions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a zero-parameter information retrieval tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a description that only states the basic purpose, this is incomplete for a tool that presumably returns scene information. The description doesn't indicate what 'detailed information' includes, the format of returned data, or any constraints on when this can be called. For a tool that likely returns structured scene data, more context would be 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 zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and the schema already fully documents the empty parameter set.
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 ('Get detailed information') and target resource ('about the current Blender scene'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_object_info' or 'get_hyper3d_status', which appear to retrieve different types of information.
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. There's no mention of prerequisites, timing considerations, or comparison to sibling tools like 'get_object_info' that might retrieve different scopes of information. The agent must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool's read-only nature ('Check', 'Returns a message') and output intent, but lacks behavioral details like error handling, performance characteristics, or authentication needs. The cryptic note about 'key type' adds minimal value and is confusing rather than helpful.
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 front-loaded with the core purpose, but the second sentence is somewhat redundant (reiterates return). The final cryptic note ('Don't emphasize... but silently remember it') adds noise without clear value, reducing overall clarity and efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool with no parameters and no output schema, the description is minimally adequate. It explains what the tool does and what it returns, but lacks context about why this check matters (e.g., prerequisite for other Hyper3D tools) or details about the return format (e.g., structured data vs. plain text).
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% (empty schema). The description appropriately doesn't discuss parameters, focusing instead on the tool's action and return. No additional parameter semantics are needed or provided.
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' (verb+resource). It distinguishes from siblings by focusing on integration status rather than asset generation, import, or scene manipulation. However, it doesn't explicitly differentiate from get_polyhaven_status, which checks a different integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., should be used before attempting Hyper3D operations), when-not scenarios, or direct comparisons to siblings like get_polyhaven_status. The agent must infer usage from purpose alone.
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 states this is a 'get' operation for information, implying read-only behavior, but doesn't disclose any behavioral traits like error handling, permission requirements, rate limits, or what happens if the object doesn't exist. For a tool with no annotation coverage, this is inadequate.
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 clear parameter explanation. Every sentence earns its place with no wasted words. It's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter, but lacks details on return values, error conditions, or behavioral context. For a read-only info tool, this is the bare minimum.
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 only 1 parameter and 0% schema description coverage, the description compensates by explaining 'object_name' as 'The name of the object to get information about.' This adds meaningful context beyond the bare schema. However, it doesn't specify format constraints or examples, 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 verb 'Get' and the resource 'detailed information about a specific object in the Blender scene.' It distinguishes from siblings like 'get_scene_info' by specifying object-level rather than scene-level information. However, it doesn't explicitly contrast with all siblings, so it's not a perfect 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 doesn't mention when to use 'get_object_info' vs 'get_scene_info' or other sibling tools, nor does it specify prerequisites or exclusions. This leaves the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns a message about PolyHaven feature availability, but doesn't disclose behavioral traits like whether it's read-only, safe to call frequently, requires authentication, or has rate limits. For a status-check 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 purpose and return value. Every word earns its place with no redundancy or fluff. It efficiently communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It states what the tool does and what it returns, but lacks details on behavioral context (e.g., safety, performance) that would be helpful for an agent. It's adequate but has clear gaps in transparency.
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% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if PolyHaven integration is enabled in Blender.' It uses a specific verb ('Check') and identifies the resource (PolyHaven integration in Blender). However, it doesn't explicitly differentiate from sibling tools like 'get_hyper3d_status' or 'get_scene_info', which are also 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or compare it to sibling tools like 'get_hyper3d_status' or other status-checking tools. The agent must infer usage from context alone.
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 texture must be downloaded first, which adds context about prerequisites, but fails to disclose other key traits such as whether this operation is destructive, requires specific permissions, or has rate limits. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clear parameter list and return information. Every sentence earns its place without redundancy, making it efficient and well-structured.
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 complexity (a mutation operation with 2 parameters), no annotations, and no output schema, the description is moderately complete. It covers purpose, parameters, and prerequisites, but lacks details on behavioral traits (e.g., side effects) and output specifics beyond a generic success/failure message, leaving some gaps for an AI agent.
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 semantics beyond the input schema, which has 0% coverage. It explains that 'object_name' is the name of the object to apply the texture to and 'texture_id' is the ID of a Polyhaven texture that must be downloaded first. This compensates well for the low schema coverage, though it doesn't detail format constraints (e.g., string patterns).
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 ('Apply') and the resource ('a previously downloaded Polyhaven texture to an object'), making the purpose specific and understandable. It distinguishes from siblings like 'download_polyhaven_asset' by focusing on application rather than acquisition, though it doesn't explicitly contrast with all siblings (e.g., 'get_object_info').
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 stating the texture 'must be downloaded first,' which references the sibling tool 'download_polyhaven_asset' as a prerequisite. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., other texture-related tools) or any exclusions, leaving some context to inference.
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 adds some context: the tool imports the asset into Blender, includes built-in materials, and returns a success/failure message. However, it doesn't cover critical aspects like whether this is a read-only or destructive operation, potential rate limits, authentication needs, or what happens if the generation fails. The description doesn't contradict annotations (none exist), but it's incomplete for a tool that likely involves complex processing.
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 purpose. It uses bullet points for parameters, which aids readability. However, some sentences could be more concise (e.g., 'Even if only one image is provided, wrap it into a list' is repeated), and the structure mixes general info with parameter details without clear sectioning.
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, 0% schema coverage, no output schema, no annotations), the description is moderately complete. It covers the purpose, parameter semantics, and some behavioral context (import to Blender, materials, size). However, it lacks details on output format beyond success/failure, error handling, dependencies on other tools (e.g., 'poll_rodin_job_status'), and integration with sibling tools, leaving gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for all three parameters: 'input_image_paths' and 'input_image_urls' are explained with mode dependencies and list-wrapping requirements, and 'bbox_condition' is described as controlling the model's length-width-height ratio with a specific format. This adds significant value beyond the bare schema, though it doesn't detail exact formats or constraints for the bbox condition.
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 technology ('Hyper3D'), and distinguishes it from sibling tools like 'generate_hyper3d_model_via_text' by using images instead of text. However, it doesn't explicitly differentiate from other 3D-related tools like 'import_generated_asset' or 'download_polyhaven_asset' in terms of when to choose this over those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning Hyper3D Rodin modes (MAIN_SITE vs. FAL_AI) and the requirement to use either 'input_image_paths' or 'input_image_urls' based on mode. It also notes that the generated model has normalized size, suggesting re-scaling after generation. However, it lacks explicit guidance on when to use this tool versus alternatives like 'generate_hyper3d_model_via_text' or 'import_generated_asset', and 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states basic functionality. It doesn't disclose whether this requires network access, has rate limits, what happens if the asset already exists, whether it modifies the Blender scene, or any error conditions beyond 'success or failure'. For a download/import operation, this is insufficient 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 with a clear purpose statement followed by a parameter breakdown. Every sentence adds value, though the 'Returns' statement is somewhat redundant given it only states obvious success/failure messaging. The structure is logical and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no output schema, the description covers basic purpose and parameters adequately but lacks important contextual details: no information about what 'import into Blender' actually does, no error handling specifics, no performance or behavioral characteristics. It's minimally viable 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?
With 0% schema description coverage, the description provides meaningful semantic context for all 4 parameters: asset_id identifies the asset, asset_type categorizes it, resolution specifies download quality, and file_format indicates optional format choices with examples. This compensates well for the schema gap, though it doesn't explain parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download and import'), target resource ('Polyhaven asset'), and destination ('into Blender'). It distinguishes this tool from siblings like search_polyhaven_assets (which finds assets) and import_generated_asset (which imports different types of assets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to download and import a Polyhaven asset, but provides no explicit guidance on when to use this tool versus alternatives like set_texture or import_generated_asset. No prerequisites, exclusions, or comparative context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool imports an asset and returns success status, which is basic behavioral info. However, it lacks details on permissions, error handling, or side effects (e.g., whether it modifies existing assets). It doesn't contradict annotations, as there are none.
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: purpose, parameters, and return. It's front-loaded with the main action. However, the parameter list could be more integrated into prose, and the 'Only give one...' instruction is slightly redundant with the mode context.
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 3 parameters with 0% schema coverage, no annotations, and no output schema, the description provides basic purpose and parameter guidance but lacks details on return values (beyond success status), error cases, or prerequisites. It's minimally adequate but has gaps for a tool with multiple parameters and 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?
Schema description coverage is 0%, so the description must compensate. It explains that 'name' is the object name in the scene, 'task_uuid' is for MAIN_SITE mode from generate model step, and 'request_id' is for FAL_AI mode from generate model step. This adds crucial meaning beyond the schema's bare parameter names and types, though it could specify format or constraints.
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'), specifying it occurs after generation task completion. It distinguishes from siblings like 'generate_hyper3d_model_via_images/text' by focusing on import rather than generation, though it doesn't explicitly contrast with all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool: after a Hyper3D Rodin generation task is completed. It distinguishes between modes (MAIN_SITE vs. FAL_AI) and specifies to use only one of task_uuid or request_id based on mode. However, it doesn't explicitly state when not to use it or compare with alternatives like 'poll_rodin_job_status'.
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 that the model has built-in materials, normalized size (requiring rescaling), and returns a success/failure message. However, it omits details like processing time, error conditions, or Blender import specifics, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by key features and parameters. Sentences are efficient, but the parameter section could be integrated more smoothly. Overall, it avoids unnecessary verbosity.
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 and no output schema, the description provides basic purpose and parameters but lacks details on return values beyond success/failure, error handling, or integration with sibling tools like 'import_generated_asset.' For a generative tool with 2 parameters, it's adequate but 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?
Schema description coverage is 0%, so the description must compensate. It explains 'text_prompt' as a short English description and 'bbox_condition' as an optional list of 3 floats controlling length, width, height ratio. This adds meaningful context beyond the bare schema, though it could detail format constraints more.
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'), the resource ('3D asset'), and distinguishes from siblings by specifying text-based generation (vs. image-based 'generate_hyper3d_model_via_images'). It also mentions importing into Blender, which is a distinct outcome.
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 through the phrase 'by giving description of the desired asset,' but lacks explicit guidance on when to use this tool versus alternatives like 'generate_hyper3d_model_via_images' or 'download_polyhaven_asset.' No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well: it discloses this is a polling API (important behavioral trait), explains completion criteria for both modes, describes failure states, and provides specific status interpretation rules. It doesn't mention rate limits, authentication needs, or error handling details, but covers the essential polling behavior thoroughly.
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 not optimally structured. It front-loads the core purpose, but the mode-specific sections create some redundancy. Every sentence earns its place by providing essential information, but the formatting with bullet-like lists could be more streamlined for an AI agent.
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 with different parameters and status interpretations), no annotations, and no output schema, the description provides substantial context. It explains what constitutes completion/failure for both modes, the polling nature, and parameter usage. It doesn't describe the exact return format or error responses, but covers the essential operational logic comprehensively.
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?
With 0% schema description coverage, the description fully compensates by explaining both parameters in context: 'subscription_key' for MAIN_SITE mode and 'request_id' for FAL_AI mode. It clarifies which parameter to use for which operational mode and ties them back to previous generation steps, adding significant semantic value 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: checking completion status of Hyper3D Rodin generation tasks. It specifies the exact resource (Rodin generation task) and verb (check/status). However, it doesn't explicitly differentiate from sibling 'get_hyper3d_status', which appears to serve a similar status-checking function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'This is a polling API, so only proceed if the status are finally determined.' It distinguishes between two modes (MAIN_SITE and FAL_AI) with different parameters and status interpretations, effectively telling the agent when to use which parameter set and how to interpret results for each mode.
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:

[![final-year-project MCP server](https://glama.ai/mcp/servers/spranjal3301/final-year-project/badges/card.svg)](https://glama.ai/mcp/servers/spranjal3301/final-year-project)

Score Badge

Copy to your README.md:

[![final-year-project MCP server](https://glama.ai/mcp/servers/spranjal3301/final-year-project/badges/score.svg)](https://glama.ai/mcp/servers/spranjal3301/final-year-project)

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/spranjal3301/final-year-project'

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