three.ws 3D Studio (free)
Server Details
Free text/image → 3D: generate, rig, avatar-ify, and refine GLB models. No auth, no payment.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- nirholas/three.ws
- GitHub Stars
- 23
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 9 of 9 tools scored.
Tools like forge_avatar and text_to_avatar appear to serve similar purposes (generating rigged avatars), and forge_free and mesh_forge both generate textured meshes with overlapping descriptions, causing potential confusion for an agent. Some tools have distinct roles (e.g., persona management vs. model generation), but the generation category is muddled.
Names mix patterns: 'forge_avatar', 'forge_free', 'mesh_forge', 'text_to_avatar', 'create_agent_persona', 'get_agent_persona', 'persona_say', 'refine_model', 'rig_mesh'. There is no consistent verb_noun structure; some use 'forge' as prefix, others use different verbs. The variety and lack of a clear convention reduce predictability.
With 9 tools covering generation, refinement, rigging, avatar creation, persona management, and animation, the count feels well-scoped. Each tool has a place in the workflow, and the set is neither too sparse nor overwhelming for a 3D studio.
The tool set covers the main lifecycle: generation (multiple entry points), refinement, rigging, and even persistent personas with animation. Minor gaps exist (e.g., no explicit delete tool for models or personas, no import/export options), but the core creative workflow is well-supported.
Available Tools
9 toolscreate_agent_personaSave a rigged model as a living, persistent agent bodyAInspect
Turn a generated GLB into a NAMED, persistent agent body — a "persona" the assistant reuses across turns and across sessions. The model is copied into durable storage so the body survives the source URL expiring, then registered under a stable persona_id. The returned view renders the LIVING body inline: it idles between turns, and persona_say makes it lip-sync and emote a reply. The persona_id is the handle — keep it and pass it to get_agent_persona or persona_say later to bring the exact same body back. No sign-in required.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A display name for the persona, 1–80 characters. | |
| voice | No | Optional voice name to speak with (used for audio-driven lip-sync when available). | |
| glb_url | Yes | Public https URL of the rigged GLB to embody (e.g. from forge_avatar). | |
| source_prompt | No | Optional: the prompt that generated this body, kept as provenance. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-idempotency. Description adds key behavioral traits: durable storage, survival of expired URL, inline living body with idle animation and lip-sync via persona_say. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise (~100 words) with front-loaded purpose, followed by persistence, behavior, and usage. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key aspects: persistence, behavior, handle usage, and relation to siblings. Missing explicit return value details (no output schema), but the description mentions the returned view and is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds context linking glb_url to forge_avatar, voice to lip-sync, and name/source_prompt to display and provenance, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: converting a GLB into a persistent, named agent persona. It differentiates from sibling tools like forge_avatar (GLB creation) and get_agent_persona (retrieval) by focusing on persistence and naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: persist the persona, reuse via persona_id, and later use get_agent_persona or persona_say. Does not explicitly exclude when not to use or list alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forge_avatarGenerate a rigged, animation-ready avatarAInspect
Generate a rigged, animation-ready 3D avatar (GLB) from a single text prompt or a reference image — in one step. Generates the mesh, then auto-rigs it with a humanoid skeleton so it is ready to pose and animate. Best for characters; objects are steered to the mesh generator. Renders inline in an interactive 3D viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Description of the character/avatar to generate. | |
| image_url | No | Optional http(s) URL to a reference image to reconstruct in 3D. | |
| allow_non_humanoid | No | Set true to rig a non-humanoid subject anyway (rigging assumes a humanoid figure). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the generation pipeline (mesh then auto-rig) and output format (GLB) with inline viewer. Annotations provide readOnlyHint=false and destructiveHint=false, and description adds behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. Front-loaded with core action, then process detail, then usage guidance. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers inputs, process, output, and differentiation. Handles 3 params and 0 required. No output schema needed for this generative tool. Minor gap: no explicit mention of rate limits or authorization, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. Description adds semantic value by explaining workflow (text/image, one-step, auto-rigging, viewer) and clarifying purpose of allow_non_humanoid (rigging assumes humanoid).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states generate a rigged, animation-ready avatar from text or image, specifying output format (GLB) and one-step process. Differentiates from siblings by noting 'Best for characters' versus objects steered to mesh generator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly guides use for characters via 'Best for characters; objects are steered to the mesh generator.' Provides context for allow_non_humanoid parameter. Lacks explicit when-not-to-use or exhaustive alternatives, but sufficient given sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forge_freeGenerate a 3D model from textAInspect
Turn a text prompt into a textured, downloadable 3D model (GLB) — free. Describe a single object, character, or creature; the studio generates an interactive model you can rotate, view, and download. Optional quality tier (draft, standard, high); high is slower and may fall back to standard under load. Renders inline in an interactive 3D viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Detail level: draft (fastest), standard (default), or high (best, slower; may fall back to standard under load). | |
| prompt | Yes | Description of the single object or character to model, e.g. "a friendly round robot mascot, glossy white plastic". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint=false) and not destructive. The description adds valuable behavioral context: the model is free, outputs GLB, renders in an interactive viewer, and high quality may fall back to standard under load. It does not cover rate limits or account requirements but provides sufficient transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no redundancy. The first sentence delivers the core purpose, the second adds scope and interactivity, the third explains tier options. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters and no output schema, the description covers the main behavior (generation, viewing, downloading, tier behavior). It does not detail post-generation steps or constraints like rate limits, but for a straightforward generation tool, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes each parameter well (e.g., tier options, prompt limits). The description adds meaning by explaining the expected scope of the prompt ('Describe a single object, character, or creature') and the tier fallback behavior, enriching the semantic interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Turn a text prompt into'), the resource ('a textured, downloadable 3D model'), and key differentiators ('free', 'GLB format', 'single object'). It distinguishes from siblings like 'forge_avatar' (free, not avatar-specific) and 'refine_model' (generates from scratch, not refinement).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (single object, free) but does not explicitly state when not to use or suggest alternatives among sibling tools. It mentions quality fallback behavior under load, which is helpful but not a full usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_personaReload a persona by id (continuity across sessions)ARead-onlyIdempotentInspect
Bring back a previously saved persona by its persona_id — the SAME body and identity, in a fresh session. Returns the persona name, its model, the accumulated turn count, and the inline living-body view. Use this at the start of a conversation when the user returns to a named agent.
| Name | Required | Description | Default |
|---|---|---|---|
| persona_id | Yes | The persona_id returned by create_agent_persona. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: it returns specific fields (persona name, model, turn count, living-body view) and clarifies it is for a fresh session, going beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence defines action and return, the second gives usage context. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, no output schema, and full annotation coverage, the description covers the purpose, return fields, and when to use. Complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema already describes persona_id as returned by create_agent_persona. The description mentions the same, adding no extra semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (bring back/reload) and the resource (persona by ID), with explicit scope (same body and identity in a fresh session). It differentiates from siblings like create_agent_persona by focusing on continuity across sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises use at the start of a conversation when a user returns to a named agent. While it doesn't list alternatives, the context is clear enough and the sibling tool names imply distinct use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mesh_forgeGenerate a 3D mesh (art-directed)AInspect
Generate a textured 3D mesh (GLB) from a text prompt or a reference image URL. In text mode an AI art-director first refines your prompt into an optimized single-subject spec for higher mesh quality. Renders inline in an interactive 3D viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Description of the single object to model. | |
| image_url | No | Optional http(s) URL to a reference image to reconstruct directly. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it is not read-only and has open-world effects. The description adds behavioral details: an AI art-director refines text prompts, and results render inline in a 3D viewer, going beyond annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences front-load the core function and efficiently add key behavioral details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two optional params, no output schema), the description covers modes, art-direction, and viewer rendering. It could mention what is returned (e.g., GLB file), but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover both parameters (prompt, image_url). The description adds value by explaining the art-director refinement for text mode, enriching understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a textured 3D mesh (GLB) from text or image, with an art-directed process, distinguishing it from sibling tools like forge_avatar or refine_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool (from text or image URL) and notes the art-direction refinement, but does not explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
persona_saySpeak a reply through a persona — lip-sync + emotion + gestureAInspect
Make a persona PERFORM a reply: the body lip-syncs the text and shows the matching facial expression and body gesture. Pass the persona_id and the exact text the agent is saying this turn; the emotion is detected from the text automatically (or set it explicitly). The returned view animates the body for this turn — show it alongside the reply. This is the turn-by-turn embodiment hook.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The reply text the agent is saying this turn — drives lip-sync and emotion. | |
| emotion | No | Optional explicit emotion override; omit to auto-detect from the text. | |
| persona_id | Yes | The persona to speak through. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful behavioral details beyond annotations: lip-sync, facial expression, body gesture, automatic emotion detection, and the return of an animated view. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, no wasted words. Each sentence serves a clear purpose: action, parameter handling, return value placement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains the return value (animated view to show alongside reply). Covers all key aspects: what is performed, parameters, behavior, and output usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by explaining that text drives lip-sync and emotion, and that emotion can be auto-detected. Persona_id is minimally described but schema already handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-resource pair: 'Make a persona PERFORM a reply' with specific details about lip-sync, emotion, and gesture. It distinguishes from sibling tools that focus on creation/forging rather than performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to pass persona_id and text, and notes that emotion can be auto-detected or overridden. Provides clear context as the 'turn-by-turn embodiment hook' but lacks explicit when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
refine_modelRefine a 3D model by describing a changeAInspect
Iterate on a model you already generated — just describe the change in words ("make it metallic", "bigger helmet", "add wings"). The studio re-generates a new version anchored to the previous one, carrying its form and materials forward. Pass the previous model's glb_url and, when you have it, the prompt that made it (parent_prompt) so the change builds on it. Each refinement is recorded as a new version in a lineage you can revert to or branch from — the returned lineage drives a version strip in the viewer. Renders the new version inline in the interactive 3D viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| glb_url | Yes | http(s) URL of the model to refine (e.g. the glbUrl a previous generation returned). | |
| instruction | Yes | The change to make, in plain language: "make it metallic", "bigger helmet", "add a cape". | |
| parent_index | No | Optional — branch off an earlier version in parent_lineage (its index) instead of the latest. | |
| parent_prompt | No | Optional — the prompt that produced the model being refined, so the change builds on it instead of starting over. | |
| parent_lineage | No | Optional — the lineage array from a previous refine_model result, to extend the same version history. | |
| reference_image_url | No | Optional http(s) image of the current model to anchor the re-generation (image→3D). Omit for text-guided refinement. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false) and non-destructiveness. The description adds details: re-generation anchored to previous version, lineage recording, inline rendering in viewer. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with four sentences, each providing essential information. It front-loads the primary purpose. Slightly longer than minimal but without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the tool's behavior, parameters, and expected result (new version, lineage). It could mention return values like glbUrl of refined model, but the description is still sufficiently complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, and the description adds value by explaining the role of glb_url, instruction, and optional parameters (e.g., parent_prompt for building on previous prompt). It clarifies the lineage usage beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('iterate', 'refine') and clearly identifies the resource ('3D model') and action ('describing a change'). It distinguishes itself from sibling tools by emphasizing iteration on an existing model rather than creation from scratch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 iterate on a generated model) and provides guidance on optional parameters like parent_prompt and parent_lineage to build on previous versions. It does not explicitly list sibling alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rig_meshRig a 3D model for animationAInspect
Auto-rig a static 3D model (GLB) into an animation-ready model: adds a humanoid skeleton and skin weights so it can be posed and animated. Provide the GLB URL of a model (e.g. one generated by the other tools). Renders the rigged result inline in an interactive 3D viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| glb_url | Yes | http(s) URL to the static GLB mesh to rig. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutation operation (readOnlyHint=false). Description adds that the result is rendered inline in a 3D viewer. However, it omits potential failure cases (e.g., non-humanoid models) and prerequisites. With annotations covering the safety profile, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: three sentences, front-loaded with the main action, no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description explains what the tool does and hints at the result (inline render). It covers the essential purpose and usage. Some detail on limitations or output format would improve completeness, but it is fairly complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (glb_url) described as 'http(s) URL to the static GLB mesh to rig.' Description adds context that the model should be static and may come from other tools, but adds minimal extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool auto-rigs a static 3D model by adding a humanoid skeleton and skin weights. It specifies the resource (GLB model) and the outcome (animation-ready). Sibling tool names like 'mesh_forge' and 'text_to_avatar' suggest mesh generation, making this rigging tool distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description advises providing a GLB URL from other tools, giving clear context for use. It does not explicitly state when not to use it, but as a single-purpose tool with one required parameter, the guidance is sufficient for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
text_to_avatarGenerate a 3D avatarAInspect
Generate a textured 3D avatar (GLB) from a text description or a reference image URL. Best for characters and figures. Renders inline in an interactive 3D viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Description of the avatar to generate. | |
| image_url | No | Optional http(s) URL to a reference image to reconstruct in 3D. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey non-read-only, non-destructive, and open-world hints. The description adds behavioral context: output format (GLB) and inline rendering in an interactive 3D viewer. This goes beyond annotations, though it omits details like cost or resolution limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the main functionality, add domain context, and describe output behavior. Every sentence serves a purpose without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description specifies output format (GLB) and viewer behavior, providing good context given no output schema. However, it does not explain how the tool handles both inputs simultaneously or set expectations for generation time or quality, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description rephrases the schema ('from a text description or a reference image URL') but does not add significant new meaning, such as handling when both are provided or constraints on the image URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a textured 3D avatar (GLB) from text or image URL, and specifies it's best for characters and figures. While it gives a domain cue, it does not explicitly differentiate from sibling tools like forge_avatar, which likely have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Best for characters and figures' provides implicit usage guidance, but the description does not specify when not to use this tool or mention alternative sibling tools. No formal when-to-use/when-not-to-use delineation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!