maige-3d-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes with clear boundaries, such as createObject vs. updateObject, or animateObject vs. addBehavior. However, some overlap exists: animateObject and addBehavior both handle object animations, which could cause confusion in selection, though their descriptions clarify animateObject is for property transitions while addBehavior is for continuous frame-tick effects.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as createObject, deleteObject, updateObject, and getSceneState. All tools use camelCase uniformly, with no mixing of naming conventions, making the set predictable and easy to navigate.
Tool Count3/5
With 33 tools, the count is borderline high for a 3D scene management server, potentially overwhelming for agents. While the tools cover a comprehensive range of operations, the number may feel heavy compared to typical well-scoped servers, though it aligns with the domain's complexity.
Completeness5/5
The tool set provides complete coverage for 3D scene management, including CRUD operations for objects, lights, and particles, scene state management, animation controls, user interaction handling, and advanced features like scripting and export. No obvious gaps exist; agents can perform full lifecycle workflows without dead ends.
Average 3.4/5 across 33 of 33 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral information. It mentions 'partial updates' which is useful context, but doesn't disclose important behavioral traits like whether this is a destructive operation, what permissions are needed, how errors are handled, or what the response looks like. For a mutation tool with complex parameters, this is inadequate.
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 concise with two sentences that communicate the core functionality. It's front-loaded with the main purpose and adds a useful detail about partial updates. No wasted words, though it could benefit from more complete information given the tool's complexity.
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 (6 parameters with nested objects, no output schema, and no annotations), the description is insufficient. It doesn't explain the scope of updatable properties, doesn't mention the required 'id' parameter, and provides no information about return values or error conditions. For a mutation tool with this level of schema complexity, much more context is needed.
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 only 17% schema description coverage (only the 'rotation' parameter has a description), the description must compensate but fails to do so. The description mentions 'any properties' but doesn't explain what those properties are, their formats, or constraints. It doesn't add meaningful semantic context beyond what the bare schema provides for the 6 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 verb ('Update') and resource ('any properties of an existing 3D object'), specifying it supports partial updates. It distinguishes from creation tools like 'createObject' by focusing on existing objects, but doesn't explicitly differentiate from similar update tools like 'updateLight' or 'updateParticles'.
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. While it's clear this updates 3D objects, there's no mention of when to choose this over 'animateObject', 'cloneObject', or other sibling tools that might modify objects. The description lacks context about prerequisites or typical use cases.
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 stops animations, implying a mutation, but doesn't cover critical aspects like permissions needed, side effects (e.g., if it halts all animations or just one), error handling, or response format. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the core action and target, making it highly efficient and easy to parse, which is ideal for conciseness.
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 (a mutation with no annotations, 1 undocumented parameter, and no output schema), the description is incomplete. It lacks details on behavior, parameters, return values, and usage context, making it insufficient for an agent to reliably invoke the tool without additional information.
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 1 parameter with 0% description coverage, so the schema provides no semantic information. The description does not mention the 'id' parameter at all, failing to explain what it represents (e.g., object ID, animation ID) or how to use it, leaving the parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and target ('any running animation on an object'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'removeBehavior' or 'animateObject', which might also affect animations, so it doesn't fully achieve 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 (e.g., an animation must be running), exclusions, or comparisons to siblings like 'removeBehavior' for broader behavior removal, leaving the agent to infer usage context.
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, the description carries full burden but only states it updates a light without disclosing behavioral traits. It doesn't mention permission requirements, whether changes are reversible, side effects (e.g., on scene rendering), or error handling (e.g., invalid ID). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. Every word contributes to stating the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with nested objects, no annotations, no output schema), the description is incomplete. It doesn't cover parameter meanings, behavioral context, or usage guidelines, leaving the agent with insufficient information to invoke the tool correctly beyond its basic intent.
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 the description must compensate but adds no parameter details. It doesn't explain what 'id' refers to, the format of 'color', the range of 'intensity', the coordinate system for 'position', or the effect of 'castShadow'. This fails to address the 5 parameters, including a nested object.
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 ('Update') and resource ('an existing light by id'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'updateObject' or 'createLight', which would require mentioning specific light properties or contrasting with creation.
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. It doesn't mention prerequisites (e.g., needing an existing light ID), exclusions, or comparisons to siblings like 'createLight' for new lights or 'updateObject' for non-light objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't describe effects (e.g., whether changes are immediate, reversible, or require specific permissions), side effects (e.g., impact on animations or scene state), or error conditions (e.g., invalid IDs). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part earning its place by conveying the core action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on behavioral traits, parameter meanings, usage context, and return values. For a mutation tool in a graphics/scene management context with rich siblings, this minimal description leaves too many gaps for effective agent use.
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 low (13%, with only the 'id' parameter documented), and the description adds no parameter semantics beyond the generic 'properties.' It doesn't explain what 'position,' 'color,' 'size,' etc., mean in context, their units, valid ranges, or default behaviors. With 7 of 8 parameters undocumented in both schema and description, the description fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('properties of an existing particle system'), making the purpose evident. It distinguishes from sibling tools like 'createParticles' (creation vs. update) and 'deleteParticles' (update vs. deletion), though it doesn't explicitly differentiate from 'updateObject' or 'updateLight' which might handle similar property updates for different resource types.
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., needing an existing particle system ID), exclusions (e.g., what properties cannot be updated), or comparisons to siblings like 'updateObject' (for general objects) or 'createParticles' (for new systems). Usage is implied only by the verb 'update,' but no explicit context is given.
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 basic functionality. It doesn't disclose behavioral traits like whether cloning preserves object properties, permissions required, if it's destructive to the original, rate limits, or what happens on failure. 'Duplicate' implies a write operation, but no safety or side-effect details are given.
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?
Extremely concise with a single sentence that front-loads the core purpose ('duplicate an object') and adds key constraint ('with an optional position offset'). No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what properties are cloned, the format of returned data, error conditions, or how it interacts with sibling tools like 'updateObject'. The context signals show complexity (nested objects, 3 parameters), but the description lacks necessary operational details.
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 100%, so parameters are fully documented in the schema. The description adds minimal value beyond schema: it mentions 'optional position offset' which aligns with the 'offset' parameter in schema, but doesn't provide additional context like units for offset or when to specify newId.
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 ('duplicate') and resource ('an object'), specifying it creates a copy with optional positioning. It distinguishes from siblings like 'createObject' (new from scratch) and 'getObject' (retrieve existing), but doesn't explicitly contrast with all similar tools like 'copy' operations if they existed.
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 on when to use this tool versus alternatives like 'createObject' for new objects or 'copy' operations. The description mentions optional position offset but doesn't provide context for when offset is needed versus using default positioning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. 'Add a light' implies a write operation that modifies the scene, but it doesn't disclose whether this requires specific permissions, if it's idempotent, what happens on failure, or how the light integrates with the scene (e.g., immediate visibility). The description lacks details on side effects or system behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'adding a light' entails in this context (e.g., 3D scene rendering), what the expected outcome is, or any behavioral nuances. The agent must rely entirely on the input schema for operational details.
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 100%, so the schema fully documents all 11 parameters. The description adds no parameter-specific information beyond what's in the schema, not even mentioning the required 'lightType' parameter. However, since the schema is comprehensive, a baseline score of 3 is appropriate as the description doesn't need to compensate.
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 ('Add') and resource ('a light to the scene'), making the purpose immediately understandable. It distinguishes from siblings like 'updateLight' or 'deleteLight' by specifying creation. However, it doesn't explicitly differentiate from 'createObject' or 'createParticles' which might also add scene elements.
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., needing an active scene), when not to use it, or how it relates to siblings like 'updateLight' for modifications or 'createObject' for non-light objects.
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 the action is 'Remove' (implying destructive mutation) but doesn't specify whether this is permanent, reversible (e.g., via 'undo'), requires specific permissions, or has side effects (e.g., affecting scene lighting). The description is minimal and lacks critical behavioral context 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 a single, direct sentence with zero wasted words. It front-loads the core action ('Remove a light') and efficiently specifies the parameter requirement ('by id'). Every word earns its place, making it highly concise and well-structured.
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 destructive nature (implied by 'Remove'), lack of annotations, no output schema, and minimal parameter documentation, the description is incomplete. It doesn't address what happens after deletion (e.g., success/failure response, error conditions), whether the action can be undone, or how it interacts with sibling tools like 'undo' or 'getSceneState'. For a mutation tool with no structured support, more context is needed.
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 mentions 'by id', which clarifies the purpose of the single parameter beyond the schema's generic 'string' type. However, with 0% schema description coverage and only one parameter, this adds marginal value. The baseline for 0 parameters would be 4, but with one parameter and minimal explanation, a score of 3 reflects adequate but not comprehensive parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target resource ('a light from the scene'), making the purpose immediately understandable. It distinguishes from siblings like 'deleteObject' by specifying 'light' as the resource type. However, it doesn't explicitly differentiate from 'updateLight' or 'createLight' beyond the verb choice.
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 'deleteObject' (for non-light objects) or 'updateLight' (for modifying instead of removing). There's no mention of prerequisites (e.g., light must exist), consequences, or typical scenarios for deletion.
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. It states the destructive action ('Remove') but doesn't disclose whether deletion is permanent, reversible via 'undo', requires specific permissions, affects scene state, or has side effects. For a destructive tool with zero annotation coverage, this leaves significant behavioral 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and includes essential parameter context, making it immediately understandable without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It lacks crucial details like deletion permanence, error handling, dependencies on other tools, or return values, leaving the agent with significant uncertainty about tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the 'id' parameter and its purpose ('by id'), but doesn't explain ID format, how to obtain valid IDs (e.g., from 'getObject' or 'listScenes'), or what happens with invalid IDs. This adds basic context but insufficiently compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target ('a 3D object from the scene'), and specifies the required identifier ('by id'). It distinguishes from siblings like 'deleteLight' and 'deleteParticles' by specifying object type, but doesn't differentiate from 'clearScene' which removes all objects.
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 'clearScene' (remove all objects) or 'undo' (reverse deletion). It mentions the 'id' parameter but doesn't explain how to obtain valid IDs or prerequisites for deletion.
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. 'Remove' implies a destructive mutation, but it doesn't specify if this action is permanent, reversible (e.g., via 'undo'), or requires specific permissions. It also omits details like whether it affects scene state or triggers side effects, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it easy to parse and front-loaded with the essential action. It efficiently conveys the core purpose without unnecessary elaboration.
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 destructive nature (implied by 'Remove'), no annotations, no output schema, and low schema coverage, the description is incomplete. It fails to address critical aspects like error handling, return values, or interaction with sibling tools (e.g., 'undo' for reversal), making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'a particle system,' which aligns with the 'id' parameter in the schema, but with 0% schema description coverage, it doesn't add meaningful details like what format the ID should be (e.g., a string identifier) or where to obtain it. Since there's only one parameter, the baseline is 4, but the lack of compensation for the coverage gap reduces it to 3.
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 ('Remove') and the target resource ('a particle system from the scene'), making the purpose immediately understandable. It distinguishes from siblings like 'deleteObject' or 'deleteLight' by specifying particle systems, though it doesn't explicitly contrast with 'updateParticles' or 'createParticles'.
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 'deleteObject' (which might handle particles differently) or 'clearScene' (which removes everything). There's no mention of prerequisites, such as whether the particle system must exist or be active, or any context about what happens after removal.
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 this is a 'Get' operation, implying it's likely read-only, but doesn't confirm safety aspects like whether it requires authentication, has rate limits, or what happens if the object doesn't exist. The description is minimal and lacks behavioral context 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 a single, efficient sentence that front-loads the core purpose without any wasted words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with no annotations, no output schema, and minimal parameter documentation), the description is incomplete. It doesn't explain what 'properties' are returned, potential errors, or how this fits into the broader scene management context with many sibling tools. More detail is needed for effective 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?
The description adds minimal meaning beyond the input schema: it clarifies that the 'id' parameter refers to a 'scene object' id. However, with 0% schema description coverage and only one parameter, this provides basic but insufficient context—it doesn't explain what format the id should be or where to obtain it. The baseline is appropriate given the single parameter.
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 properties') and resource ('a single scene object by id'), making the purpose unambiguous. It doesn't explicitly differentiate from siblings like 'getSceneState' or 'listScenes', but the specificity of 'single scene object' provides reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'getSceneState' (which might return broader scene data) or 'listScenes' (which lists multiple scenes). The description implies usage for retrieving properties of a specific object, but offers no explicit when/when-not context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions loading from a specific folder and referencing 'listScenes', but it doesn't disclose critical behavioral traits such as whether this operation overwrites the current scene, requires specific permissions, handles errors (e.g., missing files), or what the expected outcome is. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core action. It avoids unnecessary words and directly communicates the essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a scene-loading operation with no annotations and no output schema, the description is insufficient. It lacks details on behavioral effects (e.g., scene replacement), error handling, or return values, making it incomplete for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the 'name' parameter, so the baseline is 3. The description adds some context by mentioning the 'scenes/ folder' and referencing 'listScenes', but it doesn't provide additional semantic details beyond what the schema already states (e.g., file format specifics or validation rules).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Load') and resource ('previously saved scene from the scenes/ folder'), making the purpose evident. However, it doesn't explicitly distinguish this tool from the sibling 'loadScene' tool, which appears to be a similar operation.
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 minimal guidance by mentioning the 'scenes/ folder' and referencing 'listScenes' for file names, but it doesn't specify when to use this tool versus alternatives like 'loadScene' or 'getSceneState'. No explicit when-not-to-use or prerequisite information is included.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the effect ('stopping its frame-tick effect'), which adds some context about what the removal entails, but fails to cover critical aspects like whether this is reversible, requires specific permissions, or has side effects on related objects. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and effect without any wasted words. It is appropriately sized for a simple tool with one parameter.
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 as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks information on return values, error conditions, or broader context like how behaviors are identified or managed, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'id' as the ID of the behavior to remove. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, resulting in a baseline score of 3.
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 ('Remove') and target ('a behavior by its ID'), and specifies the effect ('stopping its frame-tick effect'), which distinguishes it from generic deletion tools. However, it doesn't explicitly differentiate from siblings like 'deleteObject' or 'clearScene', which could involve similar removal concepts.
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 'deleteObject' or 'clearScene', nor does it mention prerequisites such as needing an existing behavior ID. It implies usage by stating the effect but lacks explicit context or exclusions.
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 sets camera properties but doesn't mention whether this is a persistent change, requires specific permissions, affects other scene elements, or has side effects like triggering animations. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and resource. There is no wasted language, and it directly communicates the tool's function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after setting the camera (e.g., immediate view change, persistence), error conditions, or integration with sibling tools like 'animateObject'. More context is needed given the complexity of 3D scene manipulation.
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 100%, with clear descriptions for 'position', 'target', and 'fov'. The description adds no additional meaning beyond the schema, such as default values, units beyond degrees for 'fov', or constraints on coordinate ranges. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Set') and the resource ('camera position and look-at target'), making the purpose immediately understandable. It doesn't differentiate from siblings like 'flyToObject' or 'takeScreenshot', which would require more specificity about when to use each camera-related tool.
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 'flyToObject' or 'setEnvironment'. The description lacks context about prerequisites, such as whether a scene must be loaded first, or exclusions for when other tools might be more 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 implies a mutation ('Configure') but doesn't specify if changes are reversible, require permissions, or affect performance. It mentions post-processing effects but omits details like default values, side effects, or error handling, leaving significant gaps for a tool with 9 parameters.
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, efficient sentence that front-loads the purpose and enumerates key aspects without unnecessary words. However, it could be slightly more structured by grouping related parameters or adding brief context, but it avoids redundancy and stays focused.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, nested objects, no output schema, and no annotations), the description is inadequate. It doesn't explain return values, error conditions, or how changes persist (e.g., across scene saves). For a configuration tool with rich parameters, more context on behavior and integration with other tools is needed.
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 schema description coverage is 100%, providing detailed documentation for all parameters, including nested objects. The description adds minimal value by listing categories like 'background' and 'post-processing effects', but doesn't explain interactions (e.g., hdriUrl overriding background) or provide usage examples beyond what the schema already covers.
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 ('Configure') and the target ('scene environment'), listing specific aspects like background, fog, tone mapping, shadows, and post-processing effects. It distinguishes from siblings like setCamera or updateObject by focusing on environmental settings rather than camera or object properties, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as setCamera for camera settings or updateObject for object properties. It lacks context about prerequisites, like whether a scene must be loaded first, or exclusions, such as not applying to specific object types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'smoothly move' implying animation, but doesn't address permissions, side effects, error conditions, or what happens if the object doesn't exist. For a camera manipulation tool with zero annotation coverage, this leaves significant behavioral 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 a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward camera movement tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (camera animation with parameters), no annotations, and no output schema, the description is minimally adequate but incomplete. It explains what the tool does at a high level but lacks behavioral context, usage guidance, and error handling information that would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all three parameters thoroughly. The description doesn't add any additional meaning about parameters beyond what's in the schema, meeting the baseline expectation when schema does the heavy lifting.
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 ('Smoothly move the camera') and target ('to look at an object'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'setCamera' or 'getObject', which might have overlapping camera-related functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'setCamera' or 'getObject'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Redo' implies a mutation operation, the description doesn't specify what happens if no undone change exists, whether this affects scene state permanently, or what the response looks like. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what constitutes a 'scene change', what happens on success/failure, or how this interacts with the 'undo' tool. For a tool that modifies state, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters, earning a baseline score of 4 for this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Redo') and the target ('a previously undone scene change'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this from the 'undo' sibling tool, which would be helpful for full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an undone change available), when not to use it, or how it relates to the 'undo' sibling tool, leaving the agent without contextual usage instructions.
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 what the tool does (listing files) but lacks behavioral details such as whether it returns file paths, metadata, or full JSON content; if there are permissions or rate limits; or how it handles empty folders. This leaves significant gaps for an agent to understand the operation fully.
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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate but incomplete. It explains the basic purpose but lacks output details (e.g., format of the list) and behavioral context, which could hinder an agent's ability to use it effectively without trial and error.
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 doesn't add param info, but that's appropriate here. Baseline is 4 for zero parameters, as it avoids unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all saved scene JSON files in the scenes/ folder'), making the purpose specific and understandable. It doesn't explicitly distinguish from siblings like 'loadScene' or 'getSceneState', but the folder-focused listing is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'getSceneState' (which might retrieve current scene data) or 'loadScene' (which might load a specific scene). There's no mention of prerequisites, exclusions, or comparative context with sibling tools.
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 'Replace[s] the entire scene', implying a destructive mutation, but does not clarify if this action is reversible (e.g., via 'undo'), what happens to existing scene elements, or any side effects like requiring specific permissions. More context is needed for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action ('Replace the entire scene') without unnecessary words. Every part of the sentence contributes to understanding the tool's purpose.
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 destructive scene replacement with one parameter) and lack of annotations or output schema, the description is adequate but incomplete. It explains the basic action but omits important behavioral details like reversibility or effects on sibling tools (e.g., interaction with 'undo'), leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'previously exported scene JSON', which aligns with the 'sceneJson' parameter in the schema. Since schema description coverage is 100%, the baseline is 3, and the description adds minimal value beyond what the schema already provides (e.g., it doesn't specify JSON format details).
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 ('Replace the entire scene') with the resource ('previously exported scene JSON'), distinguishing it from siblings like 'loadSceneFromFile' (which likely loads from a file) and 'exportScene' (which exports rather than imports).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'loadSceneFromFile' or 'clearScene', nor does it mention prerequisites like needing a scene JSON from 'exportScene' first. It lacks explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool saves to a file and returns a path, but lacks details on permissions, error handling, or side effects (e.g., overwriting existing files). It adds basic behavioral context but is incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with zero waste: the first states the action and destination, the second specifies the return value. It is front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple parameter, the description covers the core purpose and return value adequately. However, as a mutation tool, it should provide more behavioral context (e.g., file overwriting, error cases) for better completeness.
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 100%, so the schema fully documents the 'name' parameter. The description adds no additional parameter semantics beyond implying file naming, aligning with the baseline when schema does the heavy lifting.
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 ('Save') and resource ('current scene'), specifying it saves to a JSON file in the scenes/ folder. It distinguishes from siblings like 'exportScene' or 'listScenes' by focusing on saving the current state locally, but doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'exportScene' or 'save' operations in other contexts. The description implies usage for persisting the current scene, but lacks context on prerequisites, timing, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool undoes changes and has a 20-level limit, but doesn't disclose critical behavioral traits such as whether it requires specific permissions, if it's reversible, what happens to nested changes, or error conditions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('undo the last scene change') and adds essential detail ('up to 20 levels') without any wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is incomplete. It lacks details on behavioral traits, error handling, and what the tool returns, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value by explaining the tool's scope (undoing scene changes up to 20 levels), which compensates for the lack of parameters in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('undo') and the resource ('last scene change'), specifying it can revert up to 20 levels. However, it doesn't explicitly differentiate from its sibling 'redo', which is a related but opposite operation.
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 after a scene change has occurred, but doesn't provide explicit guidance on when to use it versus alternatives like 'redo' or manual corrections. It mentions the 20-level limit, which offers some context but no clear exclusions or prerequisites.
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 describes the basic behavior (displaying a message in chat overlay) but lacks details on permissions needed, whether messages persist, rate limits, or how the overlay interacts with the user. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core purpose without unnecessary words. It is appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description covers the basic purpose but lacks behavioral details (e.g., message persistence, user interaction). It is minimally viable but has clear gaps in explaining how the tool behaves in the broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description does not add any additional meaning beyond what the schema provides (e.g., no examples of message format or sessionId usage). Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Display a message') and target resource ('in-world chat overlay visible to the user inside the 3D view'), distinguishing it from all sibling tools which involve object manipulation, scene management, or other functions rather than chat messaging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (displaying messages in a 3D view chat), but does not explicitly state when to use this tool versus alternatives like 'getPendingUserMessages' or 'clearPendingMessages'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool animates properties to target values with support for transforms and material effects, but does not disclose critical behavioral traits such as whether animations are interruptible, if they persist across scene changes, permission requirements, or error handling. The description is insufficient 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 appropriately sized and front-loaded, with a clear purpose statement followed by specific examples in a single, efficient sentence. Every part earns its place by directly supporting tool understanding without redundancy or waste.
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 (6 parameters, mutation operation) and lack of annotations and output schema, the description is moderately complete. It covers the core purpose and parameter context but misses behavioral details like animation control, persistence, or error responses. It is adequate for basic use but has clear gaps for advanced scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds marginal value by clarifying the purpose of 'property' with examples (e.g., 'material.* for glow/fade effects') and hinting at 'to' values for different property types, but does not significantly enhance parameter understanding beyond the schema. A baseline of 3 is adjusted to 4 due to the helpful contextual examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('animate') and resources ('object property'), and distinguishes it from siblings by focusing on property animation rather than creation, deletion, or other scene manipulations. It explicitly lists supported property types (transforms and material properties) and visual effects (pulsing glow, fading, color shifts).
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 through examples of supported properties and effects (e.g., 'material.* for glow/fade effects'), but does not explicitly state when to use this tool versus alternatives like 'stopAnimation' or 'updateObject' for direct property changes. It provides some context but lacks clear exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses technical implementation details (GPU-efficient point sprites) and behavioral traits like optional drift animation and twinkle effects, but doesn't mention performance implications of high particle counts, whether particles persist across scenes, or what happens on creation failure. It adds some context but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the purpose and examples, the second adds technical implementation and key features. No wasted words, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 14 parameters, no annotations, and no output schema, the description provides adequate purpose and technical context but lacks information about return values, error conditions, or performance constraints. It's complete enough for basic understanding but has gaps for a complex creation tool.
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 100%, so the schema already documents all 14 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 verb 'create' and the resource 'particle system', specifying it can create various types (stars, dust, sparks, snow, fire embers, laser trails). It distinguishes from siblings like createObject or createLight by focusing specifically on particle systems with GPU-efficient point sprites.
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 for creating visual particle effects with optional animations, but doesn't explicitly state when to use this versus alternatives like createObject for non-particle objects or updateParticles for modifying existing systems. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns messages 'the user has typed from inside the 3D environment' and should be called 'at the start of every turn,' which adds useful context about its role in a turn-based system. However, it doesn't describe potential side effects, error conditions, or what happens if no messages are pending, leaving some behavioral aspects unclear.
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 sentences that are front-loaded with the core purpose and followed by specific usage instructions. Every word contributes to understanding the tool's function and when to use it, with no wasted text or unnecessary details.
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 no annotations, no output schema, and 0 parameters, the description does a decent job by explaining what it returns and when to call it. However, it lacks details on the return format (e.g., structure of messages) and error handling, which could be important for an AI agent to use it effectively in a 3D environment context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on usage context. A baseline of 4 is applied since it avoids redundancy while adding value through usage guidance.
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: 'Return any in-world chat messages the user has typed from inside the 3D environment.' This specifies the verb ('return') and resource ('in-world chat messages'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'sendChatMessage' or 'clearPendingMessages', 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 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: 'Call this at the start of every turn to check for user input from the canvas.' This gives clear context for usage frequency and timing, which is helpful for an AI agent in determining when to invoke it versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool removes objects and resets lighting, indicating a destructive operation. However, it lacks details on permissions, reversibility (e.g., via undo), or effects on non-user objects, which are important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main action ('Remove all user-created objects') and includes an additional effect. Every word earns its place, with no redundancy or unnecessary elaboration.
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 (destructive reset), no annotations, and no output schema, the description is minimal but covers the core action. It lacks details on what 'user-created objects' entails, whether default lighting is configurable, or error conditions, making it adequate but with gaps for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it could have mentioned any implicit parameters or side effects, though not required. Baseline is 4 for zero 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?
The description clearly states the specific action ('Remove all user-created objects') and the resource ('from the scene'), and distinguishes it from siblings like deleteObject (which removes individual objects) or loadScene (which resets to a saved state). It also includes an additional effect ('reset default lighting'), making the purpose comprehensive and specific.
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 implies usage when a full scene reset is needed, distinguishing it from tools like deleteObject for selective removal. However, it does not explicitly state when not to use it or name alternatives, such as loadScene for reverting to a saved state, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool exports data (a read-like operation) and mentions the output format (JSON string) and its use case (storage/re-loading), but does not cover potential side effects, permissions needed, or error conditions. This is adequate but lacks depth for a tool with no annotation support.
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, well-structured sentence that efficiently conveys the action, output format, and purpose without any wasted words. It is front-loaded with the core functionality ('Export the current scene as a JSON string') and adds context succinctly.
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 no parameters, no annotations, and no output schema, the description provides basic completeness by explaining what the tool does and the output format. However, it lacks details on behavioral aspects like error handling or performance, which could be relevant for an export operation. It is minimally viable but has gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100% (empty schema). The description does not need to add parameter information, so it appropriately focuses on the tool's purpose and output. A baseline of 4 is given as it compensates for the lack of parameters by being clear about functionality.
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 ('Export') and resource ('the current scene'), and distinguishes it from siblings like 'exportStandaloneScene' by specifying the output format ('as a JSON string') and purpose ('can be stored and re-loaded later'). It avoids tautology by not just restating the tool name.
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 implies usage context by mentioning 'the current scene' and the purpose of storing/re-loading, which helps differentiate it from tools like 'saveScene' or 'loadScene'. However, it does not explicitly state when to use this tool versus alternatives like 'exportStandaloneScene', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the core action (capturing viewport) and output format (base-64 PNG data URL), and mentions the browser client requirement. However, it doesn't address potential limitations like viewport size constraints, performance implications, or error conditions.
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 concise with two sentences that each earn their place: the first specifies the action and output, the second states the prerequisite. No wasted words, and the most critical information (what it does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no annotations, and no output schema, the description provides adequate basic information about what the tool does and its prerequisite. However, it doesn't describe what the returned data URL looks like, potential size limitations, or error scenarios, leaving some contextual 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, and schema description coverage is 100%. The description appropriately doesn't discuss parameters since none exist. It focuses instead on the tool's behavior and prerequisites, which is the correct emphasis for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Capture the current 3D viewport') and output format ('return a base-64 PNG data URL'), distinguishing it from all sibling tools which manipulate scene objects, execute scripts, or manage scenes rather than capturing visual output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Requires a browser client to be connected'), establishing a prerequisite condition. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for similar functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that behaviors run continuously until removed, which is useful behavioral context. However, it omits details like performance impact, error conditions, or whether this requires specific permissions, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a concise list of behavior types with brief explanations. Every sentence adds necessary information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides good context on purpose and parameters. However, it lacks details on return values or error handling, which could be important for an agent invoking this 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?
Schema description coverage is 100%, so the baseline is 3. The description adds value by listing and briefly explaining the behavior types (spin, bob, orbit, lookAt, pulse), which helps interpret the 'type' parameter and 'params' object beyond the schema's technical details.
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 verb ('attach') and resource ('continuous frame-tick behavior to an object'), specifying it runs every frame until removed. It distinguishes from siblings like 'animateObject' by focusing on continuous behaviors rather than one-time animations, and from 'removeBehavior' as its inverse.
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 implies usage for attaching continuous behaviors, with context from sibling tools suggesting alternatives like 'animateObject' for discrete animations. However, it lacks explicit when-not-to-use guidance or direct naming of alternatives, such as not using this for one-time effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates the tool performs a deletion/clearance action ('Clear all queued messages'), which implies mutation, but does not specify if this is reversible, requires permissions, or has side effects. It adds some context about batch processing but lacks details on error handling or confirmation.
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, well-structured sentence that front-loads the core action ('Clear all queued in-world user messages') and adds a brief usage note. Every word earns its place, with no redundancy or unnecessary elaboration, making it highly 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 the tool's complexity (simple mutation with 0 parameters), no annotations, and no output schema, the description is reasonably complete. It explains what the tool does and when to use it, but could improve by addressing behavioral aspects like irreversibility or error conditions, which are relevant 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is applied as it efficiently handles the zero-parameter case.
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 ('Clear') and resource ('all queued in-world user messages'), distinguishing it from siblings like 'getPendingUserMessages' (which retrieves messages) and 'clearScene' (which clears scene objects). It uses precise terminology that directly conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage ('useful after processing a batch'), which implies it should be used post-processing rather than during or before. However, it does not explicitly state when NOT to use it or name specific alternatives, keeping it from a perfect score.
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 well: it discloses that the tool creates a file ('Saved to the scenes/ folder'), specifies what's included ('all objects, lights, materials, animations, camera, and environment'), excludes chat UI, and mentions the return value ('Returns the file path'). It doesn't cover potential errors or file size limitations, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in three sentences: first states the core action and key features, second specifies the output location and exclusion, third declares the return value. Every sentence adds essential information with zero waste, making it easy to parse.
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?
For a single-parameter tool with no annotations and no output schema, the description provides strong completeness: it explains what the tool does, what's included/excluded, where files are saved, and what's returned. The main gap is lack of explicit error handling or limitations information, but it covers most essential context given the tool's complexity.
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 100% for the single parameter 'name', which is documented in the schema as 'File name (without .html extension). Defaults to a timestamp-based name.' The description adds no additional parameter information beyond what the schema already provides, meeting the baseline for high schema coverage.
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 ('Export the current scene as a standalone HTML file') and resource ('current scene'), distinguishing it from sibling tools like 'exportScene' (which likely exports in a different format) and 'saveScene' (which saves scene state rather than creating a browser-playable file). It precisely defines what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to create a browser-playable HTML file from the current scene. It implicitly distinguishes from alternatives like 'exportScene' (likely server-dependent) by specifying 'without a server', but doesn't explicitly name when not to use it or list all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a read operation ('Get') and implies it returns comprehensive scene data, but lacks details on response format, potential size limitations, or error conditions. The description adds some context about workflow sequencing but doesn't fully compensate for the absence of 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?
The description is two concise sentences with zero waste. The first sentence states the purpose clearly, and the second provides crucial usage guidance. Every word earns its place, and information is front-loaded effectively.
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 returning 'full current scene state' with multiple components, no annotations, and no output schema, the description is somewhat incomplete. It explains what the tool does and when to use it but doesn't describe the return format or potential limitations. However, the zero parameters and clear purpose partially mitigate this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and usage. A baseline of 4 is appropriate for zero-parameter tools when the schema coverage is complete.
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 explicitly states the verb 'Get' and specifies the resource as 'full current scene state' with detailed components: 'all objects, lights, camera, and environment'. It clearly distinguishes this read operation from sibling tools that modify the scene (e.g., createObject, deleteObject, updateLight).
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: 'Call this first before making any changes', which clearly indicates when to use this tool versus alternatives. This establishes a prerequisite for modification operations, helping the agent understand the proper sequence in a workflow.
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. It discloses key behavioral traits: it's a write operation ('Add'), it returns a value ('Returns the assigned id'), and it has a prerequisite workflow. However, it doesn't mention potential side effects like scene performance impact, whether duplicates are allowed, or error conditions for invalid parameters.
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 with zero waste. The first sentence states the core purpose and return value. The second provides crucial usage guidance. Every word earns its place, and the most important information is front-loaded.
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?
For a complex creation tool with 16 parameters, no annotations, and no output schema, the description provides good foundational context. It covers the core purpose, return value, and a critical prerequisite. However, it could better address the complexity by mentioning parameter dependencies or common usage patterns given the extensive parameter set.
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 94%, so the schema already documents most parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting, though the description could have explained parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a 3D object') and the target ('to the live scene'), specifying the resource being created. It distinguishes from siblings like 'createLight' or 'createParticles' by focusing on 3D objects, and from 'cloneObject' by creating new rather than copying existing objects.
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: 'Always call getSceneState first to understand what already exists.' This gives a clear prerequisite and distinguishes when to use this tool versus alternatives like 'updateObject' or 'cloneObject' that modify existing objects.
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 execution environment ('runs inside an async function with access to: scene (THREE.Scene), camera, renderer, controls, and a helpers object'), the return mechanism ('Return a value to send it back'), and the general capability scope. It doesn't mention security implications, error handling, or performance limitations, but provides substantial operational context.
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 three sentences: the core functionality, the execution context details, and the usage guidelines. Every sentence adds essential information with zero wasted words, making it easy to parse and understand.
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?
For a powerful tool with no annotations and no output schema, the description provides strong context about the execution environment, return mechanism, and appropriate use cases. It could be more complete by mentioning potential risks of arbitrary code execution or error behavior, but it covers the essential operational aspects well given the complexity.
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 input schema has 100% description coverage, thoroughly documenting the single 'code' parameter with examples and context. The description adds no additional parameter information beyond what's already in the schema, so the baseline score of 3 is appropriate when the schema does the heavy lifting.
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 ('Execute arbitrary JavaScript code') and the resource ('in the connected browser scene context'), distinguishing it from all sibling tools which perform specific predefined operations rather than allowing arbitrary code execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 ('Use this for advanced effects the other tools cannot achieve — custom shaders, complex geometry, procedural generation, physics, etc.') and implicitly suggests when not to use it (for effects achievable through other sibling tools).
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:

[![mcp-webgpu MCP server](https://glama.ai/mcp/servers/m-ai-geXR/mcp-webgpu/badges/card.svg)](https://glama.ai/mcp/servers/m-ai-geXR/mcp-webgpu)

Score Badge

Copy to your README.md:

[![mcp-webgpu MCP server](https://glama.ai/mcp/servers/m-ai-geXR/mcp-webgpu/badges/score.svg)](https://glama.ai/mcp/servers/m-ai-geXR/mcp-webgpu)

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/m-ai-geXR/mcp-webgpu'

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