Thrixel MCP Server

Official

by thrixel

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
All 12 tools have clearly distinct purposes: creation (create vs sculpt), modification (detail vs retexture vs edit vs autofix), optimization (reduce), inspection (inspect, job_status, list_assets), download, and account status. No two tools do the same thing, and descriptions explicitly guide when to use which.
Naming Consistency5/5
Every tool follows the consistent pattern 'thrixel_verb_noun' in snake_case (e.g., thrixel_create_model, thrixel_reduce_triangles). There are no deviations or mixed conventions.
Tool Count5/5
12 tools is well-scoped for a 3D model generation and editing service. Each tool earns its place, covering all major operations without bloat or redundancy.
Completeness4/5
The tool set covers the full lifecycle: creation, detailing, retouching, optimization, inspection, and download. One minor gap is the lack of a delete tool, but assets can be managed elsewhere, and the core workflow is complete.
Average 4.1/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool costs 40 cubes, does not modify geometry, works on any completed model, and allows selective restyling. However, it misses key behaviors: whether the operation is asynchronous (though wait parameter exists), whether it creates a new model or updates in-place, and what happens on failure. These gaps lower the score.
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 efficient: 4 sentences that quickly convey purpose, cost, use case, and parameter tips. It is front-loaded with the main action. However, the sentence about reusing an image could be more direct, and the 'cyberpunk' example is slightly verbose. Still, it wastes very little space.
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 (9 parameters, no annotations, no output schema), the description is far from complete. It does not describe return values, error scenarios, or the role of most parameters. An agent would lack critical information to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 9 parameters with 0% schema description coverage, so the description must explain them. It only explains reference_image_id and apply_to_node_names, leaving 7 other parameters (submission_id, dest, seed, wait, prompt, project_id, texture_size) completely unexplained. This is insufficient for an agent to use the tool correctly without guessing.
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 starts with a clear verb+resource: 'Generate fresh textures for a model without touching its geometry.' It distinguishes itself from siblings like thrixel_create_model or thrixel_sculpt_model by explicitly focusing on retexturing and calling it the 'cheap way to restyle', contrasting with regeneration. This makes the purpose highly specific and distinct.
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 useful guidance: it recommends using this tool for cheap restyling, suggests passing the same reference_image_id for consistency, notes that reusing an image is not recharged, mentions that it works on any completed model, and explains how to restyle only some parts using apply_to_node_names. However, it does not explicitly state when not to use this tool or compare it directly to other siblings like thrixel_edit_model, which would make it a 5.
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 explains the ordering (newest first) and suggests the tool can recover submission_ids, but lacks details on pagination, result limits, or behavior on empty results, which are typical for a list 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 concise, consisting of two efficient sentences that state the core function and key use cases without extra verbiage.
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 and the presence of an output schema (presumably documenting return values), the description is moderately complete. It covers the purpose and use cases but misses parameter explanations and behavioral details like pagination or result limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description does not explain the two parameters (limit and search). It mentions 'submission_id' but does not clarify that search filters by it or other metadata. A brief mention of how these parameters affect results is needed.
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 lists models in the account, newest first, and gives specific use cases like finding an existing asset or recovering a submission_id, distinguishing it from sibling tools like thrixel_create_model or thrixel_job_status.
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 explains when to use the tool: to find and reuse an existing asset or recover a submission_id, providing clear context. However, it does not explicitly state when not to use it or mention alternatives beyond avoiding duplicates.
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?
Describes autonomous self-critique behavior and mentions slowness, but no info on side effects or permissions. With no annotations, description does reasonable job.
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?
Three short, focused sentences; no fluff; effectively front-loaded with purpose.
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?
Missing details on parameters, return values, error conditions, and model mutation behavior. 5 parameters with no explanation is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameter information in description despite 0% schema coverage. Key parameters like submission_id, dest, wait, max_iters, project_id are left unexplained.
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?
Clearly states it runs an automatic refinement pass on a model and distinguishes from sibling tool thrixel_edit_model.
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?
Explicitly tells when to use (model roughly right but can't articulate) and when not to use (use thrixel_edit_model if you can describe the issue).
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 provided, so description carries full burden. It states purpose but does not disclose return behavior, error handling, or polling semantics. Adequate but could be more transparent.
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?
Two succinct sentences, front-loaded with purpose, 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?
Covers core purpose and usage context well; output schema exists to explain return values, so lack of return info is acceptable. Missing parameter description is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage and description adds no meaning to the sole parameter 'submission_id'—does not explain what it is or where to get it.
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?
Description clearly states verb 'check' and resource 'job status', and distinguishes from siblings by noting it's only for jobs with wait=false.
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?
Explicitly specifies when to use (only for jobs with wait=false) and implies when not to use (other tools already wait and return finished asset).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses that the tool regenerates geometry, costs cubes, runs on GPU, and uses a reference image via prompt or ID. It mentions time expectations and that it is not free. However, it does not clarify whether the operation is destructive or idempotent, or what happens to the original model, which could affect agent decision-making.
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 a single well-structured paragraph that front-loads the main purpose, then provides cost, time, and usage guidance. It is efficient but could be improved by listing parameters or using bullet points for clarity. No wasted sentences, but information density is high.
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 11 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the tool returns (e.g., a new model ID or job ID?), how the 'wait' parameter works, or the meaning of most parameters. The agent lacks critical information to invoke the tool correctly without external help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains only two parameters (prompt and reference_image_id) out of eleven. Critical parameters like texture_size, coherence_level, decimation_target, preserve_parts, and dest are not mentioned, leaving the agent without guidance on their purpose or impact.
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 turns a rough model into a high-resolution mesh with PBR texture. It distinguishes itself from sibling 'thrixel_reduce_triangles' by explicitly stating it is not for reducing triangles, and mentions it is the step that finalizes a blockout. This provides specific verb+resource and differentiates from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (after an Architect blockout) and when not to (for reducing triangle count). It names an alternative tool (thrixel_reduce_triangles) and provides key decision factors like cost (40 cubes) and runtime (a couple of minutes). This gives clear guidance on appropriate 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?
Discloses that it preserves unmentioned parts and works with natural language. No annotations exist, so description carries full burden. Missing details on side effects or costs, but adequate.
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?
Well-structured with three clear paragraphs, front-loaded with purpose. Could be slightly more concise but no unnecessary repetition.
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?
No output schema, so return values are unexplained. Does not clarify async behavior (wait parameter implies but not explicit). Comprehensive for a mid-complexity tool, but some gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description only explains 'change' (natural language) and 'focus_on_node_names' (get from inspect_model). Other 4 parameters (dest, wait, project_id, submission_id) are not elaborated.
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?
Clearly states the tool edits existing 3D models via natural-language instructions, emphasizing iteration and preservation. Distinguishes from siblings like thrixel_create_model.
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?
Provides explicit when-to-use (iterate vs. regenerate), applicable inputs (Architect, Auto-fix, Edit results), instruction phrasing tips, and guidance for partial edits via focus_on_node_names.
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?
No annotations provided, so description carries full burden. It discloses cost (40 cubes), wait behavior, output format (GLB file path and thumbnail), and notes lower editability. Lacks details on permission or reversibility but covers key behaviors.
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?
Three concise paragraphs with front-loaded purpose. Minor redundancy (e.g., 'dense, organic' and 'sculpted rather than assembled') but overall 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?
While the description provides a good overview, it omits explanations for 7 parameters with zero schema coverage. No output schema exists, so return value details are minimal. More guidance on optional parameters like texture_size would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. Description only loosely explains 'prompt' and 'image' via 'text description and/or a single reference image'. Other parameters (dest, wait, project_id, texture_size, decimation_target) are not mentioned.
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?
Description clearly states it creates a dense, organic 3D model from text and/or image. It differentiates from sibling thrixel_create_model by noting the output is a single high-density mesh rather than separate parts.
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?
Explicitly recommends for creatures, characters, plants, rocks, food, cloth, and when starting from a photo. It also explicitly advises using thrixel_create_model for man-made objects with distinct components.
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?
No annotations are provided, so the description carries full burden. It describes the output (part names, triangle counts, thumbnail) which implies a read-only inspection. It does not mention side effects or permissions, but for a read tool this is sufficient. No contradiction with annotations.
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?
Two sentences, no wasted words. First sentence clearly states what the tool does and its output. Second sentence gives usage context. Perfectly front-loaded 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?
The tool has one parameter and no output schema or annotations. The description covers output and usage context well, but fails to document the parameter (submission_id). This missing detail reduces completeness for an otherwise simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (submission_id) with 0% description coverage. The description does not explain what submission_id is or provide any format guidance. Given that the schema itself lacks a description, the tool description should compensate but does not.
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 states exactly what the tool does: shows part names, per-part triangle counts, and a rendered thumbnail. It distinguishes itself by recommending use before other tools that target specific parts (thrixel_edit_model, thrixel_retexture_model, thrixel_reduce_triangles), clearly differentiating from siblings.
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 explicitly says when to use this tool: 'Call this before any operation that targets specific parts' and lists the sibling tools that require exact node names. It also provides a second use case: checking triangle budget before shipping. This gives clear context and exclusions.
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 responsibility. It discloses important behaviors: keeps existing texture, works on any completed model, handles detailed/sculpted and other models differently, and selects the right endpoint. It does not mention authentication needs or rate limits, but covers key behavioral traits.
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 with three short paragraphs, each serving a distinct purpose: purpose and differentiation, behavior, and example budgets. No unnecessary words or repetition.
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 (6 parameters, no output schema, no annotations), the description covers the essential purpose, usage guidance, and behavioral details. It lacks explanation of return values and some parameters, but provides enough context for typical use.
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 explains the target triangle parameter by providing typical game budgets, adding context. However, it does not explain the required submission_id or optional parameters like dest, wait, project_id, focus_on_node_names. Partial compensation.
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: 'Cut a model down to a triangle budget.' It uses specific verbs and resource ('reduce', 'model'), and explicitly distinguishes from a sibling tool (thrixel_detail_model) by explaining why this should be preferred (free, fast, lighter version of the same model).
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 guidance on when to use this tool: always use it instead of re-running thrixel_detail_model for lightening. It includes typical triangle budgets for game assets. However, it does not explicitly state when not to use it or mention alternatives beyond the one sibling.
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?
Despite no annotations, the description discloses important behavioral trait: non-GLB formats are converted on demand, causing first request to take longer. It doesn't explicitly state non-destructiveness or auth needs, but the context of a download tool implies read-only. Slight deduction for missing explicit safety statement.
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 clear sentences followed by a paragraph of context. No wasted words; the first sentence effectively summarizes the action and resource.
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 presence of an output schema, the description need not detail return values. It covers when to use, format details, and conversion behavior. It could briefly mention what the tool returns (e.g., file path or data stream), but overall it is sufficiently complete for a straightforward download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description should compensate. While it explains the 'format' parameter by listing examples (GLB, FBX, OBJ, STL, USDZ), it does not explain the required 'submission_id' or the optional 'dest' parameter. The description adds only partial meaning beyond the raw 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 title and description clearly state the verb 'save' (or download) and the resource 'finished model', and the description distinguishes this from sibling tools like create_model or edit_model by noting that most tools auto-save GLB, so this tool is for alternative formats or re-downloading.
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?
Explicitly states when to use: 'only need this to get a different format, or to re-save a model from an earlier session.' It implies when not to use (default GLB is auto-saved) and provides context on format availability and conversion behavior.
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?
No annotations provided, so description fully covers behavioral traits: output is rough but editable multi-part mesh with separate named nodes. Waits for job, saves GLB, returns file path and thumbnail. Advises checking thumbnail before building.
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?
Three concise paragraphs with front-loaded action, then output details, then usage tip. Every sentence adds unique value; 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?
Provides enough context for primary use case: explains output format, workflow, and prompt style. Lacks detail on optional parameters like dest and wait, but defaults are reasonable. Overall sufficient for agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring description to compensate. Only covers prompt (with usage advice) and images (reference images). Does not explain dest, wait, project_id, or style_reference_submission_id. Missing information on 4 of 6 parameters.
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?
Clearly states it creates a 3D model from text description, optionally with reference images. Specifies it's for man-made objects like game props, vehicles, etc. Distinguishes from sibling thrixel_sculpt_model.
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?
Explicitly says when to use (default for man-made, distinct components) and when to prefer thrixel_sculpt_model. Provides prompt advice: describe object itself, not the request.
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?
No annotations provided, but description discloses it is a read operation (checking status, balance, jobs) with no destructive actions mentioned, though it could explicitly state readOnlyHint.
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?
Description is concise with two clear sentences for purpose and usage, plus cost info; no 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 zero parameters, no annotations, and an output schema available, the description provides sufficient context for correct invocation and usage.
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?
No parameters exist, so schema coverage is 100%. The description focuses on the tool's function rather than parameter details, which is appropriate.
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 it checks the Thrixel API key, cube balance, and running jobs, distinguishing it from sibling tools that perform model operations.
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?
Explicitly advises to call before submitting a large batch for sizing and after specific errors, providing clear context for when to use this tool.
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:

[![thrixel_mcp MCP server](https://glama.ai/mcp/servers/thrixel/thrixel_mcp/badges/card.svg)](https://glama.ai/mcp/servers/thrixel/thrixel_mcp)

Score Badge

Copy to your README.md:

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

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