Tripo MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is some overlap between create_object and modify_object (both handle object properties), and between the Polyhaven tools (download, search, get_categories, get_status) which could be confusing for agents. The Tripo model generation tools (create_3d_model_from_image and create_3d_model_from_text) are clearly distinct, and the Blender scene management tools (get_scene_info, get_object_info, delete_object) are well-defined.
Naming Consistency4/5
The tool names follow a consistent verb_noun pattern throughout (e.g., create_3d_model_from_image, get_task_status, modify_object). All tools use snake_case, and the verbs are generally clear (create, get, delete, execute, import, set, etc.). There are no major deviations in naming conventions, making the set predictable and readable.
Tool Count4/5
With 16 tools, the count is reasonable for a server that integrates 3D model generation (Tripo API) and Blender scene management. It covers multiple workflows (model creation, object manipulation, asset import, material/texture handling), but it might feel slightly heavy due to the breadth of functionalities. However, each tool appears to serve a specific purpose, so the count is appropriate for the scope.
Completeness4/5
The server provides good coverage for 3D modeling workflows: it supports model creation from images/text (with status checking), Blender object CRUD operations (create, modify, delete, get info), asset import/download (Polyhaven and Tripo models), and material/texture application. Minor gaps include no direct tool for updating materials or textures beyond initial setting, and no explicit tool for scene clearing or batch operations, but agents can work around these with existing tools.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 12, 2025
- 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 but lacks critical details: it doesn't specify security implications, execution environment constraints, error handling, or output behavior. For a tool executing 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 appropriately sized with two sentences: one stating the purpose and another listing the parameter. It's front-loaded and avoids unnecessary details, though the parameter listing could be integrated more seamlessly for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing arbitrary code, the lack of annotations, and the presence of an output schema (which handles return values), the description is minimally adequate. It covers the basic action but misses critical context like safety warnings or execution scope, making it incomplete for high-risk operations.
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 'code' parameter and stating it's 'Python code to execute', but with 0% schema description coverage and only one parameter, this provides basic context. It doesn't elaborate on code format, Blender API usage, or examples, keeping it at the baseline for a single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'execute' and the resource 'arbitrary Python code in Blender', making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'modify_object' or 'create_object' which might also involve code execution in different contexts, 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, limitations, or compare it to sibling tools like 'modify_object' that might handle specific object modifications, 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 full burden. It states 'modify an existing object,' implying mutation, but lacks critical behavioral details: whether changes are reversible, what permissions are needed, how errors are handled (e.g., if object doesn't exist), or if there are rate limits. 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: the first sentence states the purpose clearly, followed by a bulleted list of parameters. There's no wasted text, but the structure could be slightly improved by integrating parameter details more seamlessly rather than as a separate list.
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 5 parameters with 0% schema coverage and no annotations, the description is moderately complete: it covers the purpose and parameters. However, as a mutation tool, it lacks behavioral context (e.g., side effects, error handling). The presence of an output schema (not shown) reduces the need to explain return values, but overall completeness is adequate with clear gaps.
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 all 5 parameters with brief explanations (e.g., 'Optional [x, y, z] location coordinates'), adding basic semantics beyond the schema's titles. However, it doesn't clarify units (e.g., radians for rotation), constraints (e.g., array length must be 3), or interactions between parameters, leaving gaps in understanding.
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 'modify' and resource 'existing object in the Blender scene,' making the purpose immediately understandable. It distinguishes from siblings like 'create_object' and 'delete_object' by specifying modification rather than creation or deletion. However, it doesn't explicitly differentiate from tools like 'set_material' or 'set_texture' that might also modify objects in different ways.
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., object must exist), exclusions (e.g., not for creating new objects), or comparisons to siblings like 'set_material' for material changes. The agent must infer usage from the name and parameter list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'set or create' but doesn't clarify if this is a read-only or destructive operation, what permissions are needed, or how errors are handled. The description is minimal and misses key behavioral traits like side effects or response format.
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, with a clear purpose statement followed by a bulleted parameter list. Every sentence adds value, and there's no redundant information. It could be slightly improved by front-loading more context, but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, but has an output schema), the description is minimally adequate. It covers the basic action and parameters but lacks completeness in usage guidelines, behavioral details, and integration with sibling tools. The output schema helps, but the description should do more to compensate for missing annotations.
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 lists parameters with brief explanations, adding some meaning beyond the input schema, which has 0% description coverage. It clarifies 'object_name' as the target, 'material_name' as optional for use or creation, and 'color' as RGB values. However, it doesn't fully compensate for the schema gap, lacking details on defaults or interactions between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set or create a material for an object.' It specifies the verb ('set or create'), resource ('material'), and target ('object'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'set_texture' or 'modify_object', which might handle similar operations.
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. The description lacks context about prerequisites, such as whether the object must exist, or when to choose this over tools like 'set_texture' or 'modify_object'. It only lists parameters without explaining usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information' but doesn't specify what that includes (e.g., properties, location, materials), whether it's read-only, potential errors, or performance characteristics. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that directly address purpose and parameters. It's front-loaded with the main purpose and avoids unnecessary fluff, though the parameter explanation could be slightly more integrated rather than listed separately.
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 has an output schema (which handles return values), the description covers the basic purpose and parameter. However, for a tool with no annotations and moderate complexity (interacting with a 3D scene), it lacks details on error conditions, what 'detailed information' entails, or how it differs from siblings, leaving room for improvement.
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 'object_name' by explaining it's 'The name of the object to get information about'. Since schema description coverage is 0% and there's only one parameter, this adequately compensates, though it doesn't elaborate on format constraints 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 verb ('Get detailed information') and resource ('about a specific object in the Blender scene'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_scene_info' or 'get_task_status', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, compare with similar tools like 'get_scene_info', or specify scenarios where this tool is appropriate versus others in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this creates a new object but doesn't cover important aspects like whether this requires specific permissions, if it's destructive to existing scene elements, what happens on failure, or typical response behavior. The description is minimal beyond the basic action.
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 structured and concise. It starts with the core purpose in one sentence, then provides a clean bulleted list of parameters with clear explanations. Every sentence earns its place with no wasted words.
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 that there's an output schema (which handles return values), no annotations, and 5 parameters with good description coverage, the description is reasonably complete for the basic operation. However, for a creation tool in a 3D modeling context, it could benefit from mentioning typical use cases, limitations, or integration with other tools.
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 excellent parameter semantics that compensate for the 0% schema description coverage. It clearly explains what each parameter represents (object type with specific enum values, optional name, location coordinates, rotation in radians, scale factors), adding substantial 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 verb ('Create') and resource ('new object in the Blender scene'), making the purpose immediately understandable. However, it doesn't distinguish this tool from siblings like 'create_3d_model_from_image' or 'create_3d_model_from_text', which also create objects but through different methods.
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 siblings like 'create_3d_model_from_image' (for creating from images) or 'modify_object' (for editing existing objects), leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose critical behavioral traits such as whether deletion is permanent, requires specific permissions, affects scene hierarchy, or has side effects like removing associated materials. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one stating the purpose and another listing parameters. It's front-loaded with the core action and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and presence of an output schema (which might cover return values), the description is minimally adequate. It covers the basic action and parameter but misses important context like safety warnings or usage scenarios, leaving gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter by specifying it's the 'Name of the object to delete', which clarifies its role beyond the schema's generic 'Name' title. With 0% schema description coverage and only one parameter, this compensates well, though it doesn't detail format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('object from the Blender scene'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'modify_object' or 'create_object' beyond the verb, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'modify_object' or 'create_object', nor any prerequisites or exclusions. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Get a list of categories', implying a read-only operation, but doesn't cover aspects like rate limits, authentication needs, error handling, or what the output looks like. 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 section. Every sentence earns its place by providing essential information without redundancy, making it efficiently structured and appropriately sized.
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) and the presence of an output schema, the description is somewhat complete. It covers the purpose and parameter semantics adequately, but with no annotations and missing behavioral details like error cases or usage context, it has clear gaps that prevent a higher score.
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 allowed values (hdris, textures, models, all), which is not covered in the input schema (0% schema description coverage). This compensates well for the schema gap, though it doesn't explain the semantics of 'all' or default behavior, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'list of categories for a specific asset type on Polyhaven', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_polyhaven_assets' or 'get_polyhaven_status', which might also involve Polyhaven data retrieval, so it doesn't reach the highest 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, context for selecting asset types, or compare it to sibling tools like 'search_polyhaven_assets', leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a message about feature availability, which implies a read-only operation, but doesn't clarify if it requires specific permissions, has side effects, or details the message format. For a status-checking tool, this is a minimal but incomplete 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 extremely concise and front-loaded, using two sentences that directly state the action and outcome without any fluff. Every sentence earns its place by contributing essential information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, simple status check), the description is adequate but has gaps. It lacks usage guidelines and behavioral details, though the presence of an output schema means it doesn't need to explain return values. For a basic tool, this is minimally viable but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's function. This meets the baseline for tools with no parameters, as it avoids unnecessary detail.
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 with a specific verb ('Check') and resource ('PolyHaven integration in Blender'), and distinguishes it from siblings by focusing on status checking rather than asset operations like 'download_polyhaven_asset' or 'search_polyhaven_assets'. However, it doesn't explicitly differentiate from other status-checking tools like 'get_task_status', which slightly reduces specificity.
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), context for checking integration status, or when to choose this over other tools like 'get_task_status' for monitoring. This leaves usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Get') but doesn't specify what 'detailed information' includes, whether it requires specific scene states, or how it handles errors. This leaves significant behavioral aspects undocumented.
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 immediately conveys the core purpose without any wasted words. It's perfectly front-loaded and appropriately sized for a zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists, the description doesn't need to explain parameters or return values. However, as a read operation with no annotations, it should provide more context about what 'detailed information' encompasses and any scene requirements, leaving some completeness gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score since 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 action ('Get detailed information') and target resource ('about the current Blender scene'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_object_info' or 'get_polyhaven_status', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_object_info' for object-specific details or 'get_polyhaven_status' for external asset status. There's no mention of prerequisites, timing, or contextual constraints for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Import') and return type ('Result message'), but lacks details on permissions, side effects (e.g., scene modification), error handling, or operational constraints like rate limits. This is inadequate for a mutation 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 clear sections for parameters and returns. It uses minimal sentences with zero waste, 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?
Given the tool's complexity (a mutation with 1 parameter), no annotations, and an output schema (which covers return values), the description is partially complete. It explains the purpose and parameter but lacks behavioral context like side effects or usage guidelines, leaving gaps that could hinder agent 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 explicitly lists the parameter 'glb_url' and explains it as 'Download URL of the GLB model file', adding meaningful context beyond the schema's basic title. With 0% schema description coverage and only 1 parameter, this compensates well, though it could specify URL format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Import') and resource ('GLB model from URL into Blender scene'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_3d_model_from_image' or 'download_polyhaven_asset', which might also involve 3D model handling, so it misses full sibling 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. It doesn't mention prerequisites, context (e.g., when importing vs. creating models), or exclusions, leaving the agent to 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?
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 pagination, rate limits, authentication needs, or error handling. This is insufficient for a search tool with no annotation coverage, resulting in a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with three sentences that efficiently cover purpose, parameters, and returns. Each sentence adds value without redundancy, and it is front-loaded with the core functionality. There is no wasted text, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters adequately, and the output schema likely handles return values, reducing the need for detailed output explanation. However, it lacks behavioral context and usage guidelines, leaving gaps in overall 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 context: 'asset_type' is explained with allowed values (hdris, textures, models, all), and 'categories' is described as an 'optional comma-separated list.' This clarifies parameter usage beyond the schema's basic titles, though it could provide more detail on category formats 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 tool's purpose: 'Search for assets on Polyhaven with optional filtering.' It specifies the verb ('search'), resource ('assets on Polyhaven'), and scope ('with optional filtering'). However, it does not explicitly differentiate from sibling tools like 'download_polyhaven_asset' or 'get_polyhaven_categories', which reduces 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. For example, it does not clarify if this should be used before downloading assets or as an alternative to browsing categories directly, 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?
No annotations are provided, so the description carries full burden. It mentions 'Apply' (implying mutation) and a prerequisite ('must be downloaded first'), but doesn't disclose behavioral traits like permissions needed, whether changes are reversible, error handling, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, parameters, and return value. It's front-loaded with the main action, and each sentence adds value (e.g., the parameter list clarifies inputs). Minor room for improvement in flow, but overall efficient.
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 2 parameters, no annotations, and an output schema (implied by 'Returns a message'), the description is fairly complete: it covers purpose, parameters with semantics, and return indication. However, it could better address behavioral aspects like error cases or integration with sibling tools, keeping it from a 5.
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 explaining 'object_name' as 'Name of the object to apply the texture to' and 'texture_id' as 'ID of the Polyhaven texture to apply (must be downloaded first)', which clarifies purpose and constraints. However, it doesn't detail format or examples, leaving some ambiguity.
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'), distinguishing it from siblings like 'set_material' or 'modify_object' by specifying texture application. However, it doesn't explicitly differentiate from all siblings (e.g., 'modify_object' might also handle textures), keeping it at 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by noting the texture 'must be downloaded first' (referencing 'download_polyhaven_asset'), but it doesn't explicitly state when to use this tool versus alternatives like 'set_material' or provide exclusions. This gives some context but lacks clear guidance on tool selection.
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 operation (download and import) and return value (success/failure message), but doesn't cover important behavioral aspects like whether this requires internet connectivity, what happens if the asset already exists, potential file size implications, or any rate limits. For a tool with no annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It starts with a clear purpose statement, then provides a bulleted list of parameters with helpful explanations, and ends with return value information. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), 4 parameters with excellent description coverage, and no annotations, the description is quite complete. It explains what the tool does, all parameters meaningfully, and mentions the return type. The main gap is insufficient behavioral context for a download/import operation with no annotation coverage.
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 provides excellent parameter semantics beyond the 0% schema description coverage. It clearly explains each parameter's purpose: asset_id identifies the specific asset, asset_type categorizes it, resolution specifies download quality, and file_format offers format options with examples for each asset type. 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.
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 target resource ('Polyhaven asset'), and the destination environment ('into Blender'). It distinguishes this tool from siblings like search_polyhaven_assets or import_tripo_glb_model by specifying the download+import operation for Polyhaven assets specifically.
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 Polyhaven assets for Blender, but doesn't explicitly state when to use this versus alternatives like import_tripo_glb_model or when not to use it (e.g., for non-Polyhaven assets). It provides some context but lacks explicit guidance on alternatives or prerequisites.
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 asynchronous nature of the operation, the need for polling with another tool, and the expected workflow. It doesn't mention rate limits, authentication requirements, or error handling specifics, but provides substantial behavioral context beyond basic 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 and well-structured with clear sections. The workflow steps are numbered for clarity. While comprehensive, some information could be more concise, such as the detailed workflow that spans multiple sentences. Overall, most content earns its place in helping the agent understand the tool's usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (asynchronous operation requiring polling), no annotations, and the presence of an output schema, the description provides excellent contextual completeness. It explains the asynchronous nature, the required follow-up actions, the return value usage, and references the output schema's content. This adequately compensates for the lack of annotations.
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 for the lack of parameter documentation. It provides clear explanations for all 3 parameters mentioned (image, face_limit, auto_size), though the input schema only shows 2 parameters (missing auto_size). The description adds meaningful context about what each parameter controls, though there's a parameter mismatch between description and 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 ('Create a 3D model from an image') and identifies the resource ('using the Tripo API'). It distinguishes from sibling tools like 'create_3d_model_from_text' by specifying the image input source, and from 'import_tripo_glb_model' by indicating generation rather than import.
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 ('initiates a 3D model generation task') and when not to use it ('does NOT wait for completion'). It clearly names the alternative tool ('get_task_status') that must be used in conjunction and provides a detailed 6-step workflow for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job explaining the asynchronous behavior, workflow requirements, and expected response structure. It discloses that this is an initiation tool requiring follow-up calls, describes the polling pattern, and explains how to access the final result via pbr_model_url.
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 structured with clear sections: purpose statement, important behavioral note, numbered workflow steps, and parameter/return explanations. Every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (asynchronous operation requiring workflow coordination) and the presence of an output schema, the description provides complete context. It explains the asynchronous nature, the required follow-up workflow with sibling tools, parameter meanings, and what to expect in responses - covering everything an agent needs to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining all 3 parameters mentioned in the Args section. It clarifies what 'describe_the_look_of_object' should contain, what 'face_limit' controls, and what 'auto_size' does. However, the input schema only shows 2 parameters, creating a minor discrepancy with the description mentioning 3.
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 ('Create a 3D model from a text description') and identifies the resource ('using the Tripo API'). It distinguishes this tool from siblings like 'create_3d_model_from_image' by specifying it works 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow instructions with numbered steps, including when to use this tool (to initiate generation) and when to use the sibling 'get_task_status' tool (to check completion). It clearly states this tool doesn't wait for completion and must be followed by status checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 thoroughly explains the polling nature of the tool ('call this tool MULTIPLE TIMES'), status interpretation (SUCCESS, FAILED, etc.), typical response structure (pbr_model_url on success), and failure conditions. This goes well beyond what a basic description would cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections (purpose, important notes, workflow, args, returns). Every sentence adds value: the first states the purpose, the second clarifies dependency, the third explains polling behavior, and the workflow provides actionable steps. No redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (asynchronous task status checking), lack of annotations, and presence of an output schema, the description is highly complete. It covers purpose, usage, behavioral details, parameter semantics, and response interpretation. The output schema handles return structure, so the description appropriately focuses on 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 clearly explains the single parameter (task_id), its purpose ('to check'), and its source ('obtained from create_3d_model_from_text'). However, it doesn't specify the expected format or constraints of task_id (e.g., string pattern, length), leaving a minor gap.
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 ('Get the status') and resource ('a 3D model generation task'), distinguishing it from siblings like create_3d_model_from_text (which starts tasks) and get_object_info (which checks objects). It explicitly mentions the dependency on create_3d_model_from_text, avoiding confusion with other task-related tools.
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 (after create_3d_model_from_text, with the returned task_id) and when to call it repeatedly (until task completion). It outlines a complete workflow with status interpretation and alternatives for different outcomes, clearly differentiating it from other status-checking siblings.
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:

[![tripo-mcp MCP server](https://glama.ai/mcp/servers/VAST-AI-Research/tripo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/VAST-AI-Research/tripo-mcp)

Score Badge

Copy to your README.md:

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

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