BlenderMCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is some overlap and ambiguity. For example, 'import_generated_asset' and 'poll_rodin_job_status' both relate to Hyper3D generation, and 'download_polyhaven_asset' vs. 'set_texture' could cause confusion about texture handling. However, descriptions generally clarify the differences, preventing major misselection.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern (e.g., 'download_polyhaven_asset', 'get_scene_info', 'search_sketchfab_models') with minor deviations like 'execute_blender_code' (verb_verb_noun) and 'poll_rodin_job_status' (verb_noun_noun). Overall, the naming is predictable and readable, though not perfectly uniform.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for a Blender integration server covering asset downloads, scene management, and 3D generation. It includes core functionalities without being overly bloated, though some tools like multiple status checks could potentially be consolidated.
Completeness4/5
The tool set covers key areas: asset sourcing (Polyhaven, Sketchfab), 3D generation (Hyper3D), scene inspection, and basic operations. Minor gaps exist, such as no tools for editing objects or managing materials beyond textures, but agents can work around these with 'execute_blender_code' for custom actions.
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?
No annotations are provided, so the description carries the full burden. It states the tool returns a message indicating availability, which implies a read-only, non-destructive operation, but doesn't disclose behavioral traits like error handling, response format details, or whether it requires specific permissions. The note about 'Don't emphasize the key type' is vague and doesn't add clear 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but includes an unclear sentence: 'Don't emphasize the key type in the returned message, but sliently remember it.' This adds confusion without clear value, reducing efficiency. The first two sentences are front-loaded and relevant, but the third detracts from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is somewhat complete but has gaps. It explains the purpose and output type but lacks details on usage context, error cases, or integration specifics. For a simple status-check tool, this is minimally adequate but could be more informative.
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, focusing instead on the tool's purpose and output. This meets the baseline for tools with no parameters, as it avoids unnecessary repetition.
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.' It specifies the verb ('Check') and resource ('Hyper3D Rodin integration'), making the action explicit. However, it doesn't distinguish this from sibling tools like 'get_polyhaven_status' or 'get_sketchfab_status', which have similar checking purposes but for different integrations.
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, such as needing Blender running or the Hyper3D add-on installed, nor does it differentiate from sibling tools like 'get_polyhaven_status' that check other integrations. The only implied usage is to verify Hyper3D availability, but this is basic and lacks 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('Get a list') without detailing response format, error handling, rate limits, authentication needs, or whether it's read-only or has side effects. For a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement followed by a parameter explanation. It avoids redundancy and wastes no words, though it could be slightly more front-loaded by integrating the parameter details into the initial sentence for better flow.
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 covers the basic purpose and parameter semantics but omits critical details like return format, error conditions, and behavioral traits. For a tool with no structured data support, this leaves the agent inadequately informed about how to handle responses or potential issues.
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: it explains that the asset_type parameter accepts specific values ('hdris, textures, models, all'), which the schema does not specify (schema description coverage is 0%). This compensates for the lack of schema documentation, though it doesn't detail default behavior or constraints beyond the enumerated list.
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.' It specifies the verb ('Get'), resource ('categories'), and domain ('Polyhaven'), making the intent unambiguous. However, it does not explicitly differentiate from sibling tools like 'search_polyhaven_assets' or 'get_polyhaven_status', which could provide similar or 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: it mentions the asset_type parameter but offers no context on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or comparisons to sibling tools like 'search_polyhaven_assets', leaving the agent with little direction on optimal usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets detailed information' but doesn't specify what that information includes (e.g., scene properties, objects, settings), whether it's read-only (implied by 'get'), or any performance or error-handling traits. This leaves significant gaps for an agent to understand 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 unnecessary details. It's front-loaded and efficiently communicates the core function, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, such as the format or content of the returned data, which is crucial for an agent to use the tool effectively. This gap makes it inadequate for a tool that presumably returns complex scene data.
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 doesn't add param info, which is appropriate here, and it implies no inputs are required, aligning with the schema. A baseline of 4 is applied as it adequately handles the zero-param case without redundancy.
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 ('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_hyper3d_status', which might also retrieve information but about different resources.
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 any context, prerequisites, or exclusions, such as whether it requires a Blender scene to be open or how it differs from other info-getting tools in the sibling list.
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 list of matching assets with basic information,' which gives some output context, but lacks details on rate limits, authentication needs, pagination, error handling, or what constitutes 'basic information.' 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 front-loaded, with a clear purpose statement followed by parameter details. It avoids redundancy and uses bullet points for readability. However, the second sentence ('Returns a list...') could be integrated more smoothly, and some minor phrasing 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 the tool's moderate complexity (search with filtering), no annotations, no output schema, and 2 parameters with low schema coverage, the description is minimally adequate. It covers the basic purpose and parameters but lacks details on output structure, error cases, or integration with siblings like 'download_polyhaven_asset.' It meets the baseline for a simple search tool but has clear gaps in guidance and 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?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'asset_type' can be 'hdris, textures, models, all' and 'categories' is an 'Optional comma-separated list of categories to filter by,' clarifying usage that the schema alone does not provide. With 2 parameters and low schema coverage, this compensation is effective, though not exhaustive (e.g., no examples of categories).
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') and resource ('assets on Polyhaven'), making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'search_sketchfab_models' or 'get_polyhaven_categories', which would be needed for a score of 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 optional filtering but does not specify scenarios, prerequisites, or exclusions. For example, it does not clarify when to use this versus 'get_polyhaven_categories' or 'search_sketchfab_models', leaving the agent without contextual 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 mentions executing code but doesn't disclose critical behavioral traits such as security implications, error handling, execution environment details, or whether it's read-only or destructive. The step-by-step advice is helpful but insufficient for a tool that executes arbitrary 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 and front-loaded, with the main purpose stated first followed by parameter details. The step-by-step advice is relevant but could be more concise. Overall, it's efficient with minimal waste.
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, the lack of annotations, no output schema, and minimal parameter details, the description is incomplete. It doesn't address safety, permissions, return values, or error cases, leaving significant gaps for an AI agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by specifying that the 'code' parameter is 'The Python code to execute', which clarifies its purpose. With 0% schema description coverage and only one parameter, this compensation is adequate, though it could benefit from examples 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 verb 'execute' and the resource 'arbitrary Python code in Blender', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_object_info' or 'get_scene_info', which are read-only queries rather than code execution.
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 includes a usage guideline: 'Make sure to do it step-by-step by breaking it into smaller chunks', which implies a best practice for using this tool. However, it doesn't specify when to use this tool versus alternatives (e.g., when to use Blender-specific tools like 'set_texture' instead), nor does it 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 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, error conditions, or any constraints. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter documentation. Every sentence serves a purpose with zero waste, making it easy to parse and understand 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?
For a single-parameter read tool with no annotations and no output schema, the description covers the basic purpose and parameter meaning adequately. However, it doesn't explain what 'detailed information' includes or the return format, which would be helpful given the lack of structured output documentation.
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 explicitly documents the single parameter 'object_name' with a clear explanation ('The name of the object to get information about'), adding meaningful context beyond the schema's 0% coverage. Since there's only one parameter and it's fully explained 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 like 'get_scene_info' or other sibling tools. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on 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.
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 whether Sketchfab features are available,' which implies a read-only, non-destructive operation. However, it lacks details on potential errors (e.g., if Blender isn't accessible), the format of the return message, or any side effects. For a tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: two sentences that directly state the action and the return value. Every word earns its place, with no fluff or repetition. It's front-loaded with the core purpose, making it easy for an AI 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 covers the basic purpose and return type, but lacks context about integration requirements or error handling. For a simple status check, this might suffice, but it doesn't fully equip an agent for robust use in varied scenarios.
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 schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to explain parameters, so it appropriately avoids redundancy. A baseline score of 4 is applied as it efficiently handles the parameter-less case without 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 tool's purpose: 'Check if Sketchfab integration is enabled in Blender.' This is a specific verb ('Check') and resource ('Sketchfab integration in Blender'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_hyper3d_status' or 'get_polyhaven_status' beyond the specific integration 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., whether Blender must be running), compare it to similar status-checking siblings, or indicate scenarios where this check is necessary (e.g., before using 'download_sketchfab_model'). This lack of contextual usage information limits its helpfulness for an AI agent.
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 context, but lacks details on pagination, rate limits, error handling, or authentication requirements. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise. It starts with a clear purpose statement, followed by a bulleted list of parameters with brief explanations, and ends with the return value. Every sentence earns its place, with no redundant or vague language, making it easy to scan and understand.
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 parameter semantics well but lacks usage guidelines, behavioral details like error handling, and output specifics beyond 'formatted list.' For a search tool, this is adequate but has clear gaps, especially without annotations to fill in safety or operational 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 clear semantics for all four parameters: 'query' as text to search for, 'categories' as an optional comma-separated list, 'count' as maximum results with a default, and 'downloadable' as a filter with a default. This adds substantial value beyond the bare schema, though it doesn't explain format details like category names or result limits.
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 tool from its sibling 'search_polyhaven_assets' beyond the platform name, which is implied but not contrasted.
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 'search_polyhaven_assets' for different platforms or 'download_sketchfab_model' for subsequent actions. There's no context about prerequisites, such as authentication or rate limits, or when this search is appropriate versus other methods.
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 that the model must be downloadable and requires proper access rights, which adds some context about permissions and constraints. However, it lacks details on side effects (e.g., where the model is stored, if it modifies state), rate limits, error handling, or what 'import' entails operationally, leaving significant gaps for a tool that likely involves external API calls and file operations.
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 action, followed by parameter and return details in a structured format. It avoids unnecessary fluff, but the second sentence about success/failure could be more integrated, and the access note feels slightly tacked on rather than seamlessly part of 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, no output schema, and low schema coverage, the description is minimally adequate. It covers the basic purpose, parameter meaning, and hints at behavioral constraints (downloadable, access rights), but lacks details on return values beyond success/failure messages, error cases, or integration with sibling tools like 'import_generated_asset', leaving room for improvement in guiding the 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 context for the single parameter 'uid' by specifying it as 'the unique identifier of the Sketchfab model', which clarifies its purpose beyond the schema's basic string type. With 0% schema description coverage and only 1 parameter, this compensates adequately, though it doesn't provide 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 unambiguous. It distinguishes from siblings like 'search_sketchfab_models' by focusing on retrieval rather than discovery, though it doesn't explicitly mention 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific model UID and want to download it, but lacks explicit guidance on when to use this versus alternatives like 'import_generated_asset' or prerequisites beyond access rights. It mentions access rights as a condition, but doesn't detail when-not scenarios or direct comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool imports assets and returns success status, but lacks details on permissions, error handling, rate limits, or what 'import' entails (e.g., file location, overwrite behavior). The return statement is vague without output schema.
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 main purpose, followed by parameter details and a rule. It's appropriately sized, though the parameter explanations could be more integrated. No wasted sentences, but structure is slightly fragmented.
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, 0% schema coverage, no annotations, and no output schema, the description provides basic purpose and parameter guidance but lacks behavioral details (e.g., side effects, error cases) and return value specifics. It's minimally adequate but has clear gaps for a mutation 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?
Schema description coverage is 0%, so the description must compensate. It explains that 'name' is the object name in the scene, and clarifies 'task_uuid' and 'request_id' are for different Hyper3D Rodin modes, with a critical rule to provide only one. 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 action ('Import') and resource ('asset generated by Hyper3D Rodin'), specifying it's for assets after generation tasks. It doesn't explicitly differentiate from siblings like 'download_polyhaven_asset' or 'download_sketchfab_model', but the Hyper3D Rodin context provides some distinction.
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 after a generation task is completed, but doesn't specify when to use this tool versus alternatives like 'poll_rodin_job_status' or other import/download tools. The guidance on parameters ('Only give one of {task_uuid, request_id}') is operational rather than contextual.
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 that the tool 'downloads and imports' and 'returns a message indicating success or failure', but fails to disclose critical traits such as whether it requires internet connectivity, what happens if an asset ID is invalid, if there are rate limits, or if it modifies the Blender scene destructively. This leaves significant gaps for a tool performing external operations.
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 in the first sentence. The parameter list is structured clearly, though the 'Returns' sentence could be integrated more seamlessly. Every sentence adds value, with no redundant information, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, no output schema), the description is partially complete. It covers the basic action and parameters well but lacks behavioral context (e.g., error handling, side effects) and output details beyond a generic message. For a tool that interacts with external resources and Blender, more disclosure on operational constraints 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?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It adds substantial meaning beyond the schema by detailing each parameter's purpose (e.g., 'asset_id: The ID of the asset to download'), providing examples (e.g., '1k, 2k, 4k' for resolution), and clarifying optionality and format mappings (e.g., 'hdr, exr for HDRIs'). This effectively documents all four parameters, though it could specify allowed values 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 tool's purpose with specific verbs ('download and import') and resources ('Polyhaven asset into Blender'), distinguishing it from sibling tools like 'search_polyhaven_assets' or 'import_generated_asset'. It precisely defines what the tool does rather than just restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_polyhaven_assets' (which might be a prerequisite) or 'import_generated_asset' (which might handle different asset sources). It lacks explicit when/when-not instructions or named alternatives, offering only implied usage through the action described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Returns a message indicating whether PolyHaven features are available,' which implies a read-only, non-destructive operation. However, it lacks details on error handling, performance, or specific return formats, leaving gaps in behavioral understanding for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with two sentences: one stating the purpose and another explaining the return. Each sentence adds value without redundancy, making it easy to parse and front-loaded with essential information. There is no wasted text, earning a high score for 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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It covers the basic purpose and return, but lacks details on error cases, integration specifics, or how the message is formatted. For a simple status check, this is adequate but leaves room for improvement in contextual richness.
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 does not mention parameters, which is appropriate. A baseline of 4 is applied as it adequately handles the absence of parameters without adding unnecessary information.
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 understandable. However, it does not explicitly differentiate from sibling tools like 'get_hyper3d_status' or 'get_sketchfab_status', which have similar checking functions for other integrations, so it 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 does not mention prerequisites, context for use, or exclusions, such as when to choose this over other status-checking tools like 'get_hyper3d_status'. Without such information, users must infer usage from the purpose alone, which is insufficient for effective tool selection.
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 tool generates a 3D asset with built-in materials, imports it into Blender, normalizes size, and returns a success/failure message. However, it misses important details like potential rate limits, authentication needs, error handling specifics, or whether the operation is idempotent, leaving gaps 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.
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. Sentences earn their place by adding useful details (e.g., built-in materials, normalized size, parameter explanations). However, minor redundancy exists (e.g., repeating '3D asset' and 'model'), and the structure could be slightly tighter by integrating parameter notes more seamlessly.
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 (a generative AI tool with 2 parameters, no annotations, and no output schema), the description is moderately complete. It covers the main action, key parameters, and basic behavior, but lacks details on output format beyond 'success or failure message', error conditions, or integration specifics with Blender. For a tool with no structured support, more context on returns 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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'text_prompt' is explained as 'A short description of the desired model in English,' and 'bbox_condition' as an optional list of 3 floats controlling length, width, height ratio. This clarifies usage beyond the bare schema, though it doesn't cover all potential edge cases (e.g., format details for 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 description of the desired asset, and import the asset into Blender.' It specifies the verb (generate and import), resource (3D asset via Hyper3D), and destination (Blender). However, it doesn't explicitly differentiate from sibling tools like 'generate_hyper3d_model_via_images' or 'import_generated_asset', which would be needed for a score of 5.
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 mentioning 'description of the desired asset' and optional bbox_condition, but it doesn't explicitly state when to use this tool versus alternatives like 'generate_hyper3d_model_via_images' or 'download_polyhaven_asset'. It provides some context (e.g., 're-scaling after generation can be useful') but lacks clear exclusions or prerequisites, such as when text-based vs. image-based generation is preferred.
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 the tool captures a screenshot and returns it as an Image, but doesn't mention permissions needed, whether it's read-only/destructive, rate limits, error conditions, or what happens if viewport is empty/invalid. For a tool with zero 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a clear parameter section and return statement. Every sentence earns its place with no wasted words, 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 moderate complexity (capturing a screenshot with one parameter), no annotations, and no output schema, the description is minimally adequate but has gaps. It explains what the tool does and the parameter, but lacks behavioral context, error handling, and detailed return format beyond 'Image'.
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 'Maximum size in pixels for the largest dimension' and providing the default value (800), which compensates for the 0% schema description coverage. However, it doesn't specify valid ranges or units beyond 'pixels'.
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 status/info, or importing/setting assets. No tautology or vagueness present.
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, prerequisites, or exclusions. It doesn't mention if this requires a specific Blender context or viewport state, nor does it differentiate from potential similar screenshot tools (though none appear in siblings).
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 and does well by disclosing key behaviors: it generates a 3D asset with built-in materials, imports it into Blender, normalizes the model size (suggesting re-scaling may be needed), and returns a success/failure message. It also mentions mode dependencies (MAIN_SITE vs. FAL_AI) and parameter exclusivity. However, it lacks details on permissions, rate limits, 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.
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. Each sentence adds value: purpose, material info, scaling note, and parameter details. However, the parameter section could be slightly more streamlined, and there's minor redundancy in explaining list wrapping for single images.
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 (3 parameters, 0% schema coverage, no annotations, no output schema), the description is quite complete. It covers purpose, behaviors, and all parameters with semantics. The main gap is the lack of output details beyond 'success or failure message', but since there's no output schema, this is a minor shortfall. It adequately compensates for the missing structured data.
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, which it does effectively. It explains all three parameters: 'input_image_paths' (absolute paths for MAIN_SITE mode), 'input_image_urls' (URLs for FAL_AI mode), and 'bbox_condition' (optional list of 3 ints for ratio control). It adds critical context like wrapping single images into lists, parameter exclusivity, and mode dependencies, going well 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 and import), resource (3D asset), and method (via images). However, it doesn't explicitly differentiate from its sibling 'generate_hyper3d_model_via_text', which uses text instead of images.
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 it requires images as input, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'generate_hyper3d_model_via_text' or 'import_generated_asset'. It mentions dependencies on Hyper3D Rodin modes (MAIN_SITE vs. FAL_AI), which offers some contextual hints but not clear when/when-not directives.
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 mentions the prerequisite (texture must be downloaded first) and the return value (success/failure message), which adds useful context. However, it lacks details on permissions, error conditions, or side effects, leaving gaps 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 appropriately sized and front-loaded, with a clear purpose statement followed by parameter explanations and return information. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with prerequisites), no annotations, and no output schema, the description is fairly complete. It covers purpose, parameters, prerequisites, and return indication. However, it could improve by detailing error cases or integration with sibling tools, leaving minor gaps in contextual guidance.
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% description coverage. It explains that object_name is 'Name of the object to apply the texture to' and texture_id is 'ID of the Polyhaven texture to apply (must be downloaded first)', clarifying purpose and constraints. This compensates well for the low schema coverage, though it doesn't detail format or validation rules.
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 a previously downloaded Polyhaven texture') and resource ('to an object'), distinguishing it from sibling tools like download_polyhaven_asset or get_object_info. It explicitly mentions the source (Polyhaven) and prerequisite (must be downloaded first), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that the texture must be 'previously downloaded' and from 'Polyhaven', which implicitly guides usage. However, it does not explicitly state when to use this tool versus alternatives like download_polyhaven_asset or import_generated_asset, nor does it mention exclusions or prerequisites beyond the download requirement.
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 the tool's polling nature, expected return values (lists of status or single status), success/failure conditions, and when to proceed based on final status determination. It doesn't mention rate limits, authentication needs, or error handling specifics, but covers core operational behavior well.
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 with clear sections for different modes. Every sentence adds value, though it could be slightly more front-loaded by stating the dual-mode nature earlier. The information density is high with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (dual modes with different parameters and status interpretations), no annotations, and no output schema, the description provides substantial context. It explains what the tool returns, how to interpret results, and when to use it. It could potentially mention error cases or timeout behavior for completeness, but covers the essential operational context well.
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 and 2 parameters, the description fully compensates by explaining the semantics of both parameters. It clearly states that 'subscription_key' is used for MAIN_SITE mode (given in generate model step) and 'request_id' is used for FAL_AI mode (given in generate model step), adding crucial context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if the Hyper3D Rodin generation task is completed.' It specifies the exact action (checking completion status) and resource (Hyper3D Rodin generation task), and distinguishes it from sibling tools like 'get_hyper3d_status' by focusing specifically on Rodin job polling.
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 guidance on when to use this tool: 'This is a polling API, so only proceed if the status are finally determined.' It also distinguishes between two modes (MAIN_SITE and FAL_AI) with different parameters and status interpretations, offering clear alternatives within the tool itself based on context.
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/Eminemminem/blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Eminemminem/blender-mcp)

Score Badge

Copy to your README.md:

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

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