BlenderMCP

by drrodingo-del

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as downloading assets from different sources (Polyhaven, Sketchfab), generating models via Hyper3D, and getting scene/object info. However, there is some overlap between 'generate_hyper3d_model_via_images' and 'generate_hyper3d_model_via_text' as both generate Hyper3D assets, which could cause confusion if the user is unsure which input method to use, though their descriptions clarify the difference.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as 'download_polyhaven_asset', 'execute_blender_code', and 'get_scene_info'. There are no deviations in naming conventions, making the set predictable and easy to parse for an agent.
Tool Count4/5
With 17 tools, the count is slightly high but reasonable for a Blender integration server that covers asset downloading, model generation, scene management, and status checks. It feels comprehensive without being overwhelming, though it borders on the upper limit of typical scoping (3-15 tools).
Completeness4/5
The tool surface covers key areas like asset import (Polyhaven, Sketchfab, Hyper3D), scene inspection, and basic operations (e.g., screenshot, code execution). Minor gaps exist, such as no tools for editing or deleting objects in Blender, but agents can work around this using 'execute_blender_code' for custom operations, ensuring core workflows are supported.
Average 3.5/5 across 17 of 17 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is to 'get' information, implying a read-only operation, but doesn't specify permissions, error handling, or output format. This leaves gaps in understanding how the tool behaves beyond its basic function.
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 a brief parameter explanation. Every sentence earns its place without redundancy or unnecessary detail, making it efficient for quick understanding.
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 (single parameter, no annotations, no output schema), the description is incomplete. It doesn't explain what 'detailed information' includes, how errors are handled, or provide examples, which could hinder an AI agent from using it effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics by naming the parameter 'object_name' and stating it's 'the name of the object to get information about'. Since schema description coverage is 0%, this provides some value, but it doesn't explain format constraints, examples, or what constitutes a valid object name in Blender context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific object in the Blender scene', making the purpose explicit. However, it doesn't distinguish from sibling tools like 'get_scene_info' or 'get_viewport_screenshot', which also retrieve information but for 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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this is for object metadata versus scene-wide details (compared to 'get_scene_info') or visual snapshots (compared to 'get_viewport_screenshot'), leaving usage context implied but unspecified.
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 executing 'arbitrary Python code' and suggests a step-by-step approach, but fails to cover critical traits like safety (e.g., potential for destructive operations), permissions, error handling, or output format. This is a significant gap for a tool with such open-ended functionality.
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 one offering usage advice. It's front-loaded with the core function, and the second sentence adds value without redundancy. There's minimal waste, though it could be slightly more structured (e.g., bullet points).
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 high complexity (executing arbitrary code) and lack of annotations or output schema, the description is insufficient. It doesn't address risks, expected outputs, error conditions, or how results are returned, making it incomplete for 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?
Schema description coverage is 0%, so the description must compensate. It lists the single parameter 'code' and explains it as 'The Python code to execute,' adding basic meaning beyond the schema's title 'Code.' However, it doesn't provide details on code format, constraints, or examples, leaving the parameter only partially documented.
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') and resource ('Python code in Blender'), making the function unambiguous. However, it doesn't explicitly differentiate from siblings like 'get_object_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 implied usage guidance by suggesting to 'break it into smaller chunks' for step-by-step execution, which hints at best practices for this tool. However, it lacks explicit when-to-use rules, alternatives (e.g., vs. other Blender tools), or exclusions, leaving the agent to infer context from 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get detailed information' implies a read-only operation, it doesn't specify what information is returned, format, potential errors, or whether this requires Blender to be in a particular state. The description is too vague about the actual 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, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a zero-parameter tool and front-loads the essential information about what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and no parameters, the description should do more to explain what 'detailed information' includes and how this differs from other information-retrieval tools in the sibling set. The current description leaves too many questions unanswered about the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose rather than repeating what's already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and target resource ('about the current Blender scene'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'get_object_info' or 'get_hyper3d_status', but the specificity of 'Blender scene' provides reasonable distinction.
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_object_info' or 'get_hyper3d_status'. It doesn't mention prerequisites, timing considerations, or any context about what 'current' means in relation to Blender's state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] a list of categories,' implying a read-only operation, but does not detail aspects like whether it requires authentication, rate limits, error handling, or the format of the returned list. For a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement followed by a bullet point for parameters. Every sentence earns its place by directly contributing to understanding the tool's function and inputs, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally complete. It explains what the tool does and the parameter options, but lacks details on behavioral traits (e.g., response format, errors) and usage context. This is adequate for a simple read operation but leaves gaps that could hinder effective 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 adds meaningful context for the single parameter 'asset_type' by listing its possible values (hdris, textures, models, all), which the input schema does not provide (schema description coverage is 0%). This compensates for the schema's lack of detail, giving the agent clear guidance on valid inputs. Since there is only one parameter, the description adequately covers its semantics.
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 scope ('for a specific asset type on Polyhaven'), making the intent unambiguous. However, it does not explicitly differentiate this tool from its sibling 'search_polyhaven_assets', which might also involve categories, 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 mentions the parameter 'asset_type' but does not explain why or when to call this tool, such as for filtering assets by category before searching or downloading. With multiple sibling tools like 'search_polyhaven_assets' and 'download_polyhaven_asset', the absence of usage context leaves the agent without clear 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 of behavioral disclosure. It mentions 'Returns a list of matching assets with basic information,' which hints at read-only behavior and output format, but lacks details on rate limits, authentication needs, pagination, or error handling. For a search 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 clear parameter explanations and return information in a structured format. 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.
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 (2 parameters, no output schema, no annotations), the description covers the basic purpose and parameters adequately but lacks depth in usage guidelines, behavioral traits, and output details. It is minimally viable but has clear gaps in providing a complete context for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'asset_type' includes options like 'hdris, textures, models, all' and 'categories' is an 'optional comma-separated list,' clarifying usage that the schema alone does not provide. With only 2 parameters, 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 tool's purpose as 'Search for assets on Polyhaven with optional filtering,' which is a specific verb (search) and resource (assets on Polyhaven). However, it does not explicitly distinguish itself from sibling tools like 'search_sketchfab_models' or 'get_polyhaven_categories,' which limits the score from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions optional filtering but does not specify scenarios, prerequisites, or exclusions, such as when to prefer 'search_sketchfab_models' for models or 'get_polyhaven_categories' for category lists. This lack of contextual direction results in a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 as a status check that returns a message about feature availability, which is adequate for a read-only operation. However, it doesn't mention potential errors (e.g., if Blender isn't accessible), performance considerations, or authentication needs. The note about 'Don't emphasize the key type in the returned message' adds some behavioral context but is vague.
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 with three sentences, each serving a purpose: stating the tool's function, describing the return, and adding a behavioral note. It's front-loaded with the core purpose. The last sentence is somewhat cryptic but not wasteful. Minor improvements could clarify the behavioral note.
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 mostly complete for a simple status check. It explains what the tool does and what it returns. However, without an output schema, it doesn't detail the return format (e.g., structured data vs. plain text), and the behavioral note is unclear, leaving gaps in understanding the tool's full behavior.
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 function. This meets the baseline for tools with no parameters, as it avoids 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 Hyper3D Rodin integration is enabled in Blender.' This specifies the verb ('Check') and resource ('Hyper3D Rodin integration'), and distinguishes it from siblings like 'get_polyhaven_status' or 'get_sketchfab_status' by focusing on Hyper3D Rodin. However, it doesn't explicitly differentiate from other status-checking tools beyond naming the specific integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
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), exclusions, or comparisons to other status-checking tools like 'get_polyhaven_status'. The only implied usage is to verify Hyper3D Rodin availability, but this is basic and lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'returns a message indicating whether PolyHaven features are available,' which describes output behavior. However, it lacks details on error handling, performance characteristics (e.g., speed), or whether it requires specific Blender configurations. For a tool with zero annotation coverage, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the purpose, and the second explains the return value. It's appropriately sized and front-loaded, with every sentence earning its place by adding essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but has gaps. It explains what the tool does and what it returns, but lacks details on the return format (e.g., structured data vs. plain text) or error conditions. For a status-check tool, this is minimally viable but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to explain parameters, so it appropriately focuses on the tool's purpose and output. No parameter information is missing or needed, meeting the baseline for zero-parameter tools.
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' specifies the verb ('check') and resource ('PolyHaven integration in Blender'). It distinguishes from siblings like 'get_hyper3d_status' or 'get_sketchfab_status' by focusing on PolyHaven specifically. However, it doesn't explicitly differentiate from 'get_polyhaven_categories' which also checks PolyHaven status but for categories.
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: it's for checking PolyHaven availability before using related features. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_hyper3d_status' for other integrations, or provide prerequisites (e.g., use before 'download_polyhaven_asset'). The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action and return type ('Returns the screenshot as an Image'). It misses critical behavioral details: whether it captures the active viewport only, if it requires specific Blender modes, potential performance impacts, or error conditions (e.g., no viewport open).
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 concise parameter explanation and return statement. Every sentence adds value without waste, and the structure is logical and efficient for quick understanding.
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 (interacting with Blender's viewport) and lack of annotations or output schema, the description is incomplete. It omits details like image format, handling of multiple viewports, or error responses, which are essential for an AI agent to use it correctly 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?
Schema description coverage is 0%, but the description compensates by explaining the single parameter's purpose ('Maximum size in pixels for the largest dimension') and default value, adding meaningful context beyond the schema's basic type and title. Since there's only one parameter, this is sufficient for clarity.
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 sibling tools that handle downloads, code execution, model generation, or scene queries. It precisely defines what the tool does without redundancy.
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, such as whether it's for debugging, documentation, or preview purposes. It lacks context about prerequisites (e.g., Blender must be running) or exclusions, leaving usage unclear beyond the basic action.
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 it 'Returns a formatted list of matching models,' which gives basic output information, but lacks details on rate limits, authentication needs, pagination, error handling, or what 'formatted list' entails (e.g., structure, fields included). This is insufficient for a search tool with potential API constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a bulleted list of parameters with concise explanations, and ends with the return statement. Every sentence earns its place with no wasted words, 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 no annotations and no output schema, the description covers parameters well but lacks behavioral context (e.g., rate limits, auth) and detailed output information. It's adequate for a basic search tool but incomplete for robust agent use, as it doesn't fully address the complexity of interacting with an external API like Sketchfab.
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?
The schema description coverage is 0%, so the description must fully compensate. It provides clear semantics for all 4 parameters: query (text to search for), categories (optional comma-separated list), count (maximum results with default 20), and downloadable (boolean filter with default True). This adds essential meaning beyond the bare schema, effectively documenting each parameter's purpose and defaults.
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 'Search' and resource 'models on Sketchfab' with the purpose of finding models with optional filtering. It distinguishes from siblings like download_sketchfab_model (which retrieves specific models) and search_polyhaven_assets (which searches a different platform), though it doesn't explicitly contrast with these 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 like search_polyhaven_assets or download_sketchfab_model. It mentions optional filtering but doesn't specify scenarios where this search is preferred over other search or retrieval tools in the sibling set.
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 full burden. It discloses that the model must be downloadable and requires proper access rights, which are useful behavioral constraints. However, it lacks details on what 'import' entails (e.g., file format, destination), potential side effects, or error handling, 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 with three sentences: purpose, parameters, and behavioral notes. It's front-loaded with the core action and wastes no words, though the parameter explanation could be slightly more integrated rather than bulleted for optimal 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 a single parameter, the description is minimally adequate. It covers the basic purpose and constraints but lacks details on return values (only mentions 'message'), import specifics, or error cases, which are important for a download/import operation.
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 meaning by explaining that 'uid' is 'The unique identifier of the Sketchfab model', which clarifies the parameter's purpose beyond the schema's generic string type. Since there's only one parameter, this is sufficient for a high score, though not exhaustive.
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 resource ('a Sketchfab model by its UID'), distinguishing it from siblings like 'search_sketchfab_models' or 'get_sketchfab_status'. However, it doesn't explicitly differentiate from 'import_generated_asset' or specify the import destination, 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 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 need to download/import it, but provides no explicit guidance on when to use this versus alternatives like 'import_generated_asset' or prerequisites beyond access rights. It mentions access requirements but lacks context on alternatives 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context: the 3D asset has built-in materials, the model has normalized size (suggesting rescaling may be needed), and it returns a success/failure message. However, it lacks details on permissions, rate limits, error conditions, or what 'import into Blender' entails operationally. The description compensates partially but leaves 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 functionality. Each sentence adds useful information: generation method, material properties, sizing note, parameter details, and return value. There's minimal waste, though the parameter section could be integrated more seamlessly. Overall, it's 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 complexity (a generative 3D modeling tool with 2 parameters, no annotations, and no output schema), the description is moderately complete. It covers the basic operation, parameters, and return message, but lacks details on behavioral aspects like error handling, Blender integration specifics, or performance expectations. For a tool with no structured metadata, it provides a foundation but leaves room for more 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 provides meaningful semantics for both parameters: '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.' With 0% schema description coverage, this adds significant value beyond the bare schema, clarifying purpose and constraints, though it doesn't specify exact formats or units for the bbox_condition 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: '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), and method (via text prompt), though it doesn't explicitly differentiate from its sibling 'generate_hyper3d_model_via_images' beyond the input method. The mention of importing into Blender adds useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the tool generates 3D assets from text prompts and imports them into Blender, suggesting it's for text-to-3D generation workflows. However, it doesn't explicitly say when to use this tool versus alternatives like 'generate_hyper3d_model_via_images' or 'download_polyhaven_asset', nor does it provide exclusions or prerequisites. The guidance is contextual 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?
No annotations are provided, so the description carries full burden. It mentions the tool downloads and imports, implying mutation/write operations, but doesn't disclose behavioral traits like required permissions, whether it overwrites existing files, network dependencies, error handling, or what 'import into Blender' entails operationally. The return message mention is minimal.
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 with brief explanations. Every sentence earns its place with no redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and no output schema, the description covers purpose and parameters adequately but lacks behavioral context (e.g., side effects, error cases) and detailed return value explanation beyond 'success or failure message'. For a tool that performs downloads and imports, more operational transparency would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining all 4 parameters: asset_id (ID to download), asset_type (type like hdris), resolution (e.g., 1k), and file_format (optional, with format examples per type). It adds meaning beyond the bare schema titles, though it doesn't specify allowed values or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download and import'), the resource ('Polyhaven asset'), and the target environment ('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 needing to obtain and use Polyhaven assets in Blender, but doesn't explicitly state when to use this vs. alternatives like 'download_sketchfab_model' for different asset sources or 'import_generated_asset' for already-downloaded assets. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 generated model has built-in materials, normalized size (requiring potential rescaling), and returns a success/failure message. However, it misses important details like required permissions, processing time, rate limits, or what specific failure conditions might be.
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: purpose statement, parameter explanations, and return value. Most sentences earn their place by providing essential information. However, the first paragraph could be more front-loaded, and some phrasing ('The generated model has a normalized size') is slightly redundant with the rescaling note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3D generation with multiple modes), no annotations, and no output schema, the description provides adequate basics but has gaps. It covers parameters well and mentions the Blender import, but doesn't explain the Hyper3D Rodin modes further, what 'built-in materials' entail, or details about the success/failure message format.
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?
The description adds significant semantic value beyond the 0% schema coverage. It explains that input_image_paths requires absolute paths and is for MAIN_SITE mode, while input_image_urls is for FAL_AI mode, clarifies that even single images must be wrapped in lists, and describes bbox_condition as controlling the [Length, Width, Height] ratio. This fully compensates for the lack of schema descriptions.
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', which creates similar assets but from text input rather than 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 provides some usage context by mentioning Hyper3D Rodin modes (MAIN_SITE vs. FAL_AI) and the exclusive choice between input_image_paths and input_image_urls. However, it lacks explicit guidance on when to use this tool versus alternatives like 'generate_hyper3d_model_via_text' or 'import_generated_asset', and doesn't mention prerequisites or error conditions beyond success/failure messages.
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 full burden. It discloses that the tool imports assets and returns success status, which covers basic behavior. However, it lacks details on potential side effects (e.g., whether it modifies existing scenes), error conditions, authentication needs, or rate limits. The description doesn't contradict annotations (none exist), but it's minimally adequate for a mutation tool without rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with four sentences: purpose statement, parameter explanations, usage rule, and return value. Each sentence adds value without redundancy. It's front-loaded with the core purpose, though the parameter details could be slightly more integrated. There's minimal waste, but the structure is straightforward rather than optimized for rapid comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description does well on parameters and usage but has gaps. It explains what the tool does and how to use parameters, but lacks details on behavioral traits (e.g., idempotency, errors), output format beyond success status, or integration with siblings like 'generate_hyper3d_model_via_text'. For a mutation tool with 3 parameters, it's minimally complete but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so by explaining all three parameters: 'name' as 'The name of the object in scene', 'task_uuid' for MAIN_SITE mode, and 'request_id' for FAL_AI mode. It adds critical semantic context beyond the schema's basic titles, clarifying the mode-dependent usage and exclusivity rule ('Only give one of {task_uuid, request_id}'). This effectively bridges 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 action ('Import') and resource ('asset generated by Hyper3D Rodin'), specifying it's for assets after generation completion. It distinguishes from siblings like 'download_polyhaven_asset' or 'generate_hyper3d_model_via_text' by focusing on importing rather than creating or fetching external assets. However, it doesn't explicitly contrast with all siblings (e.g., 'get_object_info' might retrieve similar data).
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 usage: 'after the generation task is completed' and specifies which parameter to use based on Hyper3D Rodin Mode (MAIN_SITE vs FAL_AI). It explicitly states 'Only give one of {task_uuid, request_id} based on the Hyper3D Rodin Mode!' This offers good guidance but doesn't mention when NOT to use it versus alternatives like 'poll_rodin_job_status' or 'get_hyper3d_status' for checking generation progress.
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 by indicating it returns a message about feature availability, which is useful context. However, it lacks details on potential errors, response format, or operational constraints (e.g., network dependencies), leaving gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and adds output clarification in the second. Both sentences earn their place by providing essential information without waste, making it highly efficient and well-structured.
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 low complexity (0 parameters, no annotations, no output schema), the description is reasonably complete. It explains what the tool does and what it returns, covering the basics. However, it could be more thorough by detailing the message format or integration specifics, slightly reducing 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 information is needed. The description appropriately focuses on the tool's purpose and output without redundant parameter details, earning a high score as it adds value beyond the schema (which is minimal here).
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 ('Check if Sketchfab integration is enabled') and the target resource ('in Blender'), distinguishing it from sibling tools like 'get_hyper3d_status' or 'get_polyhaven_status' which check different integrations. It precisely communicates the tool's function without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'Sketchfab integration in Blender,' suggesting it should be used when needing to verify this specific integration status. However, it does not explicitly state when to use this tool versus alternatives (e.g., other status-checking tools) or provide exclusions, leaving some ambiguity for the agent.
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 this is a mutation operation ('Apply') and mentions a prerequisite (texture must be downloaded first), but doesn't cover other behavioral aspects like error conditions, permissions needed, or what happens if the object doesn't exist. It adds some context but leaves 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 perfectly front-loaded with the core purpose in the first sentence, followed by clear parameter explanations. Every sentence earns its place with no wasted words, and the structure is logical and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides adequate basic information about what the tool does and its parameters. However, it lacks details about return values (only mentions 'message indicating success or failure' without specifics), error handling, or integration with other tools like download_polyhaven_asset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It provides meaningful explanations for both parameters: 'Name of the object to apply the texture to' and 'ID of the Polyhaven texture to apply (must be downloaded first)'. This adds substantial value beyond the bare schema, though it doesn't specify format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Apply a previously downloaded Polyhaven texture') and target resource ('to an object'), distinguishing it from siblings like download_polyhaven_asset or search_polyhaven_assets. It specifies the exact verb and resource combination.
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 stating the texture must be 'downloaded first' and referencing Polyhaven textures, which helps differentiate from other texture-related tools. However, it doesn't explicitly mention when NOT to use this tool or name specific alternatives among 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 of behavioral disclosure. It effectively describes the tool's polling nature, status interpretation rules for both modes, and failure conditions. It explains what the tool returns and how to determine completion/failure, though it doesn't mention rate limits or authentication needs.
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. Each sentence adds value by explaining parameters, return values, and usage rules. While comprehensive, it could be slightly more concise by combining some status interpretation rules.
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 operational modes with different parameters and status interpretations, the description provides substantial context. With no annotations and no output schema, it explains return formats, status meanings, and failure conditions. It could benefit from explicitly mentioning that only one parameter should be used at a time.
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?
The input schema has 0% description coverage, so the description fully compensates by explaining both parameters in context. It clearly defines 'subscription_key' for MAIN_SITE mode and 'request_id' for FAL_AI mode, linking them to previous generation steps and specifying which parameter to use based on the operational mode.
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), distinguishing it from sibling tools like 'get_hyper3d_status' which likely provides different status information.
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 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/drrodingo-del/blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/drrodingo-del/blender-mcp)

Score Badge

Copy to your README.md:

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

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