BlenderMCP

by diegofornalha

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: v0.1.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap between the two Hyper3D generation tools (via images vs. text) and the import_generated_asset tool, which could cause confusion about when to use each. Additionally, the status-check tools (get_hyper3d_status, get_polyhaven_status, get_sketchfab_status) are clear but might be redundant if not properly contextualized.
Naming Consistency4/5
The naming follows a consistent verb_noun pattern (e.g., download_polyhaven_asset, get_scene_info, search_sketchfab_models) with minor deviations like poll_rodin_job_status (which uses 'poll' instead of 'get' or 'check') and execute_blender_code (which is more generic). Overall, the pattern is predictable and readable.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for a Blender integration server that covers asset downloading, 3D generation, scene management, and status checks. It feels comprehensive without being overwhelmingly bloated, though some tools could potentially be consolidated.
Completeness4/5
The toolset covers key areas like asset sourcing (Polyhaven, Sketchfab), 3D generation (Hyper3D), scene inspection, and basic operations (e.g., screenshot, texture application). However, there are minor gaps, such as no tools for editing or deleting objects in Blender, and the Hyper3D workflow relies on multiple tools (generate, poll, import) that might not be fully intuitive as a cohesive set.
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 of behavioral disclosure. It states the tool retrieves 'detailed information' but does not specify what that includes (e.g., object type, properties, location), whether it requires specific permissions, or how errors are handled. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: one stating the purpose and another listing parameters. It is front-loaded with the main function, though the parameter listing could be integrated more seamlessly. There is minimal waste, earning a high score.
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 low schema description coverage, the description is incomplete. It lacks details on what 'detailed information' entails, error handling, or prerequisites, making it inadequate for a tool that interacts with a Blender scene, which could involve complex data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that 'object_name' refers to 'The name of the object to get information about', which clarifies the parameter's purpose beyond the schema's title. However, it does not provide details like format constraints or examples, leaving some gaps.
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 ('a specific object in the Blender scene'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'get_scene_info' or 'get_viewport_screenshot', which limits the score to 4 rather than 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 does not mention sibling tools like 'get_scene_info' for broader scene details or 'get_viewport_screenshot' for visual output, leaving usage context implied at best.
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 offers minimal behavioral insight. It mentions returns a list with basic information but doesn't disclose pagination, rate limits, authentication needs, or error handling. For a search tool, this lack of detail on result format and constraints 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 with the core purpose. The parameter explanations are concise and relevant, with no wasted sentences. However, the structure could be slightly improved by integrating usage context, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search with filtering), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain return value details, error cases, or behavioral traits like result limits, making it inadequate for an agent to fully understand tool behavior.
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 some value by explaining 'asset_type' options (hdris, textures, models, all) and that 'categories' is comma-separated, which isn't in the schema (0% coverage). However, it doesn't fully compensate for the schema gap—e.g., it doesn't detail category values or search query parameters, leaving parameters partially undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for assets on Polyhaven with filtering, specifying the verb 'search' and resource 'assets on Polyhaven'. However, it doesn't explicitly distinguish itself from sibling tools like 'search_sketchfab_models', which searches a different platform, leaving some ambiguity about when to choose between similar search 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 mentions optional filtering but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't clarify if this should be used before 'download_polyhaven_asset' or how it differs from 'get_polyhaven_categories', leaving the agent without contextual usage cues.
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. While it mentions executing code 'in Blender' and suggests a step-by-step approach, it lacks critical details: it doesn't specify permissions needed, potential side effects (e.g., modifying Blender scenes), error handling, or execution limits. For a tool that executes arbitrary code, 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 concise and well-structured: it starts with the core purpose, adds a usage tip, and then lists parameters clearly. Every sentence adds value, and there's no unnecessary repetition. However, it could be slightly more front-loaded by integrating the parameter info more seamlessly, but it's efficient overall.
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 in Blender, the description is incomplete. No annotations or output schema exist, and the description doesn't cover key aspects like return values, error cases, or safety considerations. For a tool with such broad potential impact, more context is needed to ensure safe and effective use by an AI agent.
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 lists the 'code' parameter and states it's 'The Python code to execute.' With 0% schema description coverage (the schema has no descriptions for parameters), this provides basic meaning but doesn't elaborate on format, constraints, or examples. Since there's only one parameter, the baseline is higher, but the description doesn't fully compensate for the lack of schema 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: 'Execute arbitrary Python code in Blender.' It specifies the verb ('execute'), resource ('Python code'), and context ('in Blender'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_scene_info' or 'set_texture', which are more specific operations rather than general 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 provides some usage guidance with '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 explicitly state when to use this tool versus alternatives (e.g., for automation vs. using specific sibling tools) or list any prerequisites or exclusions. The guidance is helpful but not comprehensive.
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 offers minimal behavioral insight. It implies a read operation ('Get') but doesn't disclose critical traits: whether it requires Blender to be running, what 'detailed information' includes (e.g., scene properties, objects list), error handling, or performance characteristics. The description is too vague for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It front-loads the core action ('Get detailed information') and specifies the target ('current Blender scene'), making it immediately understandable. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description is incomplete. It lacks context about what 'detailed information' entails, how it relates to Blender state, or what format the output takes. For a tool in a Blender automation context, this leaves significant gaps for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty schema is fully described). The description doesn't need to compensate for any parameter gaps, so it meets the baseline for a parameterless tool. No additional parameter context is required 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 verb ('Get') and resource ('detailed information about the current Blender scene'), making the purpose unambiguous. It distinguishes from siblings like 'get_object_info' (specific object vs. scene) and 'get_viewport_screenshot' (visual capture vs. information retrieval). However, it doesn't explicitly contrast with all siblings, preventing 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., requires an open Blender scene), exclusions, or comparisons to siblings like 'get_object_info' for object-specific details. 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the model must be downloadable and proper access rights are needed, which adds some context. However, it lacks details on what 'import' entails (e.g., file format, destination), potential side effects, error handling, or rate limits, leaving significant gaps for a tool that likely involves network operations and file system changes.
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: the first states the purpose, the second explains the parameter, and the third covers returns and prerequisites. It's front-loaded with the core action, but the last sentence could be more structured to separate return values from requirements.
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 downloading and importing a model, no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain what 'import' means in this context, the expected output format, error conditions, or how it interacts with sibling tools, leaving the agent with insufficient information for reliable 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?
The description explicitly defines the 'uid' parameter as 'The unique identifier of the Sketchfab model', adding meaning beyond the input schema which has 0% description coverage and only provides a title 'Uid'. This compensates well for the schema's lack of detail, though it doesn't elaborate on format 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 action ('Download and import') and the resource ('a Sketchfab model by its UID'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_sketchfab_models' or 'import_generated_asset', which could help the agent choose correctly.
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 Sketchfab model UID to download and import, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'search_sketchfab_models' or 'import_generated_asset'. No exclusions or prerequisites are clearly stated beyond access rights.
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 describes a read operation ('Get') but lacks details on permissions, rate limits, response format, or error handling. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a clear parameter explanation in a structured format. It uses minimal words effectively, with no redundant or wasted sentences.
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) and lack of annotations, the description is adequate for basic understanding but incomplete. It covers the parameter semantics but misses behavioral aspects like response format or error cases, which are important for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'asset_type' by listing its possible values (hdris, textures, models, all), which is not covered in the schema (0% description coverage). This compensates well for the schema's lack of detail, though it could clarify the meaning of 'all'.
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 does not explicitly differentiate from sibling tools like 'search_polyhaven_assets' or 'get_polyhaven_status', which could provide related but different 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 no guidance on when to use this tool versus alternatives. It mentions the asset_type parameter but does not specify scenarios, prerequisites, or exclusions, leaving the agent to 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 states the tool 'returns a message indicating whether PolyHaven features are available,' which hints at read-only behavior but lacks details on error handling, response format, or any side effects. 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 concise and front-loaded, consisting of two sentences that directly state the tool's purpose and return value. There is no wasted text, and every sentence earns its place by providing essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return indication but lacks details on behavioral traits, error cases, or integration with siblings. It meets the minimum viable threshold but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but that's acceptable here. A baseline score of 4 is appropriate as it doesn't need to compensate for any gaps.
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 doesn't explicitly differentiate from sibling tools like 'get_hyper3d_status' or 'get_sketchfab_status' beyond mentioning PolyHaven specifically.
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, context for checking integration status, or how it relates to sibling tools like 'download_polyhaven_asset' or 'search_polyhaven_assets'. Usage is implied but not explicitly stated.
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 the tool 'Returns a formatted list of matching models,' which gives basic output information, but lacks critical behavioral details such as rate limits, authentication requirements, pagination behavior, error handling, or what 'formatted list' entails. For a search tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 bulleted list of parameters with concise explanations. Every sentence earns its place with no redundant information, 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 no annotations and no output schema, the description partially compensates by explaining parameters and stating the return type. However, it lacks details on output format, error cases, and behavioral constraints. For a search tool with 4 parameters and no structured output documentation, this is minimally adequate but leaves gaps in 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 adds meaningful semantics for all 4 parameters: 'query' as 'Text to search for,' 'categories' as 'Optional comma-separated list of categories,' 'count' as 'Maximum number of results to return (default 20),' and 'downloadable' as 'Whether to include only downloadable models (default True).' This provides clear usage context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for models on Sketchfab with optional filtering.' This specifies the verb ('search'), resource ('models on Sketchfab'), and scope ('optional filtering'). However, it doesn't explicitly differentiate from sibling tools like 'search_polyhaven_assets' beyond the platform 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. It doesn't mention sibling tools like 'search_polyhaven_assets' for cross-platform comparisons, nor does it specify prerequisites or scenarios where this search is preferred over direct downloads or other model-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior: it checks integration status and returns a message. However, it lacks details on potential errors, performance, or side effects. The note about 'Don't emphasize the key type in the returned message' adds some context but is vague and not critical for agent invocation.
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 front-loaded with the main purpose in the first sentence. The second sentence adds necessary detail about the return, and the third provides a minor instruction. It is efficient with minimal waste, though the last sentence could be omitted without losing core functionality.
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 0 parameters, no annotations, and no output schema, the description is moderately complete. It explains what the tool does and the return type, but lacks details on the message structure, error handling, or integration with sibling tools. For a simple status check, this is adequate but has gaps in full contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not discuss parameters, which is appropriate. It adds value by explaining the return message, compensating for the lack of output schema, though not fully detailing the message format.
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'), but does not explicitly differentiate it from sibling tools like 'get_polyhaven_status' or 'get_sketchfab_status', which have similar checking functions for other integrations. This makes it clear but not fully distinguished from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools or contexts where this check is necessary, such as before using Hyper3D-related tools like 'generate_hyper3d_model_via_text'. Without explicit when-to-use or exclusion criteria, 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 the full burden of behavioral disclosure. It mentions the return type ('Returns the screenshot as an Image') but lacks critical details: whether this is a read-only operation, if it requires specific Blender state or permissions, potential performance impacts, or error conditions (e.g., if no viewport is active).
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 structured parameter explanation and return statement. Every sentence adds value without redundancy, making it efficient and easy to parse for an agent.
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 tool with one parameter and no output schema, the description covers the basics adequately. However, given the lack of annotations and the tool's dependency on Blender's state, it should ideally mention prerequisites or limitations to be fully complete for safe 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?
The schema description coverage is 0%, so the description must compensate. It documents the single parameter 'max_size' with its purpose ('Maximum size in pixels for the largest dimension') and default value (800), adding meaningful context beyond the schema's basic type and title. However, it doesn't explain constraints like minimum/maximum values or how scaling affects quality.
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 the target resource ('current Blender 3D viewport'), using a precise verb+resource combination. It distinguishes itself from sibling tools like 'get_scene_info' or 'get_object_info' by focusing on visual capture rather than data retrieval.
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., requiring Blender to be running), exclusions, or comparisons to similar tools, leaving the agent to infer usage context solely from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool imports an asset and returns success status, but lacks details on behavioral traits like required permissions, error handling, rate limits, or what 'import' entails (e.g., adding to a scene, file storage). For a mutation tool 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, starting with the core purpose. The parameter explanations are bulleted for clarity, and the warning about using only one ID is concise. However, the final sentence 'Return if the asset has been imported successfully' is slightly redundant with the purpose, and the structure could be more streamlined by integrating the return statement earlier.
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 mutation tool with 3 parameters, 0% schema coverage, no output schema, and no annotations), the description is moderately complete. It covers the purpose, parameter usage, and return indication, but lacks details on behavioral aspects like error cases, what 'import' means operationally, or output format. This leaves gaps for an AI agent to invoke it correctly without additional 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 adds meaningful context: 'name' is explained as 'The name of the object in scene', and it clarifies that 'task_uuid' and 'request_id' correspond to different Hyper3D Rodin modes (MAIN_SITE vs. FAL_AI), with a rule to use only one. This provides crucial semantics beyond the bare schema, though it doesn't detail formats or constraints for the 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 action ('Import') and the resource ('asset generated by Hyper3D Rodin'), making the purpose understandable. It distinguishes from siblings by specifying it handles assets from Hyper3D Rodin generation tasks, unlike download tools for external sources. However, it doesn't explicitly contrast with all siblings like 'set_texture' or 'execute_blender_code', preventing 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: after a Hyper3D Rodin generation task is completed. It also specifies to use only one of {task_uuid, request_id} based on the Hyper3D Rodin Mode, offering guidance on parameter selection. However, it doesn't explicitly state when not to use it or name alternatives among siblings, such as distinguishing from 'download_polyhaven_asset' for external assets.
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 mentions the tool downloads and imports, implying mutation/write operations, but doesn't specify authentication needs, rate limits, file system impacts, or what 'import into Blender' entails (e.g., whether it opens a new file or modifies current scene).
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 efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence earns its place, though the 'Returns' statement could be integrated more smoothly. It's appropriately sized for a 4-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers purpose and parameters well but lacks behavioral context about what the import actually does in Blender, error conditions, or output details beyond success/failure message. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic meaning for all 4 parameters: asset_id identifies the asset, asset_type categorizes it, resolution specifies download quality, and file_format offers optional format choices with examples. This adds substantial value 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 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 from other sources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to obtain a Polyhaven asset for Blender, but doesn't explicitly state when to use this vs alternatives like 'download_sketchfab_model' or 'import_generated_asset'. No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a message about feature availability, which is basic behavioral info. However, it lacks details on permissions, rate limits, or error handling, leaving gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: two sentences with zero waste. The first sentence states the purpose, and the second explains the return value, 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 simplicity (0 params, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose and return type, but for a status-check tool, it could benefit from more context on what 'enabled' entails or example outputs, though not strictly required.
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 info is needed. The description doesn't add param details, but this is appropriate given the lack of parameters, meeting the baseline for such cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if Sketchfab integration is enabled in Blender' specifies the verb (check) and resource (Sketchfab integration in Blender). It distinguishes from siblings like get_hyper3d_status by focusing on Sketchfab specifically, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context—checking Sketchfab availability—but doesn't provide explicit guidance on when to use this vs. alternatives like get_hyper3d_status or get_polyhaven_status. No exclusions or prerequisites are mentioned, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that the texture 'must be downloaded first' (a prerequisite) and that it 'Returns a message indicating success or failure' (basic outcome). However, it lacks details on permissions needed, whether the operation is destructive (e.g., overwrites existing textures), error conditions (e.g., invalid object_name), or side effects. For a mutation 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a clear parameter list and return statement. Every sentence earns its place with no redundancy or fluff, making it easy to scan 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?
Given 2 parameters with 0% schema coverage and no output schema, the description covers the basics: purpose, parameters, and return type. However, as a mutation tool with no annotations, it lacks details on behavioral traits (e.g., idempotency, error handling) and doesn't fully compensate for the missing output schema (e.g., what the success/failure message contains). It's adequate but has clear gaps for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains both parameters: '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)'. This adds meaning beyond the schema's bare titles, clarifying purpose and constraints. However, it doesn't specify format (e.g., string patterns) or examples.
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 target ('a previously downloaded Polyhaven texture to an object'), specifying both the resource (texture) and target (object). It distinguishes from siblings like 'download_polyhaven_asset' by focusing on application rather than acquisition. However, it doesn't explicitly differentiate from other texture-related tools that might exist in broader contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'must be downloaded first' indicates a prerequisite, and the mention of 'Polyhaven texture' suggests it's specific to that source. It implicitly distinguishes from siblings like 'download_polyhaven_asset' (which acquires textures) and 'get_object_info' (which inspects objects). However, it doesn't explicitly state when NOT to use it or name alternatives for similar operations.
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 3D assets with built-in materials, imports them into Blender, produces normalized-sized models requiring potential rescaling, and returns a success/failure message. However, it lacks details on permissions, rate limits, error conditions, or what 'import into Blender' entails operationally.
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 in the first sentence. Additional sentences provide useful context without redundancy. The parameter section is clear but could be more integrated. Minor improvements could enhance flow, but overall it's efficient with zero wasted sentences.
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 0% schema description coverage, the description provides basic context: purpose, parameters, and behavioral notes like normalized size. However, for a tool that generates and imports 3D assets, it lacks details on output format, error handling, Blender integration specifics, or dependencies, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: 'text_prompt' is described as 'A short description of the desired model in **English**,' and 'bbox_condition' as 'Optional... Controls the ratio between [Length, Width, Height] of the model.' This clarifies purpose and constraints beyond the bare schema, though it doesn't fully detail format (e.g., units for bbox_condition).
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: 'Generate 3D asset using Hyper3D by giving description of the desired asset, and import the asset into Blender.' It specifies the verb (generate), resource (3D asset), technology (Hyper3D), and destination (Blender). It distinguishes from sibling tools like 'generate_hyper3d_model_via_images' by specifying text-based generation and from 'import_generated_asset' by combining generation and import.
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 through statements like 'The generated model has a normalized size, so re-scaling after generation can be useful,' which suggests when this tool is appropriate. However, it lacks explicit guidance on when to use this tool versus alternatives like 'generate_hyper3d_model_via_images' or 'download_sketchfab_model,' and does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the 3D asset has built-in materials, the model has normalized size (requiring potential re-scaling), and it returns a success/failure message. However, it omits details like processing time, error handling, Blender integration specifics, or any rate limits/permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, key behavioral notes, and a dedicated parameters section. Each sentence adds value, such as the normalization and re-scaling advice. It could be slightly more concise by integrating the parameters explanation more seamlessly, but overall it's efficient 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?
Given the complexity (3D generation, Blender import), no annotations, and no output schema, the description is moderately complete. It covers parameters well and mentions critical behaviors like built-in materials and normalized size. However, it lacks details on the return message format, error conditions, or integration with sibling tools like 'import_generated_asset' or 'poll_rodin_job_status'.
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 compensates fully by explaining all three parameters. It clarifies that input_image_paths and input_image_urls are mutually exclusive based on Hyper3D Rodin mode, specifies they must be lists even for single images, and details bbox_condition as an optional list of 3 ints controlling [Length, Width, Height] ratio. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate 3D asset using Hyper3D by giving images of the wanted asset, and import the generated asset into Blender.' It specifies the verb (generate), resource (3D asset), and destination (Blender). However, it doesn't explicitly differentiate from its sibling 'generate_hyper3d_model_via_text' beyond the input type, missing a direct comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: for generating 3D assets from images via Hyper3D and importing to Blender. It mentions the dependency on Hyper3D Rodin's mode (MAIN_SITE vs. FAL_AI) to choose between input_image_paths and input_image_urls. However, it lacks explicit guidance on when to use this vs. 'generate_hyper3d_model_via_text' or other 3D asset tools like 'download_polyhaven_asset'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool as a polling API, explains what constitutes completion ('Done' or 'COMPLETED'), failure conditions ('Failed' or other statuses), and provides mode-specific behavioral details. It doesn't mention rate limits or authentication needs, but covers core 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 well-structured with clear sections for different modes, but could be more concise. Each sentence earns its place by providing essential information about parameters, returns, and usage guidance. The front-loaded purpose statement is clear, though the detailed mode explanations add length.
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 of supporting two different modes with different parameters and status interpretations, and with no output schema, the description provides substantial context about return values and status interpretation. It explains what constitutes completion, failure, and intermediate states for both modes. Some details like exact response format or error handling could be more explicit.
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 for 2 parameters, the description fully compensates by explaining both parameters in detail: 'subscription_key: The subscription_key given in the generate model step' and 'request_id: The request_id given in the generate model step.' It clearly maps each parameter to specific modes and provides essential context about their origin.
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 jobs.
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.
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-claude MCP server](https://glama.ai/mcp/servers/diegofornalha/blender-mcp-claude/badges/card.svg)](https://glama.ai/mcp/servers/diegofornalha/blender-mcp-claude)

Score Badge

Copy to your README.md:

[![blender-mcp-claude MCP server](https://glama.ai/mcp/servers/diegofornalha/blender-mcp-claude/badges/score.svg)](https://glama.ai/mcp/servers/diegofornalha/blender-mcp-claude)

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/diegofornalha/blender-mcp-claude'

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